قبل از اینکه درصدهای پیشرفت دوره را وارد برنامه کنید، پنج دقیقه برای سلامت خودِ برنامه وقت بگذارید: سرهای باز، لگهای منفی، قیدهای سخت، شناوریهای غیرواقعی و تاریخهای نامعتبر، همان چیزهایی هستند که یک بهروزرسانی تمیز را به یک گزارش پر از عدد مشکوک تبدیل میکنند. هر پنج چک زیر با فیلترهای آمادهٔ MSP و P6 انجام میشود؛ بدون هیچ ابزار اضافهای.
۱. سرها و تههای باز (Open Ends)
هر فعالیتی باید دستکم یک پیشنیاز و یک پسنیاز داشته باشد؛ استثنا فقط شروع پروژه (بیپیشنیاز) و پایان پروژه (بیپسنیاز) است. فعالیت بیمنطق در محاسبهٔ مسیر بحرانی شرکت نمیکند و شناوریاش باد میکند — یعنی گزارش پیشرفتتان از همینجا شروع به دروغ گفتن میکند. استاندارد DCMA میگوید منطقِ گمشده باید زیر ۵٪ فعالیتها باشد.
ستونهای Predecessors و Successors را به جدول اضافه کنید و با AutoFilter ردیفهای خالی را ببینید. فقط اولین و آخرین فعالیت کل پروژه مجازند خالی باشند؛ بقیه را با منطق واقعی (معمولاً FS) وصل کنید.
از مسیر Tools ← Schedule برنامه را زمانبندی کنید و View Log را باز کنید؛ شمار فعالیتهای بدون پیشنیاز و بدون پسنیاز همانجا گزارش میشود. برای لیست کردنشان یک فیلتر سفارشی روی ستونهای Predecessors و Successors (بخش Details) بسازید.
۲. شکار لگ منفی (Lead)
لگ منفی یعنی «دو روز زودتر شروع کن» — روی کاغذ جذاب است، در عمل یعنی وابستگی را شل کردهاید و تاریخها بهجای منطق، با حدس جلو میروند. قانون DCMA روشن است: صفر درصد رابطهٔ دارای Lead. لگ مثبتِ مستند بحث دیگری است؛ Lead تقریباً همیشه باید صفر شود.
در MSP ستون Predecessors را فیلتر کنید با شرط contains روی کاراکتر - (رابطههایی مثل 12FS-2 days همان Leadها هستند) و آنها را به FS ساده یا Lag مثبتِ مستند تبدیل کنید. در P6 ستونهای Predecessors و Successors را به جدول فعالیتها اضافه کنید و همین جستوجو را روی علامت منفی انجام دهید. اگر Lead واقعاً لازم است، علتش را در Notes همان رابطه بنویسید تا در بهروزرسانی بعدی کسی پاکش نکند.
۳. حسابرسی قیدهای سخت
قیدهای Must Finish On و Finish No Later Than منطق شبکه را قفل میکنند و مسیر بحرانی مصنوعی میسازند؛ هر چه تعدادشان بیشتر، برنامهتان کمتر «زمانبندی» و بیشتر «تقویم دیواری» است. قاعدهٔ عملی من: قید سخت فقط برای تاریخ اجباری قراردادی که واقعاً در دست ما نیست؛ بقیهٔ موعدها با Deadline.
در MSP فیلتر جدید بسازید: فیلد Constraint Type مخالف As Soon As Possible — هر چه در لیست آمد، کاندیدای حذف یا تبدیل به Deadline است (مسیر دقیق منو را در یادداشت MSP آوردهام). در P6 فیلتر بزنید روی فعالیتهایی که Primary Constraint آنها خالی نیست و تکتکشان را با مجری مربوطه بازبینی کنید.
۴. شناوری بالا و مدتهای طولانی
دو عدد DCMA را حفظ باشید: فعالیت با شناوری کل بیش از ۴۴ روز کاری (حدود دو ماه) و فعالیت با مدت بیش از ۴۴ روز، هر کدام باید زیر ۵٪ برنامه باشند. شناوری نجومی معمولاً یعنی منطق جا افتاده (برگردید به چک شمارهٔ ۱) و مدت طولانی یعنی فعالیت باید شکسته شود — فعالیتی که شش ماه طول میکشد، درصد پیشرفتش همیشه حدس است و ارزش کسبشده را خراب میکند.
در MSP بر اساس ستون Total Slack مرتب کنید و سقف لیست را بشکافید؛ در P6 فیلتر Total Float بزرگتر از 352h (معادل ۴۴ روز هشتساعته) همان کار را میکند. برای شکستن فعالیتهای بلند از Global Change در P6 میتوانید بهصورت گروهی کمک بگیرید.
۵. تاریخ واقعی در آینده، کار ناقص در گذشته
دو خطای کلاسیک بهروزرسانی: ثبت Actual برای تاریخی که هنوز نیامده، و رها کردن کار ناتمام قبل از تاریخ گزارش (Status Date / Data Date). دومی یعنی برنامهتان عقبماندگی را قایم کرده و درصدهای بعدی همه خوشبینانه از آب درمیآیند.
در MSP ابتدا Status Date را از تب Project ست کنید، بعد فیلتر Slipping Tasks را بگیرید و ستون Finish را با Status Date مقایسه کنید. در P6 خط Data Date را روی گانت بگذارید: هر میلهٔ فعالی که سمت چپ خط مانده و هنوز تمام نشده، باید یا درصد بگیرد یا دوباره زمانبندی شود. این چک را هر دوره، قبل از گرفتن درصدها انجام دهید نه بعدش.
جمعبندی — چکلیست پنجدقیقهای
اگر فقط همین پنج فیلتر را قبل از هر بهروزرسانی بگیرید — سرهای باز، لگ منفی، قید سخت، شناوری/مدت مشکوک، و کارِ مانده در گذشته — برنامهتان در عمل استاندارد DCMA را پاس میکند و عددهای پیشرفت برای محاسبهٔ پیشرفت وزنی قابل دفاع میمانند. قدم بعدی: همین چکها را یکبار روی برنامهٔ جاریتان اجرا کنید و نتیجه را یادداشت کنید؛ اختلاف قبل و بعد، بهترین سند برای جلسهٔ بعدی با کارفرماست.