PMP , مدیریت پروژه

هفت تغییر اساسی در ویرایش ششم PMBOK در مقایسه با نسخه پنجم

در حال مطالعه نسخه جدید PMBOK یعنی ویرایش ششم بودم و تغییراتش را نسبت به نسخه قبلی مقایسه می‌کردم که دیدم بهتر است این تغییرات را اینجا یادداشت کنم تا هم ذهن خودم منظم‌تر شود و هم شما استفاده کنید. (توجه: تمامی مطالب زیر برداشت‌های من از نسخه ششم است و شاید برداشت اشتباهی هم این بین باشد که ممنون خواهم شد اگر عنوان نمایید)

توجه: اگر احیاناً این مطلب در صفحه اول وب سایت، یا کانال تلگرام می‌خوانید، برای مشاهده کامل مطلب و تصاویر و عکس‌ها باید به لینک اصلی مطلب مراجعه کنید.)

ویرایش ششم PMBOK که امسال منتشر شد، هفت تغییر اساسی با نسخه قبلی یعنی ویرایش پنجم دارد:
این هفت تغییر اساسی در نسخه ششم به شرح زیر است:
۱- تغییر مجموع تعداد فصول کتاب PMBOK
۲- تغییر اسامی دو حوزه دانش
۳- اضافه شدن سه فرآیند جدید به مجموع فرآیندها و حذف یک فرآیند
۴- تغییر اسامی برخی از فرآیندها
۵- اضافه شدن اجایل به نسخه ششم
۶- تغییرات در ورودی‌ها، خروجی‌ها، تکنیک‌ها و ابزارها (ITTO)
۷- سایر تغییرات

در ادامه به صورت مختصر به هر کدام از این تغییرات می پردازم:

۱- تغییر مجموع تعداد فصول کتاب PMBOK

ساختار این راهنما اکنون به سه بخش تقسیم شده است:
۱- راهنمای کتاب مدیریت دانش پروژه (راهنمای PMBOK®)
۲- استاندارد مدیریت پروژه (The Standard for Project Management)
۳- پیوست‌ها، واژه‌نامه و فهرست (Appendices, Glossary, and Index)
در نسخه ششم مقدمه (فصل ۱)، فرآیندهای مدیریت پروژه (فصل ۳) و ضمیمه A1 نسخه پنجم در حال حاضر در بخش دوم (استاندارد مدیریت پروژه) منتشر شده است.

فصل نقش مدیر پروژه (PM ROLE) به ویرایش ششم اضافه شده است. نقش مدیر پروژه، بخشی از فصل اول ویرایش پنجم بود، ولی در حال حاضر یک فصل جداگانه (فصل ۳) است. طبیعی است که از نظر PMI موضوع “نقش مدیریت پروژه” اهمیت زیادی داشته است که فصل جداگانه‌ای برای آن در نظر گرفته است.

در این فصل جدید در مورد مثلث استعدادهای PMI (PMI Talent Triangle) صحبت می‌شود.
در شکل زیر می‌توانید مثلث استعدادهای PMI را مشاهده فرمایید:

این مثلث شامل موارد زیر است:
۱- مدیریت استراتژیک و کسب و کار
۲- مهارت‌های رهبری
۳- مهارت‌های فنی

مدیریت استراتژیک و کسب و کار
راهنما معتقد است تنها مدیریت محدودیت‌های سه گانه مدیریت پروژه کافی نیست و مدیر پروژه نیاز به مهارت‌های مدیریت استراتژیک و کسب و کار دارد. با تغییر در نسخه ۶ PMBOK، راهنما می‌گوید یک مدیر پروژه نیاز به درک مهارت‌هایی دارد که به او در تحلیل رقابت، بازار، پیامدهای قانونی، مدل‌های کسب و کار و غیره کمک می‌کند.

مهارت های رهبری
اگر چه مهارت‌های رهبری در نسخه پنجم PMBOK مورد بحث قرار گرفت، ولی در نسخه ششم PMBOK تأکید بیشتری بر این مهارت‌ها می‌شود. (مهارت‌های رهبری شامل هوش هیجانی، حل مسئله، تیم‌سازی و تأثیر آن است که به مدیر پروژه توانایی لازم را برای انگیزه دادن به تیم خود می‌دهد.)

مهارتهای فنی
در نسخه جدید PMBOK همچنان در خصوص نیاز مدیر پروژه به دانستن مهارت‌های فنی مربوط به پروژه تأکید می‌شود. علاوه بر این، مدیر پروژه باید مفاهیم مدیریت عملکرد، EVM، قوانین دولتی، مدیریت چرخه عمر پروژه و … که بخشی از نسخه قبلی هم بودند را بداند.

۲- تغییر اسامی دو حوزه دانش

گروه‌های فرآیندی(Process Group) همان پنج گروه سابق است. بدون تغییر در تعداد یا اسامی. (آغازین/برنامه‌ریزی/اجرا/نظارت و کنترل/پایانی – initiating /Planning /Executing /Monitoring & Control /Closing)
تعداد حوزه‌های دانش (Knowledge Area) هم تغییر نکرده و همان ده حوزه دانش سابق است، منتها اسامی دو حوزه دانش تغییر کرده است. در شکل زیر می‌توانید این تغییر اسامی را مشاهده کنید:

حوزه دانش مدیریت زمان(Time) به Schedule Management تغییر نام پیدا کرده است. چندین دهه گذشت تا بالاخره نویسندگان PMBOK به این نتیجه رسیدند که مدیران پروژه “زمان” را مدیریت نمی‌کنند، بلکه “برنامه زمان بندی” را تعریف و مدیریت می‌کنند. (به هر حال دیر رسیدن بهتر از هرگز نرسیدن است.) در حقیقت از نظر فلسفی نمی‌شود زمان را مدیریت کرد. زمان هر ساعت و هر لحظه و هر ثانیه می‌گذرد، اما برنامه زمان‌بندی را می‌توان مدیریت نمود.

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

در ویرایش ششم هر حوزه دانش شامل ۴ قسمت زیر است:
مفاهیم کلیدی- Key Concepts
Trends and Emerging Practices
Tailoring Considerations
Considerations for Agile/Adaptive Environments

۳- اضافه شدن سه فرآیند جدید به مجموع فرآیندها و حذف یک فرآیند:

سه فرآیند جدید به مجموع فرآیندهای PMBOK اضافه شده است. این سه فرآیند موارد زیر هستند:
۱- فرآیند مدیریت دانش پروژه : Manage Project Knowledge (در حوزه دانش Integration و گروه فرآیندی Executing)
۲- فرآیند کنترل منابع: Control Resources (در حوزه دانش Resource و گروه فرآیندی M&C)
۳- پیاده‌سازی پاسخ به ریسک Implement Risk Responses (در حوزه دانش Risk و گروه فرآیندی Executing)

همین طور فرآیند پایان تدارکات (Close Procurements ) نیز حذف شده است.

بنابراین در حال حاضر پس از حذف یک فرآیند و اضافه شدن سه فرآیند، مجموع تعداد فرآیندهای PMBOK به ۴۹ فرآیند رسیده است.


در شکل زیر می‌توانید تغییرات فرآیندهای PMBOK را مشاهده کنید:

همین طور در نسخه ششم، فرآیند برآورد منابع فعالیت‌ها (Estimate Activity Resources) از حوزه دانش زمان به حوزه دانش منابع جابه‌جا شده است.

۴- تغییر اسامی برخی از فرآیندها

نام ۹ فرآیند در نسخه ششم PMBOK تغییر کرده است:
اسامی قدیمی در نسخه پنجم:
۱- Perform Quality Assurance
۲- Plan Human Resource Management
۳- Acquire Project Team
۴- Develop Project Team
۵- Manage Project Team
۶- Control Communications
۷- Control Risks
۸- Plan Stakeholder Management
۹- Control Stakeholder Engagement

اسامی جدید در نسخه ششم:
۱- Manage Quality
۲- Plan Resource Management
۳- Acquire Resources
۴- Develop Team
۵- Manage Team
۶- Monitor Communications
۷- Monitor Risks
۸- Plan Stakeholder Engagement
۹- Monitor Stakeholder Engagement

در شکل زیر می توانید این تغییر اسامی فرآیندها را مشاهده نمایید:

در شکل زیر می توانید کلیه تغییرات مربوط به فرآیندهای PMBOK را ملاحظه کنید:

۵- اضافه شدن اجایل به نسخه ششم:

اگر فایل الکترونیکی نسخه ششم PMBOK رو از سایت PMI دانلود کرده باشید، حتمن متوجه شده‌اید که با یک فایل حدود ۹۷۰ صفحه‌ای طرفید! تا صفحه ۷۵۶ این فایل، راهنمای PMBOK است و بعد از آن یک بخش جدید حدود ۱۸۰ صفحه‌ای به فایل اضافه شده است، تحت عنوان : Agile Practice Guide

علاوه بر این در خود راهنما نیز در فرآیندها، بر چرخه‌های حیات adaptive و iterative تأکید بیشتری شده است. به عنوان مثال در فرآیند Develop Schedule تأکید بشتری بر مفهوم اجایل شده است. در مجموع دانش مدیریت پروژه هر روز بیش‌تر به سمت مفاهیمی همانند اجایل و اسکرام پیش می‌رود و علت این امر هم پیشتاز بودن صنایع IT و نرم‌افزاری در جهان چه از نظر مالی و چه از نظر توسعه سریع است.

 

۶- تغییرات در ورودی‌ها، خروجی‌ها، تکنیک‌ها و ابزارها (ITTO)

در مورد این تغییرات من یک خبر خوب برای شما دارم و یک خبر بد:
خبر خوب این است که در نسخه ششم، ورودی‌ها، خروجی‌ها، ابزارها و تکنیک‌ها بهتر معرفی شده‌اند و توضیح دادن اینکه چرا یک ورودی یا یک ابزار یا تکنیک در یک فرآیند استفاده می‌شود، بهتر انجام شده است.

و اما خبر بد این است که علی‌رغم اینکه PMI ادعا می‌کند که تعدادی از ابزارها و تکنیک‌ها کاهش یافته است، اما بر خلاف آن، شمارش من می‌گوید که تعداد ۱۱۸ ابزار و تکنیک در نسخه قبلی به ۱۳۱ ابزار و تکنیک منحصر به فرد افزایش یافته است. (یعنی ۱۱٪ افزایش)

ابزارها و تکنیک‌ها در دسته‌های زیر گروه‌بندی شده‌اند:
۱- Data gathering, e.g. Brainstorming, Interviews, Market Research
۲- Data analysis, e.g. Cost-benefit Analysis, Earned Value Analysis, Performance Reviews
۳- Data representation, e.g. Cause-and-effect Diagrams, Flowcharts, Histograms
۴- Decision-making, e.g. Multi criteria Decision Analysis, Voting
۵- Communication skills, e.g. Feedback, Presentation
۶- Interpersonal and team skills, e.g. Active Listening, Conflict Management, Emotional Intelligence

تعداد کلی ITTO ها از ۶۱۸ به ۷۲۲ افزایش یافته است (۱۷٪ افزایش) به عبارتی افرادی که با نسخه ششم قصد آزمون PMP دارند، کار سخت‌تری خواهند داشت.

۷- سایر تغییرات:

– تغییرات در برنامه مدیریت پروژه(PMP) و مدارک پروژه(Project Document)
– اضافه شدن استراتژی Escalate Response به استراتژی‌های قبلی پاسخ به ریسک
– تأکید بیشتر بر روی اهمیت دو موضوع product and project scope.
– تأکید بیشتر بر روی Benefits Management
– مفهوم Business Documents که شامل Business Case و Benefits Management است، معرفی شده است.

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

خواهش می‌کنم بدون ذکر منبع، کپی نکنید!

برنامه ریزی و کنترل پروژه , مایکروسافت پراجکت

محاسبات EVM در نرم‌افزار مایکروسافت پراجکت

اغلب گزارشات و محاسباتی که همکاران ما در مورد مدیریت ارزش حاصله یا Earned Value Management انجام می‌دهند، در نرم‌افزار اکسل انجام می‌شود. غالباً همکاران اطلاعات پایه‌ای EVM همانند مقادیر EV,PV,AC را در اکسل وارد می‌کنند و همانجا با فرمول‌های EVM، شاخص‌های مدیریت ارزش حاصله مانند SPI و CPI را محاسبه می‌کنند.

 

اما هر دو نرم‌افزار معروف برنامه‌ریزی و کنترل پروژه، یعنی  MSPو PRIMAVERA این قابلیت را دارند که محاسبات EVM را انجام دهند. کاری که در ایران کم‌تر معمول است. چرا که در روش برنامه‌ریزی و کنترل پروژه به سبک ایرانی، تعریف و تخصیص منابع و ثبت هزینه‌ها در برنامه‌های زمان‌بندی چندان رایج نیست.

 

 

برای آشنایی شما با انجام محاسبات EVM در برنامه زمان‌بندی، یک فایل برنامه زمان‌بندی که در نرم افزار مایکروسافت پراجکت (MSP) نوشته شده را برای دانلود در اختیارتان قرار می‌دهم.

 

لینک دانلود برنامه زمان‌بندی MSP، شامل محاسبات EVM

(پسوورد فایل زیپ: sharifiz.com)

 

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

Report>cost>Earned Value Report

 

شما می توانید از ویدئوی زیر برای مشاهده چگونگی ایجاد گزارش EVM در MSP استفاده کنید.


خواهش می‌کنم بدون ذکر منبع، کپی نکنید!

برنامه ریزی و کنترل پروژه , عمومی

ماتریس برنامه‌ریزی زمان

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

ماتریس مدیریت زمان

 

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

 

خواهش می کنم بدون ذکر منبع کپی نکنید.

برنامه ریزی و کنترل پروژه , مایکروسافت پراجکت

اوزان فیزیکی فعالیت های پروژه

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

«مي شه لطفا» بگيد چطوري مي شه توي msp وزن داد به فعاليت ها. برنامه زماني كه قبلا» واسه پروژه هامون مي نوشتيم خيلي كلي بود. حالا مي خوان كه وزن ريالي و حجمي و زماني را هم مشخص كنيم. اگر ممكنه مي شه بگيد چطوري مي شه اين كارو كرد؟»

و اما جواب:
اول از همه باید بدونیم «وزن هر فعالیت» یعنی چی و اصلاً با چه هدفی اون رو محاسبه می کنیم. می دونید که فعالیت های هر پروژه تفاوت های زیادی از نظر حجم کاری، هزینه، استفاده از منابع و… با همدیگر دارند و خیلی کم پیش میاد(یا اصلاً هرگز پیش نمیاد) که همه فعالیت های یک پروژه از هر نظر مشابه هم باشند. به همین خاطر به فعالیت های مختلف وزن می دهند تا تأثیرشون در درصد پیشرفت فعالیت های مادر و همچنین درصد پیشرفت کل پروژه مطابق با اهمیت هر فعالیت باشد.

مبنای محاسبه وزن فیزیکی:
در مورد مبنای محاسبه وزن هر فعالیت بحث های زیادی انجام شده و پروژه های مختلف از روش های مختلف برای وزن دهی فعالیت ها استفاده می کنند. اما معمولاً از ۶ روش به عنوان مبنای وزن دهی استفاده می کنند. وزن دهی به فعالیت ها بر اساس: ۱- هزینه فعالیت ۲- مدت زمان فعالیت ۳- حجم کاری فعالیت ۴- استفاده از منابع(نفر-روز) ۵- نظرات کارشناسی و ۶- ترکیبی از پنج روش فوق

این که کدوم روش رو انتخاب می کنید بستگی به نوع WBS پروژه، نوع پروژه و نوع فعالیت ها و خیلی مسائل دیگه داره.

از نظر من بهترین روش برای وزن دهی، بر اساس حجم کاری فعالیتهاست. ولی خوب اغلب نمی تونیم از این روش استفاده کنیم. چون همیشه در عمل تعداد و تنوع فعالیت ها زیاده و چون واحد احجام فعالیت های مختلف فرق می کنه، همیشه نمیشه از این روش استفاده کرد. برای رفع این مشکل از یک واحد یکسان برای وزن دهی به فعالیت ها استفاده می کنیم. مثلاً هزینه فعالیت یا زمان اون رو به عنوان مبنای وزن دهی انتخاب می کنیم. اما این روش ها هم ایرادات خودشو داره! مثلاً ممکنه یک فعالیت هزینه زیادی داشته باشه ولی حجم کمی داشته باشه! بعد از وزن دهی بر مبنای احجام کاری دومین روش برتر استفاده از واحد نفر-روز به عنوان مبناست.

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

۱- دو روش بری وزن دهی به فعالیت ها وجود داره: الف) وزن دهی از پایین به بالا ب)وزن دهی از بالا به پایین. در روش اول فقط بسته های کاری(سطح آخر WBS) رو در نظر می گیریم و کاری به سطح های بالاتر نداریم. اما در روش از بالا به پایین وزن بسته های کاری با توجه به فعالیت های سطح بالاتر WBS محاسبه می شود. کلاً روش دوم، معقول تر و حرفه ای تره.
۲- وزن فیزیکی سهم هر فعالیت از ۱۰۰ درصد حجم کل پروژه را نشان می دهد. به عبارتی وقتی میگیم وزن یک فعالیت ۱۰ است، یعنی اگر این فعالیت تکمیل شود، درصد پیشرفت فیزیکی پروژه ۱۰ درصد خواهد بود.
۳- جمع اوزان فیزیکی فعالیت ها پروژه باید ۱۰۰ یا مضربی از ۱۰۰شود.

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

خواهش می کنم بدون ذکر منبع کپی نکنید.

برنامه ریزی و کنترل پروژه , عمومی , مدیریت پروژه

برآورد مدت زمان فعالیت‌ها (بخش دوم)

محال است که شما در زمینه برنامه‌ریزی و کنترل پروژه کار کنید و با مشكلی که در پست قبل مطرح کردم روبه رو نشوید. اگر حوصله خواندن آن ماجرا را ندارید، خلاصه‌اش از این قرار است: هنگامی که قرار است يك برنامه‌ي زمان‌بندي بنويسيد، حتمن بايد با مسئولين اجراي هر فعاليت صحبت كنيد و نظر آن‌ها را در مورد تخمين زمان فعاليت‌ها جویا شوید. ولي مسأله‌اي كه مطرح می‌شود اين است كه اغلب اوقات، مسئولين اجرايي هر فعاليت بنا به دلايل مختلف، سعي مي‌كنند، زماني بيش‌تر از پيش‌بيني منطقي يك كار خاص را به شما تحميل كنند. به اصطلاح دچار عارضه Pad estimate هستیم.

مثلن شما مطابق تجارب قبلی و فعاليت‌هاي مشابه گذشته كاملاً مطمئنيد كه اجرای چند بلوك لاینینگ یک تونل، نهایتن ۳۰ روز طول خواهد کشید، ولي مسئول اجراي بتن اصرار مي‌كند كه زمان اين فعاليت ۹۰ روز در نظر گرفته شود. حالا اینکه اينجا چرا آن مسئول اجرايي چنين اصراري دارد، موضوع اين بحث نيست ولي مي‌شود حدس زد كه او با این کار، چنین اهدافی را دنبال مي‌كند: ۱- انجام فعاليت مورد نظر زودتر از زمان مقرر در برنامه و مطرح كردن ادعا در مورد پاداش و تشويق شدن ۲- مواخذه نشدن در صورت پايان ديرهنگام فعاليت ۳- تمایل ذاتی افراد (به خصوص ایرانی‌ها) برای انجام دادن امور در آخرین دقایق و نهایت بهره بردن از شناوری‌ها.

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

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

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

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

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

خواهش می کنم بدون ذکر منبع کپی نکنید.

برنامه ریزی و کنترل پروژه , عمومی , مدیریت پروژه

برآورد مدت زمان فعالیت‌ها (بخش اول)

گفتگوی فرضی در یکی از جلسات:
من: مهندس فلانی! ما برای حفر این تونل با توجه به نُرم‌ها و سوابق گذشته حفاری، در برنامه زمان‌بندی یک ماه در نظر گرفته‌ایم.
مهندس فلانی(مسول واحد حفاری): به هیچ وجه یک ماه کافی نیست. شما تو برنامه‌تون حداقل سه ماه باید در نظر بگیرید.
مدیر پروژه و رئیس کارگاه: حتمن و حتمن قبل از بستن برنامه و ارسال آن به مشاور، با واحدهای اجرایی هماهنگی کن و تاییده آنها را بگیر. (حرفی کاملن منطقی)
مهندس فلانی(مسول واحد حفاری) در مقابل اصرارهای من: نه مهندس، برنامه‌ای که کم‌تر از سه ماه برای حفر این تونل در نظر گرفته باشه، به هیچ وجه مورد تأیید من نیست.

در برنامه زمان بندی سه ماه برای این عملیات در نظر گرفتیم. چند ماه بعد، عملیات حفاری تونل مذبور آغاز و طی بیست و چهار روز به اتمام رسید! مهندس فلانی برای گروه خود تقاضای پاداش و کارانه کرد.

نماینده دستگاه نظارت(مشاور) در جلسه‌ای با حضور همه عوامل پروژه خطاب به من: خب، حفر تونل فلان که سه هفته‌ای تمام شد. آقای شریفی! چرا این قدر به برنامه‌ات آب بسته بودی؟ {خنده حضار از جمله مهندس فلانی(مسول واحد حفاری)}
دوربینی در جلسه نبود، وگرنه در آن لحظه حتمن به لنز آن خیره میشدم!

در پست بعدی به بررسی این مشکل می‌پردازم، شاید به کمک شما بتوانیم راهکاری برای حل چنین مسائلی پیدا کنیم.

خواهش می کنم بدون ذکر منبع کپی نکنید.