درحال مشاهده: مهندسی و مدیریت ساخت پروژه - مطالب ابر مدیریت منابع انسانی

22.jpg (364×96)11.jpg (364×96)

ادعونی
اهدای خون
موسسه محک
اهداء عضو

اهمیت کاربرد ساختار شکست کار (WBS) در پروژه ها

-
-
امیرحسین ستوده بیدختی
اهمیت کاربرد ساختار شکست کار (WBS) در پروژه ها

نویسنده : فریدون فرداد

در دهه‌های گذشته و در کشورهای مختلف دنیا، پروژه‌های زیادی با مالکیت‌های گوناگون،‌ حیطه زمانی متفاوت و با بکار بردن حجم‌های مختلفی از منابع مالی، اجرا شده است. اجرا و تکمیل پروژه‌ها، تلاش زیاد و قابلیت‌های فنی و تخصصی مدیران پروژه را می‌طلبیده است. کاربرد کامپیوترهای کوچک و شخصی (PC) ابعاد دیگری از استفاده ابزار موثر، در روند مدیریت پروژه بوده است. 

این نوشته بر این امر تاکید دارد که طراحی صحیح و کاربرد ساختار شکست کار Work Breakdown Structure (WBS) با نظام کدینگ و استفاده از واژه‌های مشخص، مبنای موثری برای کنترل نظام های پروژه، خط‌مشی‌ها و روش‌ها  برای کلیه پروژه‌ها است. ساختار شکست کار به سازماندهی، برنامه‌ریزی کلیه مراحل پروژه کمک می‌کند. مدیریت پروژه و کلیه افرادی که در اجرای عملیات و مدیریت و کنترل درگیر هستند، در مراحل مختلف اجرای کار به اطلاعات دقیق و مفید نیاز دارند. یک ساختار شکست کار خوب طراحی شده، مبنایی برای تنظیم مناسب سیستم اطلاعاتی برای کنترل پروژه در اجرای عملیات را فراهم می‌کند.

 

تعریف ساختار شکست کار:

 

ساختار شکست کار را می‌توان بدین ترتیب تعریف کرد:

یک ساختار شبکه‌ای یا درختی به صورت گرافیکی است برای نشان دادن روش تولید محصول یا خدمت شامل، بخش‌های سخت‌افزار، نرم‌افزار، خدمات و سایر وظایفی که یک سازمان یا شرکت انجام می‌دهد مانند کارهایی که باید انجام شود تا یک محصول یا خدمت مشخص تولید و یا ارایه شود.

در این تعریف منظور از «کارهایی که باید انجام شود» انجام و اتمام یک پروژه با بودجه و زمان مشخص است. تدوین ساختار شکست کار به عنوان یک نظام کاری، برای اطمینان از مشارکت‌کنندگان در اجرای پروژه، اعم از کارفرما، پیمانکاران/فروشندگان است که همگی بدانند چه عملیاتی برای تکمیل پروژه مورد نیاز است.

استفاده از ساختار شکست کار به عنوان یک شالوده اطلاعاتی، برقراری ارتباط صحیح در باره پروژه را برای گروههای کاری و سازمانهای حکومتی ناظر بر پروژه و سایر فرآیندهای قانونی، از طریق کاربرد یک مبنای مشترک، تسهیل می‌کند.

 

کاربران ساختار شکست کار

در اجرای پروژه‌های بزرگ، علاوه بر کارکنان پروژه، عواملی چون سرمایه‌گذاران،‌ تامین‌کنندگان مالی، پیمانکاران، در بعضی موارد سازمانهای دولتی و موسسات با دانش تکنولوژیکی پیچیده،‌دخالت و مشارکت دارند که بیشتر از گذشته به اطلاعات چندگانه و متمرکز نیاز دارند.

رعایت الزامات حکومتی و مقررات قانونی و مسوولیت نظارتی سازمانها، به اطلاعات و زبان مشترک نیاز دارند. فلسفه ایجاد کد برای هر یک از عملیات در WBS و متدولوژی آن، می‌تواند این نیاز اطلاعاتی کلیه مراجع و واحدها را مرتفع کند.

در حقیقت در اجرای پروژه، ساختار شکست کار یک داده و زبان مشترک است و ابزاری برای برقراری ارتباط بین کاربران مختلف در پروژه است که کاربرد موثری دارد.

در تامین داده‌های مورد نیاز برای تدوین ساختار شکست کار، دو گروه شامل گروه عملیاتی پروژه و گروه‌های حاکمیتی و مسوول دخالت دارند. گروه‌های عملیاتی شامل، طراحی و مهندسی، ساخت و اجرا، مدیریت مالی، اداری و تامین تجهیزات و گروه‌های حاکمیتی و مسوول مانند، کارفرما/صاحب‌کار، سازمانهای دولتی و پیمانکاران هستند.

یک ساختار شکست کار خوب طراحی و تدوین شده، گروه‌های عملیاتی و مسوول را قادر می‌سازد که ارتباطات دقیق و منظمی با هم داشته باشند.

 

داده‌های اولیه برای تهیه WBS

برای تهیه یک ساختار شکست کار کامل و بدون نقص، داده‌ها و مواد اولیه باید گردآوری شود. این داده‌ها که در زمینه‌های مختلف است به قرار زیر هستند:

 

بودجه: نحوه و مقدار تامین مالی و جریان نقدینگی (Cash Flow) سالیانه را مشخص می‌کند.

برآورد هزینه: میزان هزینه‌های پروژه را بر مبنای تامین خدمات فنی و مهندسی، تامین کالا و تجهیزات و هزینه‌های ساخت، اجرا و نصب و راه‌اندازی را تعیین می‌کند.

بهره‌وری: نرخ بهره‌وری مورد انتظار برای عوامل درگیر در اجرای پروژه عامل مهمی در تدوین ساختار شکست کار است.

زمان‌بندی: جدول و برنامه‌ زمان‌بندی و ترتیب انجام فعالیت‌های پروژه از ابتدای کار تا خاتمه پروژه عامل مهمی در تعیین روش کار است.

منابع: برای اجرای پروژه از منابعی مانند سرمایه، ماشین‌آلات، ‌تجهیزات، نیروی انسانی و مواد مصرفی استفاده می‌شود که اطلاعات آنها برای تدوین ساختار شکست کار ضرورت دارد.

 

پس از آنکه کلیه داده‌های پیش گفته فراهم شد، آنگاه کارشناسانی که ساختار شکست کار را تنظیم می‌کنند، کلیه ردیف‌ها و رده‌های عملیاتی را تعریف و تدوین می‌کنند. این تعاریف علاوه بر آنکه کلیه عوامل را قادر می‌سازد که حول یک شالوده مشترک اقدام و حرکت کنند، موجب ارتباط سه جانبه هزینه، زمان‌بندی و بهره‌وری بر محور ثابت و در نهایت باعث اندازه‌گیری مناسب پیشرفت کار و کنترل پروژه می‌شود.

گردآوری مجموعه اینگونه اطلاعات بر مبنای مشترک، در مورد قابل قیاس بودن عملیات انجام شده با خطوط مبنای معین، اطمینان ایجاد می‌کند. اطلاعات حاصل از گروه‌های مختلف، علاوه بر آنکه در تهیه بودجه، زمان‌بندی و برآورد هزینه‌ها کاربرد دارد در تدوین خطوط مبنای برآورد هزینه و زمان‌بندی ساخت و اجرا موثر است.

بنابراین ساختار شکست کار از مرحله شروع تا انتهای پروژه در برنامه‌ریزی،‌اجرا و کنترل و اصلاح بکار می‌رود. ساختار شکست کار ابزاری است برای کلیه کاربران پروژه تا بر تامین خدمات و تجهیزات، اجرا و اتمام موفقیت‌آمیز پروژه نظارت و کنترل داشته باشند.

 

ترکیب سیستم‌ها – کاربرد WBS

عوامل و سیستم‌های اجرا و کنترل پروژه از قبیل، زمان‌بندی، برآورد، سنجش پیشرفت و عملکرد، نیروی انسانی، تامین تجهیزات، پایش و کنترل هزینه‌ها و سایر نظام‌ها به اطلاعات نیازمند است. انتقال اطلاعات بین واحدهای مختلف پروژه و سایر سازمانهای مرتبط با پروژه، باید به صورت صحیح عملکرد داشته باشد تا اطلاعات لازم بین واحدها و سیستم‌های فرعی به موقع و دقیق انتقال یابد سیستم کنترل پروژه چه به صورت دستی و چه به صورت خودکار و ماشینی،‌به عنوان سیستم جمع‌آوری به موقع اطلاعات اجرایی و به جریان انداختن این نوع اطلاعات از طریق تنظیم گزارش‌های مختلف و ارایه پیش‌بینی‌ها به مدیر پروژه به مقدار زیادی به ساختار شکست کار مناسب و کاربردی نیاز دارد.

 

ایجاد و توسعه ساختار شکست کار

وقتی با استخراج از برنامه‌ زمان‌بندی کلی کارفرما/صاحب‌کار، برنامه اجرایی تفضیلی پروژه تهیه شد، در رابطه با عناصری که برای اجرای کار مورد نیاز است، ساختار شکست کار تعریف می‌شود.

عوامل اصلی ساختار شکست کار شامل:

1- ساختار

2- شماره‌گذاری فعالیت‌ها(کدینگ)

3- گزارش‌دهی

شیوه طراحی WBS و توسعه و تکامل آن، به دیدگاه و فلسفه مدیریت پروژه ارتباط پیدا می‌کند.

 

ساختار

برای تهیه ساختار شکست کار پروژه معمولاً کل فعالیت‌های پروژه به طریق سلسله مراتبی به سطوح مختلف‌کاری تقسیم می‌شود در سطح اول پروژه اصلی به چند پروژه یا سیستم فرعی مطرح می‌شود. در سطح‌ بعدی عنوان هر یک از پروژه‌های فرعی به چند فعالیت اصلی تقسیم می‌شود و در مرحله بعدی هر یک از فعالیت‌های اصلی به چندین فعالیت فرعی‌تر تقسیم می‌شود و این تقسیم‌بندی تا حدی ادامه می‌یابد که آخرین فعالیت‌ها دارای معنی و مفهوم اجرایی و عملیاتی باشد. به عبارت دیگر فعالیت‌ها باید به حدی تقسیم و جزیی شود که قابل سنجش و اندازه‌گیری باشند.

 

همانطوری که در تقسیم سطوح کاری پروژه فرضی ایستگاه گاز ملاحظه می‌شود، پروژه به چهار سطح کاری تقسیم شده است. در سطح اول، پروژه اصلی به 5 پروژه فرعی یا فعالیت اصلی تقسیم شده است. در سطح دوم، هر یک از پروژه‌های فرعی به چندین فعالیت تفکیک می‌شود. (ممکن است بطور مثال شامل 15 فعالیت و کمتر یا بیشتر باشد) که یکی از فعالیت‌های منشعب از پروژه فرعی خطوط لوله، خط اصلی است. در سطح سوم، فعالیت خط اصلی به دو فعالیت، کالا و مواد و نصب تفکیک شده است. در سطح چهارم، هر یک از فعالیت‌های کالا و مواد و نصب به پنج فعالیت جزیی تقسیم شده است که در آخرین سطح اجرایی و عملیاتی تعریف شده است.

بنابراین WBS با یک ساختار سلسله مراتبی یا اصطلاحاً درختی تنظیم می‌شود، به صورتی که در پایین‌ترین سطح اطلاعات با جزییات اجرایی ارایه می‌شود. پایین‌ترین سطح به حالتی است که کاربر می‌تواند نیاز به تبادل اطلاعات و پایش کارها را پیش‌بینی کند. سطوح بالاتر ساختار اطلاعات کلی‌تر را برای مدیران میانی و مدیر پروژه ارایه می‌دهد. به طور کلی برای ساختار کار می‌توان تا بیست سطح هم تعریف کرد ولی برای اغلب پروژه‌ها چهار الی شش سطوح مناسبی است. برای ساختار باید شیوه جریان اطلاعات از بالا به پایین مشخص شود.

ساختار شکست کار باید به بسته کاری و فعالیت‌هایی با در نظر گرفتن مشخصات و موارد زیر تهیه و تدوین شود:

 

قابل تعریف: فعالیت قابل توضیح بوده و برای کاربران به سادگی قابل درک و فهم باشد.

قابل سرپرستی و انجام بودن: یک واحد کاری با معنی و با مسوولیت مشخص و اختیار اجرای آن قابل واگذاری به یک فرد باشد.

قابل برآورد بودن: مدت اجرا و زمان لازم برای اتمام کار و هزینه و منابع مورد نیاز قابل برآورد و تخمین باشد.

استقلال: هر فعالیت حداقل فصل مشترک با سایر فعالیت‌ها را داشته و به صورت یک فعالیت مستقل قابل اجرا و کنترل باشد.

قابلیت تلفیق: فعالیت یا بسته کاری به نحوی تعریف شود که با سایر فعالیت‌ها هر پروژه فرعی قابل تلفیق و ترکیب نهایی باشد.

قابلیت اندازه‌گیری: پیشرفت اجرای فعالیت یا بسته کاری قبل سنجش بوده وزمان شروع و خاتمه آن مشخص شود.

 

ساختار به نحوی تعیین و طراحی می‌شود که کدگذاری فعالیت‌ها امکان‌پذیر بوده از طرف دیگر کدها برای کاربران مفهوم و معنی‌دار باشد. به عبارت دیگر کاربر باید بتواند WBS را ابزاری تسهیل‌کننده تشخیص داده و وقتی از حوزه و حیطه کاری خود خارج می‌شود، این امر برایش قابل درک باشد.

 

طراحی کد

طراحی کد برای ساختار شکست کار، بخش مهمی از ساختار شکست کار است. کدینگ در ساختار شکست کار، ابزاری است که بخش‌های مالی و اجرایی و کنترل پروژه از آن استفاده‌های زیادی می‌برند یک سیستم کدینگ موثر و با معنی به همه کاربران برای انجام درست کارها کمک می‌کند.

برای طراحی کد ابتدا باید اطلاعات لازم گردآوری شده و اطلاعات مورد تجزیه و تحلیل قرار گیرد سپس نسبت به کدگذاری فعالیت‌ها اقدام شود. کد از تعدادی ارقام که نشانگر یک فعالیت در یک سطح است تشکیل شده است. اگر پروژه‌های فرعی و یا سیستم‌های اصلی پروژه از 9 تا کمتر باشد از اعداد یک رقمی و اگر تعداد از 9 تا بیشتر باشد از اعداد دو رقمی استفاده می‌شود. در سطوح بعدی متناسب با تعداد فعالیت‌ها کد تخصیص می‌یابد و در هر سطح کد سطوح بالاتر تکرار می‌شود.

 

گزارش‌دهی

در طراحی ساختار شکست کار، لازم است کلیه سطوح پروژه از مدیریت ارشد گرفته تا پایین‌ترین سطوح اجرایی مدنظر قرار گیرند. ساختار شکست کار باید به نحوی طراحی شود که کلیه گزارش‌های لازم و برای کلیه سطوح به صورت خودکار تولید و ارایه شود. توجه و دقت به نیاز گزارش‌دهی و انواع آن، در زمان طراحی و تدوین ساختار شکست کار، به تامین نیازهای مدیریت و سایر سطوح به گزارشها، کمک و مساعدت زیادی خواهد کرد.

 

هماهنگی بین ساختار، کدینگ و ضرورت گزارش‌دهی

تدوین و طراحی صحیح WBS به ترکیب و تلفیق سه عامل ساختار، کد و ضرورت گزارش‌دهی نیاز دارد. بطور کلی شرح محدوده کار پروژه، تصویری از ساختار شکست کار را فراهم می‌کند.

انجمن مهندسی و مدیریت ساخت ایران (ICEMA) Iran Construction Engineering Management Association

در ابتدا، مهم است که دیدگاههای آتی مدیران درباره پروژه مورد بررسی قرار گیرد. ساختاری که تدوین می‌شود باید ساده، شفاف و با مفهوم باشد سپس این ساختار نهایی شده باید با کدینگ تلفیق شود. نمونه گزارشها هم استخراج شده و برای نظرخواهی به کاربران اصلی داده شود و پس از نهایی شدن فرمت گزارشها، ساختار شکست کار کامل می‌شود و به واحدهای مختلف ابلاغ خواهد شد و در صورت نیاز به شرح و توضیح، این امر توسط طراح و تدوین‌کننده ساختار شکست کار برای افراد یا کارشناسان مربوطه انجام می‌شود.


7 قانون برای تضمین شکست پروژه

-
-
امیرحسین ستوده بیدختی

7 قانون برای تضمین شکست پروژه
رعایت قوانین زیر، شکست کامل پروژه شما را تضمین می کند؛ می توانید با مسئولیت خود، آنها را امتحان کنید!
فقط تحویل دهی.
به خاطر داشته باشید که وظیفه اصلی شما تحویل دادن نتایج در موعدهای مقرر است. آنقدر توجه خود را به این مسئله معطوف دارید که مسائل فرعی مانند تضمین کیفیت، تست ها، ارتباطات، مدیریت تیم و داشتن کمی مروت را از یاد ببرید.
برنامه ریزی، کاری عبث.
از آنجا که شما از همکاری مشاوران و طراحان بسیار زیرکی برخوردار هستید، نیازی نیست که هزینه های بالاسری برنامه ریزی و کنترل پروژه را متحمل شوید.
تیم خود را به کار بیشتر وادار کنید.
رمز موفقیت برای تحویل دادن به موقع نتایج تحت بودجه مقرر، آن است که تا می توانید افراد تیم را به کار بیشتر وادار نمایید؛ به جای استخدام افراد بیشتر، مقداری قهوه بخرید و به اعضای تیم بدهید تا کمتر بخوابند و بیشتر کار کنند. به خود اجازه بدهید که در تمامی جزئیات کار آنها دخالت کنید.
بازندگان به ارتباطات توجه می کنند.
همه گروه ها باید با موضوعات مدیریت پروژه آشنا باشند. اگر کسی توضیح بیشتری از شما خواست، از یک پادو بخواهید که مقدار زیادی مدارک و مستندات تهیه کند؛ البته هیچ اهمیتی ندارد که این مستندات، بیانگر مطلبی نباشند.
تشکیل جلسات، بسیار مهم است؛ بکوشید حداقل روزی 4 یا 5 جلسه با اعضای تیم خود تشکیل دهید. تهیه دستور جلسه، چیزی جز اتلاف وقت نیست؛ پس از تشکیل جلسه از افراد بپرسید که در مورد چه موضوعی مایلند صحبت کنند. اگر کسی جرأت کرد در مورد طرح پروژه از شما سؤال کند، به او پرخاش کنید.
اجرای یک مرحله ای.
وقت خود را برای اجرای مرحله به مرحله پروژه تلف نکنید؛ همانگونه که جهان یک باره خلق شد، شما نیز پروژه خود را در یک مرحله بزرگ به اجرا درآورید. شما همواره فرصت بازگشت و جبران خطاهای خود را خواهید داشت. مهم آن است که اقلام قابل تحویل را به موقع تحویل دهید.
استفاده از شعور حسی.
واقعاً نیازی نیست که با تمامی مفاهیم مرتبط با نمودار گانت، ساختارهای شکست، تجزیه و تحلیل هزینه ها و ... آشنا باشید؛ شعور حسی شما کفایت می کند. فقط تعداد زیادی افراد زیرک را در پروژه به کار بگمارید، آنها را وادار کنید روزی 20 ساعت کار کنند، و منتظر شوید تا اقلام قابل تحویل، آماده شوند.
برخورد درست با کارفرما.


هرکاری از دستتان برمی آید بکنید تا تمامی خواسته های کارفرما را برآورده سازید، صرف نظر از اینکه ممکن است این خواسته ها عاقلانه نباشند یا پروژه شما را با تأخیر مواجه سازند. تنها کافی است به افراد تیم خود فشار بیشتری وارد کنید تا از آخرین باقیمانده های انرژی خود نیز استفاده کنند.


Delegation and Escalation

-
-
امیرحسین ستوده بیدختی

No one likes being micromanaged. When you do so, and when you fail to delegate, you will face multiple problems, including:

  • You won’t have enough time for more important things
  • You’re not using the potentials in your team
  • You’ll miss the buy-in of team members

We should delegate. However, there are also some problems with delegation. Most notably, sometimes important decisions are made in lower levels of hierarchy, where people do not have the required high-level understanding.

The fifth core principle is Manage by Exception.

It provides you with a structured system of delegation and escalation. We recognize the project targets (time, cost, scope, quality, etc.) and define tolerances for each level. For example, we say that the team leader is responsible for making decisions that do not have monetary consequences larger than €10,000. Then, if the monetary consequence is lower than that, we expect the higher manager to let the team leader handle it, and when it’s higher, we expect the team leader to escalate it to the higher level.

That’s it for the fifth principle. Let’s move on to the next one… for tomorrow of course. My question this time is: what should be your focus, the work, or the product? What’s the consequence of each approach?


چگونه اثربخشی برنامه ریزی و کنترل را در پروژه تضمین کنیم؟

-
-
امیرحسین ستوده بیدختی

چگونه اثربخشی برنامه ریزی و کنترل را در پروژه تضمین کنیم؟
این صحنه را تصور کنید؛ در جلسه هفتگی همراه با دیگر دست اندرکاران پروژه مشغول ارزیابی عملکرد سازمان های مختلف هستید. شما به عنوان برنامه ریز و کنترل کننده همان برنامه، مغایرتها را به دیگران تذکر می دهید: "شما قرار بوده این فونداسیون را دو روزه تمام کنید ولی اینک یک هفته می گذرد و همچنان ناتمام مانده است!"
پاسخ می آید:"معلوم است که این مدت باید طول بکشد. بچینگ به دلیل خرابی یک قطعه سه روز است که از کار افتاده و به هر دری می زنیم نمی توانیم قطعه یدکی را پیدا کنیم. اگر می توانید در این زمینه به ما کمک کنید."
شما در جواب ادامه می دهید:" آخر این هم شد دلیل؟ خوب تا بچینگ راه بیفتد می رفتید از سایت همسایه مقداری بتن قرض می کردید، بعد برمی گرداندید. آقا مثل اینکه شما این کاره نیستید! این که مشکل حساسی نیست."
پیمانکار می گوید:"اصلاً سیمان در منطقه نایاب شده، چون نزدیکترین کارخانه سیمان به علت تعمیرات اساسی، کوره خود را خاموش کرده و اگر بخواهیم از جای دیگر سیمان تهیه کنیم دو برابر قیمت را باید پرداخت کنیم. این مشکل فقط با دخالت کارفرما حل می شود."
بحث بالا می گیرد و هر یک از طرفین به ابراز نظر ادامه می دهند. نهایتاً شما که برنامه ریز هستید می پرسید:"بالأخره کی کار را تمام می کنید؟"
پاسخ می آید:"اگر امکانات اجازه دهد تا اول هفته آینده."
شما در پایان می گویید: "دفعه بعد نیایید و همین موضوعات را به ما تحویل دهید. آقا این پروژه را مدیریت کنید."
در سناریوی بالا چه اتفاقی افتاد؟ کار ساخت یک فونداسیون به تعویق افتاد و موضوعات متعدد بدون تعیین عواقب معلق ماندند. اشکال کار کجاست؟ اشکال اصلی این کار در این است که برنامه ریز به وظایف عملیات خود آشنا نیست. برنامه ریز برای اینکه به پیمانکار اثبات کند حداقل به اندازه وی به دانش ساخت فونداسیون آشناست به جای اینکه دغدغه برنامه را داشته باشد به بحث راجع به مسائل فنی می پردازد. شاید به این طریق می خواهد پیمانکار را از زدن انگ اینکه "برنامه ریز با امور پروژه آشنا نیست" بازدارد. اما این، کار برنامه ریز و کنترل کننده همان برنامه نیست. بسیار خوب، پس از عارضه یابی بهتر است بگوییم که کار برنامه ریز چیست.
برنامه ریز و کنترل کننده پروژه باید کارهای زیر را انجام دهد:
برنامه ریزی پروژه
پایش پروژه به صورت دوره ای در سطوح متناظر برنامه
کنترل پروژه به صورت دوره ای در سطوح متناظر برنامه
محاسبه اثربخشی اجرای برنامه بر پروژه
تعیین عواقب اجرای کار بر برنامه
همانگونه که مشاهده می نمایید برنامه ریز پروژه، اولین مدافع و نگاه دارنده برنامه در پروژه محسوب می شود. برای مباحث فنی و مهندسی، ناظرین حضور دارند. اما قبل از نتیجه گیری، یک موضوع دیگر را نیز باید به این بحث اضافه کنیم و آن، فلسفه تسهیم ریسک برنامه است. توجه کنید که هر برنامه ای با ریسک مواجه است. یعنی اینکه با احتمالی آنچه پیش بینی شده است، اتفاق نمی افتد. این ماهیت برنامه است، در غیر این صورت برنامه ریزی به جای پیش بینی به پیشگویی می پرداخت.
اما ریسک را چگونه مدیریت کنیم؟ قدم اول این است که روش تسهیم ریسک را تعریف کنیم. مثلاً می توانیم فعالیت های مربوط به یک برنامه را به قدری دقیق تعریف کنیم که هر فعالیت دارای یک مجری باشد. در آن صورت توافق می کنیم که چنانچه به هر دلیل مجری نتواند فعالیت را در زمان مقرر انجام دهد، به میزان معینی خسارت بپردازد. این مجری می تواند در بدنه کارفرما باشد یا پیمانکار یا مشاور یا مدیریت. نحوه تسهیم ریسک برنامه در قرارداد پروژه باید ذکر گردد تا برنامه پروژه دارای تضمین اجرایی باشد. با توجه به این موضوع و قدم هایی که در بالا به آنها اشاره شد، سناریوی اول این نوشتار به این صورت بازنویسی می گردد:
برنامه ریز: "قرار بوده که امروز ساخت فونداسیون به اتمام برسد ولی هنوز تمام نشده است. این را مدارک ما و ناظرین پروژه شهادت می دهند (قدم 1)."
پیمانکار: "درست است ولی بچینگ ما سه روز است که خراب است."
برنامه ریز: "بسیار خوب، شما 3 روز در اجرای این فعالیت تأخیر دارید (قدم 2). این عقب ماندگی پیشرفت پروژه را در این دوره 2/0 درصد کاهش خواهد داد (قدم 3). این 2/0 درصد به واحد امور قراردادها عرضه خواهد شد تا در صورتحساب شما برای این دوره منظور گردد (قدم 4). باید زمان جدید در برنامه دوره آینده منظور شود (قدم 5)."
همانگونه که مشاهده می کنید تمامی صحبت ها در زمان کنترل برنامه در سناریوی دوم در مورد برنامه است نه در مورد ساخت فونداسیون، آنگونه که در سناریوی اول به آن پرداخته شده است.

مغایرت اجرا با برنامه نباید به ابزاری برای تحقیر تبدیل گردد. در عین حال برنامه ریز نباید به جای پرداختن به موضوع اصلی کارش، که همانا حراست از برنامه و پروژه است، به موضوعات فرعی (فرعی در محدوده برنامه ریزی) بپردازد و از موضوع اصلی فاصله بگیرد. با درج شیوه تسهیم ریسک برنامه، به صورت تفصیلی، در قرارداد هم زمینه تضمین اجرای برنامه فراهم خواهد شد.

چگونه اثربخشی برنامه ریزی و کنترل را در پروژه تضمین کنیم؟


مهندسی و مدیریت ساخت پروژه - مطالب ابر مدیریت منابع انسانی

مهندسی و مدیریت ساخت پروژه - مطالب ابر مدیریت منابع انسانی,مدیریت ساخت ,مدیریت پروژه, مدیریت پروژه های ساخت, مدیریت پروژه و ساخت,مدل سازی اطلاعات ساختمان,مدیریت ساخت
تمامی حقوق این وب سایت متعلق به مهندسی و مدیریت ساخت پروژه است. |طراحی و توسعه:امیرحسین ستوده بیدختی|