برنامه جامع مدیریت پروژه _ بررسی نمونه موردی پروژه سیمرغ پنتاگون_ بخش اول

در آن لحظه، پروژه ققنوس به پروژه جدیدی در برنامه نوسازی پنتاگون تبدیل شد. این پروژه، بازسازی بخش هایی از پنتاگون را که در اثر حمله به شدت آسیب دیدند، در محدوده خود داشت . منطقه کار از راهروی 4 تا راهروی 5 و حلقه های C،D و E گسترش یافت که تقریباً 400 هزار فوت مربع از پنتاگون را شامل می شد. نیمی از منطقه آسیب دیده در بخش 1 پنتاگون و نیمی دیگر از منطقه در بخش 2 قرار داشت. محدوده کار شامل تخریب ساختار آسیب دیده، بازسازی هسته و پوسته در بخش 1 و پوسته برای بخش 2 بود. کار اصلی، زیرساخت مشترک ساختمان در نظر گرفته می شود که ساکنان را پشتیبانی کرده و پوسته آن به ساختار بتنی محدود می شد.

هدف این پروژه از سر گرفتن مجدد فعالیت در حلقه E در کمتر از یک سال و تا 11 سپتامبر سال بعد، یعنی سال 2002 میلادی بود.

نتایج اجرای پروژه

پروژه ققنوس فراتر از انتظارات مشتری پیش رفت:

پروژه زودتر از موعد مقرر، با بودجه کمتر، با محدوده اجرائی وسیع تر پیش رفت. فعالیت در حلقهE در 15 اوت 2002 مجدداً از سر گرفته شد. وسعت فضای بازسازی شده تحت اشغال حلقه E، تا 11 سپتامبر 2002، بیشتر از برنامه مشخص شده بود.

پروژه ققنوس پیچیده بود و مشکلات و موانع متعددی برای عدم موفقیت پروژه وجود داشت:

• در ماه اول، 646 مشکل و مساله ثبت و پیگیری شد. این عدد معادل 21.5 مسئله در 7 روز کاری است.
• مدیریت زمانبندی با 30 هزار فعالیت.
• تخریب 400 هزار فوت مربع ناخالص سازه که منجر به تولید 56 هزار تن زباله آلوده شد.
• ساخت و نصب نمای سنگ آهک، با استفاده از1941 کارگر ساختمانی.
• 2.5 میلیون پوند سنگ آهک تا 11 ژوئن 2002 ساخته و نصب شد.
• 3 میلیون ساعت کار در یک دوره 11 ماهه ساخت و ساز که تنها 5 روز آن بخاطر حادثه کاری تعطیل شده بود.
• 21 هزار یارد مکعب بتن ریخته شده و 3800 تن فولاد تقویت کننده قرار داده شده بود.
• ساخت و ساز در طول یک سازمان پرتغییر ؛ در پنتاگون، مأموریت‌های سازمان‌های مختلف نظامی هر روز در حال تغییر بود و باعث تجدیدنظر مداوم در برنامه، سیستم ها و تجهیزات این ساختمان می‌شد.
• افزایش محدودیت های امنیتی برای استخدام و دسترسی به سایت نیروی انسانی.

نوآوری های مدیریت پروژه

پروژه ققنوس با نوآوری های مختلفی در زمینه مدیریت پروژه به چالش های مختلفی پاسخ داد:

• مدیریت پروژه یکپارچه از طریق استفاده از یک تیم محصول یکپارچه، تشکیل سریع‌تر تیم های اجرائی، ارتباطات تیم پروژه را بهبود بخشید و برنامه‌های پروژه را یکپارچه‌تر و دقیق‌تر کرد.
• مدیریت زمان از طریق توسعه برنامه “مسیر فوق سریع”، چندین کارگر را قادر می ساخت تا به طور همزمان در چرخه حیات ساخت و ساز، برای نصب اولیه سنگ آهک بیرونی کار کنند.
• مدیریت زمان با صدور نقشه ها، در حالی که هنوز در حال تهیه بودند (Fast Tracking)، امکان سفارش اولیه مواد و برنامه ریزی نیروی انسانی را فراهم می کرد.
• مدیریت تدارکات از طریق استفاده از چرخه حیات پروژه طراحی – ساخت به جای چرخه حیات طراحی – مزایده – ساخت؛ قراردادهای منفرد با قیمت ثابت برای طراحی و ساخت پروژه ققنوس منعقد شد.
• مدیریت تدارکات از طریق استفاده از قرارداد مسئولیت عملکرد کل سیستم؛ پیمانکاران مسئولیت دسترسی و برآورده کردن اهداف و الزامات عملکردی مشخص شده را داشتند.
• مدیریت تدارکات از طریق اجرای قراردادهای قیمت ثابت، هزینه پاداش و هزینه تشویقی (که به مجموع آنها FPAFIF گفته می شود)؛ پیمانکاران انگیزه مالی برای انجام مدیریت پروژه مورد نظر از جمله تکمیل پروژه بر اساس هزینه و زودتر از برنامه را داشتند.

برای دستیابی به اهداف این پروژه، تیم پروژه باید:

• برنامه زمانبندی مقدماتی را مشخص می کرد.
• محدوده پروژه را تعیین می کرد.
• پروژه جدید ققنوس را با فعالیت های پروژه قبلی (توسعه ساختمان پنتاگون که از قبل از حملات ۱۱ سپتامبر برنامه ریزی شده بود)، یکپارچه می کرد.
• اطلاعات هزینه/بودجه را جمع آوری می کرد.
• قراردادهای پیمانکاری با پیمانکاران فرعی و قراردادهای تدارکاتی با تامین کنندگان را نهائی می نمود.
• تجزیه و تحلیل ریسک پروژه را انجام می داد.
• استانداردهای کنترل کیفیت/تضمین کیفیت برای تمام مراحل چرخه حیات پروژه را ایجاد می کرد.
• برنامه ارتباطات داخلی و خارجی را ایجاد می کرد.
• و همچنین برنامه منابع انسانی برای تقویت کار تیمی بین همه پرسنل و همچنین مقابله با تأثیرات عاطفی فاجعه را ایجاد می کرد.

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

چرا که قُقنوس: (Phoenix) پرندهٔ مقدس افسانه‌ا‌ی‌ است که در اساطیر ایران، یونان، مصر و چین از آن نام برده شده. گفته می‌شود که ققنوس، مرغی نادر و تنهاست و جفت و زایشی ندارد. اما هر هزار سال یک بار، بر توده‌ای بزرگ از هیزم بال می‌گشاید و آواز می‌خواند و چون از آواز خویش به وجد و اشتیاق آمد، به منقار خویش آتشی می‌افروزد و با سوختن در آتش از خاکستر آن ققنوسی دیگر متولد می‌شود. در بسیاری فرهنگ ها ققنوس را رمز جاودانگی، فداکاری و عمر دگربار تلقی میکنند.

روش ها و حوزه های دانش مدیریت ویژه ققنوس

ساختار و فرآیندهای تیم پروژه یکپارچه (IPT: Integrated Project Teams):

• تیم های پروژه یکپارچه (IPTs) در برخی از مناطق پروژه های نوسازی بخش 1 و بخش 2 مورد استفاده قرار گرفتند. پروژه ققنوس استفاده از تیم های پروژه یکپارچه را به گروه هایی مانند مدیریت اطلاعات و مخابرات (IM&T) گسترش داد. موفقیت تیم های پروژه یکپارچه در سطح مدیریت، منجر به ایجاد تیم های پروژه یکپارچه غیررسمی توسط خود کارگران برای تصمیم گیری در محل شد. تیم های پروژه یکپارچه، امکان ساخت تیم را فراهم کردند و در فرآیند ارتباطات نقش اساسی داشتند.

نوع قرارداد:

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

مدیریت ریسک:

• در ساختار قرارداد، دولت مقدار فزاینده ای از مسئولیت مدیریت ریسک را به پیمانکار واگذار کرد. هم هزینه های پاداش و هم هزینه های تشویقی، خلاقیت راهکارها و مدیریت هزینه ها را تقویت کردند.
• در داخل، مدیر برنامه دولت به گروه خود گفت که برای مدیریت زمان بندی و کیفیت، خودش بخش هزینه پروژه را مدیریت خواهد کرد.

مدیریت کیفیت:

• بازرسی های روزانه با یک پانچ لیست انجام می شد. تکمیل فرآیندهای کنترل و تضمین کیفیت QA/QC چندین هفته طول می کشید. درعوض، هم دولت و هم پیمانکار، برنامه‌ریزی‌های روزانه را انجام می‌دادند تا تمام کمبودهای کیفی برطرف شود. نوع قرارداد، همچنین بار کنترل کیفیت را بر دوش پیمانکار گذاشت در حالی که دولت مسئولیت اصلی تضمین کیفیت را بر عهده داشت.

توسعه برنامه پروژه

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

نتیجه جلسات تیم پروژه یکپارچه، اینگونه شد که کارکنان درگیر عملیات توانستند سازمان خود را در مورد برنامه های پروژه مطلع کنند. AMEC، پیمانکار اصلی ساخت و ساز، نمونه خوبی از این فرآیند بود. AMEC اصطلاح پاد (Pod) را توسعه داد که معادل یک تیم پروژه یکپارچه (IPT) است. پاد، یک نقطه کانونی برای مرحله خاصی از ساخت و ساز ساختمان بود؛ به عنوان مثال، ساختار و پوسته. پادهای AMEC، متشکل از مهندسان، سرپرست ساخت و ساز، مهندسان کیفیت و مدیر پروژه ارشد بود. مدیر پروژه ارشد حاضر در تیم پروژه یکپارچه، اطلاعات را به پاد ساختار و پوسته AMEC برمی‌گرداند و برنامه‌های AMEC را بر این اساس به‌روزرسانی می‌کرد.

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

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

اجرای برنامه پروژه

اجرای پروژه همزمان با توسعه محدوده، یکپارچه سازی پروژه و سایر فعالیت های برنامه ریزی انجام شد. قبل از نهایی شدن برنامه ها و یا حتی به صورت پیش نویس، پروژه در حال اجرای فعالیت هایی هرچند برنامه ریزی نشده بود. ریسک هائی که این امر می توانست ایجاد کند بسیار بود. از جمله:

• تفسیرهای متفاوت از دستورالعمل ها در بین اعضای پروژه برای اینکه چه کسی، چه زمانی، چه چیزی و در کجا فعالیت ها را اجرا کند.
• شکست در یکپارچه سازی برنامه های پروژه به طور منسجم؛
• بلاتکلیفی / تصمیم های عجولانه / تصمیم های اشتباه؛
• برآورد هزینه و زمانبندی ضعیف؛
• کیفیت پایین و انجام دوباره کاری؛
• نارضایتی مشتری.

پروژه ققنوس با حفظ ارتباط مکرر بین تیم پروژه یکپارچه، استفاده مجدد از سرمایه فکری پروژه های مشابه، استخدام خبرگان این زمینه، ساعات طولانی کار، ساده کردن پروژه به دو هدف (چسبیدن به صندلی (کار) (BIC) در نقطه تأثیر) و یک محدودیت (ساختمان را به همان شکلی که 10 سپتامبر 2001 بود، تبدیل کنید) ریسک پروژه را کاهش داد.

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

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

کنترل یکپارچه تغییرات

اکثر تغییرات در پروژه ققنوس سریع و مکرر بود. قرارداد AMEC به تنهایی 50 میلیون دلار تغییر در یک قرارداد 205 میلیون دلاری داشت.

در اوایل پروژه، مدیریت پروژه ققنوس متوجه شد که مدیریت تغییر، پیشرفت پروژه را متوقف می کند. به همین دلیل، دستیار مدیر پروژه به سایت اعزام شد تا در دسترس باشد و به مسائل و مشکلات رسیدگی کند. جلسات تغییرات، هفته ای یکبار برگزار می شد. در این جلسات، یک فرآیند تغییر تیم پروژه یکپارچه ایجاد شد. فرآیند ایجاد شده، این مراحل را دنبال کرد:

1.  افرادی به عنوان نقطه تماس (POC) پیمانکار و نقطه تماس دولت اختصاص داده شد.
2. گام های تغییر، در جایی که قرار است تغییر رخ دهد، انجام شود.
3. محدوده کار مستند شود.
4. مفروضات بین هر دو طرف را مستند و موافقتشان اخذ شود.
5. پیمانکار، میزان تقریبی فعالیت را با روش (ROM) تخمین زده و ثبت و ارسال می کند. سپس بسته به فوریت تغییر، دولت می تواند یک نامه الحاقیه به قرارداد به همراه عدم تخطی از آن صادر می کرد.
6. جلسه تیم پروژه یکپارچه برای بررسی نهایی برای تأیید یا رد برنامه ریزی تغییرات انجام شود.

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

برای تسریع بیشتر فرآیند مدیریت تغییر، آستانه هایی بر اساس دلار به صورت ردیفی ایجاد شد که تعیین می کرد چه سطوحی از تایید و امضا مورد نیاز است. در پایین ترین آستانه، تغییر در همان جایی که درخواست شده بود، تایید می شد. اجرای آستانه های دلاری زمان تایید درخواست های تغییر را کاهش داد.

پس از تصویب این تغییر، اعضای مربوطه آماده تنظیم خطوط مبنای جدید و اصلاح برنامه ها، بخصوص برنامه مدیریت پروژه بودند.

جمع بندی برنامه جامع مدیریت پروژه

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

لطفا نظر خودتون رو برامون بنویسید.