منابع ساخت‌یافته درباره مدیریت پروژه را به دو دسته می‌توان تقسیم کرد:
متدولوژی‌ها راه مناسب را در پروژه نشان می‌دهند.
راهنماها به شما کمک می‌کنند که متدولوژی خود را کارآتر کنید.
نخستین عنصری که نیاز دارید متدولوژی است. پس از استقرار متدولوژی مناسب، می‌توانید از راهنماها برای افزایش کارآیی سیستم کمک بگیرید.
پم‌باک راهنماست و نه متدولوژی. همواره کسان زیادی کوشش کرده‌اند که آن را به‌شکل یک متدولوژی به کار ببرند و هیچ‌گاه نیز موفق نبوده‌اند. این مسئله چنان حاد بود که توضیحی به مقدمه ویرایش‌های پیشین افزوده شد و متدولوژی نبودن پم‌باک و لزوم بهره‌مندی از یک متدولوژی در کنار آن را توضیح داد. بااین‌همه، رویکرد فرآیند محور پم‌باک همچنان سوتفاهم ایجاد می‌کرد و کماکان کسان زیادی آن را با یک متدولوژی اشتباه می‌گرفتند. یکی از اهداف تدوین نسخه هفتم این بود که به‌گونه‌ای زیربنایی جلوی این اشتباه گرفته شود و گمان می‌کنم در این کار موفق بوده‌ایم! ساختار اصل محور نسخه هفتم را دیگر نمی‌توان با متدولوژی اشتباه گرفت.
پم‌باک به دو شکل می‌تواند به شما کمک کند:
اصل‌ها کمک می‌کنند که تعبیر و تفسیر بهتری از متدولوژی‌های مدیریت پروژه داشته باشید.
حوزه‌های عملکردی کمک می‌کنند که متدولوژی خود را کارآتر کنید.
از این رو، در ادامه کتاب این سه فصل اصلی وجود دارد:
دو راه کلی برای ساخت محصول پروژه وجود دارد، متعین (predictive) و تطبیقی (adaptive):
در روش متعین، در آغاز پروژه به همه جنبه‌ها می‌اندیشیم، محصول را به‌دقت طراحی می‌کنیم و سپس آن را می‌سازیم. پروژه‌ای برای ساخت و فرستادن یک مریخ‌نورد را در نظر بگیرید. مریخ‌نورد باید در محیطی کاملا متفاوت با محیط عادی ما کار کند، با گرانش، نوع اتمسفر و بسیاری از شاخص‌هایی که مانند زمین نیستند. چنین پروژه‌ای بسیار پرهزینه هم هست و نمی‌توان با آزمایش و خطای فراوان به نتیجه رسید، بلکه باید با بهره‌مندی بهینه از دانش موجود پیش‌بینی همه مسایل را در آغاز کرد و سپس محصول را ساخت. به‌عنوان نمونه‌ای ساده‌تر، ساخت یک پل را در نظر بگیرید: چنین محصولی هم باید به شکل متعین ساخته شود.
در برخی پروژه‌ها که به شدت وابسته به برداشت و سلیقه مشتری هستند نمی‌توان محصول مناسب را پیش‌بینی کرد، چون رفتار انسان‌ها پیش‌بینی‌ناپذیرند. از این رو، به‌جای شیوه متعین از شیوه تطبیقی استفاده می‌کنیم. در این شیوه به‌جای این‌که همه‌چیز را در آغاز طراحی کنیم و سپس بسازیم، ترتیبی فراهم می‌کنیم که بتوان بخشی کوچک و در عین حال معنادار از محصول را ساخت و به کاربران نهایی یا گزیده‌هایی از آن‌ها ارائه کرد و از رفتار و برخوردشان بازخورد گرفت. با کمک آن بازخورد حدس می‌زنیم که بهترین گام بعدی برای محصول چیست و با آن دانش نسخه بعدی را می‌سازیم. …
یکی از معیارهای مهم در ارزیابی وضعیت پروژه، توجیه‌پذیری آن است. دایما باید این مسئله را کنترل کنید و هرگاه پروژه توجیه‌پذیری خود را از دست داد مسئله را به حامی پروژه اطلاع دهید.
متدولوژیتان احتمالا کنترل‌هایی دوره‌ای برای توجیه‌پذیری پروژه دارد. اگر این‌گونه نیست، لازم است آن را بیفزایید.
درباره متغیرهای پروژه چه باید کرد؟
متغیرهای پروژه جنبه‌هایی مانند گستره، زمان، هزینه، و کیفیت هستند. برخی منابع متغیرهای دیگری مانند مجموع ریسک و منافع را نیز اضافه می‌کنند. همه این متغیرها را باید دایما ارزیابی کرد و توجیه‌پذیری پروژه معمولا ترکیبی از همه آن‌هاست.
هریک از متغیرهای پروژه‌تان تا چه اندازه حساسند؟ برای نمونه، اگر قرار است مجموعه‌ای بسازید که برای همایشی ملی به کار برود، هیچ‌گونه تاخیری پذیرفتنی نخواهد بود و نیاز به کنترل‌های دقیق‌تری برای زمان خواهید داشت. در چنین مواردی، کنترل‌های لازم را در متدولوژی خود تقویت کنید.
هر متدولوژی زمان مناسب و روند برنامه‌ریزی را توضیح می‌دهد، ولی گاهی محتوای برنامه‌هایشان چندان روشن نیست.
نسخه‌های پیشین پم‌باک مجموعه‌ای از حوزه‌های دانش داشتند که از برخی جهات مانند حوزه‌های عملکردی نسخه هفتم (موضوع این فصل) بودند، ولی یکسان نیستند. به نظر من حوزه‌های دانش دسته‌بندی بسیار خوبی برای شرح آنچه قرار است برنامه‌ریزی شود هستند:
یکپارچگی
گستره
زمان
هزینه
کیفیت
منابع
ارتباطات
ریسک
تدارکات
ذی‌نفعان
این دسته‌بندی یکی از انواع دسته‌بندی است که می‌توانید در نظر داشته باشید. همه این موارد باید به‌نوعی در برنامه‌هایتان وجود داشته باشند. متدولوژیتان احتمالا همگی را پوشش دهد، ولی شاید برخی از این جنبه‌های پروژه‌تان حساس‌تر باشند و بنابراین نیاز باشد که آن‌ها را بسته به پیش‌فرضی که در متدلوژی وجود دارد قوی‌تر کنید.
فراموش نکنید که برنامه زمان‌بندی فقط یکی از این ۱۲ مورد است.
پشتیبانی از رهبران نامرئی که در بخش پیش مطرح شد مبحث مهمی در حوزه رهبریست، ولی از آن گذشته، باید بر رشد توانایی‌های رهبری خودتان نیز تمرکز کنید.
برای نمونه، به‌عنوان یک رهبر، باید بتوانید در افراد انگیزه ایجاد کنید. فرض کنید یکی از اعضای تیم کار درخشانی در پروژه انجام داده است و می‌خواهید از او قدردانی کنید. چگونه این کار را خواهید کرد؟ با پرداخت پاداش مالی؟
پاسخ بستگی به مسایل فراوانی دارد. پاداش مالی هنگامی کارآمد است که مقدارش نسبت به نیاز مالی فرد مناسب باشد، وگرنه اثر معکوس خواهد داشت، زیرا کم بودن پاداش به معنی دست‌کم گرفتن کار فرد به شمار خواهد رفت. فرض کنید بودجه بسیار محدودی دارید و فقط می‌توانید معادل چهار پیتزا برای قدردانی از آن فرد هزینه کنید. پرداخت چنین پاداشی شایسته نیست، ولی با همان بودجه می‌توانید خودکاری برازنده سفارش دهید که نام آن فرد رویش حک شده باشد، آن را هدیه دهید و با چند جمله زیبا قدردانی خود را نشان دهید.
سوتفاهم‌های فراوانی درباره مفهوم رهبری وجود دارد. برای نمونه، داشتن کاریزما برای رهبران سودمند است، ولی کاریزما محدود به داشتن شخصیتی سرسخت، پرابهت و گاهی بداخلاق نیست. شکل‌های مختلفی از کاریزما وجود دارد و برخی از آن‌ها وابسته به دانش، مهربانی، دلسوزی و هماهنند آن‌ها هستند. بهتر است به جای الگوبرداری از شخصیت‌های کاریزماتیک فیلم‌ها، نوع کاریزمای مناسب …
چابکی رویکردی در ساخت محصول است. برخی از متدولوژی‌ها فقط برای ساخت چابک طراحی شده‌اند، برخی هم برای ساخت چابک و هم متعین، و برخی نیز بیشتر مناسب ساخت محصول متعین هستند.
بیشتر روش‌های چابک نسل نخست، مانند DSDM و XP، نقشی به‌عنوان مدیر پروژه دارند یا دست‌کم مخالفتی با چنین نقشی ندارند. با این‌همه، اسکرام چنین نقشی ندارد و افزودنش به اسکرام نیز سازگاری درونی آن را نابود می‌کند. این مسئله اهمیت فراوانی دارد، زیرا برخی گمان می‌کنند که با افزودن مدیر پروژه به اسکرام آن را تقویت کرده‌اند، با این‌که آن را ضعیف‌تر کرده‌اند.
از سوی دیگر، به دلیل گستردگی فراوان اسکرام و این واقعیت که بسیاری از روش‌های چابک نسل دوم از اسکرام الگوبرداری کردند، برخی می‌پندارند که وجود مدیر پروژه با ذات چابکی ناسازگار است، که کاملا اشتباهست. بسیاری از روش‌های چابک نیاز به مدیر پروژه دارند.
مدیر پروژه واقعی رئیس نیست! هر چه باشد، بیشتر سازمان‌ها کمبود رئیس ندارند. آنچه به‌عنوان مدیر پروژه نیاز داریم، کسانی هستند که بتوانند از تیم پروژه پشتیبانی کنند و با تسهیل‌گری و گره‌گشایی زمینه‌ای فراهم کنند که اعضای تیم پروژه بتوانند کارهای تخصصی خود را به بهترین شکل انجام دهند.
هر برچسبی بار معنایی ویژه خود را دارد که در طی سال‌ها بر پایه تجربه‌ها و رویدادهای فراوان شکل گرفته است. اگر گمان می‌کنید برچسب «مدیر پروژه» بار معنایی مناسبی در سازمانتان ندارد، می‌توانید به‌جای آن از برچسب دیگری استفاده کنید. پیشنهاد همیشگی من برای جانشینی این برچسب، «تسهیل‌گر ارشد پروژه» است. بهره‌مندی از چنین برچسبی دایما مفهوم واقعی مدیر پروژه را به او و دیگران یادآوری می‌کند. البته به یاد داشته باشید که این پیشنهاد من بیشتر برای شرکت‌های نرم‌افزاریست که تصویر ناپسندی از مدیر پروژه دارند، وگرنه مفهوم مدیر پروژه در سایر پروژه‌ها، به‌ویژه در ایران، بار معنایی منفی ندارد (دست‌کم تا جایی که من اطلاع دارم) و بنابراین نیازی به این راهکار نخواهند داشت.