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

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

 1. در زمانی که تحلیل تاخیرات صورت می‌گیرد، بخصوص در استفاده از روش CAB که به صورت معکوس حرکت می‌شود و یا استفاده از Fragnet گذاری، بخصوص برای روشهای آینده نگر، اگر لگ منفی داشته باشید شبکه شما دچار مشکل خواهد شد و پیچیدگی بالایی ایجاد می‌گردد. در واقع شما با به تاخیر انداختن فعالیت پیشنیاز زمان شروع فعالیت پسنیاز هم به تاخیر خواهید انداخت، در صورتی‌که ممکن است در واقعیت نیازی به تاخیر این فعالیت نباشد. در این شرایط باید مدام حواستات به تغییرات دستی این موارد باشد و مدام Lagها را اصلاح نمایید. این موضوع مثلا زمانی که شما باید ۱۰۰۰ تا Fragnet را مدل‌سازی نمایید و این تعداد فعالیتها با رابطه FS و لگ منفی زیاد باشد عملا شما را دچار بحران و بعضا از تحلیل دقیق تاخیرات عاجز خواهد نمود. اما زمانی که رابطه SS با لگ مثبت استفاده شود، در Fragnet گذاری کمتر دچار این مشکل خواهید شد چون فعالیت بعدی به صورت خودکار به تاخیر نخواهد افتاد. 

این موضوع هم که گفته میشود به خاطر اینکه رابطه FS با لگ منفی باعث میشود تاخیر در فعالیت پیشنیاز باعث تاخیر خودکار در فعالیت پسنیاز شده و این موضوع خوب است، اتفاقا این موضوع اصلا خوب نیست و یکی از مهمترین دلیل منع کردن استانداردها برای استفاده از این روش تلقی می‌شود. در واقع شما به عنوان یک نیروی برنامه‌ریزی و کنترل پروژه نباید تمام موارد را صرفا از نگاه برنامه‌ریزی نگاه کنید زیرا تمامی این تصمیمات فراتر از ابعاد فنی، ابعاد حقوقی نیز دارند. مثلا ما نمیتونیم لزوما بر اساس منطق برنامه تاخیرات فعالیت پیشنیاز را روی پسنیاز مدل کنیم و این ممکن است با واقعیت همخوانی نداشته باشد. این‌گونه نیست که بگوییم چون فعالیت پیشنیاز تاخیر دارد باید فعالیت پسنیاز هم به تاخیر بیفتد چون ممکن است فعالیت پسنیاز بتواند از مثلا ۵۰ درصد پیشرفت فعالیت پیشنیاز شروع شده و به تاخیر انداختن فعالیت پسنیاز لزومی نداشته باشد! از طرفی تحلیل تاخیرات از روی شرایط حقیقی و مشاهداتی (Observational) یا Fragnet گذاری با استفاده از روش Modeled صورت گرفته که در این شرایط باید تمامی موارد یا بر اساس حقیقت ثبت شده یا مدل شوند. اینها از شناسنامه تاخیر (EAS) خوانده شده و برای تاخیرات روی هر فعالیت باید مستندات قابل ارائه وجود داشته باشد. این تاخیرات در خیلی از مواقع به صورت Fragnet مدل شده و اگر تاخیری روی فعالیت پیشنیاز صورت گرفته باشد ما نمیتوانیم فعالیت پسنیاز را بدون Fragnet گذاری یا ثبت شرایط حقیقی به تاخیر بندازیم. این دو باید از هم تفکیک شده و ابتدا تاخیرات هر کدام صرف نظر از رابطه آن‌ها با یکدیگر مدل شوند.
یکی از مهمترین دلایل برتری این نوع رابطه به خاطر تحلیل تاخیرات هست.

 2. از نگاه برنامه ریزی نیز رابطه FS با Lag منفی مشکل دیگری ایجاد می‌نماید. شما در برنامه ریزی در زمان استفاده از این رابطه عملا از پایان نامشخص یک فعالیت، شروع زودهنگام‌تر یک فعالیت دیگر را پیشبینی می‌نمایید و این از نظر خود Oracle مورد نقد واقع شده است (در دوره برنامه‌ریزی پروژه مفصل درباره این موارد صحبت می‌شود). در واقع اگر تاخیری در فعالیت پیشنیاز رخ دهد و شما از پایان دقیق این فعالیت اطلاع نداشته باشید، نمیتوانید شروع زودتر فعالیت بعدی را پیشبینی نمایید. مثلا زمانی که Lag منفی 50 روزه وجود داشته باشد، ما نمیدانیم که آیا فعالیت پیشنیاز روز ۱۰۰ام تمام میشود که فعالیت پسنیاز را روز ۵۰ام شروع کنیم یا روز ۱۲۰ ام تمام میشود که فعالیت پسنیاز را روز ۷۰ام شروع کنیم؟ این در شرایطی که تعلیق نامشخص از سوی کارفرما رخ داده باشد از همه بدتر بوده و میتواند تبعات حقوقی را به‌خصوص در بحث تصدیع (Disruption) در تاخیرات بسیار بالا برده و خسارت بیشتری به کارفرما وارد نماید. برای همین موضوع است که برخی قراردادهای فدرال آمریکا اجازه استفاده از رابطه FS با Lead یا همان Lag منفی را در Schedule Specs خود نمی‌دهند. این به آن دلیل رخ میدهد که پیمانکار باید مدام نیروها و منابع فعالیت پسنیاز را hold نگه داشته و این موضوع مشکلات بهره‌وری را در سایت پروژه نیز ایجاد می‌نماید و میتواند خسارات بیشتری را به علت تصدیع (Disruption) به پروژه تحمیل نموده و ادعاهای بیشتری ایجاد کند.

اینها مهمترین مواردی هستن که داکیومنتها و best practice ها و Schedule specs های متعدد و خیلی از صاحب نظرانی که اقلا ما در آمریکا با آن‌ها کار کرده‌ایم با این موضوع که Lag منفی استفاده شود مخالف بوده و اقلا SS با لگ مثبت را در شرایطی که فعالیت قابل ریز شدن نباشد ترجیح میدهد.

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