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