نخستین گام مدیریت ریسک، شناسایی ریسک‌هاست. باید در آغاز پروژه کارگاه‌هایی برگزار کرد و با کمک اعضای تیم پروژه به عدم‌قطعیت‌ها اندیشید. با این همه، هرچه هم که در آغاز کار زمان صرف شناسایی ریسک‌ها کنیم، باز هم مواردی شناسایی نشده باقی می‌مانند و فقط هنگامی که به آن‌ها نزدیک‌تر شویم از آن‌ها آگاه می‌شویم. گاهی هم ریسک‌های تازه‌ای به دلیل تغییر شرایط محیطی به وجود می‌آیند. از این رو، لازم است که روند شناسایی ریسک‌ها دایما تکرار شود.
یک راه خوب این است که بخش کوچکی برای شناسایی ریسک‌های تازه به انتهای بیشتر جلسه‌ها و کارگاه‌ها بیفزایید.
در P3.express مجموعه فعالیت‌هایی برای آغازش پروژه و پایان پروژه وجود دارد. در میان این دو، چرخه‌هایی ماهانه برای انجام کار پروژه وجود دارد، با گروه فعالیت‌هایی برای آغازش ماهانه و پایان ماهانه. درون چرخه‌های ماهانه نیز فعالیت‌هایی برای مدیریت هفتگی و مدیریت روزانه وجود دارد. پس از پایان پروژه شماری فعالیت مدیریت پساپروژه برای ارزیابی منافع پروژه و طراحی اقدام‌های تازه وجود دارد.
برای آغازش پروژه باید اعضای کلیدی تیم منصوب و به کمک آن‌ها برنامه‌ای کلان آماده شود. برنامه برای حامی پروژه فرستاده می‌شود تا درباره اجرا کردن یا نکردن پروژه تصمیم بگیرد.
ترجیح بر این است که برنامه نخستین کلان باشد و سپس در هر آغازش ماهانه بازبینی شده، برای ماه پیش رو تفصیلی شود. اطلاعات بازبینی و تفصیلی شده در پایان آغازش ماهانه برای حامی پروژه فرستاده می‌شوند تا درباره ادامه دادن یا متوقف کردن پروژه تصمیم بگیرد.
در طول ماه بر روی محصول پروژه کار می‌کنیم و هر هفته پیشرفت آن را ارزیابی کرده، به انحراف‌ها واکنش نشان می‌دهیم. فعالیت‌هایی روزانه نیز برای تایید تحویل‌شدنی‌های کامل شده و پیگیری اقلام قابل‌پیگیری (ریسک‌ها، مسایل، درخواست‌های تغییر، برنامه‌های بهبود، و درس آموخته‌ها) وجود دارد.
در زمان پایان ماهانه، رضایت ذی‌نفعان را ارزیابی کرده، بر آن پایه برنامه‌هایی برای بهبود پروژه در ماه بعد طراحی می‌کنیم. …
وقتی ایده پروژه‌ای شکل می‌گیرد و به نظر جالب می‌رسد و پیش از آن‌که تصمیم نهایی درباره آن گرفته شود، فرآیند راه‌اندازی پروژه اجرا می‌شود. در این فرآیند برخی اعضای کلیدی تیم منصوب می‌شوند و همراه هم اطلاعاتی کلان گردآوری می‌کنند که در پایان در سندی با نام خلاصه پروژه (project brief) ذخیره خواهند شد. این سند اطلاعاتی تقریبی درباره توجیه‌پذیری پروژه و شیوه اجرای مناسب آن دارد.
مدیر ارشد و سایر افراد تصمیم‌گیرنده بر پایه اطلاعات گردآوری شده تصمیم می‌گیرند که پروژه ارزش بررسی دقیق‌تر دارد یا خیر. اگر داشته باشد، فرآیند آغازش پروژه اجرا می‌شود.
در آغازش پروژه برنامه کلان آماده می‌شود و بر آن پایه می‌توان توجیه‌پذیری پروژه را با اطمینان بیشتر برآورد کرد. این اطلاعات در سندی با نام سند آغازش پروژه (project initiation documentation) ذخیره می‌شود. این سند نیز در اختیار مدیر ارشد و سایر تصمیم‌گیرندگان گذاشته می‌شود که تصمیم نهایی را برای آغاز کردن یا نکردن کار اجرایی پروژه بگیرند.
همان‌گونه که می‌بینید، پروژه در دو مرحله ارزیابی می‌شود. در مرحله نخست به‌سرعت و با صرف توان محدود آن را بررسی می‌کنیم تا پروژه‌هایی که اصلا توجیه‌پذیر نیستند حذف شوند. در مرحله دوم، با صرف زمان و انرژی بیشتر، پروژه را به دقت بررسی می‌کنیم و بر آن پایه تصمیم نهایی را می‌گیریم.
برخلاف بیشتر سیستم‌ها، اسکرام آغازش و پایانی رسمی و ساخت‌یافته تعریف نکرده است و فقط بر روند مناسب برای زمان اجرای پروژه تمرکز دارد. دلیل این مسئله این است که اسکرام برآن نیست که همه جنبه‌های مدیریت پروژه را پوشش دهد.
در آغاز پروژه، مالک محصول با ذی‌نفعان گفتگو می‌کند و فهرستی ساده و نخستین از قابلیت‌های مدنظرشان فراهم می‌کند. فهرست محصول (product backlog) به هیچ وجه کامل نیست و در طول اجرای پروژه دستخوش دگرگونی‌های فراوانی خواهد شد.
مالک محصول هم مسئول تدوین آیتم‌های فهرست است و هم مرتب کردن آن‌ها بر پایه ارزششان. آیتم‌های باارزش‌تر و مهم‌تر در بالای فهرست قرار می‌گیرند.
اسکرام نیز مانند پرینس۲ و P3.express چرخه‌ایست و چرخه‌هایش Sprint نام دارند. این چرخه‌ها مدت‌زمان ثابتی دارند و همیشه در زمان معین پایان می‌پذیرند، حتی اگر کار چرخه کامل نشده باشد. تعیین مدت‌زمان چرخه‌ها بر دوش تیم است، ولی این مدت نباید بیشتر از یک ماه باشد. برای مدت‌زمان چرخه‌ها هر بار تصمیم‌گیری نمی‌کنیم، بلکه همه چرخه‌ها را با مدت یکسان اجرا می‌کنیم، مگر این‌که پس از مدتی متوجه شویم که مدت تعیین شده برای نوع پروژه مناسب نیست و بهتر است آن را برای چرخه‌های بعد اصلاح کنیم.
هر چرخه با جلسه‌ای حداکثر ۸ ساعته برای برنامه‌ریزی چرخه آغاز می‌شود. اعضای تیم گرد هم می‌آیند و درباره آیتم‌هایی که در بالای فهرست قرار دارند …
کار در DSDM با فاز پیشاپروژه آغاز می‌شود. در این فاز توجیه‌پذیری پروژه را به‌کوتاهی بررسی و نتیجه را همراه با اطلاعات تکمیلی در سندی با نام terms of reference ذخیره می‌کنیم. تصمیم‌گیرندگان با کمک این اطلاعات فرمان توقف کار یا اجرای فاز بعدی را می‌دهند.
فاز بعدی، توجیه‌پذیری است. در این فاز زمان بیشتری صرف شناسایی پروژه و جنبه‌های کسب و کار، فنی، و مدیریتی آن می‌کنیم. اطلاعات گردآوری شده در سند ارزیابی توجیه‌پذیری ذخیره می‌شوند و برای تصمیم‌گیرندگان فرستاده می‌شوند تا فرمان توقف پروژه یا اجرای فاز بعد را بدهند.
فاز سوم شالوده است. در این فاز برنامه کلان پروژه را آماده می‌کنیم که شالوده پروژه به شمار خواهد رفت. بر پایه برنامه کلان می‌توان درک بهتری از توجیه‌پذیری آن نیز پیدا کرد و همه این اطلاعات در قالب سندی با نام چکیده شالوده در اختیار تصمیم‌گیرندگان قرار می‌گیرد.
اگر پروژه توجیه‌پذیر باشد، آن را در فازی تکرار شونده با نام توسعه تکاملی اجرا خواهیم کرد. در هر چرخه این فاز نسخه تازه‌ای از محصول پروژه آماده می‌شود و مانند همه پروژه‌های چابک برای گردآوری بازخورد و روشن کردن مسیر پیش رو به کار می‌رود.
فاز دیگر، انتشار است. این فاز را می‌توان پس از هر چرخه توسعه تکاملی یا با بسامدی کمتر تکرار کرد. در هر تکرار، تازه‌ترین نسخه نرم‌افزار در اختیار کاربران نهایی قرار می‌گیرد.
اختصاصی‌سازی سیستم بحثی کمابیش طولانیست و در فصل چهارم با تفصیل بیشتری به آن خواهیم پرداخت. اکنون بر موضوع دیگری تمرکز می‌کنیم: فرآیند و روش اختصاصی‌سازی.
در پم‌باک ۷ روشی دومرحله‌ای برای اختصاصی‌سازی پیشنهاد کرده‌ایم:
پروژه‌هایی که در یک سازمان اجرا می‌شوند همانندی‌های فراوانی دارند. از این رو، به‌جای این‌که هربار متدولوژی مدیریت پروژه را درون پروژه اختصاصی کنید، بهتر است که یک‌بار آن را کلان و نیمه‌کاره در سطح سازمان و برای جنبه‌های مشترک پروژه‌ها اختصاصی‌سازی کنید. اگر نیاز باشد می‌توانید بیشتر از یک حالت نیمه اختصاصی‌سازی شده در سطح سازمان داشته باشید تا انواع مختلفی از پروژه را پشتیبانی کنند.
هرچه هم که پروژه‌های سازمان همانند باشند، باز هم دقیقا یکسان نیستند و باید حدی از اختصاصی‌سازی درون پروژه انجام شود. از این رو، اختصاصی‌سازی سازمانی نیمه‌کاره است و قسمت دوم آن جداگانه در هر پروژه انجام می‌شود.
برای نخستین مرحله اختصاصی‌سازی نیاز به مرکزی در سازمان دارید. این مرکز را می‌توان مرکز تعالی (center of excellence) نامید. بسیاری علاقه وافر به عبارت PMO دارند (مخفف project management office یا عبارت‌های دیگر). اگر سازمان PMO داشته باشد، مدیریت نخستین مرحله اختصاصی‌سازی می‌تواند از وظایف اصلی آن به شمار برود.
پم‌باک و سایر استانداردهای PMI با روندی مطابق با آنچه برای تدوین استانداردها در موسسه استاندارد آمریکا (ANSI) تعریف شده مدیریت می‌شوند. در ویرایش‌های نخستین تلاش بر این بود که این روند تا جای ممکن با آنچه موسسه بین‌المللی استانداردسازی (ISO) انتظار دارد نیز همخوان باشد، ولی متاسفانه این توجه در سال‌های اخیر کمتر شده است.
متاسفانه PMI در عمل موسسه‌ای بین‌المللی نیست، بلکه موسسه‌ایست آمریکایی که بیشتر نقاط جهان فعال و شناخته‌شده است. این مسئله از سوی بسیاری کمبودی زیربنایی به شمار می‌رود.
تیم تالیف پم‌باک دوازده عضو داشت و من هم یکی از این افراد بودم. اعضای تیم از نقاط مختلف جهان و با پس‌زمینه‌ها و مهارت‌های گوناگون انتخاب شده بودند و تدوین استاندارد را بردوش داشتند. تیمی هم برای رهبری پروژه وجود داشت که مسئول هماهنگی‌ها، نظارت بر مطابقت کارها با الزامات موسسه و همانند آن بود.
گروهی حدودا هفتاد نفره مسئولیت مرور خروجی‌های تیم تالیف را در زمان کار داشت. در پایان، پیش‌نویسی از محتوا در اختیار عموم قرار گرفت و حدود ششصد نفر دیدگاه‌هایشان را در اختیارمان قرار دادند. دیدگاه‌ها گونه‌ای میان اعضای تیم تالیف بخش شد که هر دیدگاه را دو نفر مستقل از هم بررسی کنند و درباره آن تصمیم بگیرند. اگر تصمیم آن دو عضو یکسان نمی‌بود، نفر سومی هم دیدگاه را بررسی می‌کرد و بر پایه رای اکثریت در میان این سه …