داستان تاسف‌آوری که تعریف کردم نتیجه یکی از عدم‌قطعیت‌های پروژه بود؛ این‌که در مدتی که دیوار بیرونی طبقه‌ای ساخته نشده باشد، احتمال دارد کسانی که در آن طبقه کار می‌کنند به پایین پرت شوند.
عدم‌قطعیت‌هایی که می‌توانند بر پروژه اثر مثبت یا منفی بگذارند ریسک نامیده می‌شوند. شیوه مدیریت این موارد با آنچه قطعیت دارد (برای نمونه، این‌که می‌دانیم حتما باید دیوار بیرونی آن طبقه را بسازیم) تفاوت دارد و از این رو مبحثی برای مدیریت ریسک وجود دارد.
مدیریت ریسک مانند مدیریت کیفیت و سایر جنبه‌های مدیریتی منافع فراوانی دارد، ولی هرگاه به لزوم مدیریت ریسک شک کردید، آن جوانی که گفته شد را به یاد بیاورید و به این نکته بیندیشید که اگر مدیریت ریسک بهتر انجام شده بود شاید هنوز زنده می‌بود و در کنار همسر و دو فرزندش زندگی می‌کرد.
تحویل یک‌باره در پایان پروژه ریسک‌های فراوانی دارد، زیرا اگر عنصری از پروژه مناسب نباشد و در زمان تحویل کشف شود، اصلاحش می‌تواند بسیار پرهزینه باشد. پروژه‌های تطبیقی که تحویل تدریجی دارند چنین ریسکی ندارند، اما در پروژه‌های متعین باید مراقب آن بود.
با این‌که در بسیاری از پروژه‌های متعین نمی‌توان تحویل در میانه کار داشت، بازهم می‌توان روندی دوره‌ای برای بررسی وضعیت تازه محصول و دریافت تاییدی ضمنی از کارفرما داشت. این مسئله چنان مهم است که بسیاری از متدولوژی‌ها روندی برای این منظور دارند. اگر متدولوژیتان چنین جنبه‌ای را پوشش نداده باشد، بهتر است آن را بیفزایید، به‌ویژه اگر پیش‌بینی می‌کنید که میان کارفرما و پیمانکار اختلاف‌نظر به وجود خواهد آمد.
چه زمانی باید سیستم را اختصاصی‌سازی کرد؟ پاسخ بستگی به متدولوژی‌ای دارد که انتخاب کرده‌اید:
در سیستم‌های ماکسیمالیستی، مانند پرینس۲، عناصر فراوانی وجود دارد که کمابیش هر نوع پروژه‌ای را پوشش می‌دهد. از این رو، لازم است که در آغاز و پیش از به کارگیری سیستم آن را اختصاصی‌سازی کرد.
سیستم‌های مینیمالیستی، مانند P3.express، حداقل عناصری که در پروژه‌های مخاطبشان کلیدی و مشترک باشند را پوشش می‌دهند. از این رو، نیازی نیست که در آغاز سیستم را اختصاصی‌سازی کرد و به‌جای آن باید پس از مرور زمان و بر پایه بازخورد محیطی به تدریج دست‌به‌کار اختصاصی‌سازی شد.
حتی زمانی که سیستم نیاز به اختصاصی‌سازی آغازین داشته باشد، باز هم لازم است که اختصاصی‌سازی تدریجی در هنگام کار داشته باشید. از سوی دیگر، اختصاصی‌سازی آغازین کار پر ریسکی است؛ چالش رایج این است که اختصاصی‌سازی‌های نخستین غیرواقع‌بینانه و زیاد از حد پیچیده و سنگین می‌شوند و کارکرد سیستم را مختل می‌کنند. از این رو، بهتر است که اگر نیاز به اختصاصی‌سازی آغازین دارید، آن را ساده و حداقلی انجام دهید و باقیمانده آن را در هنگام کار پیش ببرید.
دیر یا زود، محصول نهایی پروژه، شامل همه تحویل‌شدنی‌هایش، به کارفرما تحویل می‌شود و در اختیار کاربران نهایی قرار می‌گیرد. با این‌همه، زمان، چگونگی، و بسامد تحویل همیشه یکسان نیست:
پروژه‌های متعین: به دلیل روند کمابیش خطی این نوع پروژه، معمولا محصول نهایی پروژه یک‌باره و در پایان کار تحویل می‌شود. برخی پروژه‌های متعین چند بخش کمابیش جدا از هم دارند و در فازهای مختلف انجام شده، جداگانه و در طول انجام پروژه تحویل می‌شوند.
پروژه‌های تطبیقی: در هنگام اجرای پروژه‌های تطبیقی باید نسخه‌های قابل استفاده محصول نهایی ساخته شده، در اختیار همه یا بخشی از کاربران نهایی قرار گیرد تا بر پایه بازخوردهای دریافتی مسیر پیش روی پروژه تعیین گردد. این نسخه‌ها باید قابل استفاده باشند، وگرنه بازخورد فراهم شده اطمینان‌پذیر نخواهد بود. از آن‌جایی که نسخه‌ها قابل استفاده هستند، می‌توان آن‌ها را تحویل نیز داد و عملیاتی کرد. اینگونه، تحویل در پروژه‌های تطبیقی می‌تواند تدریجی باشد.
پروژه‌ای که نتواند نسخه‌های قابل استفاده محصول را بسازد نمی‌تواند تطبیقی باشد. فراموش هم نکنید که هر نسخه قابل استفاده مجموعه‌ای از تحویل‌شدنی‌هاست، ولی هر مجموعه‌ای از تحویل‌شدنی‌ها نسخه‌ای قابل استفاده نیست.
حامی پروژه: این فرد یکی از مدیران ارشد سازمان با رویکرد کسب و کار است که تصمیم‌گیری‌های کلان و مسئولیت فراهم کردن منابع را بر دوش دارد.
مدیر پروژه: این فرد مسئول مدیریت مسایل روزمره است.
رهبران تیم‌ها: چنانچه پروژه تیم‌هایی متشکل از افراد درونی سازمان داشته باشد، برای هر تیم رهبری انتخاب می‌شود که در مسایل مدیریتی با مدیر پروژه هماهنگ شود.
مدیران پروژه پیمانکار: اگر پروژه پیمانکارانی داشته باشد، هر پیمانکار جز مانند یک تیم عمل خواهد کرد و فردی که در راس آن تیم باشد مدیر پروژه پیمانکار نامیده می‌شود.
توجه داشته باشید که هرکدام از ارکان پروژه که از P3.express استفاده کنند زاویه دید خود را خواهند داشت و ساختار، اسناد، و فرآیندهایش نیز بر همان پایه خواهد بود. برخلاف آن، در حالت پیش‌فرض پرینس۲، ساختاری یکه برای ترکیب همه ارکان پروژه وجود دارد.
اگر لازم باشد می‌توانید نقش‌های بیشتری به سیستم بیفزایید، ولی مراقب باشید که این کار را به تدریج، بر پایه بازخوردهایی که از محیط دریافت می‌کنید و بدون پیچیده کردن سیستم انجام دهید.
در پرینس۲ سه سطح مدیریتی درون پروژه، پایین‌تر از سطح مدیریتی سازمان وجود دارد. نقش‌های متعددی در این لایه‌ها تعریف شده است، ازجمله:
لایه هدایت
هیئت پروژه
مدیر ارشد: یکی از مدیران ارشد سازمان با گرایش کسب و کار است که مسئولیت تصمیم‌های کلان پروژه و فراهم‌آوری منابع را بر دوش دارد.
کاربران ارشد: این افراد نمایندگانی از کاربران نهایی محصول پروژه هستند یا کسانی که درک کاملی از کاربران نهایی دارند و این اطلاعات را به هیئت پروژه می‌آورند.
تامین‌کنندگان ارشد: این افراد یا نمایندگان کسانی هستند که محصول پروژه را می‌سازند، یا کسانی که درک کاملی از آن‌ها دارند و این اطلاعات را به هیئت پروژه می‌آورند.
لایه مدیریت
مدیر پروژه: این فرد مسئول مدیریت مسایل روزمره پروژه است.
پشتیبانی پروژه: این افراد در مدیریت پروژه به مدیر پروژه کمک می‌کنند.
لایه ساخت
رهبران تیم‌ها: این افراد تیم‌های اجرایی درونی و بیرونی را رهبری می‌کنند و با مدیر پروژه در ارتباط هستند.
می‌توانید با شکستن هرکدام از نقشها، نقش‌های تازه‌ای به وجود آورید یا با ادغام کردن آن‌ها در هم سیستم سیستم را ساده‌تر کنید. برای این کار محدودیت‌هایی نیز وجود دارد؛ برای نمونه، نباید نقش مدیر پروژه و مدیر ارشد در هم ادغام شوند زیرا هم تضاد منافع به وجود می‌آید و هم این‌که برای یک نفر دشوار است که هم به جنبه‌های بسیار کلان توجه کند و …
اسکرام مستر: این فرد شیوه کارکرد تیم را زیر نظر دارد و آن‌ها را هدایت می‌کند که از اسکرام به‌درستی استفاده کنند. افزون بر آن، مسئولیت تسهیل‌گری و رفع چالش‌ها را نیز بر دوش دارد.
مالک محصول: این فرد درک کاملی از کسب و کار دارد و از یک سو با دیگر اعضای تیم در تماس است و از سوی دیگر با ذی‌نفعان بیرونی تیم. با پیگیری‌هایش نیازهای کارفرما را درک کرده، در تیم بازتاب می‌دهد. افزون بر آن، نیازها را بر پایه پتانسیل ارزششان اولویت‌بندی می‌کند تا تیم همیشه بر باارزش‌ترین قابلیت‌ها متمرکز شود.
توسعه‌دهندگان: این افراد کسانی مانند برنامه‌نویسان، طراحان رابط کاربری، و معماران نرم‌افزار هستند که ساخت محصول را بر دوش دارند. البته در کنار کار فنی، مسئولیت‌هایی مدیریتی نیز دارند.
سیستم مدیریتی اسکرام غیرمتمرکز است؛ به این معنی که به‌جای داشتن فرد و گروهی که مسئولیت اصلی هماهنگی‌ها و مدیریت پروژه را بر دوش داشته باشند، این مسئولیت‌ها در میان همه اعضای تیم پخش شده است.
به دلیل ساختاری که اسکرام دارد، افزودن نقش‌های دیگر به سازگاری درونی آن آسیب می‌زند و بنابراین مجاز نیست.