کتاب کم حجمیه درباره استاندارد مدیریت پروژه پم‌باک، که مفاهیم و کلیات استاندارد رو به سادگی توضیح میده. کتاب رو بر اساس بازخوردهایی که از خواننده‌های کتاب‌های قبلیم دریافت کردم و برای کسایی نوشتم که می‌خوان سریع و ساده با استاندارد آشنا بشن و کتاب‌های حجیمی که وارد تمام جزئیات می‌شن براشون جذاب نیست. البته من امیدوارم که با خوندن این کتاب علاقه‌مند به مطالعه بیشتر و حتی گرفتن مدرک PMP بشن. ولی در هر حال، کسایی که می‌خوان فقط بفهمن که کل ماجرای پم‌باک که روز به روز داره بیشتر سر زبون‌ها می‌افته چیه، جواب تمام سوال‌هاشون رو همونجا می‌گیرن.
از زمانی که استانداردهای مدیریت پروژه مثل PMBOK سر زبون‌ها افتادن، ارتباط بیشتری بین برنامه‌ریزی و کنترل پروژه از یه طرف و مدیریت پروژه از طرف دیگه به وجود اومده و کارشناسای برنامه‌ریزی و کنترل پروژه اطلاعات خیلی بیشتری در مورد مدیریت پروژه به دست آوردن.
مشکلی که من دارم تو این مسئله می‌بینم، اینه که هرکس یه مقدار در مورد مدیریت پروژه مطالعه می‌کنه شروع می‌کنه به ایراد گرفتن از کارها و تصمیم‌های هر مدیر پروژه‌ای که می‌بینه. این درسته؟ نه. همیشه این گفته یادتون باشه:
Little Knowledge is a dangerous thing
اطلاعاتی که می‌شه با خوندن کتاب‌ها به دست آورد، اطلاعاتی انتزاعیه، یعنی هر مسئله‌ای رو تو شرایط انتزاعی و با تعداد پارامتر خیلی کم می‌سنجه. این در حالیه که کار واقعی مدیریت پروژه کاملا کانکریته و تعداد پارامترهای موثر در هر تصمیم‌گیری بسیار زیاد هستن.
شکی نیست که هر مدیر پروژه‌ای که پیدا کنین اشتباه‌های زیادی مرتکب می‌شه، ولی تا وقتی که این ماجرا به صورت یه اصل تو ذهنتون باشه، عملا خودتون رو از یکی از مهم‌ترین ابزارهای یادگیری محروم کردین. روی دیگه سکه اینه که هرکدوم از اون‌ها مهارت‌های بالایی دارن و تصمیم‌گیری‌های خیلی خوبی هم می‌کنن که می‌تونه برای شما آموزنده باشه. دقت در کارها و تصمیم‌های مدیر پروژه‌هایی که در اطراف خودتون دارین و تجزیه و تحلیل اون‌ها «با توجه به توصیه‌ها، …
چهار نوع رابطه برای زمان‌بندی وجود داره و اکثر برنامه‌ریزها آزادانه از این چهار نوع استفاده می‌کنن (اشتباه!).
خیلی وقت پیش، وقتی که قرار بود برای یه طرح شیوه‌نامه برنامه‌ریزی تهیه کنم، یکی از بندهایی که گذاشتم این بود که برنامه‌ریز باید سعی کنه اکثر روابطش رو با FS پیاده‌سازی کنه. این رو به این خاطر گفته بودم که به تجربه بهم ثابت شده بود که بقیه روابط شبکه رو ضعیف می‌کنن و نتایجی که تو این حالت از برنامه می‌گیریم کیفیت مناسب ندارن.
مدتی بعد که مشغول خوندن استانداردها شدم، دیدم که PMBOK، استاندارد زمان‌بندی PMI و PRINCE2 همگی تاکید می‌کنن که باید تا جای ممکن از FS استفاده کرد. این ماجرا رویکرد من رو به این ماجرا تاکید کرد.
مدت‌ها بعد از اون گه‌گاه به این ماجرا فکر می‌کردم و تحلیلش می‌کردم، تا جایی که وقتی داشتم یه منبع آموزشی برای پراجکت تهیه می‌کردم، توش از طرف خودم توصیه کردم که سعی کنن بیشتر از ۹۰ درصد روابط رو با FS بسازن، چون تا اون موقع به این نتیجه رسیده بودم که استفاده از سایر روابط معمولا توجیه اصولی نداره و صرفا ناشی از اشتباه برداشته.
نکته جالب اینه که مدتی بعد یکی از دستورالعمل‌های وزارت دفاع آمریکا رو می‌خوندم که به پیمانکارانشون ابلاغ می‌شه. جایی تو اون دستورالعمل گفته بود که اگه تعداد روابط FS یه برنامه‌ای کمتر از ۹۰ درصد باشه، اون برنامه از نظرشون مردوده.
الان در حال تدوین یه مجموعه آموزشی مالتی‌مدیای نرم‌افزار پراجکت برای سازمان فنی و حرفه‌ای هستم. این مجموعه آموزشی نرم‌افزار پراجکت رو همراه با اصول و مفاهیم برنامه‌ریزی و کنترل پروژه توضیح میده. عملا دوره آموزشی رو طوری دارم تنظیم می‌کنم که مخاطب تا پایان دوره دانش و مهارت‌های کافی برای برنامه‌ریزی و کنترل تمام جنبه‌های رایج در پروژه‌های ساده رو داشته باشه.
ویژگی مهم این دوره اینه که صرفا بر قابلیت‌های نرم‌افزار متمرکز نیست و حتی می‌تونم بگم که بیشتر از اون بر اصول و مفاهیم برنامه‌ریزی و کنترل پروژه متمرکزه. یه پروژه ساختمانی رو در نظر گرفتم و از ابتدا تا انتهای کار اون رو همراه با خواننده برنامه‌ریزی و کنترل می‌کنیم.
این مجموعه برای آموزش استاندارد پراجکت در مراکز فنی و حرفه‌ای به کار خواهد رفت. دوره‌هایی تشکیل می‌شه که این مجموعه در اختیار داوطلب قرار می‌گیره تا اون رو بخونه و بعد تو کلاس همراه با استاد مثال‌های بیشتر حل کنه و رفع اشکال کنه. تو پایان دوره هم آزمونی برگزار می‌شه و داوطلب‌هایی که تو آزمون موفق بشن گواهی فنی و حرفه‌ای این نرم‌افزار رو می‌گیرن.
خبر خوب اینه که به من اعلام کردن که نسخه کامل این دوره آموزشی رو تو سایت فنی و حرفه‌ای منتشر می‌کنن تا هر فردی که مایل بود بتونه به طور رایگان ازش استفاده کنه. بنابراین کسانی که به دنبال چنین منبعی هستن گوش به زنگ باشن که بعد …
تو اکثر نرم‌افزارهای برنامه‌ریزی دو جور هزینه وجود داره:
هزینه‌ای که بر اساس کارکرد منابع تعریف می‌شه
هزینه مستقل از منبع
هزینه مستقل از منبع پراجکت تو فیلد Fixed Cost وارد می‌شه. اگه مقداری تو فیلد Cost وارد کنین هم عملا مابه‌التفاوتش با هزینه منابع (اگه وجود داشته باشه) می‌ره تو همون فیلد Fixed Cost.
یه راه دیگه برای تعریف هزینه‌های مستقل از منبع تو پراجکت، استفاده از منابع هزینه هست (منظور Cost Resourc هست). می‌دونم که اسمش به نظر عجیب میاد، ولی این نوع منبع با منابع معمولی، یعنی منابع انسانی و ماشین آلات و مصالح فرق داره و عملا برای پیاده‌سازی هزینه‌های مستقل از منبعه. امتیازش به Fixed Cost اینه که انعطاف‌پذیری بیشتری داره و می‌شه باهاش هزینه‌های ثابت رو دسته‌بندی کرد و …
فقط مشکلش اینه که منابع هزینه تو محاسبات تحلیل ارزش کسب شده در نظر گرفته نمی‌شن. مایکروسافت فلسفه‌ای برای این ماجرا داره، ولی در هر حال باعث می‌شه که این فیلد زیاد کاربردی نباشه.
راه تعریف هزینه‌های مستقل از منبع تو پریماورا، استفاده از expense هست. رفتارش نزدیک به منابع هزینه پراجکته، ولی بر خلاف اون تو محاسبات تحلیل ارزش کسب شده هم میاد.
این از هزینه مستقل از منبع. هزینه وابسه به منبع هم که با منابع تعریف می‌شه.
تو پراجکت دوتا فیلد Fixed Cost Accrual برای هزینه‌های مستقل از منبع و Accrue At برای هزینه‌های …
خیلی وقت‌ها لازمه که برای باقیمانده کارها برنامه تهیه بشه یا اصولا وقتی که برنامه تهیه می‌شه قسمتی از کار انجام شده. خیلی‌ها تو این شرایط فقط قسمت‌های باقیمونده رو تو برنامه وارد می‌کنن و دارم این مطلب رو می‌نویسم که با تمام وجود تاکید کنم که:
گستره برنامه زمان‌بندی تو هر شرایطی باید کامل باشه
اگه از شما می‌خوان که برنامه‌ای برای باقیمونده کارها بنویسین، باز هم باید شامل تمام کارها بشه. می‌تونین یه دسته‌بندی فرعی برای برنامه درست کنین که قسمت‌ها باقیمونده رو جدا کنه یا فیلتری بسازین که فقط باقیمونده‌ها رو نمایش بده.
اگه برنامه‌تون کامل نباشه تو خیلی جاها دچار مشکل می‌شین که شاید مهم‌ترینش محاسبه پیشرفت‌ها باشه. بعدا اگه بخواین روی محاسبه تاخیرها کار کنین هم گرفتار می‌شین.
این متن برای اعلام خبر کتاب جدیدمه، ولی این دفعه یه تفاوت عمد وجود داره: کتاب رو الکترونیکی و رایگان منتشر کردم.
در نتیجه می‌تونین همین الان اون رو دانلود و مطالعه کنین. برای این کار به صفحه معرفی کتاب مراجعه کنین.
کتاب نزدیک به صد صفحه‌س و حجمش هم کمتر از 7 مگابایت.
تو این کتاب هر مسئله‌ای که به تدوین ساختار شکست کار مربوط می‌شده رو توضیح دادم. استانداردهای PMBOK و PRINCE2 و صد البته استاندارد ساختار شکست کار PMI هم توش به تفصیل توضیح داده شده. فکر می‌کنم حتی افراد پرسابقه هم بتونن تو بخش‌های آخر کتاب مطالب جالبی پیدا کنن.
سوال‌های اینطوری خیلی زیاده و خیلی‌ها در مورد انواع اصطلاح‌هایی که برای قرارداد به کار می‌ره گیج می‌شن. تو این مطلب یه مقدار در مورد انواع قرارداد توضیح می‌دم، ولی مهم‌تر از اون دو نکته رو بهتون می‌گم که بهتون کمک می‌کنه مشکلاتتون رو تو فهم ماجراهای این حوزه راحت‌تر حل کنین:
اصلاح‌های قراردادی (مثل چنتایی که مثال زدم) تعریف خیلی دقیقی ندارن و خیلی وقت‌ها تو متن‌های مختلف با معنی‌های کمابیش متفاوتی به کار می‌رن. از طرف دیگه، تصورهای نادرستی هم در مورد بعضی از اون‌ها هست و بعضی از متن‌ها اون‌ها رو اشتباه توضیح می‌دن. مثلا Turnkey تو بیشتر از نصف متن‌های انگلیسی که می‌شه تو اینترنت پیدا کرد اشتباه توضیح داده شده! باور کنین!
قراردادها رو از چند جهت می‌شه دسته‌بندی کرد و هر نوع دسته‌بندی هم اصطلاح‌های خودش رو داره، در نتیجه این دو گروه اصطلاح رو نمی‌شه با هم مقایسه کرد. مثلا Lump Sum و EPC رو نباید با هم مقایسه کنیم، چون یکی درباره قیمت قرارداده و اونیکی درباره ارتباط ارکان پروژه.
خوب، این دو نکته رو همیشه در نظر داشته باشین تا کمتر سردرگم بشین. حالا یه مقدار هم دسته‌بندی‌ها رو توضیح می‌دم.
دسته‌بندی اول بر اساس مبلغ قرارداده، یعنی همون چیزی که تو حوزه دانش مدیریت تدارکات پم‌باک هم توضیح داده می‌شه. قراردادها رو از نظر طبیعت قیمتشون به …
منظور از شبکه منطقی فعالیت‌ها، رابطه بین اون‌ها و به عبارت دیگه پیش‌نیازی‌هاس. اگه هر فعالیت رو یه نقطه در نظر بگیریم و رابط بین اون‌ها رو خط‌هایی بین نقطه‌ها در نظر بگیریم، یه شبکه به وجود میاد. این شبکه باید یه مجموعه پیوسته باشه و تمام نقطه‌ها رو به شکل مناسبی به همدیگه وصل کنه. اگه اینطور نباشه، می‌گیم که شبکه ناقصه.
وقتی شبکه منطقی فعالیت‌ها ناقص باشه، ممکنه همین الان زمان‌بندیمون مناسب به نظر بیاد، ولی یه مدت بعدش که مقدارهای واقعی رو وارد کردیم و برنامه به روز شد و انتظار داشتیم که باز هم زمان‌بندی جدید و پیش‌بینی‌های درستی بگیریم، با جواب‌های عجیب و غریب روبرو بشیم.
برای این‌که شبکه منطقی فعالیت‌ها رو کامل کنیم، باید طبیعت اون‌ها رو به خوبی بشناسیم و تمام وابستگی‌های بین فعالیت‌ها رو وارد کرده باشیم. این از اون جاهاییه که باید مدت زمان خیلی زیادی رو صرف جمع آوری اطلاعات از بقیه اعضای تیم پروژه بکنین. به نظر من این قسمت از برنامه‌ریزی زمان‌برترین قسمتشه و قطعا یکی از قسمت‌های خیلی مهمش هم هست.
در مورد شبکه منطقی فعالیت‌ها یک قاعده وجود داره، که مثلا تو استاندارد برنامه‌ریزی PMI هم هست:
تو هر برنامه نباید بیش از یک فعالیت بدون پیش‌نیاز و بیش از یک فعالیت بدون پس‌نیاز باشه.
خیلی‌ها به من ایمیل می‌دن و می‌پرسن که واقعا نیازی به رعایت این قاعده هست یا نه. جواب من اینه: بله، …
اکسل تو اکثر کارها لازمه و تو کار ما، بدون اکسل تقریبا فلج خواهیم بود. با این حال مدتیه متوجه یه مشکل خیلی بزرگ شدم: استفاده نابجا از اکسل!
تقریبا 10 سال پیش بود که وضعیت یه پروژه خیلی نامناسب بود و کارفرما می‌خواست پیمانکار رو خلع ید کنه. پذیرفت که یه شانس دیگه به پیمانکار بده تا با یه تیم مدیریت پروژه جدید کار رو پیش ببره. من یکی از اعضای تیمی بودم که به اون کارگاه رفتیم، کار رو از تیم قبلی تحویل گرفتیم و بعد از 2 سال کار رو به شکل مناسبی تموم کردیم و کارفرما هم راضی شد. یکی از تجربه‌های جالب من تو اون پروژه (که ربطی به این بحث نداره، ولی گفتنش جالبه)، اینه که مدیر پروژه بعد از یک هفته تعداد نیروهای کارگاه رو نصف کرد، ولی قراردادهای همه رو از روزمزد به کنترات تبدیل کرد. نتیجه این بود که راندمان بیشتر از 2 برابر شد. یعنی با این‌که نیروها نصف شده بودن، کاری که انجام می‌شد بیشتر از قبل بود. به تدریج با حفظ همین راندمان تعداد نیروها هم زیاد شد و نتایج بیشتری می‌گرفتیم.
یکی از اولین چیزهای عجیبی که تو اون کارگاه دیدم، دستورکارها بود. دستورکارها رو سرپرست کارگاه قبلی تهیه می‌کرد، می‌داد به سرپرست نظارت و اون هم پس از تایید ابلاغش می‌کرد به سرپرست کارگاه. خیلی از دستورکارها دیتیل‌های اجرایی داشتن، نقشه‌های کوچیک. چیزی که باعث شد تعجب کنم این بود که سرپرست کارگاه تمام نقشه‌ها رو تو اکسل …
به نظر شما مدیر پروژه باید وقتش رو بیشتر از هر چیز صرف چه کاری کنه؟
پم‌باک تاکید می‌کنه که بیشترین وقت مدیر پروژه باید صرف ارتباطات بشه. تو آزمون PMP سوال‌هایی هست که گزینه درستش اینه: 90% زمان مدیر پروژه باید صرف ارتباطات بشه.
تمام مدیر پروژه‌های موفقی که پا به سن گذاشتن هم این مسئله رو تایید می‌کنن. ولی متاسفانه خیلی‌ها اینطور نیستن. چرا؟ به خاطر این‌که مجبورن وقتشون رو صرف کارهای دیگه بکنن. تکلیف چیه؟ خیلی مشخصه، باید برای انجام اون کارها راه حل‌ها یا افراد دیگه‌ای رو پیدا کنن و وقتشون رو بذارن برای اون کارهایی که واقعا وظیفه مدیر پروژه‌س. من که به جرات می‌تونم ادعا کنم که بیشتر از 70% زمان مدیر پروژه‌هایی که تا حالا دیدم (به جز بعض استثناها) صرف کارهایی می‌شه که اصلا تو حوزه مدیریت پروژه نیست. باید بپذیریم که خیلی‌ها هنوز مفهوم درست مدیریت پروژه رو نمی‌دونن.
چند روز پیش داشتم یه کتاب صوتی در مورد زبان‌شناسی گوش می‌دادم. یه افسانه قدیمی در مورد برج بابل هست. گروهی از بابلی‌ها مشغول ساختن برج بلندی شدن که اون‌ها رو به آسمان‌ها (محل خدایان) می‌رسوند. خدایان ترسیدن و تصمیم گرفتن کاری کنن که پروژه اون‌ها شکست بخوره. بهترین راه حلی که به نظرشون رسید این بود: کاری کردن که اون مردم که قبلا همگی به یک زبون حرف می‌زدن، هرکدوم زبان متفاوتی پیدا کردن.
قبلا درباره گواهی CSM (مخفف Certified ScrumMaster) مختصری نوشته بودم. CSM شناخته شده‌ترین گواهی اسکرام (سبکی در مدیریت پروژه چابک) هست. بعضی‌ها اعتقاد دارن که PSM (مخفف Professional ScrumMaster) با وجود این‌که کمتر از CSM شناخته شده هست، قوی‌تر و قابل اتکاتره.
موضوع در واقع گواهی PSM I هست. این گواهی رو موسسه Scrum.Org میده که علاوه بر اون گواهی PSM II (پیشرفته‌تر)، یه گواهی برای Product Ownerها و یه گواهی دیگه برای Developerها هم داره.
برای شرکت در امتحان نیازی نیست که حتما دوره PSM رو هم گذرونده باشین، ولی تو سایتش تاکید زیادی شده که امکان موفقیت برای کسایی که دوره رونگذروندن خیلی کمه. به نظر من هم کسی که نخواد تو دوره شرکت کنه باید خیلی جدی و سنگین مطالعه کنه. علاوه بر اون، دوره CSM که یکی از معدود دوره‌هایی بوده که تو زندگیم تجربه کردم، به خاطر تسلط مدرس (هنریک نیبرگ) به شیوه تدریس، بسیار جالب، آموزنده و هیجان انگیز بود. اگه توانایی مدرس این دوره حتی نصف هنریک هم باشه، باز ارزش شرکت کردن داره. ظاهرا این مدرس هم سابقه زیادی تو کارش داره.
Scrum.Org یه منبع 17 صفحه‌ای در مورد اسکرام داره که جمع‌بندی ماجراس و به نظر من کسی که می‌خواد موضوع رو خوب بفهمه و تو امتحان هم موفق باشه حتما باید اون رو به دقت خونده باشه و فهمیده باشه. این کتاب برای یادگرفتن اسکرام مناسب نیست، فقط برای …
وقتی آدم می‌تونه مفهوم یه روش مدیریت پروژه، مثلا پم‌باک، رو خوب بفهمه، که اون رو با روش‌های دیگه مقایسه کنه. به نظر من می‌شه جنبه‌های مدیریتی مطرح شده تو استانداردها رو به سه حوزه تقسیم کرد:
مدیریت چهارچوب‌های مدیریت پروژه
مدیریت کلان پروژه
مدیریت تفیصلی پروژه
مثلا یکی از کارهایی که باید تو پم‌باک انجام بدیم، اینه که فرآیندهایی که قراره تو پروژه به کار برن و شکل به کار رفتنشون رو مشخص کنیم. این می‌شه چیزی که بهش گفتم “مدیریت چهارچوب‌های مدیریت پروژه”.
حالا این سه جنبه مدیریتی اگه بخوایم تو پم‌باک، پرینس2 و اسکرام مقایسه کنیم، مسئولیت‌های مدیریتی مدیر پروژه (یا اسکرام مستر) تو سیستم‌های مختلف عملا به این شکله:
پم‌باک
پرینس۲
اسکرام
مدیریت چهارچوب‌ها
بله
بله
بله
مدیریت کلان
بله
بله
خیر
مدیریت تفصیلی
بله
خیر
خیر
با این توضیح که هم پم‌باک اجازه میده که مدیریت تفصیلی به عهده مدیر پروژه نباشه و هم پرینس2 اجازه میده که مدیر پروژه مدیریت تفصیلی رو به عهده بگیره؛ چیزی که تو جدول نوشتم گرایش پیش‌فرض هرکدوم از این استانداردها و چیزیه که مخاطب رو به اون سمت هدایت می‌کنن.
این تفاوت‌ها خیلی جالبن. تو پم‌باک مدیر پروژه عملا در مورد تمام برنامه‌ریزی‌ها مسئوله و برنامه‌ریزی تو این استاندارد همیشه تفصیلیه، مگر این‌که امکانش نباشه. مثال ریتا رو همیشه خیلی می‌پسندم. اگه تو دفتر پروژه …
چند وقت پیش یه ایده‌ای به ذهنم رسید و بعد از پیاده‌سازیش کاملا راضی بودم. محصولش اینه:
این یه فیلد اختصاصیه که پیشرفت فعالیت‌ها رو به صورت تصویری نشون میده.
شاید تعجب کنین که چطوری می‌شه تو یه فیلد اختصاصی تصویری به جز آیکن‌های از پیش تعریف شده پراجکت نشون داد. این روش خیلی قدیمیه و زمان داس برای نشون دادن گرافیک‌های ساده استفاده می‌کردیم. این نمودارها با دو کارکتر █ و ░ ترسیم شدن. فرمول اینه:
فکر می‌کنن اگه می‌خوان کاری خوب انجام بشه، باید روش اسم پروژه بذارن و با ابزارهای پروژه مدیریتش کنن.
فکر می‌کنن اگه جایی داره پروژه اجرا می‌کنه باید پروژه محور باشه و پروژه محور بودن صفت الزاما مثبتیه.
هر چیزی پروژه نیست
اگه کاری پروژه نباشه و سعی کنین وانمود کنین که پروژه‌س و بخواین با ابزارهای مدیریت پروژه پیش ببرینش اوضاع بهتر می‌شه؟
نه، احتمالا بدتر هم می‌شه. مدیریت هر کاری ابزارهای خودش رو داره. باید ماهیت واقعی اون کار رو بشناسین و با ابزارهایی که موفقیتشون رو تو اون کار اثبات کردن پیش ببرینشون.
پروژه محور بودن به معنی حرفه‌ای بودن نیست
اصلا “پروژه محور” یعنی چی؟
پروژه محور بودن به این معنی نیست که کار یه شرکت پروژه‌ای باشه. پروژه محور بودن سازمان‌دهی شرکت رو مشخص می‌کنه. اگه یه شرکتی برای هرکدوم از پروژه‌هاش جداگانه نیرو استخدام کنه و همشون تا حد زیادی به لحاظ فنی و اجرایی از دفتر مرکزی مستقل باشن، سازماندهیش می‌شه پروژه محور. یعنی اگه نیروهایی که برای یه شرکت استخدام شدن رو بشه صرفا بر اساس پروژه تقسیم‌بندی کرد، می‌شه پروژه محور. اگه این آدم‌ها تو گروه‌های تخصصی (دپارتمان‌ها) تقسیم شده باشن و به پروژه‌های متعدد سرویس بدن، دیگه پروژه محور نخواهند بود (کارکردی یا ماتریسی می‌شن).
سازمان‌دهی پروژه محور نکات مثبت و منفی خاص خودش رو داره. مثبتش به …
مهم‌ترین نکته اینه که یکی از این دو روش رو انتخاب کنین و کاملا بهش پایبند باشین. اگه نیمه کاره یکی از این دو راهکار رو در پیش بگیرین، برنامه‌های خیلی نامناسبی به وجود میاد.
زمان‌بندی با انتهای آزاد
تو این حالت هیچ عنصر زمانی نباید وارد کنیم که حرکت فعالیت‌ها رو به سمت آینده محدود بکنه. تمام عناصر فقط دوست دارن همه چیز رو به سمت آینده هل بدن.
فرجه و قیدهای “دیرتر از … شروع نشود”، “دیرتر از … تمام نشود”، “حتما در … شروع شود” و “حتما در … تمام شود” همه دوست دارن به شکلی مانع حرکت فعالیت به آینده بشن و در نتیجه نباید استفاده بشن.
خیلی از فعالیت‌ها محدودیت‌های تاریخی دارن. حداقلش اینه که کل پروژه نباید بعد از تاریخ خاصی تموم بشه. می‌تونین این تاریخ‌ها رو تو یه فیلد اختصاصی وارد کنین. تو زمان اجرا هم باید تاریخ‌ها رو چک کنین تا ببینین تاریخ‌های برنامه‌ریزی شده دیرتر از تاریخ‌های تعیین شده نباشن.
تو این حالت مثلا Finish Variance می‌تونه بهتون بگه که فعالیت‌ها چقدر به تاخیر افتادن.
زمان‌بندی با انتهای مقید
تو این حالت باید تمام قیدهای زمانی رو وارد کنین. یه قید “دیرتر از … تمام نشود” برای پروژه داریم و اگه تو قرارداد یا صورت جلسات تاریخ‌های دیگه‌ای هم مشخص شده باشه، باید اون‌ها رو هم به …
