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

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

قواعد زمانبندی (گانت چارت نویسی) بر اساس استاندارد موسسه PMI آمریکا :
قاعده 1: برنامه مدیریت زمان بندی تهیه و مستند شده باشد.
قاعده 2: گستره برنامه کامل باشد.
قاعده ۳: از فعالیت های Level of Effort با احتیاط استفاده شود.
قاعده 4: نام فعالیت ها منحصر به فرد باشند.
قاعده 5: نام فعالیت ها جمله هایی فعل دار باشند.
قاعده 6: شبکه منطقی فعالیت ها کامل باشد.
قاعده 7: فعالیت ها معلق نباشند.(شروع آن دیگری تاثیر نگیرد و پایان آن بر فعالیتی اثر نگذارد.)
قاعده 8: اکثر فعالیت ها پیش نیاز FS داشته باشند.(90 درصد)
قاعده 9: از رابطه SF استفاده نشود.
قاعده10 : Lag فعالیت ها زیاد از حد نباشد. .( حداکثر 30 روز تقویمی)
قاعده11:تعداد فعالیت های ‌Lag دار زیاد نباشد.(حداکثر 5 درصد)
قاعده 12: از Lead با احتیاط استفاده شود. ( حداکثر 30 روز تقویمی)
قاعده13: فعالیت ها شناوری منفی نداشته باشند.
قاعده 14: شناوری فعالیت ها از حدی بیشتر نباشد.( حداکثر 60 روز تقویمی)
قاعده 15: فعالیت ها Split نشوند.
قاعده 16: تعداد فعالیت های دارای قید تاریخ زیاد نباشد. .(حداکثر 5 درصد)
قاعده 17: فقط مایل ستون ها مجاز به داشتن قید تاریخ هستند.
قاعده 18: مدت زمان فعالیت ها زیاد نباشد. .( حداکثر 60 روز تقویمی)
قاعده 19: فقط از یک واحد زمانی استفاده شود.
قاعده 20 : به ازای تمامی تعهدات قراردادی کارفرما و مشاور (رفع معارضین ، ابلاغ نقشه ها، انحراف ترافیک و …) باید مایلستونی به عنوان پیش نیاز فعالیتهای درگیر در برنامه لحاظ گردد در مواردی که عدم وجود نقشه های اجرایی مانع از ریز کردن سطح فعالیتها می گردد وزن تقریبی به فعالیت مربوطه تخصیص داده شده و پس از کامل شدن نقشه ها برنامه اصلاح گردد.
قاعده 21 : در تنظیم ساختار شکست کار باید اعتدال حفظ شده و نیازی به یکسان کردن تعداد سطوح قسمت های مختلف جهت زیبایی شکل برنامه نمی باشد.
قاعده 22 : مسیر بحرانی پروژه کنترل گردد.( صحت مسیر بحرانی پروژه توسط مشاور تایید می گردد)
قاعده 23 : تاریخ شروع فعالیتهاي پروژه بايد بر اساس میانگین زودترین (ES) و دیرترین (LS) زمان شروع فعاليت ها برنامه ريزي گردد.
قاعده 24 : براي آخرين فعاليت هاي پروژه نبايد قيدي از جمله Finish on يا Finish no Later than گذاشته شود پس انتهای برنامه بايد آزاد باشد.
قاعده 25 : در تقویم پروژه ، بايد روزهای کاری به دقت لحاظ گردد. البته پیمانکار می تواند ایام تعطیلات نوروزی و تعطيلات رسمي كه در آن روزها كارگاه تعطيل است را تقویم روز غیر کاری لحاظ نماید.

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

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

تاریخ‌های مهم این‌ها هستن:

1. تاریخ پایان پروژه

2. تاریخ پایان فعالیت‌هایی که پس‌نیاز ندارن (توضیح 1)

3. فرجه‌ها

4. تاریخ قیدهایی که انعطاف‌پذیر نیستن

توضیح 1: وقتی تاریخ پایان فعالیت‌هایی که پس‌نیاز ندارن در تعیین شناوری‌ها مبنا قرار می‌گیره که گزینه Calculate Multiple Critical Tasks رو تو Tools| Options| Calculation فعال کرده باشین.

حالا ماجرا رو با هم مرور می‌کنیم. برنامه شکل زیر رو ببینین:

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

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

برای فعالیت چهارم فرجه‌ای در پایان روز 9 قرار می‌دم. وضعیت اینطوری می‌شه:

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

حالا به فعالیت ششم قید Finish No Later Than برای پایان روز نهم می‌دم:

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

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

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

این هم همون شناوری منفیه که هر هفته چند نفر با جستجوی اون به سایت من می‌رسن! مفهوم پیچیده‌ای نیست، هست؟

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

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

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

وقتی بین قید و روابط تناقض وجود داشته باشه تکلیف چیه؟

پیش‌فرض اینه که قید مبنا قرار بگیره.

حالا می‌تونین برین تو Tools| Options| Schedule و گزینه Tasks will always honor their constraint dates رو غیر فعال کنین. حالا اگه تناقضی بین قید و روابط وجود داشته باشه اولویت به روابط داده می‌شه. این هم می‌شه وضعیت همون برنامه قبلی، بعد از تغییر تنظیم:

خوب، حالا من قید و فرجه رو برمی‌دارم، یعنی وضعیت برنامه می‌شه مثل اولین شکلی که دیدین (بد نیست الان برگردین بالا و نگاهی بهش بندازین). حالا می‌رم به Tools| Options| Calculate و گزینه Calculate multiple critical paths رو فعال می‌کنم. نتیجه این می‌شه:

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

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

خوب، من امیدوارم این مطالب رو به شما منتقل کرده باشم:

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

• شناوری منفی با ……. به وجود میاد. با چی؟

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

مبانی مقایسه
برخی کارشناسان به پراجکت به عنوان نرم افزار برنامه ریزی و کنترل پروژه علاقه دارند و برخی به پریماورا. از این بین گروهی از کارشناسان به نرم‌افزار مورد علاقه خود تعصب زیادی دارند و این مسئله آغازی است بر این بحث طولانی، که پراجکت بهتر است یا پریماورا.
پیش از هر چیز باید مسئله مهمی را در نظر داشت. Primavera Project Management نرم‌افزاری سازمانی است، در حالی که نسخه‌های معمولی پراجکت این‌گونه نیستند. اگر قرار باشد قابلیت‌های سازمانی مبنای مقایسه قرار گیرند، باید پریماورا را با پراجکت سرور، که نسخه سازمانی نرم‌افزار برنامه‌ریزی و کنترل پروژه مایکروسافت است، مقایسه کرد. در این نوشته به قابلیت‌های غیر سازمانی توجه می‌شود. منظور از برنامه‌ریزی و کنترل پروژه غیر سازمانی، تلاشی است که در راستای مدیریتِ مستقلِ پروژه‌ها انجام می‌شود. در سیستم‌های سازمانی به ترکیبِ پروژه‌های متعددی که در یک سازمان انجام می‌شود و قابلیت‌های کارِ گروهی توجه می‌شود.
کدامیک بهتر است؟

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