باوجود استدلال‌های بخش پیش، چه‌بسا هنوز هم احساس بهتری درباره بازی نخست داشته باشید که طبیعیست و ترس از دست دادن (loss aversion) نام دارد. بار احساسی از دست دادن بیشتر از به دست آوردن است. این نسبت در فرهنگ‌ها و افراد مختلف یکسان نیست، ولی این مقدار برای بسیاری افراد حدود دو و نیم است. در نمونه پیشین، امید ریاضی گزینه دوم دو برابر گزینه نخست بود که کمتر از آستانه دو و نیم برابر است و از این رو، بسیاری از افراد گزینه نخست را ترجیح می‌دهند.
ترس از دست دادن گرایشی طبیعیست که در همه ما وجود دارد. این گرایش به شکل تکاملی در اجدادمان که در جنگل و غار زندگی می‌کردند و جانشان دایما درخطر بود شکل گرفته است و در دنیای امروزی کاربرد کمتری دارد. این گرایش یکی از فریب‌های ذهنی (cognitive bias) است. موارد زیر نمونه‌های دیگری از فریب‌های ذهنی‌اند:
گاهی هنگامی که ایده‌ای داریم و درستی آن را ارزیابی می‌کنیم، ناخودآگاه تنها شواهد تایید کننده را می‌بینیم (confirmation bias).
گاهی کارهایی که آغاز کرده‌ایم توجیه‌پذیری خود را از دست می‌دهند، ولی به دلیل هزینه یا کوششی که پیشتر برایشان کرده‌ایم ادامه‌شان می‌دهیم تا به پایان برسند، با این‌که این کار فقط باعث اتلاف هزینه و توان بیشتر می‌شود (sunk cost effect).
گاهی افراد و شرایط را فقط بر پایه کلیشه‌هایی که درباره‌شان وجود دارد قضاوت می‌کنیم …
محصول این دو لایه را می‌توان به ترتیب برنامه و متابرنامه نامید. برای نمونه، برنامه ریسک فهرستی از ریسک‌های شناسایی شده و واکنش‌هاییست که برایشان طراحی کرده‌اید. این برنامه می‌تواند در صفحه‌گسترده‌ای در اکسل و نرم‌افزارهای همانند آن باشد و فهرست ریسک (risk register) نامیده شود. از سوی دیگر، متابرنامه ریسک سندیست که شیوه مدیریت ریسک را توضیح می‌دهد: تکنیک‌هایی که استفاده می‌کنید، جریان کار، اسناد، و …
هر متدولوژی شیوه مدیریت هرکدام از حوزه‌ها را توضیح می‌دهد و اینگونه بخشی از متابرنامه‌ها در متدولوژی وجود دارد، ولی همه جنبه‌ها را نمی‌توان در متدولوژی لحاظ کرد و از این رو گاهی پیشنهاد می‌شود که برای هر حوزه متابرنامه‌ای نیز بسازید.
معمولا متدولوژی‌هایی مانند پرینس۲، که نیاز به اختصاصی‌سازی نخستین دارند، ساخت متابرنامه‌ها را نیز پیشنهاد می‌کنند، ولی آن‌هایی که مانند P3.express نیاز به اختصاصی‌سازی نخستین ندارند چنین پیشنهادی نیز نمی‌کنند. با این‌همه، حتی در مورد دوم هم اگر حوزه‌ای وجود دارد که حساسیت‌های ویژه‌ای در پروژه دارد، بهتر است برایش در آغاز متابرنامه آماده کنید. برای نمونه، اگر تدارکات پروژه چالش‌برانگیز است، شیوه برنامه‌ریزی، ارزیابی و کنترل آن را تعیین کرده، در سندی با …
اگر سیستم مدیریت پروژه خود را شکل دهید و سپس به این بیندیشید که چگونه می‌توان عناصری برای مدیریت کیفیت به آن افزود، احتمالا چندان موفق نخواهید بود. مدیریت کیفیت باید عنصری یکپارچه در سیستم بوده، از آغاز در شکل‌دهی آن لحاظ شده باشد.
منابع ساخت‌یافته درباره مدیریت پروژه را به دو دسته می‌توان تقسیم کرد:
متدولوژی‌ها راه مناسب را در پروژه نشان می‌دهند.
راهنماها به شما کمک می‌کنند که متدولوژی خود را کارآتر کنید.
نخستین عنصری که نیاز دارید متدولوژی است. پس از استقرار متدولوژی مناسب، می‌توانید از راهنماها برای افزایش کارآیی سیستم کمک بگیرید.
پم‌باک راهنماست و نه متدولوژی. همواره کسان زیادی کوشش کرده‌اند که آن را به‌شکل یک متدولوژی به کار ببرند و هیچ‌گاه نیز موفق نبوده‌اند. این مسئله چنان حاد بود که توضیحی به مقدمه ویرایش‌های پیشین افزوده شد و متدولوژی نبودن پم‌باک و لزوم بهره‌مندی از یک متدولوژی در کنار آن را توضیح داد. بااین‌همه، رویکرد فرآیند محور پم‌باک همچنان سوتفاهم ایجاد می‌کرد و کماکان کسان زیادی آن را با یک متدولوژی اشتباه می‌گرفتند. یکی از اهداف تدوین نسخه هفتم این بود که به‌گونه‌ای زیربنایی جلوی این اشتباه گرفته شود و گمان می‌کنم در این کار موفق بوده‌ایم! ساختار اصل محور نسخه هفتم را دیگر نمی‌توان با متدولوژی اشتباه گرفت.
پم‌باک به دو شکل می‌تواند به شما کمک کند:
اصل‌ها کمک می‌کنند که تعبیر و تفسیر بهتری از متدولوژی‌های مدیریت پروژه داشته باشید.
حوزه‌های عملکردی کمک می‌کنند که متدولوژی خود را کارآتر کنید.
از این رو، در ادامه کتاب این سه فصل اصلی وجود دارد:
دو راه کلی برای ساخت محصول پروژه وجود دارد، متعین (predictive) و تطبیقی (adaptive):
در روش متعین، در آغاز پروژه به همه جنبه‌ها می‌اندیشیم، محصول را به‌دقت طراحی می‌کنیم و سپس آن را می‌سازیم. پروژه‌ای برای ساخت و فرستادن یک مریخ‌نورد را در نظر بگیرید. مریخ‌نورد باید در محیطی کاملا متفاوت با محیط عادی ما کار کند، با گرانش، نوع اتمسفر و بسیاری از شاخص‌هایی که مانند زمین نیستند. چنین پروژه‌ای بسیار پرهزینه هم هست و نمی‌توان با آزمایش و خطای فراوان به نتیجه رسید، بلکه باید با بهره‌مندی بهینه از دانش موجود پیش‌بینی همه مسایل را در آغاز کرد و سپس محصول را ساخت. به‌عنوان نمونه‌ای ساده‌تر، ساخت یک پل را در نظر بگیرید: چنین محصولی هم باید به شکل متعین ساخته شود.
در برخی پروژه‌ها که به شدت وابسته به برداشت و سلیقه مشتری هستند نمی‌توان محصول مناسب را پیش‌بینی کرد، چون رفتار انسان‌ها پیش‌بینی‌ناپذیرند. از این رو، به‌جای شیوه متعین از شیوه تطبیقی استفاده می‌کنیم. در این شیوه به‌جای این‌که همه‌چیز را در آغاز طراحی کنیم و سپس بسازیم، ترتیبی فراهم می‌کنیم که بتوان بخشی کوچک و در عین حال معنادار از محصول را ساخت و به کاربران نهایی یا گزیده‌هایی از آن‌ها ارائه کرد و از رفتار و برخوردشان بازخورد گرفت. با کمک آن بازخورد حدس می‌زنیم که بهترین گام بعدی برای محصول چیست و با آن دانش نسخه بعدی را می‌سازیم. …
یکی از معیارهای مهم در ارزیابی وضعیت پروژه، توجیه‌پذیری آن است. دایما باید این مسئله را کنترل کنید و هرگاه پروژه توجیه‌پذیری خود را از دست داد مسئله را به حامی پروژه اطلاع دهید.
متدولوژیتان احتمالا کنترل‌هایی دوره‌ای برای توجیه‌پذیری پروژه دارد. اگر اینگونه نیست، لازم است آن را بیفزایید.
درباره متغیرهای پروژه چه باید کرد؟
متغیرهای پروژه جنبه‌هایی مانند گستره، زمان، هزینه، و کیفیت هستند. برخی منابع متغیرهای دیگری مانند مجموع ریسک و منافع را نیز اضافه می‌کنند. همه این متغیرها را باید دایما ارزیابی کرد و توجیه‌پذیری پروژه معمولا ترکیبی از همه آن‌هاست.
هریک از متغیرهای پروژه‌تان تا چه اندازه حساسند؟ برای نمونه، اگر قرار است مجموعه‌ای بسازید که برای همایشی ملی به کار برود، هیچ‌گونه تاخیری پذیرفتنی نخواهد بود و نیاز به کنترل‌های دقیق‌تری برای زمان خواهید داشت. در چنین مواردی، کنترل‌های لازم را در متدولوژی خود تقویت کنید.
هر متدولوژی زمان مناسب و روند برنامه‌ریزی را توضیح می‌دهد، ولی گاهی محتوای برنامه‌هایشان چندان روشن نیست.
نسخه‌های پیشین پم‌باک مجموعه‌ای از حوزه‌های دانش داشتند که از برخی جهات مانند حوزه‌های عملکردی نسخه هفتم (موضوع این فصل) بودند، ولی یکسان نیستند. به نظر من حوزه‌های دانش دسته‌بندی بسیار خوبی برای شرح آنچه قرار است برنامه‌ریزی شود هستند:
یکپارچگی
گستره
زمان
هزینه
کیفیت
منابع
ارتباطات
ریسک
تدارکات
ذی‌نفعان
این دسته‌بندی یکی از انواع دسته‌بندی است که می‌توانید در نظر داشته باشید. همه این موارد باید به‌نوعی در برنامه‌هایتان وجود داشته باشند. متدولوژیتان احتمالا همگی را پوشش دهد، ولی شاید برخی از این جنبه‌های پروژه‌تان حساس‌تر باشند و بنابراین نیاز باشد که آن‌ها را بسته به پیش‌فرضی که در متدلوژی وجود دارد قوی‌تر کنید.
فراموش نکنید که برنامه زمان‌بندی فقط یکی از این ۱۲ مورد است.