مدیریت پروژه , مدیریت ریسک

ورودی‌های مورد نیاز جهت انجام فرایندهای مدیریت ریسک پروژه

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


در ابتدا فهرستی از این ورودی‌ها را می‌توانید مطالعه کنید و در ادامه شرح نسبتآ مختصری از هر یک از این ورودی‌ها:
۱- فرآیندهای مدیریت پروژه Project Management Process
2- اطلاعات پیش‌زمینه پروژه Project Background Information
3- منشور پروژه Project charter
4- خروجی‌های فرایندهای برنامه‌ریزی پروژه Outputs from project planning
4-1- اطلاعات ذینفعان Stakeholder Register
4-2- بیانیه شرح محدوده پروژه Project Scope Statement
4-3- محدودیت‌های پروژه Project Constraint
4-4- فرضیات پروژه Assumption
4-5- ساختار شکست کار Work Breakdown Structure
4-6- شبکه زمان‌بندی پروژه Network Diagram
4-7- برآوردهای زمان و هزینه پروژه Estimates for time and cost
4-8- برنامه منابع Resource plan
4-9- برنامه مدیریت ارتباطات پروژه Communication Management Plan
4-10- برنامه مدیریت تدارکات پروژه Procurement Management Plan
5- دارایی‌های فرایندی سازمان Organizational Process Assets
5-1- سیاست‌ها، دستورالعمل‌ها، رویه‌ها و نمونه‌های مدیریت ریسک Risk management Policies, Procedure, Templates
5-2- سوابق ثبت شده پروژه‌های قبلی Historical Record from Previous Projects
5-3- دروس آموخته پروژه‌های قبلی Lesson Learned from previous Projects
5-4- منطقه‌های حد قابل قبول ریسک Risk tolerance Area
5-5- آستانه‌های تحمل ریسک Risk Thresholds

۱- فرآیندهای مدیریت پروژه Project Management Process
به منظور اتمام سریع‌تر، ارزان‌تر و کیفیت بالاتر پروژه، مدیریت ریسک اثربخش باید در چارچوب مناسبی از فرایندهای مدیریت پروژه انجام شود.
فرایندهای مدیریت پروژه با گروه فرایندی آغازین شروع می‌شود که در این گروه فرایندی منشور پروژه تهیه می‌گردد و ذینفعان پروژه شناسایی می‌شوند. گروه فرایندی برنامه‌ریزی پروژه شامل تهیه برنامه مدیریت پروژه است. برنامه مدیریت پروژه باید دارای سه شرط زیر باشد:

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

۲- اطلاعات پیش زمینه پروژه Project Background Information
اطلاعاتی مثل مکاتبات انجام شده قبل از شروع یا تأیید پروژه، مقاله‌ها و مکتوبات در مورد پروژه‌های مشابه و سایر اطلاعاتی از این دست می‌تواند به شناسایی ریسک‌های بیشتر کمک کنند.
گام‌های زیادی در مدیریت ریسک پروژه وجود دارد و برای کوتاه کردن زمان این قدم‌ها مهم است که همه اطلاعات مرتبط را قبل از شروع پروژه جمع‌آوری کنید. بر اساس اندازه پروژه شما ممکن است اطلاعات زیر را جمع آوری کنید.
 اهداف سازمان
 سیاست‌ها و رویه‌های مدیریت ریسک سازمان
 اولویت پروژه فعلی در مقایسه با سایر پروژه‌ها
 پاسخ‌های مدیریت و مشتری در مورد سوال‌های شما در خصوص منشور پروژه، محدودیت‌ها و مشکلات مرتبط با پروژه
 اهداف زمانی و هزینه‌ای (اگر موجود بود)
 متخصصان و کارشناسان:
 آن‌ها چه افرادی هستند؟
 آن‌ها چه گونه می‌توانند به تیم پروژه در مدیریت پروژه کمک کنند؟
 مقاله و موارد منتشر شده در خصوص ریسک
 موارد فرهنگی
 پروتکل‌های پیشنهادی، تفاوت‌های زبانی و اجتماعی مشتریان
 مرور مستندات مرتبط با پروژه
 تمام ایمیل‌ها و صورتجلسات قبل از تأیید پروژه به خصوص آن‌هایی که از جانب مشتری(کارفرما) بوده است.
 مقالات و مکتوبات فنی و مدیریت پروژه
 کپی قرارداها، استانداردهای مرتبط با پروژه
 مشخصات فنی و نقشه‌ها
 نمودارهای سازمانی
 رزومه اعضای بالقوه تیم
 گزارش‌های بازاریابی و فروش
موارد پایین سوال‌هایی در مورد اطلاعات پیش زمینه پروژه است که ممکن است در زمان شناسایی ریسک‌ها پرسیده شود:
 در ایمیل‌ها به چه مواردی اشاره شده است؟
 آیا شما تا به حال قراردادهای مرتبط با پروژه‌هایتان رامطالعه کرده‌اید؟
 پروژه شما چگونه به برنامه استراتژیک سازمان شما مرتبط است؟
 حمایت مدیریت ارشد از پروژه شما در چه سطحی است؟
 شما چگونه متوجه می‌شوید که یک فهم واضح از الزامات و انتظارات مدیریت و مشتری(کارفرما) در پروژه دارید؟

۳- منشور پروژه Project charter
منشور پروژه یک برنامه مدیریت پروژه نیست، اما یک تعریف سطح بالا از اهداف کلی پروژه از جانب مدیران است. منشور پروژه موجودیت پروژه را رسمی می‌کند و به مدیر پروژه اختیار انجام پروژه و اختیار صرف منابع را می‌دهد، این سند اطلاعات مختصر اما بسیار مهمی در مورد پروژه ارائه می‌کند. منشور پروژه باید توسط مدیریت ارشد یا حامی برای هر پروژه‌ای ابلاغ شود. منشور پروژه باید نهایتاً یک یا دو صفحه باشد و شامل اطلاعات زیر باشد:
نام پروژه و تعریف پروژه: این بخش باید به صورت خلاصه پروژه را تعریف کند.
نام مدیر پروژه و سطح اختیارات: این بخش باید شامل نام مدیر پروژه و اطلاعاتی در مورد میزان اختیارات او در تصمیم‌گیری در مورد بودجه، زمان، جذب نیرو … باشد.
 Business case: در این بخش باید شرح داده شود که چرا پروژه باید انجام شود.
منابع: در این بخش شرح داده می‌شود که چه منابعی و به چه مقدار برای پروژه مورد نیاز خواهد بود.
ذینفعان: ذینفعان پروژه یعنی کسانی که در پروژه منافعی دارند یا از پروژه اثر می‌پذیرند یا بر پروژه اثر می‌‎گذارند.
الزامات ذینفعان: در این بخش الزامات مرتبط با پروژه و محدوده محصول مشخص می‌شود.
تعریف محصول پروژه: این بخش شامل تعریف مشخصات تحویل‌شدنی‌های پروژه که به منظور پایان پروژه مورد نیاز است، می‌باشد.
اهداف قابل اندازه‌گیری پروژه: این بخش انطباق پروژه با اهداف استراتژیک سازمانی را توصیف می‌کند و مشخص می‌کند که پروژه چه اهدافی دارد. (نکته مهم این است که این اهداف باید قابل اندازه‌گیری باشند)
الزامات تأیید پروژه: این بخش شامل الزامات و مواردی است که برای اخذ تأیید پروه در زمان پایان آن مورد نیاز است.
ریسک‌های سطح بالای پروژه: این بخش تهدید‌ها و فرصت‌های سطح بالای پروژه را توصیف می‌کند.
امضا: حامی پروژه با امضای این سند، موجودیت پروژه و اختیارات مدیر پروژه را تصویب می‌کند.

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

۴- خروجی‌های فرایندهای برنامه‌ریزی پروژه Outputs from project planning
4-1- اطلاعات ذینفعان Stakeholder Regist
er
ذینفعان پروژه ممکن است شامل موارد زیر باشند:
 ذینفعان حاضر درسازمان اجراکننده پروژه
 حامی پروژه
 مدیریت
 مدیر پروژه
 تیم پروژه
 سرپرست مدیر پروژه
 سرپرست‌های اعضای تیم پروژه
 دپارتمان تدارکات
 فروشندگان
 واحدهای تصمین کیفیت و کنترل کیفیت
 سازندگان
 واحد حقوقی
 سایر واحدها
 مدیران پروژه پروژه‌های مشابه قبلی
 مدیران پروژه‌ای که قبلاً با این مشتری(کارفرما) کارکرده‌اند.
 ذینفعان حاضر در خارج از سازمان اجرا کننده پروژه
 مشتری
 رقبای مشتری
 مصرف کننده نهایی
 تأمین‌کنندگان و پیمانکاران
 متخصصان
 منابع تأمین مالی

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

۴-۲- بیانیه شرح محدوده پروژه Project Scope Statement
بیانیه محدوده پروژه شامل محدوده پروژه و محصول تأیید شده پروژه است. برای اجرای مدیریت ریسک پروژه، مهم است که بیانیه محدوده پروژه نهایی شده باشد تا میزان پیچیدگی پروژه را توصیف کند.
موارد زیر سوالاتی هستند که در مورد بیانه محدوده پروژه در زمان شناسایی ریسک‌ها ممکن است پرسیده شود:
 کدام قسمت‌های محدوده پروژه کامل نیستند؟
 ذینفعان چه چیزهایی می‌خواهند که در محدوده پروژه نیست؟
 چه کارهایی تا قبل از این هرگز انجام نشده است؟
 شما به عنوان مدیر پروژه کدام کارها را قبلاً(در پروژه‌های قبلی) انجام داده‌اید؟
 در کدام کارها تجربه‌ای ندارید؟
 کدام بخش از بیانیه مدیریت پروژه، غیرشفاف است؟

۴-۳- محدودیت‌های پروژه Project Constraint
بیانیه محدوده پروژه شامل اطلاعاتی در مورد محدودیت‌های پروژه نیز هست. محدودیت‌های پروژه به عنوان یک ورودی مهم به فرایندهای مدیریت ریسک پروژه محسوب می‌گردد. محدودیت‌های پروژه هر چیزی است که در انتخاب‌ها و گزینه‌های تیم پروژه محدودیت ایجاد می‌کند.
به عنوان مثال موارد زیر:
 زمان: پروژه باید در مردادماه سال ۹۸ به اتمام برسد.
 هزینه: پروژه باید با کم‌تر از ۱۰۰ میلیون دلار هزینه به اتمام برسد.
 محدوده/عملکرد: همه کارهای لیست شده باید انجام شوند.
 کیفیت: نباید بیش از سه ایراد در هر بسته کاری باشد.
 ریسک: نمره ریسک پروژه نباید بیشتر از ۶۰ باشد.
 منابع: تنها سه نفر از واحد بازاریابی می‌توانند در پروژه کار کنند.
 مشتری، رضایت ذینفعان: رتبه رضایت مشتری(کارفرما) باید حداقل ۸ باشد.(از مجموع ده نمره)

۴-۴- فرضیات پروژه Assumption
بیانیه محدوده پروژه همچنین شامل اطلاعاتی در مورد فرضیات است. فرضیات مواردی هستند که به عنوان حقیقت و موارد صحیح پذیرفته می‌شوند، ولی ممکن است درست نباشند. فرضیات پروژه ممکن است ریسک‌های پروژه را کاهش یا افزایش دهند و در تعیین میزان اثر ریسک‌های پروژه کمک کنند. این عقاید و نظرات در مورد پروژه باید شناسایی شوند. اعتبار درستی فرضیات باید در طول فرایند آنالیز کیفی ریسک‌ها بررسی شود.
موارد زیر سوالاتی هستند که در مورد فرضیات ممکن است در طول شناسایی ریسک‌ها پرسیده شوند:
 چه فرضیاتی ممکن است بعداً در طول پروژه نادرست از آب دربیایند؟
 چگونه شما می‌توانید از طریق شفاف‌سازی فرضیات از مشکلات احتمالی آینده پروژه جلوگیری کنید؟

۴-۵- ساختار شکست کار Work Breakdown Structure
ساختار شکست کار یکی از خروجی‌های کلیدی برنامه‌ریزی مدیریت پروژه است و وجود آن برای هر پروژه‌ای ضروری است. ساختار شکست کار اجزای پروژه را به تکه‌های کوچک‌تر قابل مدیریت‌تر تقسیم می‌کند که به آن‌ها بسته کاری می‌گویند. بسته‌های کاری پایین‌ترین سطح WBS را تشکیل می‌دهند. این بسته‌های کاری توسط مدیر پروژه مدیریت می‌شوند.
بسیاری از اعضای تیم پروژه به اشتباه معتقدند که مدیریت ریسک فقط یک ارزیابی سطح بالا از پروژه است. در حالیکه مدیریت ریسک بر اساس شناسایی ریسک‌های هر بسته کاری و حتی فعالیت‌های هربسته عمل می‌کند.
موارد زیر سوالاتی هستند که در مورد ساختار شکست کار در زمان شناسایی ریسک‌های پروژه ممکن است پرسیده شوند:
 آیا بسته‌های کاری پر ریسک در ساختار شکست کار پروژه وجود دارد؟
 اجرای WBS چقدر سخت خواهد بود؟
 بر اساس WBS آیا الزامات زمانی و هزینه‌ای پروژه قابل دستیابی خواهند بود؟
 آیا بخشی از محدوده ناقص یا غیرقابل دستیابی است؟

۴-۶- شبکه زمان‌بندی پروژه Network Diagram
شبکه زمان‌بندی پروژه یک نمودار سازماندهی شده بر اساس روابط و تقدم و تأخر فعالیت‌هاست. فعالیت‌ها از خرد کردن بسته‌های کاری در ساختار شکست کار به دست می‌آیند. شبکه زمان‌بندی پروژه جریان فعالیت‌های پروژه را بر اساس روابط پیش‌نیازی بین فعالیت‌ها برای اجرا از شروع تا پایان پروژه نمایش می‌دهد. این ابزار می‌تواند برای کاهش مدت زمان پروژه از طریق موازی‌سازی فعالیت‌ها استفاده شود.
وقتی تاریخ‌ها به هر فعالیت اختصاص داده می‌شود، تبدیل به یک شبکه زمان‌بندی زمان-محور خواهد شد. شبکه زمان‌بندی به مشخص شدن مسیر بحرانی پروژه کمک می‌کند. مسیر بحرانی پروژه در شناسایی ریسک‌های پروژه بسیار مهم است.

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

۴-۷- برآوردهای زمان و هزینه پروژه Estimates for time and cost
به منظور حداقل کردن ریسک‌های پروژه و بهبود صحت برآوردها، برآوردهای هر کاری ترجیحاً باید توسط افرادی انجام شود که انجام دهنده آن فعالیت هستند. بسیاری از مدیران پروژه(یا برنامه‌ریزان پروژه) در زمان برآوردها تنها یک عدد را در نظر می‌گیرند. مطالعات نشان می‌دهد که برآوردها بر اساس تنها یک زمان برای هر فعالیت، ۵ تا ۱۵ درصد احتمال موفقیت دارند. برآوردهای زمان و هزینه باید بر اساس برآورد سه نقطه‌ای باشد: خوشبینانه، محتمل و بدبینانه. نتیجه این برآورد سه نقطه‌ای باید در برآوردها لحاظ گردد. اگر فاصله بین برآورد خوشبینانه و بدبینانه وسیع باشد، برآورد شامل عدم قطعیت بیشتری خواهد بود. این به شما می‌گوید که که ریسک‌های بیشتری باید شناسایی کنید و سپس آن‌ها را حذف یا کاهش دهید.
موارد زیر سوالاتی هستند که در مورد برآوردهای زمان و هزینه در طول شناسایی ریسک‌ها ممکن است پرسیده شوند:
 چه کسی برآوردها را انجام داده است؟
 دانش برآوردکننده از آنچه که برآورد کرده‌اند، چقدر بوده است؟
 سطح اطمینان برآوردکننده تا چه حدی است؟
 آیا برآورد بر اساس فعالیت‌های ریز بوده است یا بر اساس بسته‌های کاری؟
 آیا برآورد بر اساس احتمالات خیلی خوشبینانه بوده است؟
 از چه روشی برای انجام برآورد استفاده شده است؟
 آیا برآورد شامل برآورد دست بالا گرفتن هم است؟

۴-۸- برنامه منابع Resource plan
موارد زیر سوالاتی هستند که در مورد برنامه منابع در طول شناساسیی ریسک‌ها ممکن است پرسیده شود:
 آیا برنامه منابع در پروژه وجود دارد؟
 سطح دانش و مهارت منابع انسانی کافی است؟
 میزان در دسترس بودن منابع در پروژه به مقدار کافی است؟

۴-۹- برنامه مدیریت ارتباطات پروژه Communication Management Plan
برنامه‌ریزی ارتباطات بخشی از فرآیند برنامه‌ریزی پروژه است. ارتباطات یکی از بخش‌های حیاتی در مدیریت ریسک موفقیت‌آمیز است. برنامه مدیریت ارتباطات توسط مدیر پروژه تهیه می‌شود و بخشی از برنامه مدیریت پروژه است و ذینفعان را از شکل ارتباطات در پروژه آگاه می‌سازد. تهیه برنامه مدیریت ارتباطات شامل نیازهای هر یکی از ذینفعان است. این برنامه ممکن است شامل موارد زیر باشد:
 چه اطلاعاتی موردنیاز است که جمع‌آوری شود و در چه زمانی؟
 چه کسانی اطلاعات را دریافت خواهند کرد؟
 روش جمع‌آوری و نگهداری اطلاعات
 محدودیت‌های احتمالی
 روابط گزارش‌دهی
 اطلاعات ارتباطی ذینفعان
 برنامه زمان‌بندی توزیع هر نوع از ارتباطات
 روش‌های ترجیح داده شده ارتباطات

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

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

۴-۱۰- برنامه مدیریت تدارکات پروژه Procurement Management Plan
برنامه مدیریت تدارکات پروژه یک برنامه رسمی یا غیررسمی برای پروژه است تا مشخص کند کدام بخش یا بخش‌های پروژه توسط خود تیم پروژه انجام می‌شود یا برونسپاری می‌گردد. این برنامه همچنین شامل یک برنامه برای مدیریت تمام پیمانکاران/فروشندگان در یک پروژه است. تدارکات می‌تواند برای انتقال ریسک‌ها استفاده شود. اما در صورتی که برنامه تدارکات پروژه بر اساس نیازهای پروژه تهیه نشده باشد می‌تواند باعث ایجاد ریسک‌های بیشتر در پروژه شود.
موارد زیر سوالاتی هستند که در مورد برنامه تدارکات پروژه در زمان شناسایی ریسک ها ممکن است پرسیده شود:
 آیا شما به عنوان مدیر پروژه یا یکی از اعضای تیم پروژه، در تهیه یک قرارداد قبل از امضای آن حضور دارید؟
 چه فعالیت‌های مرتبط با مدیریت ریسک قبل از انعقاد قرارداد انجام می‌شود؟
 سطح تخصص شما در مدیریت قرارداها تا چه حدی است؟
 آیتم‌های خاص و ویژه شرایط پیمان‌های پیمانکاران کدام‌ها هستند؟

۵- دارایی‌های فرایندی سازمان Organizational Process Assets
5-1- سیاست‌ها، دستورالعمل‌ها، رویه‌ها و نمونه‌های مدیریت ریسک Risk management Policies, Procedure, Templat
es
یک شرکت باید سیاست‌ها، رویه‌ها و نمونه‌هایی برای مدیریت ریسک داشته باشد. نمونه‌های که معمولاً رایج است شامل موارد زیر است:
 فرم‌های گزارش‌دهی ریسک
 مقیاس‌های استاندارد تعریف احتمال و اثر
 رویه و دستورالعمل مشارکت ذینفعان در فرایندهای مدیریت ریسک
 سیاست‌هایی که به منظور تهیه برنامه پاسخ به ریسک مودر نیاز است
 استانداردهای رتبه‌بندی ریسک‌ها به منظور تصمیمات ادامه یا توقف پروژه
 رویه و دستورالعمل‌های ممیزی ریسک

۵-۲- سوابق ثبت شده پروژه‌های قبلی Historical Record from Previous Projects
تنها درصد کمی از مدیران پروژه اطلاعات و سوابق پروژه‌های قبلی را در اختیار دارند و به همین خاطر در بعضی مواقع وقتشان تلف می‌شود. آیا می‌توانید تصور کنید شما به ذهن و تجربیات هر کسی در شرکت حق دسترسی داشته باشید؟ چقدر می‌تواند مفید باشد که یک لیست از ریسک‌های همه پروژه‌های اخیر شرکتتان داشته باشید. این ارزش اطلاعات سوابق پروژه‌های قبلی است.
سوابق ثبت شده تاریخی ممکن است شامل موارد زیر باشد:
 فضای پروژه‌های قبلی (شرایط اقتصادی، مشکلات سازمانی، اهداف سازمانی و …)
 خروجی‌های برنامه‌ریزی پروژه
 خروجی‌های مدیریت ریسک
 لیست ریسک‌ها
 لیست دسته‌بندی‌های ریسک
 احتمال و اثر ریسک‌ها
 برنامه‌های پاسخ به ریسک
 روش‌های مورد استفاده به منظور اندازه‌گیری اثربخشی اقدامات مدیریت ریسک
 معیارهای اندزاه‌گیری تعیین شده
 الگوهای پیدا شده

۵-۳- دروس آموخته پروژه‌های قبلی Lesson Learned from previous Projects
سوابق اطلاعاتی پروژه شامل دروس آموخته پروژه نیز است. ثبت دروس آموخته در واقع مستندسازی آنچه در پروژه درست یا غلط بوده و مستندسازی این موارد به منظور استفاده در پروژه‌های آینده است. دروس آموخته می‌تواند در شناسایی و مدیریت ریسک‌های پروژه کمک شایانی کند.
چنین اطلاعاتی از دوباره‌کاری در پروژه جلوگیری می‌کند و کمک می‌کند تا اطمینان حاصل شود که اشتباهات مشابه توسط اعضای تیم سایر پروژه‌ها تکرار نشود.

۵-۴- حدود قابل قبول ریسک Risk tolerance Area
خیلی مهم است که تصمیم بگیرید در کدام منطقه و محدوده، شرکت و ذینفعان کلیدی ریسک‌ها را خواهند پذیرفت. منطقه‌های حد قابل قبول ریسک معمولاً در محدودیت‌های پروژه لحاظ می‌شوند. محدودیت پروژه شامل: محدوده، زمان، هزینه، کیفیت، ریسک، منابع و رضایت مشتری.

۵-۵- آستانه‌های تحمل ریسک Risk Thresholds
آستانه‌های تحمل ریسک به همراه حدود قابل قبول ریسک بیان می‌شوند. واژه “آستانه تحمل” به این معنی است: “خیلی زیاد، چقدر زیاد است؟”.

خواهش می‌کنم بدون ذکر منبع (نام نویسنده، آدرس سایت و آدرس کانال تلگرام) کپی نکنید!

سایر مطالب مرتبط:

مدیریت پروژه , مدیریت ریسک

خلاصه همه آن چیز که باید در مورد مدیریت ریسک پروژه بدانید

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

 

تعریف ریسک:

ریسک یک رویداد احتمالی است که ممکن است رخ بدهد یا رخ ندهد. (An uncertain event)

ریسک اگر اتفاق بیافتد دیگه بهش نمیگیم ریسک.

 

ریسک اگر اتفاق بیافتد روی یکی از اهداف پروژه ما اثر می‌گذارد.

اگر ریسک بعد از اتفاق روی یکی از اهداف پروژه ما اثر نگذارد، ریسک هست اما ریسک پروژه ما نیست.

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

 

اما نکته مهم اینه که بدونید ریسک در صورت رخ دادن حتمن باید روی یکی یا چند تا از اهداف پروژه ما اثر بذاره.

 

ریسک مترادف با عدم قطعیت یا همون Uncertainly نیست. هر جا که Uncertainly وجود داره امکان وقوع یک ریسک هم وجود دارد. به عبارتی عدم قطعیت ممکن است دلیل ایجاد یک ریسک باشد و نه خود ریسک.

 

قدیم‌ها میگفتن ریسک ها دو دسته هستند:

  • ریسک های تجاری Business Risk: که در صورت وقوع، یک عده خوشبخت میشن و یک عده هم بدبخت. (مثل گرون شدن قیمت دلار یا طلا)
  • ریسک‌های خالص یا Pure risk: که در صورت وقوع برای همه اثرات بدی داره مثل زلزله یا آتش سوزی جنگل

 

 

اثر ریسک:

۱- اثر مثبت Positive Risk, Opportunities

۲- اثر منفی Negative Risk, Threats

تهدید و فرصت مسائل مجزایی هستند و به هم تبدیل نمی‌شوند. تهدید به فرصت و فرصت به تهدید تبدیل نمی‌شود. (مثلن دیدید مسئولین میگن ما همه تهدیدها رو به فرصت تبدیل خواهیم کرد! از نظر PMBOK این کار غیرممکنه)

 

بیان حرفه ای ریسک:

Because of “one or more cause”, “risk” might occur, which would to “one or more effects”

به دلیل AAA ممکن است BBB که در آن صورتCCC.

هر ریسکی باید حتمن به شکل جمله بالا بیان بشه. در این جمله AAA همون علت وقوع ریسک هست، BBB خود ریسک و CCC نیز اثر ریسک.

AAA: Cause of Risk

BBB: Risk

CCC: Impact of risk

بنابراین ریسک با بیان دلیل و اثر بیان می‌شود. چون اگر ریسک را با این ادبیات بیان نکنید، ممکن است  Cause و Effect را با خود ریسک اشتباه بگیریم.

 

مهم‌ترین کار ما در مدیریت ریسک این است که کاری کنیم تهدیدها اتفاق نیافتند و کاری کنیم که فرصت‌ها اتفاق بیافتند.

 

چهارفاکتوری که همراه ریسک شناسایی می‌شوند:

۱- Probability احتمال وقوع ریسک

۲- Impact میزان اثر ریسک

۳- When زمان احتمالی وقوع ریسک

۴- How often چند بار ممکن است ریسک در پروژه تکرار شود.

 

فاکتورهای اول و دوم مهم تر هستند، چون برای اولویت‌بندی ریسک از آن‌ها استفاده می‌شود.

 

گام های مدیریت ریسک:

Step1: Plan Risk Management

Step2: Identify Risks

Step3: Perform Qualitative Risk Analysis

Step4: Perform Quantitative Risk Analysis

Step5: Plan Risk Responses

Step6: Implement Risk Responses

Step7: Monitor Risks

 

این گام‌ها رو می‌تونید در شکل های پایین ببینید:

 

گام اول: Plan Risk Management

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

 

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

 

خروجی گام اول: Risk Management Plan

اولین فرآیند مدیریت ریسک: Plan Risk Management

Inputs: PMP/charter/ st register/EEF/OPA

T & T: Analytical techniques/ expert judgment/meeting

Outputs: risk MP

 

ملحقات  و اجزای جدول RISK MP:

RISK CATEGORIES:

از ساختار شکست ریسک در فرایند شناسایی ریسک‌ها استفاده می‌کنیم.

RBS: Risk breakdown structure

نکته مهم: در RBS ما ریسک نداریم. RBS در شناسایی ریسک ها به ما کمک می کند.

 

در شکل زیر یک نمونه دسته بندی ریسک رو میتونید ببینید:

RISK MP: definition of impact scale

یک ریسک ممکن است چند تا اثر در پروژه داشته باشد. پس برای هر یکی از محدودیت های STCQ یک اثر ریسک را تعریف می‌کنیم. از این تعریف در فرایند ارزیابی کیفی ریسک استفاده میکنیم.

این یک خط کش جهت ارزیابی کیفی احتمال و اثر ریسک است.

در شکل زیر می توانید یک نمونه از تعریف احتمال و اثر رو ببینید:

 

RISK MP: Probability and impact risk

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

ماتریس احتمال و اثر سه ناحیه دارد: قرمز، زرد، سبز

سوال: محدوده قرمز و زرد و سبز این ماتریس چگونه تعیین می شود؟

بر اساس میزان ریسک گریزی و ریسک پذیری ذینفعان، این محدوده‌ها تعیین می‌شود.

 

اگر محدوده قرمز بزرگ بود> ریسک گریز

اگر محدوده قرمز کوچک بود> ریسک پذیر

در شکل زیر می توانید یک نمونه ماتریس احتمال و اثر رو ببینید:

گام دوم: Identify Risks

با ابزارهای مختلف ریسک‌های پروژه را شناسایی می کنیم. مثلن ۱۰۰ ریسک یا ۱۰۰۰ هزار ریسک شناسایی می‌کنیم.

خروجی گام دوم: Risk register

فرآیند دوم: Identify Risk

Input: all MP/all documents/EEF/ OPA

T&T: doc review/ information gathering techniques/assumption analysis/diagramming techniques/SWOT/Expert judgment

Outputs: Risk Register

 

فرایند شناسایی ریسک‌ها و مستند‌سازی ویژگی‌ها:

ویژگی ها: cause & effect

 

نکات:

شناسایی ریسک وظیفه همه در پروژه است.

در شناسایی ریسک، ریسک با کیفیت معنی ندارد. هرچه بیشتر ریسک شناسایی کنیم بهتر است.

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

نادیده گرفتن ریسک، ریسک را از بین نمی برد.

 

در بحث شناسایی ریسک سه نوع نگاه داریم:

۱- Past نگاه به گذشته

۲- Present نگاه به حال

۳- Future نگاه به آینده

 

در شناسایی ریسک هر سه نگاه بالا را باید داشته باشیم.

 

گام سوم و چهارم:  Perform Qualitative Risk Analysisو Perform Quantitative Risk Analysis

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

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

 

گام سوم: Perform Qualitative Risk Analysis

Inputs: risk MP/scope baseline/risk register/EEFS/ OPA

T&T: RISK PROBABILITY & IMPACT ASSESSMENT/ PROBABILITY & IMPACT MATRIX/ RISK DATA QUALITY ASSESSMENT/RISK CATEGORIZATION/RISK URGENCT ASSESSMENT/EXPERT JUDGMENT

OUTPUTS: risk register updates

 

قدمهای گاوم سوم:

۳-۱: ارزیابی کیفی احتمال و اثر

۳-۲: اولویت بندی

۳-۳: ارزیابی فوریت ریسک

 

در گام سوم ریسک هایی که اولویتشان بالاست مشخص می شود.

ریسک ها با اولویت بالا: top risk

ریسک ها با اولویت پایین: low risk

 

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

ریسکها با اولویت پایین به watch listمی روند، این ریسکها احتمال و اثرشون پایینه اما درادامه پروژه باید مراقبش باشیم.

 

گام پنجم: Plan Risk Responses

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

 

در این گام برای top risk ها چاره‌اندیشی می‌کنیم و راهکارهای مختلف مقابله با ریسک را استخراج می‌کنیم

اما استراتژی‌های پاسخ به ریسک موارد پایین هستند:

استراتژی‌های پاسخ به تهدیدها(ریسک های منفی):

Avoid / Eliminate

Transfer/Deflect/Allocate

Mitigate

Accept

Escalate

 

استراتژی‌های پاسخ به فرصت‌ها(ریسک‌های منفی):

Exploit

Share/Partnership /Join Venture

Enhance

Accept

Escalate

 

 

گام ششم: Implement risk responses

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

 

گام هفتم: Monitor risks

و در گام آخر ما دو کار عمده انجام میدیم.:

Risk Reassessment

Risk Audit

 

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

 

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

 

خواهش می‌کنم بدون ذکر منبع (نام نویسنده، آدرس سایت و آدرس کانال تلگرام) کپی نکنید!

 

در همین ارتباط بخوانید:

مدیریت پروژه , مدیریت ریسک

بیست سوالی که باید قبل از پیاده‌سازی مدیریت ریسک در پروژه پرسیده شود

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

و اما سوالات:

۱- آیا مدیریت ریسک در پروژه یک گزینه اختیاری (Optional) است یا یک وظیفه اجباری؟
۲- آیا از نظر سازمان و تیم پروژه شما مدیریت ریسک امری زائد و لوکس است؟
۳- آیا می‌توان در سازمان یا پروژه‌ای که فرهنگ مدیریت ریسک(یا به طور کلی فرهنگ مدیریت پروژه) در آن وجود ندارد، فرآیندهای مدیریت ریسک پروژه را پیاده‌سازی کرد؟
۴- آیا می‌دانید در سازمان یا پروژه‌ای که اکثریت اعضاء آن اعتقادی به مدیریت ریسک ندارند و حتی مخالف اجرای آن هستند، چگونه می‌توان به فرهنگ سازی مدیریت ریسک و پیاده‌سازی آن اقدام کرد؟
۵- آیا می‌توان گفت حوزه دانش مدیریت ریسک، از حوزه‌هایی مثل مدیریت زمان، هزینه و کیفیت پروژه اهمیت کم‌تری دارد و باید در اولویت‌های بعدی قرار گیرد؟
۶- آیا مدیریت ریسک احتیاج به صرف زمان و هزینه ویژه و اضافه‌ای دارد؟
۷- آیا تنها مدیر پروژه یا تنها واحد برنامه‌ریزی یا اعضای PMO متولی حوزه مدیریت ریسک در پروژه هستند؟ چه کسانی در پروژه یا سازمان باید در شناسایی ریسک‌ها و برنامه‌ریزی پاسخ به ریسک‌ها مشارکت نمایند؟
۸- آیا ریسک‌ها و رویدادهای پروژه‌های قبلی سازمان در جایی ثبت و ذخیره یا تحلیل شده‌اند؟
۹- آیا در سازمان‌ یا پروژه‌تان دستورالعمل، آیین‌نامه، دارایی فرآیندی خاص یا سایر تجربیات پروژه‌های قبلی به منظور کمک به شما در انجام فرایندهای مدیریت ریسک وجود دارد؟
۱۰- آیا استنباط شما از مدیریت ریسک تنها در مورد آنالیز کمی ریسک‌ها و کاربرد آن در حوزه نرم‌افزارهای مدیریت ریسک مانند RISK ANALYSIS و امثالهم است؟

 


۱۱- آیا منظور شما از مدیریت ریسک پروژه، تنها مدیریت ریسک‌های با اثر منفی بر روی پروژه(تهدیدها/THREATS) است؟
۱۲- آیا مدیر پروژه باید تنها بر روی مشکلات فعلی پروژه تمرکز کند یا تمام تمرکزش باید بر پیشگیری یا چاره اندیشی برای مشکلات احتمالی آینده باشد؟
۱۳- آیا مدیریت ریسک می‌تواند برآوردهای زمان و هزینه پروژه را کاهش دهد؟
۱۴- مدیریت ریسک چه تأثیری بر اسناد و مدارک و بیس‌لاین‌های پروژه می‌تواند داشته باشد؟
۱۵- آیا مدیریت ریسک کاری است که باید در فازهای ابتدایی پروژه انجام شود یا از ابتدا تا انتهای پروژه اجرا می‌شود؟
۱۶- آیا می‌توان فرایندهای مدیریت ریسک را بدون در نظر گرفتن اشتهای به ریسک و میزان ریسک‌پذیری ذینفعان پروژه انجام داد؟
۱۷- از چه مدلی برای مدیریت ریسک پروژه استفاده می‌کنید؟ مدل هایی مانند ISO یا آن مدلی که در PMBOK ارائه شده است؟
۱۸- شما و تیم پروژه تا چه میزان با هفت فرآیند مدیریت ریسک اشاره شده در PMBOK،(برنامه‌ریزی مدیریت ریسک/شناسایی ریسک‌ها/ انجام تحلیل کیفی ریسک/ انجام تحلیل کمی ریسک/ برنامه‌ریزی پاسخ به ریسک/پیاده‌سازی پاسخ‌های ریسک/ مانیتور ریسک‌ها) وروردی‌ها و خروجی‌های این فرآیندها، ابزارها و تکنیک‌های هر فرآیند، اسناد و فرم‌های مربوطه با آن‌ها، استراتژی‌های پاسخ به ریسک‌های مثبت(فرصت‌ها) و استراتژی‌های پاسخ به ریسک‌های منفی(تهدیدها) آشنا هستید؟
۱۹- متدولوژی شما برای پیاده‌سازی مدیریت ریسک در پروژه چیست؟
۲۰- اگر خود پیاده‌سازی مدیریت ریسک در پروژه را به شکل یک پروژه منحصر به فرد ببینید، آیا ریسک‌های این پروژه (یعنی پروژه پیاده‌سازی مدیریت ریسک پروژه) را شناسایی کرده‌اید و برای پاسخ به آن ریسک‌ها برنامه‌ریزی کرده‌اید؟

خواهش می‌کنم بدون ذکر منبع (نام نویسنده، آدرس سایت و آدرس کانال تلگرام) کپی نکنید!

 

در همین ارتباط بخوانید:

مدیریت پروژه

ده نکته طلایی برای مدیران پروژه‌ها

نکاتی که در ادامه خدمتتون عرض می‌کنم لزومن بر اساس استانداردها و معیارهای مدون نیست (هر چند سعی شده چارچوبش از استانداردها پیروی کنه) ولی بیش‌تر بر اساس تجربیات شخصی خودم طی چند سال کار در پروژه‌ها این نکته‌ها به ذهنم رسید:

۱- بهترین نیروهای انسانی رو در پروژه استخدام کنید

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

۲- از شناسایی و مدیریت ذینفعان غافل نشید

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

۳- هر روز و هر لحظه به فکر STC پروژه باشید

فکر کنم دیگه همه مدیران پروه‌ها میدونن که پروژه‌ای موفق نامیده میشه که در چارچوب محدوده (Scope)، زمان (Time) و هزینه (Cost) انجام بشه. به عبارتی کتاب مقدس شما، ذکر هر روز و هرشب و هر لحظه شما، استراتژی و فکر و برنامه و عملکرد شما و تمام تصمیم‌گیری‌های شما به عنوان یک مدیر پروژه باید در راستای STC پروژه باشه. خاطرتون باشه که عدول از STC یک شبه اتفاق نمی‌افته، بلکه شما ذره ذره و قطره قطره از STC پروژه تجاوز می‌کنید و در آخر پروژه می‌بینید که چه فاصله دوری از STC دارید. پس نذارید این قطره قطره‌ها جمع بشه.

۴- بدون برنامه‌ریزی هیچ کاری رو در پروژه شروع نکنید

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

۵- مدیریت ریسک شما رو نجات خواهد داد

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

۶- حواستون به اتلاف منابع باشه

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

۷- ارتباطات رو جدی بگیرید و یک مذاکره کننده حرفه‌ای باشید

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

دوره آموزشی رایگان فنون مذاکره-محمدرضا شعبانعلی

۸- تفویض اختیار کنید و کارتابلتون رو خلوت کنید

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

۹- برنده-برنده فکر کنید

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

۱۰- فاز اختتام پروژه رو جدی بگیرید

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

خواهش می‌کنم بدون ذکر منبع (نام نویسنده، آدرس سایت و آدرس کانال تلگرام) کپی نکنید!

امیدوارم این مطلب براتون مفید بوده باشه. راستی این آخرین مطلب این سایت در سال ۱۳۹۶ بود. ضمن تبریک سال نو و نوروز باستانی، براتون آرزوی موفقیت و شادمانی در سال جدید رو دارم.

مدیریت پروژه , مدیریت ریسک

استراتژی پاسخ به ریسک Escalate چیست؟

در مطلب “هفت تغییر اساسی در ویرایش ششم PMBOK در مقایسه با نسخه پنجم” گفتم که یکی از تغییرات ایجاد شده در نسخه ششم راهنما، اضافه شدن یک استراتژی پاسخ به ریسک به استراتژی‌های پاسخ به ریسک قبلی است. در ویرایش جدید استراتژی پاسخ به ریسک Escalate، هم به استراتژی‌های پاسخ به تهدیدها و هم پاسخ به فرصت‌ها اضافه شده است.

اما معنی Escalate چیست؟ دیکشنری‌ها می‌گویند ترجمه می‌شود: “تشدید”، “افزایش”، “زیاد شدن”، “بالا گرفتن”، “بالا رفتن”، “از مهار خارج شدن”، “از حد کنترل خارج شدن” و کلن هر چیز ناخوشایندی تشدید شدن و از این دست. اگر با استاندارد PMBOK آشنایی داشته باشید، در بخش مدیریت تعارضات، موضوع Escalate در جایی استفاده میشد که یک اختلاف یا تعارض بالا می‌گرفت. ولی به نظر من “بالا گرفتن” شاید زیاد ترجمه خوبی برای Escalate به عنوان یک استراتژی پاسخ به ریسک نباشد. شما اگر ترجمه قشنگ‌تری به ذهنتان می‌رسد، حتمن بگویید. شاید هم از آن دست کلمه‌های تخصصی است که اگر به فارسی ترجمه نشود، بهتر است.

در نسخه پنجم استراتژی‌های پاسخ به ریسک‌های منفی(تهدید ها) چهارتا بود:
Avoid / Transfer / Mitigate / Accept
و استراتژی‌های پاسخ به فرصت‌ها(ریسک‌های مثبت) هم چهارتا بود:
Exploit / Share / Enhance / Accept

حالا خود PMBOK در تعریف استراتژی جدید اضافه شده در نسخه ششم یعنی استراتژی Escalate می‌گوید:

“استراتژی Escalation زمانی مناسب است که تیم پروژه یا اسپانسر پروژه بپذیرند که تهدید(یا فرصت) خارج از محدوده (Scope) پروژه است یا اینکه پاسخ پیشنهاد شده برای ریسک از اختیارات مدیریت پروژه فراتر است. در این حالت اتخاذ استراتژی Escalate به این معنی است که ریسک یا ریسک‌های مذکور باید در سطح بالاتر از مدیر پروژه یعنی سطح پورتفولیو یا طرح رسیدگی شود.”

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

 

به روز رسانی بعد از نوشتن:

یکی از دوستان در تلگرام برای استراتژی پاسخ به ریسک Escalate یک ترجمه بسیار خوب پیشنهاد داده بود تحت عنوان “بالاسپاری”. به نظرم بالاسپاری خیلی ترجمه قشنگ و کاربردی و خوبی هست.

 

خواهش می‌کنم بدون ذکر منبع، کپی نکنید!

خواندن سایر مطالب در مورد مدیریت ریسک

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

دانلود یک نمونه فرمت مدیریت ریسک بر اساس راهنمای PMBOK

همان طور که می‌دونید بر اساس نسخه پنجم راهنمای PMBOK، فرآیندهای مدیریت ریسک شامل موارد زیر است:

۱- برنامه‌ریزی مدیریت ریسک
۲- شناسایی ریسک‌ها
۳- تحلیل کیفی ریسک‌ها
۴- تحلیل کمی ریسک‌ها
۵- برنامه پاسخ به ریسک
۶- کنترل ریسک

در این فرآیندها شما در هر محله خروجی‌های خواهید داشت. فایل اکسل که در ادامه برای دانلود در اختیارتان گذاشته می‌شود، پکیج تقریبن کاملی از این خروجی‌‌هاست. برخی از خروجی‌هایی که در این فایل می‌توانید مشاهده کنید به شرح زیر است:
برنامه مدیریت ریسک RISK MANAGEMENT PLAN
برگه ثبت ریسک‌ها Risk Register
تعریف احتمال و اثر Probability & Impact Rating Asses
ماتریس احتمال و اثرProbability & Impact matrix
و سرانجام یک برگه جهت محاسبه نمره ریسک و ثبت برنامه‌های پاسخ به ریسک

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

دانلود یک نمونه فرمت مدیریت ریسک بر اساس راهنمای PMBOK
پسوورد فایل زیپ: sharifiz.com