گریزی بر پیدایش مدیریت پروژه

اسامی بسیاری را در سال های گذشته در مورد مدیریت پروژه شنیده ایم، از راه کارهای کلاسیک و ساده مثل MSP (Microsoft Project) تا ساخت یافته های جدیدی مثل جیرا. اولین تجربه ی مدیریت پروژه برای بشر قطعا برای زمان غارنشینی بوده است. زمانی که پروژه ی تعریف شده برای انسان تلاش برای بقا بوده است و انسان های آن روزگار نمی دانستند که در حال مدیریت چگونه پروژه ای هستند. بعدها بزرگترین های تاریخ قطعا دارای مدیریت پروژه بوده است به عنوان مثال پروژه های جنگی مثل حمله مغول، در تاریخ می خوانیم در برخی از لشکرکشی ها تعداد سربازان 130 هزار، تعداد اسب همراه 500 هزار و تعداد احشام همراه اعم از قاطر و شتر و گوسفند چیزی بالغ بر 2 میلیون بوده است که قطعا مدیریت تامین آذوقه ی آن یک پروژه ی تمام عیار است تا پروژه های عمرانی مثل دیوار چین، اهرام ثلاثه و تخت جمشید که شاهکار مدیریت زمان خود و حتی زمان حال است چرا که ساخت زیر بنای سنگی با وسعت 125 هزار متر مربع، با ساختاری یکسان و مهندسی یکپارچه به مدت 120 سال، یک شاهکار مدیریتی است.

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

اکنون باید بتوانیم نتیجه گیری کنیم که چرا به مدیریت پروژه نیاز داریم، ما در واقع به برنامه ریزی و مدیریت منابع و کنترل شرایط برای رسیدن به هدف نیاز داریم. برای کنترل این شرایط است که مفاهیم دیگری شکل می گیرد و برای همین کنترل است که قاعده و استاندارد سازی مدیریت پروژه به وجود می آید و مفاهیمی مثل پیکره دانش مدیریت پروژه یا PMBOK (Project Management Body of Knowledge) ظاهر می شود. عناوینی که در این استاندارد عنوان شده است به شرح ذیل می باشد:

1. مدیریت یکپارچگی پروژه یا Project Integration Management
2. مدیریت محدوده پروژه یا Project Scope Management
3. مدیریت زمان پروژه یا Project Time Management
4. مدیریت هزینه پروژه Project Cost Management
5. مدیریت کیفیت پروژه یا Project Quality Management
6. مدیریت منابع انسانی پروژه یا Project Human Resources Management
7. مدیریت ارتباطات پروژه یا Project Communications Management
8. مدیریت ریسک پروژه یا Project Risk Management
9. مدیریت تدارکات پروژه یا Project Procurement Management
10. مدیریت ذینفعان پروژه یا Project Stakeholder Management

مدیریت اجزا، زمان، هماهنگی گروهی، تهیه و مدیریت تجهیزات، تامین نیروی کار مورد نیاز همه و همه نیازمند شناخت پروژه است. تا زمانی که هر کاری مبهم باشد و ابعاد دقیق آن مشخص نباشد تعیین زمان رسیدن به اتمام پروژه میسر نخواهد بود.

شناخت یک پروژه نیاز به شناخت اجزای کامل آن دارد یعنی ابتدا باید بخش های مختلف یک پروژه شناسایی شود و ابعاد آن به وضوح نمایان گردد تا بتوان برای آن، مقادیر زمان، هزینه، نیروی انسانی و تجهیزات مورد نیاز را تخمین زد. در صورتی که تخمین درستی زده باشیم و این تخمین ها را براساس اصول ذکر شده در استاندارد PMbok، مدیریت نماییم، پروژه با موفقیت به اتمام می رسد و مدیریت پروژه به درستی انجام شده است. برای درک ابعاد پروژه و بخش های مختلف آن مفهوم دیگری در مدیریت پروژه به نام ساختار شکست کار یا WBS (Work Breakdown Structure) به وجود آمد.

برای ایجاد ساختار شکست کار قواعدی وجود دارد اما ایجاد این ساختار به مقدار بسیار بالایی به پارامترهای PMbok وابسته است. در صورتی که محدودیت هایی بر روی پروژه اعمال شده باشد این محدودیت ها بر روی شکل گیری ساختار شکست کار تاثیر می گذارد. به عنوان مثال پروژه هایی که باید در زمان مشخصی به پایان برسند و یا پروژه هایی که نیاز به تجهیزات و یا نیروی انسانی خاصی دارد که این تجهیزات و نیرو دارای محدودیت زمان بهره هستند و یا مبلغ بودجه در نظر گرفته شده برای پروژه از قبل عدد ثابتی تعیین شده است. می توان نتیجه گرفت که مدیریت پروژه و ساختار شکست کار، لازم و ملزوم یکدیگر هستند و هیچ کدام بر دیگری ارجحیت ندارد و تا زمانی که یکی نباشد دیگری هم معنایی ندارد اما در نهایت ساختار شکست کار باید شکل بگیرد و بنا بر شرایط می تواند با گرایش عناصر تحویل شدنی، با گرایش برنامه زمانی و یا با گرایش منابع پروژه تشکیل شود. با این توضیحات بهتر و بیشتر در مورد چگونگی شکل گیری ساختار شکست کار می دانیم اما با این حال هم هنوز برای ساختار تشکیل این ساختار قواعدی(Rule) وجود دارد که به شرح ذیل می باشد:

1. قاعده 100 درصد یا rule 100%: ساختار شکست کار باید جامع و مانع باشد، یعنی تمام کارهای پروژه را در خود جای دهد و کار اضافه ای نیز نداشته باشد. این قاعده باید علاوه بر کل ساختار شکست کار، در تمام سطوح و زیرمجموعه های آن نیز برقرار باشد.
2. قاعده تشکیل ساختار بر اساس تحویل شدنی ها یا Deliverable Oriented: درست است که گرایش اصلی تعریف شکست می تواند براساس شرایط و موقعیت های برنامه زمانی و منابع پروژه باشد اما با این حال عناصر ساختار شکست کار با توجه به تمامی محدودیت ها و الزامات باید براساس تحویل شدنی های پروژه باشد و در پایین ترین سطح، به فعالیت ها ختم خواهد شد. ساختار درباره کارهای پروژه است، ولی عناصر کلان تر آن از جنس کار نیستند، بلکه از جنس تحویل شدنی ها هستند. هرچه عنصری در ساختار شکست کار بالاتر قرار داشته باشد، باید تحویل شدنی مهمتر و کلان تری در پروژه باشد.
3. قاعده سلسله ای و درختی یا Coding scheme: در تعریف ساختار، عناصر پیشین و پسین باید مشخص شده باشد یعنی باید مشخص باشد کدام عنصر قبل از عنصر دیگر تکمیل می گردد و نیز کدام عنصر پیش نیاز عنصر دیگر است.
4. قاعده عناصر منحصر به فرد و قابل ارزیابی یا Mutually exclusive elements: نمی توان در تعریف شکست کار از عبارت کلی و با ویژگی های کیفی استفاده نمود بلکه هر عنصری باید زمان شروع، زمان انجام، منابع آن (اعم از نیروی انسانی و تجهیزات) و بودجه مورد نیاز آن قابل محاسبه و تخمین باشد.
5. قاعده سطح شکست کارها یا Level of Detail: یکی از مواردی که همیشه مورد توجه بوده این است که ساختار شکست کار براساس قواعد بالا را تا کجا باید ادامه و در واقع این شکست تا کجا باید کوچک شود؟ برای این سوال نیز قاعده ای به نام سطح جزییات و یا Level of Detail وجود دارد که دارای قواعد ذیل است:
   1. قاعده 8/80: هیچ عنصری به عنوان فعالیت در پایین ترین سطح جزییات WBS، مقدار زمان اتمام آن باید بین 8 تا 80 ساعت باشد و از این مقدار نباید تجاوز نماید.
   2. تمام فعالیت ها در پایین ترین سطح جزییات WBS نباید طولانی تر از یک دوره ی گزارشی برای هر واحد اجرایی باشد. بنابراین اگر تیم پروژه پیشرفت ماهانه را گزارش کند، هیچ فعالیت واحد اجرایی نباید بیش از یک ماه طول بکشد.