چند سوال در زمینه برنامهریزی و کنترل پروژه دارم:
1. آیا همتراز کردن پیشرفت برنامهای با پیشرفت واقعی در تاریخ وضعیت (Status Date) و سپس اصلاح فعالیتها قابل قبول است؟
2. آیا سوابق واقعی تا (Status Date) باید بدون تغییر حفظ شوند و فقط کار باقیمانده (Remaining Work) دوباره برنامهریزی شود؟
3. آیا حذف خط مبنای (Baseline) مصوب قبلی قابل قبول است؟
4. آیا پیش از برنامهریزی مجدد (Replan) لازم است آنالیز تاخیرات انجام شود؟
5. در برنامه جبرانی (Catch-up Plan)، نحوه صحیح برخورد با Actual Progress و Remaining Duration و Baseline چیست؟
6. در برنامه جبرانی (Catch-up Plan)، برنامه آتی چگونه باید تنظیم شود و تفاوت آن با Replan چیست؟
پاسخ سوالهمتراز کردن پیشرفت برنامهای با پیشرفت واقعی پروژه در Status Date در یک Replan، در اصل اقدام صحیحی است؛ زیرا برنامه بازنگریشده باید وضعیت واقعی پروژه را در تاریخ مبنا منعکس کند. با این حال، این موضوع به معنای بازنویسی تاریخچه پروژه نیست.
تغییر یا اصلاح فعالیتهایی که قبل از Status Date قرار دارند، ذاتاً غیرقابل قبول نیست، مشروط بر اینکه این اصلاحات بر اساس شرایط واقعی و مستند پروژه انجام شده باشند. برای مثال، اگر مشخص شود تاریخ واقعی شروع یا پایان یک فعالیت، مدت واقعی اجرا یا میزان پیشرفت ثبتشده قبلی با واقعیت پروژه مغایرت داشته است، اصلاح آن برای انعکاس واقعیت قابل قبول است. اما اگر فعالیتهای قبل از Status Date صرفاً به صورت دستی جابهجا یا امتداد داده شوند تا بخش قبل و بعد از Status Date در گانت به شکل مطلوبی به یکدیگر متصل شوند یا Replan به یک نتیجه مشخص برسد، این اقدام قابل دفاع نیست.
بنابراین، معیار اصلی این نیست که آیا فعالیتهای قبل از Status Date تغییر کردهاند یا خیر؛ بلکه معیار این است که آیا این تغییرات ناشی از واقعیت و مستندات پروژه هستند یا صرفاً برای دستیابی به نتیجه مطلوب در Replan انجام شدهاند. Replan نباید به ابزاری برای بازنویسی تاریخچه پروژه تبدیل شود.
در اصل اطلاعات واقعی تا Status Date باید بر اساس واقعیت مستند پروژه حفظ شوند و نباید صرفاً بر اساس خواست پیمانکار یا برای دستیابی به نتیجه مطلوب در Replan تغییر کنند.
البته این به معنای آن نیست که Actuals تحت هیچ شرایطی قابل اصلاح نیستند. اگر بعداً مشخص شود اطلاعات قبلی اشتباه بوده یا با اسناد و واقعیت اجرایی پروژه مطابقت نداشته است، اصلاح آنها امکانپذیر است؛ اما این اصلاح باید مستند، قابل ردیابی و مبتنی بر واقعیت پروژه باشد.
در مقابل، Remaining Work و Remaining Duration ماهیت پیشبینی دارند و میتوانند بر اساس شرایط جدید پروژه تغییر کنند. بااینحال، پیمانکار نمیتواند آنها را صرفاً به صورت دلخواه تغییر دهد. مقادیر جدید باید با شرایط واقعی پروژه، منابع، بهرهوری، روش اجرا و منطق شبکه برنامه سازگار باشند و مطابق فرآیند کنترل پروژه و الزامات قراردادی توسط مشاور یا کارفرما بررسی و تأیید شوند.
بنابراین، اصل صحیح این است که تاریخچه واقعی پروژه تا Status Date دستکاری نشود و برنامهریزی مجدد عمدتاً بر روی Remaining Work و پیشبینی آینده متمرکز باشد؛ مگر اینکه اصلاح اطلاعات گذشته برای انطباق با واقعیت مستند پروژه ضرورت داشته باشد.
خط مبنای (Baseline) مصوب قبلی باید پیش از تهیه Replan به صورت مستقل حفظ شود. اگر Baseline قبلی حذف یا Overwrite شود، در صورتی که نسخه مستقل و قابل اتکایی از آن حفظ نشده باشد، امکان مقایسه وضعیت واقعی پروژه با برنامه مصوب اولیه و ارزیابی انحرافات قبل و بعد از Replan محدود خواهد شد.
بنابراین، حتی اگر قرار باشد برای Replan یک Baseline جدید تعریف شود، Baseline مصوب قبلی نباید بدون حفظ سابقه آن حذف یا جایگزین شود. بهتر است پیش از Replan، نسخه برنامه قبلی، Baseline مصوب و خروجیهای لازم برای مقایسه عملکرد پروژه به صورت مستقل آرشیو شوند.
در عین حال، حذف Baseline قبلی به خودی خود الزاماً به معنای از بین رفتن تمام امکان تحلیل نیست؛ چنانچه پیش از Replan نسخه قابل اتکایی از برنامه و Baseline قبلی و گزارشهای عملکرد آن حفظ شده باشد، وضعیت قبل از Replan همچنان قابل بررسی خواهد بود.
بله، بهخصوص زمانی که Replan در شرایط وجود تأخیر و با آثار قراردادی تهیه میشود، لازم است پیش از آن یا همزمان با آن، وضعیت تأخیرات پروژه مورد تحلیل قرار گیرد تا مشخص شود تأخیرهای ایجادشده تا Status Date ناشی از چه عواملی بوده و مسئولیت آنها بر عهده کدام طرف است.
باید مشخص شود که تأخیرهای موجود، برای مثال، ناشی از پیمانکار، کارفرما، عوامل خارج از کنترل طرفین، تأخیرات قابل جبران، قابل تمدید یا تأخیرات همزمان (Concurrent Delay) هستند یا خیر.
در واقع، Replan جایگزین تحلیل تأخیرات نیست. نباید با تغییر برنامه، مسئولیت تأخیرهای گذشته مخدوش شود. اگر پیش از Replan وضعیت تأخیرات و آثار زمانی آنها بهدرستی تحلیل و تعیین تکلیف شده باشد، نگرانی ناشی از تغییر برنامه و Baseline جدید نیز تا حد زیادی کاهش مییابد؛ زیرا مشخص خواهد بود که وضعیت زمانی پروژه در نقطه Replan چگونه شکل گرفته و چه میزان از تأخیرات، حسب تحلیل انجامشده، مجاز یا غیرمجاز تلقی میشود.
در Catch-up Plan نیز Actual Progress تا Status Date باید بر اساس واقعیت پروژه ثبت و حفظ شود و نباید برای دستیابی به تاریخ هدف مورد نظر تغییر داده شود.
مواردی مانند Remaining Duration و Remaining Work میتوانند در Catch-up Plan بازنگری شوند، زیرا هدف اصلی Catch-up Plan این است که با تغییر در پیشبینی و اتخاذ اقدامات جبرانی، پروژه از وضعیت فعلی به تاریخ هدف تعیینشده بازگردد. این تغییرات باید بر اساس اقدامات واقعی و قابل اجرا مانند افزایش منابع، افزایش شیفت، افزایش بهرهوری، تغییر اولویت اجرا یا سایر اقدامات جبرانی باشد و صرفاً یک تغییر صوری در برنامه نباشد.
در مورد Baseline نیز Baseline مصوب قبلی باید حفظ شود تا مشخص باشد پروژه نسبت به برنامه مصوب اولیه یا قبلی چه میزان عقبماندگی داشته است. در صورت نیاز میتوان برای Catch-up Plan یک برنامه یا Baseline جداگانه تعریف کرد، اما این امر نباید باعث حذف یا Overwrite شدن Baseline مصوب اولیه یا قبلی شود.
منطق تهیه Catch-up Plan از نظر فرآیند برنامهریزی تا حد زیادی مشابه Replan است؛ یعنی برنامه از وضعیت واقعی پروژه در یک Status Date مشخص شروع میشود و فعالیتهای باقیمانده بر اساس شرایط موجود بازتنظیم میشوند.
اما تفاوت اصلی در هدف آنهاست. در Replan، هدف اصلی بازتنظیم برنامه بر اساس وضعیت واقعی و شرایط جدید پروژه است و در صورت وجود مبنای قراردادی و احراز تأخیرات مجاز، تمدید زمانی داده میشود. در حالی که Catch-up Plan اساساً با هدف جبران عقبماندگی و دستیابی به تاریخ هدف موجود تهیه میشود و فرض آن این است که پیمانکار باید با اقدامات جبرانی، مدت تأخیر را تا حد امکان جبران کند.
بنابراین میتوان گفت منطق فنی Replan و Catch-up Plan در بازتنظیم برنامه آتی مشابه است، اما هدف آنها متفاوت است: Replan میتواند برای بازتنظیم برنامه با لحاظ شرایط واقعی پروژه و در صورت احراز شرایط، تمدید مدت مورد استفاده قرار گیرد؛ اما Catch-up Plan با هدف جبران عقبماندگی و بازگرداندن پروژه به تاریخ هدف موجود تهیه میشود.