آیا تیم توسعۀ شما وقت همه را تلف می‌کند؟
وقتی که مدیریت عدم اطمینان و ریسک در یک پروژه ضعیف باشد، چه اتفاقی می‌افتد؟ معمولاً نتیجه آن، نرسیدن به مهلت‌های تحویل، اتلاف زمان و ناخوشنودی ذینفعان است.
فرض کنید که مسئول پروژه‌ای هستید که اسناد نیازمندی‌های پروژه نداشته باشد؛ توسعه‌دهندگان نیز بدون تصویر مشخصی از آنچه باید انجام شود کدها را بنویسند؛ وقتی نتایج ارائه شوند ذینفعان شکایت می‌کنند و توسعه‌دهندگان را به دوباره‌نویسی کد وامی‌دارند و وقت هر کسی تلف می‌شود. چه بسا بعداً معلوم شود که سخت‌افزار کار نمی‌کند و لازم شود با یک معماری جدید کار را از اول شروع کرد. نتیجه تلف شدن زمان بیشتری است؛ تکمیل پروژه دو برابر بیشتر زمان می‌گیرد.
مدیریت و کنترل ضعیف عدم اطمینان و ریسک در پروژه، به چنین تجربیاتی می‌انجامد.
در پروژه‌هایی مانند توسعه محصول سخت‌افزاری که عدم اطمینان و پیچیدگی بسیاری وجود دارد، درک اینکه کدام وظیفه از بیشترین اهمیت برخوردار است بسیار ضرورت دارد. در غیر این صورت اکثر تلاش تیم هدر می‌رود. موفقیت در مدیریت این پروژه‌ها مستلزم ایجاد توازن ظریفی مابین حذف عدم اطمینان، کم کردن ریسک و پیشروی در مسیر بحرانی است. می‌توان این رویکرد را «مدیریت تطبیقی پروژه» نامید که هم از مدیریت پروژه استاندارد/Waterfall مؤلفه‌هایی دارد (که در آن کنترل پیچیدگی مناسب و کنترل عدم اطمینان ضعیف است) و هم مدیریت پروژه چابک (که کنترل عدم اطمینان در آن مناسب و پیچیدگی در آن ضعیف است).
یک- حذف عدم اطمینان
در ابتدای یک پروژه‌ی تطبیقی، باید تمرکز بر حذف عدم اطمینان باشد. چطور می‌توان بدون فهمیدن نیازهای کاربر انتهایی، کدی نوشت یا بدون اطلاع از بهترین فناوری مورد نیاز پروژه، نمونه‌های اولیه ساخت؟ در این مرحله، باید بر مشارکت با ذینفعان یا کاربران انتهایی، بررسی ظرفیت‌های فناوری‌های مورد نظر، و درک منابع و محدودیت‌های بودجه متمرکز بود.
این تلاش در کل پروژه ادامه می‌یابد اما وقتی که پروژه آنقدر فهمیده شد که بتوان یک ساختار شکست کار (WBS) ایجاد کرد، می‌توان از این تلاش کم کرد. در WBS به‌منظور حذف عدم اطمینان باقیمانده، وظایفی درنظر گرفته می‌شوند. طبیعت پروژه‌های تطبیقی به‌گونه‌ای است که مانند پروژه‌های واترفال، به‌جای به صفر رساندن کل عدم اطمینان از ابتدای کار با چند مورد از عدم اطمینان، پیشروی را ادامه می‌دهیم. همین‌که عدم اطمینان کم می‌شود، شباهت برنامه به واترفال بیشتر می‌شود.
دو- کاهش ریسک
ریسک‌ها در آینده معلوم می‌شوند، مشکلات همین الآن اتفاق می‌افتند. مشکل این است که شاید ریسک‌ها رشد کنند و به مشکلات بدل شوند. حل مشکلات زمان میبرد که نتیجه آن تأخیرها و افزایش هزینه‌ها است. هرچه زودتر بتوان ریسک‌ها را به مشکلات بدل کرد یا از آن‌ها خلاص شد، بهتر است.
وقتی که پروژه به‌خوبی فهمیده شد، لازم است یک ثبت‌نامه‌ی خطر یا «ریسک رجیستر» [۱] ایجاد شود. بدین ترتیب فهرستی از آنچه امکان دارد خوب پیش نرود، میزان امکان وقوع آن، میزان شدت آن در صورت وقوع و چگونگی کاهش آن در صورت وقوع ایجاد می‌شود. می‌توان از ۱ تا ۵ رتبه‌بندی کرد. برای «احتمال وقوع»، مثلاً می‌توان ۱ را معادل با کمتر از ۲۰ درصد و ۵ را معادل بیش از ۸۰ درصد قرار داد. برای «شدت»، ۱ معادل تأثیری بر پروژه است که کمتر، تاریخ‌های مایلستون (نقاط رویدادها) و محدودیت‌های بودجه را در خطر قرار می‌دهد. ۵ یعنی اینکه شاید نیاز به کنسل کردن کل پروژه باشد، احتمالاً به این دلیل که ویژگی بخصوصی به دست نخواهد آمد یا بهای کالای فروخته‌شده بسیار بیش از انتظار است.
به‌علاوه می‌توان یک ستون برای «اهمیت» اضافه کرد که حاصلِ‌ضرب احتمال وقوع و شدت است و ریسک‌ها را به ترتیب اهمیت رتبه‌بندی کرد (جدول ۱ مشاهده شود). بخشی از تلاش‌ها باید همیشه به کاهش ریسک‌های مهم اختصاص بیابد، چه از طریق آزمون وقوع مشکلات و چه با اعمال روش‌هایی برای کاهش. این تلاش بخشی از ساختار شکست کار است. همچنین برای کم کردن اتفاقات غیرمنتظره در مسیر، می‌توان روش‌های کاهشی را برای ریسک‌های احتمال‌بالا در برنامه قرار داد.
| کاهش | اهمیت | شدت | احتمال وقوع | ریسک |
| ایجاد قفس فارادی در اطراف تجهیزات الکترونیکی | ۱۲ | ۳ | ۴ | دستگاه در تست انطباق‌پذیری الکترونیکی خطا داشته باشد |
| اضافه کردن یک فَن | ۶ | ۲ | ۳ | خنک‌سازی پسیو کافی نباشد |
جدول ۱ این یک ثبت‌نامه‌ی خطر (ریسک رجیستر) [۱] ساده است. نسخه‌های پیچیده‌تر دارای مواردی مثل «قابلیت کشف شدن» (چقدر احتمال دارد که ریسک اتفاق بیفتد اما امکان آشکارسازی خطا نباشد) و «امکان وقوع غیرمنتظره» (اگر با کاهش مشکل حل نشد چه باید انجام شود) است. تجربه نشان می‌دهد که یک ریسک رجیستر ساده، کافی است و به‌روز نگه داشتن آن که موضوع مهمی است، آسان‌تر است.
سه- پیشروی در مسیر بحرانی
برای اطمینان از تحویل به‌موقعِ اقلام قابل‌تحویل و برآوردن نیازهای ذینفعان می‌توان ابزاری را به کار برد. در غیر این صورت لازم است اهمیت این موارد قابل‌تحویل با ذینفعان بررسی شود؛ بررسی می‌شود که آیا امکان کم کردن اقلام قابل‌تحویل وجود دارد؟ راه دیگر انتقال منابع مرتبط با کاهش ریسک به وظایف مسیر بحرانی است. در صورت انتخاب این مسیر، لازم است به ذینفعان توضیح دهید که مسئله، احتمال وقوع مشکلات بعدی را در پروژه بالا میبرد و آن‌موقع، برطرف کردن مشکل دشوارتر است.
یک مدیر پروژه خوب، بندباز است
شغل مدیریت پروژه ایجاد توازن مابین سه بخش مذکور است. اضافه‌کاری بر مسیر بحرانی، اهمیت بیشتر و کاهش ریسک و عدم اطمینان، اهمیت کمتری دارد؛ اما هیچ فرمولی نیست که پاسخ بدهد چه باید کرد.
در آخر این به مدیر پروژه و تیم او بستگی دارد که بفهمند:
- آیا عدم اطمینان آنقدر کاهش یافته که مدیر بتواند تمرکزش را بر خطرات بگذارد؟
- آیا ریسک‌ها آنقدر کاهش یافته‌اند تا بتوان بر مسیر بحرانی تمرکز کرد؟
- و آیا در این لحظه هر کسی بر مهم‌ترین وظیفه‌اش کار می‌کند؟
اگر این سؤال‌ها اشتباه برآورد شوند (مثلاً ریسکی که احتمال وقوعش کم بود به یک اشتباه زننده در پروژه تبدیل شود)، فقط کافی است لبخند بزنیم و تیم را بر مهم‌ترین وظایف فعلی‌اش متمرکز کنیم.
[۱] risk registor
