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

نادر خرمی راد

انتشار ایبوک محاسبه تاخیرهای مجاز پروژه

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

 

DA-Cover-s

این کتاب شیوه محاسبه تاخیرهای مجاز و دعاوی زمانی رو توضیح می‌ده.

نوشته نادر خرمی راد (Nader Khorrami Rad)

تاخیرهای موازی پیمانکار و کارفرما

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

 

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

  • روش کمابیش رایج‌تر: تاخیر به نفع پیمانکار محاسبه می‌شه، یعنی حق ادعای زمانی برای پیمانکار محفوظه. با این حال حق ادعای مالی اون دوره از پیمانکار گرفته می‌شه.
  • روش کمتر رایج: پیمانکار و کارفرما تو تاخیر شریک دونسته می‌شن و بر اساس معیارهای مختلف سهم اون‌ها رو تو تاخیر در نظر می‌گیرن. به این ترتیب قسمتی از حق پیمانکار در مورد اون تاخیر (مثلا نصفش) محفوظ می‌مونه، با این حال می‌تونه به اندازه همون سهم ادعای مالی هم داشته باشه.

 

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

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

 

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

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

روش های محاسبه تاخیر مجاز

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

شیوه محاسبه تاخیر مجاز رو همیشه می‌شه تو یکی از این چهار گروه قرار داد:

  1. روش‌های سرانگشتی: تو این روش‌ها یا از برنامه زمان‌بندی استفاده نمی‌شه، یا اگر هم بشه خیلی استفاده محدودیه و جنبه محاسباتی نداره. می‌شه با اصلاحات پم‌باک اینطوری گفت که به جای «مدل زمان‌بندی» از «زمان‌بندی» استفاده می‌کنه. روش‌های این خانواده خیلی تنوع دارن و خیلی‌هاشون هم ابتکاری هستن. از این روش‌ها عموما قدیم استفاده می‌شد که نرم‌افزارهای برنامه‌ریزی وجود نداشتن و نمی‌شد محاسبات کامل‌تر و پیچیده‌تر رو انجام داد. الان دیگه زیاد پذیرفته شده نیست که اینطوری تاخیرها رو محاسبه کنین.
  2. روش‌های افزاینده با الگوی ثابت: این همون روشیه که معمولا استفاده می‌کنیم. عوامل تاخیر رو به نسخه اولیه برنامه زمان‌بندی اضافه می‌کنیم و نگاه می‌کنیم که ببینیم تاریخ پایان چقدر عوض شده. مقداری که عوض شده باشه می‌شه تاخیر مجاز. امتیاز این روش به اینه که اطلاعات ورودی خیلی کمی می‌خواد و اگه برنامه زمان‌بندی هم درست و حسابی باشه دوباره کاری برای تهیه برنامه نداریم.
  3. روش‌های کاهنده با الگوی ثابت: تو این روش کار یه مقدار برعکسه. به جای این‌که از نسخه واقعی نشده اولیه برنامه استفاده کنیم و عوامل تاخیر رو بهش اضافه کنیم، نسخه واقعی شده برنامه رو برمی‌داریم و عوامل تاخیر رو ازش کم می‌کنیم. هرچقدر که مدت زمان پروژه کم بشه می‌شه تاخیر مجازمون. برای این‌که بتونیم این کارها رو بکنیم باید یه مدل زمان‌بندی بازسازی شده برای برنامه واقعی بسازیم که کار زیاد ساده‌ای هم نیست. امتیازش نسبت به قبلی تو اینه که عوامل تاخیر رو تو بستری کمابیش نزدیک‌تر به بستر واقعی‌شون در نظر می‌گیره. مثلا یه عامل تاخیر ممکنه تو سناریوی اولیه برنامه‌ریزی به شکل خاصی تاثیر بذاره، ولی تو شرایط واقعی پیمانکار تاثیرش بیشتر یا کمتر باشه. این روش اون بیشتر و کمتر بودن‌ها رو تا حد زیادی در نظر می‌گیره.
  4. روش‌های افزاینده یا کاهنده با الگوی متغیر: تو این روش‌ها به جای این‌که از یه نسخه زمان‌بندی استفاده کنیم، تاخیر رو برای برش‌های زمانی متعددی حساب می‌کنیم. تو هر برش از برنامه‌ای استفاده می‌کنیم که برای همون تاریخ واقعی شده و عوامل تاخیر همون دوره رو هم به شیوه افزایشی یا کاهشی توش وارد می‌کنیم و در نهایت نتایج رو به شیوه‌ای مناسب با هم ترکیب می‌کنیم. امتیاز این روش تو اینه که عوامل تاخیر رو با نهایت دقت تو بستر واقعیش محاسبه می‌کنه. کلا هم در حال حاضر کامل‌ترین روشه. فقط مشکلش اینه که خیلی داده اولیه زیاد لازم داره و محاسبه‌ش هم خیلی وقت می‌گیره.

 

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

ایراد زیاد بودن شناوری چیه؟

خیلی از استانداردها و منابعی که در مورد زمان‌بندی نوشته شدن درباره شناوری‌های زیاد از حد نوشتن. این‌که شناوری‌ها نباید از حدی بیشتر باشه یکی از ۱۹ قاعده‌ایه که تو کتاب قواعد زمان‌بندی پروژه هم توضیح دادم.

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

 

زیاد بودن شناوری به خودی خود هیچ مشکلی ایجاد نمی‌کنه. شناوری‌های زیاد از حد دلیل ایجاد مشکل نیستن، ولی نشونه‌ایه که به ما می‌گه احتمالا جای دیگه‌ای مشکلی وجود داره. مثل این می‌مونه که یه دکتر مثلا نشونه‌ای رو روی ناخن شما ببینه و مشکوک بشه. اون نشونه روی ناخن به خودی خود مشکلی برای شما ایجاد نمی‌کنه (مگر این‌که خیلی حساس به ظاهرتون باشین)، ولی ممکنه جای دیگه‌ای مشکل مهمی داشته باشین و به همین خاطر باید ماجرا رو بررسی کرد.

 

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

 

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

دو سبک در برنامه‌ریزی زمانی

من روش‌های زمان‌بندی رو به دو حالت تقسیم می‌کنم:

  • زمان‌بندی با انتهای آزاد
  • زمان‌بندی با انتهای مقید

 

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

 

زمان‌بندی با انتهای آزاد

تو این حالت هیچ عنصر زمانی نباید وارد کنیم که حرکت فعالیت‌ها رو به سمت آینده محدود بکنه. تمام عناصر فقط دوست دارن همه چیز رو به سمت آینده هل بدن.

فرجه و قیدهای “دیرتر از … شروع نشود”، “دیرتر از … تمام نشود”، “حتما در … شروع شود” و “حتما در … تمام شود” همه دوست دارن به شکلی مانع حرکت فعالیت به آینده بشن و در نتیجه نباید استفاده بشن.

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

تو این حالت مثلا Finish Variance می‌تونه بهتون بگه که فعالیت‌ها چقدر به تاخیر افتادن.

 

زمان‌بندی با انتهای مقید

تو این حالت باید تمام قیدهای زمانی رو وارد کنین. یه قید “دیرتر از … تمام نشود” برای پروژه داریم و اگه تو قرارداد یا صورت جلسات تاریخ‌های دیگه‌ای هم مشخص شده باشه، باید اون‌ها رو هم به همین شکل وارد کرد. توجه کنین که این تاریخ‌ها معمولا “دیرتر از … تمام نشود” هستن، نه “حتما در … تمام شود”؛ به عبارت دیگه اگه کار رو زودتر از اون تاریخ تموم کنین هیچکس بهتون ایرادی نمی‌گیره.

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

تو این حالت باید به جای Finish Variance به شناوری کل توجه داشته باشین که هیچی منفی نشه.

 

مقایسه روش‌ها

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

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

محاسبه تاخیر

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

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

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

تاخیرات پروژه

این متن رو چند وقت پیش آقای میثم بیگلر برای من فرستادن تا برای استفاده خوانندگان تو سایت قرار بگیره. متن رو بدون تغییر مفهومی اینجا گذشتم. آخرش یه توضیح کوچیک هم از خودم اضافه می‌کنم.

 

تعاریف:

تاخيرات پروژه: تقاضل زمان پايان واقعی و پايان قراردادی پروژه

تاخيرات = تاخيرات مجاز + تاخيرات غير مجاز

تأخيرات غير مجاز: تأخيرات ناشی از قصور پيمانكار، مانند تعلل در انجام فعاليت‌ها در زمان برنامه‌ريزی شده يا تاخير در شروع يا پايان فعاليت‌ها.

تأخيرات مجاز: تأخيرات ناشی از قصور كارفرما، مانند تغيير نقشه‌های اجرايی و ابلاغ دستوركارهای جديد.

 

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

تسهيم تاخيرات مجاز و غير مجاز هم در خلال پروژه و هم در پايان پروژه اهميت دارد. از آنجا كه پيشرفت پروژه در حين اجرا هميشه با توجه به برنامه پروژه محاسبه شده و با مبنای برنامه زمانبندی قياس می‌شود و معيار تسريع و تأخير پيمانكار جلو يا عقب بودن از برنامه زمانبندي است، دقيق و معتبر بودن اين مبنا اهميت ويژه‌اي دارد. تسهيم تأخيرات و اعمال تأثير تآخير مجاز در برنامه موجب اصلاح مبنای محاسبه پيشرفت خواهد شد.

تأخیرات غیرمجاز از کسر تأخیرات مجاز از کل تأخیرات به دست می‌آید و آنچه محل بحث میان کارفرما و پیمانکار است میزان و تأثیر تأخیرات مجاز در برنامه زمانبندی می‌باشد.

 

طبقه‌بندی‌های تاخیرات مجاز:

تاخیرات مجاز را می‌توان بر حسب نوع به گروه‌های زیر تقسیم کرد:

  1. افزايش احجام كارهای موجود در برنامه زمانبندی؛ مانند افزايش حجم خاكبرداری يا خاكريزی.
  2. افزايش فعاليت‌های جديد به برنامه؛ مانند اضافه شدن فضای جديد به فضاهای قبلی پروژه
  3. تاخير در ابلاغ نقشه‌ها و تعيين تكليف ديتيل‌های اجرايی از جانب كارفرما.
  4. تامين نشدن پيش‌نياز‌هايی كه بر عهده كارفرما است.

 

می‌توان تاخیرهای مجاز را بر حسب زمان بروز تاخیر به گروه‌های زیر تقسیم کرد:

  1. تاخيرهایی كه تاريخ تأثيرشان مستقل از زمان وقوع آنهاست؛ مانند افزايش احجام. تأثير اين‌گونه تأخيرات در آخرين برنامه زمانبندي مبنا ملاحظه می‌شود؛ به طور مثال به نسبت افزايش حجم كار، زمان افزايش پيدا می‌كند.
  2. تاخيراتی كه تاريخ تاثيرشان وابسته به زمان وقوع آنهاست؛ مانند تغيير نقشه‌های اجرايی. تاثير اين‌گونه تاخيرات با توجه به واقعيت اجرا ملاحظه می‌شود. به طور مثال شرايط نامناسب جوی با توجه به اينكه كار در كدام مرحله اجرا است ممكن است جزو تأخيرات مجاز يا غير مجاز درنظر گرفته شود. مثال ديگر تاخير در تعيين تكليف ديتيل‌های اجرايی است كه هم‌اكنون استعلام شده، زمان تاخير جواب كارفرما از زمان استعلام پيمانكار  (با احتساب فرجه زمانی پاسخ) محاسبه می‌شود نه از زمان شروع آيتم در برنامه زمانبندی مبنا.

 

می‌توان تاخیرها را بر حسب قرار داشتن یا نداشتن در مسیر بحرانی نیز گروه‌بندی کرد:

  1. تاخیراتی که مسیر بحرانی پروژه را متاثر می‌کنند.
  2. تاخیراتی که مسیر بحرانی را تحت تاثیر قرار نمی‌دهند.

 

مسأله ما تعیین تاخیرات مجاز و غیر مجاز نیست، بلکه تعیین نحوه تاثیر تاخیرات مجاز در برنامه زمانبندی و تاثیر زمانی آن در مدت پروژه است.

علی القاعده برنامه زمانبندی هر پروژه از اسناد منضم به پیمان است. لذا هر تغییری در مدت پیمان باید بر مبنای برنامه زمانبندی اولیه باشد.

 

نحوه تاثیر تاخیرات مجاز در برنامه

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

کارفرما تا چه حد می تواند انتظار افزایش منابع و انجام کار جدید در موعد قبلی را داشته باشد؟

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

آیا بخش‌نامه، آئین‌نامه یا قانون مدونی برای محاسبه تاثیر تاخیرات مجاز وجود دارد یا خیر؟ من بجز دستورالعمل 5090 سازمان برنامه كه البته آن هم در مورد تمديد زمان پروژه در مقابل تاخير پرداخت‌های كارفرما است، چيزي نديده‌ام.

 

پایان متن آقای بیگلر

یه توضیح کوچیک…

توجه داشته باشین که تو این متن هم گفته شده “فعالیت‌هایی که بر مسیر بحرانی تاثیر می‌ذارن”، نه “فعالیت‌هایی که تو مسیر بحرانی هستن”، چون ممکنه فعالیتی تو مسیر بحرانی نباشه، ولی تاخیرش باعث بشه که مسیر بحرانی جابجا بشه و اون فعالیت روی تاریخ پایان اثر بذاره. راه پیدا کردنش چیه؟ ساده‌ترین راه اینه که تمام فعالیت‌هایی که تاخیر دارن رو وارد کنین.

 

پی‌نوشت:

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

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

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

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

در مورد بخش‌نامه‌ها هم تا جایی که من خبر دارم به جز اون بخش‌نامه و دوتا بخش‌نامه قبلیش که تو متن اون بهشون ارجاع داده شده چیز دیگه‌ای وجود نداره.

 

بعد از انتشار این مطلب آقای صادق‌فر به من ایمیل دادن و این مطلب خودشون رو که در این خصوص بود معرفی کردن:

محاسبه تاخیر واقعی پروژه

راستش من وقتی ایشون این مطلب رو نوشتن خواستم براشون کامنت بذارم و نظر خودم رو بگم، ولی سایتشون مثل مال خودم کامنت نداره. نظر من این بود:

  1. استفاده از عبارت “تاخیر” برای اشاره به تفاضل پیشرفت برنامه‌ریزی شده و واقعی مناسب نیست و سوتفاهم ایجاد می‌کنه. بهتره “تاخیر” برای مدت زمان به کار بره و برای اشاره به تفاضل پیشرفت واقعی و برنامه‌ریزی شده بگیم “انحراف پیشرفت” یا “انحراف پروژه”.
  2. ملاحظاتی که مبنای متن ایشون قرار گرفته کاملا به‌جاس، ولی راه حل، همون‌طوری که خودشون هم گفتن، زیاد دقیق نیست، چون پیشرفت برنامه‌ریزی شده رو خطی فرض می‌کنه و در عمل این‌طور نیست؛ به خصوص که معمولا وقتی از تاریخ پایان برنامه‌ریزی گذشته باشیم معمولا واقعیت هم در یک سوم یا یا چهارم پایانیِ برنامه‌ریزیه، یعنی جایی که دیگه شیب پیشرفت داره کم می‌شه، در نتیجه جواب‌های روشی که توضیح دادن خوشبینانه‌تر از اون چیزی می‌شه که باید باشه. روش رایج اینه که زمان کسب شده (earned schedule) رو محاسبه کنیم. مثلا پروژه‌ای رو فرض کنین که 10 ماهه بوده، الان ماه 12 هستیم و پیشرفت 80٪ شده. زمانی که صرف کردیم 12 ماهه. حالا می‌ریم ببینیم کجا پیشرفت برنامه‌ریزی شده 80٪ بوده؛ مثلا ماه 7. تو این حالت زمان کسب شده 7 ماهه و زمان واقعی 12 ماه، یعنی ما تو 12 ماه کاری رو کردیم که می‌بایست تو 7 ماه کرده باشیم. در نتیجه عملا به اندازه 5 ماه عقب افتادیم. از طرف دیگه می‌شه حساب کرد که وقتی ما کار 7 ماه رو تو 12 ماه انجام دادیم، اگه تناسب بگیریم کار 10 ماه رو (یعنی کل پروژه) در 17 ماه انجام خواهیم داد. به عبارت دیگه احتمالا پروژه با 7 ماه تاخیر تموم خواهد شد.
نوشته نادر خرمی راد (Nader Khorrami Rad)

قالب‌بندی سریع در پراجکت 2010

یه ابزارهایی هم اضافه شدن که نتیجه‌شون چیز جدیدی نیست، قبلا هم بوده، ولی الان با یه کلیک می‌شه به اون نتیجه رسید و قبلا با مثلا 20تا کلیک.

Bar Formatting

اون Format همون کادر محاوره قدیمی رو باز می‌کنه؛ کادر محاوره‌ای که باهاش نمودار گانت رو قالب‌بندی می‌کردیم.
اون سه‌تا گزینه این‌طوری‌ان:
Critical Task: فعالیت‌های بحرانی رو با میله‌های قرمر نشون می‌ده
Slack: شناوری کل فعالیت‌ها رو با میله‌های باریکی که در ادامشون کشیده می‌شه نشون می‌ده
Late Tasks: فعالیت‌های به تاخیر افتاده رو با رنگ متمایز نشون می‌ده

اون گزینه Slack خیلی کاربردیه. بهتره در مراحل نهایی برنامه‌ریزی اون رو فعال کرد و شناوری‌های فعالیت‌ها رو کنترل کرد. فعالیت‌هایی که شناوری‌های خیلی زیاد دارن مشکوکن؛ ممکنه یه نقصی تو روابطشون باشه.

اون دوتا دکمه آخر هم اینا هستن:
Baseline: مقادیر خط‌مبنا رو با میله‌های باریک‌تری که روی میله‌های زمان‌بندی ترسیم می‌شن نشون می‌ده؛ خیلی با سلیقه و خوب.
Slippage: خطی از شروع خط‌مبنا (شروع برنامه‌ریزی شده) تا شروع زمان‌بندی شده، یعنی شروع فعلی، رسم می‌کنه. با این کار تاخیرهایی که به وجود اومده مشخص می‌شه.

نوشته نادر خرمی راد (Nader Khorrami Rad)

عناصر مفید گزارش‌های پیشرفت (2)

تاخیر!
یه عنصر مهم که باید تو گزارش‌ها ارائه کنیم، مقدار تاخیر پروژه و اجزای اصلی اونه. بهتره تاخیر رو بر حسب روز بگیم.
اگه برنامه جبرانی تصویب شده باشه، عملا تاخیرها در زمان تصویب برنامه جبرانی صفر می‌شن. به همین خاطر بهتره که همیشه مشخص کنیم که تاخیرهای گزارش شده از چه تاریخی به بعد هستن. مثلا بگیم که در مدت 85 روز، 14 روز تاخیر به وجود اومده، و حتی می‌تونیم بگیم که این مقدار معادل چند درصد اون زمانه، ولی اگه این کار رو بکنیم مقدار اطلاعاتِ گزارش زیاد می‌شن و این هم خودش نکته منفی‌ایه.

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

باید مفهوم و عملکرد تمام عناصر گزارش رو هم تو راهنما مشخص کنین. در مورد تاخیر می‌تونین همچنین چیزی بنویسین:
تاخیر: اگر ادامه کار با سرعتی معادلِ سرعت برنامه‌ریزی پیش برود (و نه سرعت کنونی)، پایان پروژه به اندازه‌ای که در کادر تاخیر مشخص شده است دیرتر از تاریخ برنامه‌ریزی شده پایان خواهد یافت.

خیلی‌ها فکر می‌کنن که تاخیر به این معنیه که اگه پیمانکار با روند کنونی کارش رو ادامه بده به اون اندازه دیرتر تموم می‌کنه، که خیلی اشتباهه.
در مورد تاخیر دو نکته مهم هم وجود داره:
1. تاخیر به هیچ وجه وابسته به ضرایب وزنی نیست.
2. تاخیر به شدت وابسته به روابطِ تعریف شده در برنامه‌س. اگه روابط مناسب نباشن، مقدار تاخیر به طور کاذب کم یا زیاد می‌شه. هرچی فعالیت‌های برنامه کلی‌تر باشن،‌روابطشون هم تقریبی‌تر می‌شه و تاخیرها دقت کمتری خواهند داشت.

نوشته نادر خرمی راد (Nader Khorrami Rad)

محاسبه پایان پروژه (2)

تو مطلب محاسبه پایان پروژه شماره 1 توضیح دادم که چطوری می‌شه تاخیر کلاسیک رو به دست آورد. این محاسبات در اکثر نرم‌افزارها وجود دارد و کاملا هم جا افتاده هستن. با این حال تعبیر خاصی دارن که ممکنه برای ما کافی نباشه.
شاید بخوایم بدونیم که اگه پیمانکار با سرعتی کمابیش مشابه سرعتی که از ابتدای پروژه تا الان داشته کارش رو پیش ببره در چه زمانی پروژه رو تموم می‌کنه.
برای این کار می‌تونیم از شیوه محاسبه ES (مخفف Earned Schedule) استفاده کنیم. الان یه تعداد روزی از آغاز پروژه گذشته (مثلا 140 روز) و پیشرفت واقعی پروژه هم مقداری داره (مثلا 30٪). الان باید برین بگردین و ببینین که پیشرفت برنامه‌ریزی شده در چه تاریخی با پیشرفت واقعی کنونی برابر بوده (مثلا روز 100ام). حالا تعداد روز برنامه‌ریزی رو بر تعداد روز واقعی تقسیم کنین تا شاخصی که SPIt نامیده می‌شه رو به دست بیارین. تو عددهایی که تو این مثال گذشتم مقدار SPIt می‌شه حدود 71٪. معنیش اینه که ما عملا داریم با سرعتی معادل 71٪ سرعت برنامه‌ریزی شده پیش می‌ریم.
خوب، حالا مدت زمان اولیه پروژه چقدر بوده؟ مثلا 500 روز؟ اون رو بر SPIt تقسیم کنین تا مدت زمان تخمینی پایان پروژه به دست بیاد. تو این مثال می‌شه 704 روز.

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

محاسبه تاخیر پروژه

تا حالا چند بار در مورد محاسبه تاخیر پروژه از من سوال کردن. الان روش ساده‌ای که برای متدهای پایش ساده به کار می‌ره رو توضیح می‌دم.

1. اولین کار اینه که با Tools| Tracking| Set Baseline خط مبنا رو ذخیره کنین (اگه قبلا نکردین)، چون بهتره به جای این‌که تاریخ‌ها رو از هم کم کنیم، مقدار حاضر و آمدش رو از برنامه بگیریم.

2. درصد‌های پیشرفت رو وارد کنین. شکل زیر وضعیت یه برنامه نمونه رو نشون می‌ده. خط عمودی قرمز هم تاریخیه که درصدهای پیشرفتش وارد شده.

image

3. حالا Tools| Traking| Update Project رو اجرا کنین. با این کار کادر محاوره شکل زیر باز می‌شه:

image

4. گزینه دوم، یعنی Reschedule uncompleted work رو انتخاب کنین و تاریخ ورود مقادیر پیشرفت رو هم تو کادر مقابلش انتخاب کنین. روی OK کلیک کنین.

image

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

توضیحات:

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

برای کسب اطلاعات بیشتر به راهنمای جامع Microsoft Project 2007 مراجعه کنین.

نوشته نادر خرمی راد (Nader Khorrami Rad)

وابسته نبودن تاخیر و انحراف پیشرفت

این رو دارم می‌نویسم، چون خیلی‌ها در موردش اشتباه می‌کنن.

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

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

ممکنه پیشرفت واقعی کمتر از پیشرفت برنامه‌ریزی شده باشه، ولی تاخیری به وجود نیومده باشه. این ترکیب زمانی اتفاق می‌افته  که تمام فعالیت‌های بحرانی انجام شده باشن، ولی مقداری از فعالیت‌های غیر بحرانی طبق برنامه پیش نرفته باشن. البته وقتی فعالیتی، هرچند غیر بحرانی، مقدار زیادی به تاخیر بیفته، احتمال بحرانی شدنش زیاده؛ به همین خاطر این حالت زیاد اتفاق نمی‌افته، مگر این‌که منطق اجرایی طور عجیبی باشه یا برنامه خیلی بد نوشته شده باشه.

شکل زیر این حالت رو نشون می‌ده:

image

فرض کنین در زمانی که خط عمودی قرمز رنگ نشون می‌ده می‌خوایم وضعیت را تحلیل کنیم. اگه همه فعالیت‌ها طبق برنامه انجام شده باشن، ولی T4 هنوز انجام نشده باشه، وضعیت چطوری خواهد بود؟

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

حالا حالت زیر را در نظر بگیرین:

image

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

پیشرفت فیزیکی / تاخیر زمانی

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

خیلی‌ها فکر می‌کنن پیشرفت و تاخیر رابطه مستقیمی دارن و مثلا گاهی از من می‌پرسن که “فلان مقدار کم بودن پیشرفت فیزیکی می‌شه چند روز تاخیر؟”. در حالی که اصلا این‌طور نیست. می‌شه پیشرفت بیشتر از برنامه‌ریزی باشه، ولی تاخیر داشته باشیم، یا کمتر باشه و تاخیر نداشته باشیم. این مسئله به این بستگی داره که نیروهایی که در پروژه صرف شدن، به چه فعالیت‌هایی اختصاص داده شده باشن.

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

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

نوشته نادر خرمی راد (Nader Khorrami Rad)
اشتراک مطالب سایت

با اشتراک در فرم زیر مطالب جدید برایتان ایمیل می‌شوند:

اشتراک مطالب در تلگرام