از آنجایی که ارزش عینی نیست و برای هرکس متفاوت است، برای ارزیابی ارزش پروژه باید دیدی همه‌جانبه داشت و آن را در بستر کلی سازمان سنجید و نه تنها درون پروژه.
ارزش هر پروژه‌ای، گذشته از مشخصات خود پروژه، بستگی به دیگر پروژه‌ها و عملیات سازمان نیز دارد، هم موارد کنونی و هم مواردی که شاید در آینده به وجود آیند. گاهی سیاست‌های کشور و مسایل جهانی هم بر ارزش پروژه اثر می‌گذارند. شاید برای پروژه‌تان در آغاز ارزشی پیش‌بینی کنید، ولی کمی بعد با افزوده شدن پروژه‌ای تازه برهمکنشی رخ دهد که ارزش پروژه پیشین نیز بیشتر شود.
سال‌های آغازینی که ترجمه و تالیف می‌کردم با دو ناشر بسیار خوب کار می‌کردم. از روند کار خرسند بودم، ولی محدودیت‌های طبیعی نشر سنتی، از جمله این‌که دسترسی به کتاب‌ها در برخی شهرها دشوار بود، باعث شد که کم‌کم به فکر نشر الکترونیکی کتاب‌هایم بیفتم. این گزینه به نظر خیلی‌ها ترسناک بود، ولی در عمل نتیجه بسیار خوبی داشت و منافع برآمده از نشر الکترونیکی برایم حدود ۲۰ برابر بیشتر از نشر سنتی شد. سال‌ها ماجرا اینگونه پیش رفت تا این‌که ارزش فرصت و معیارهای ارزشم به‌گونه‌ای تغییر کرد که درآمدزایی از نشر کتاب دیگر گزینه توجیه‌پذیری برایم نیست و از این رو اکنون کتاب‌ها را آزاد و رایگان منتشر می‌کنم.
از همه این مسایل که بگذریم، هدفم ارائه نمونه‌ای جالب از برهمکنش‌ها بود: به ازای هر کتاب …
زمانی با سازمانی همکاری می‌کردم که در کنار پروژه‌های خودش از برخی پروژه‌های غیرانتفاعی هم پشتیبانی مالی می‌کرد. یکی از این پروژه‌ها ساخت پناهگاهی کوهستانی بود. هر از چندی نماینده‌ای از آن پروژه به دفتر ما می‌آمد، گزارشی از کارهای انجام شده و پیش رو و برآوردی از بودجه لازم برای دوره بعد ارائه می‌کرد. زمانی متوجه شدم که مدت زیادی می‌گذرد و خبری از نمایندگان آن پروژه نیست. هنگامی که با آن‌ها تماس گرفتیم، باخبر شدیم که سازمان میراث فرهنگی پروژه را متوقف کرده است، زیرا پناهگاه بر روی جاده‌ای باستانی قرار گرفته بود. متاسفانه هزینه فراوانی که صرف ساخت بخشی از پناهگاه شده بود از دست رفته (هزینه ساخت در کوهستان بسیار زیاد است) و جاده‌ای باستانی هم آسیب دیده بود.
جاده باستانی را به‌سختی می‌شد تشخیص داد و تفاوت چندانی با پاکوبه‌هایی که به‌تدریج با رفت و آمد کوهنوردان به وجود می‌آمد نداشت. با این‌همه، همان اثر جزئی از جاده هم بازتاب تاریخی طولانی بود و میراثی فرهنگی که نیاز به حفاظت داشت.
چگونه می‌شد از بروز چنین چالشی در پروژه جلوگیری کرد؟
پیش از اجرای چنین پروژه‌ای، می‌توان مدتی به محل رفت و با کوهنوردان خبره‌ای که در آنجا رفت و آمد می‌کنند گفتگو کرد و دیدگاهشان را جویا شد. بی‌گمان برخی از کوهنوردان از جاده اطلاع داشتند و می‌توانستند در آن باره اطلاع‌رسانی کنند. افزون بر آن، شاید بتوان …
آزمون PMP درباره اطلاعات عمومی مدیریت پروژه بود. پس از مدتی، PMI برآن شد که این اطلاعات را سازمان‌دهی و در قالب راهنمایی منتشر کند. نخستین پیش‌نویس آن در ۱۹۸۷ و ویرایش نهایی‌اش پس از اصلاح‌های زیربنایی در ۱۹۹۶ منتشر شد. پس از آن هر چهار تا پنج سال یک‌بار ویرایش تازه‌ای جانشین پیشین شد:
۱۹۹۶ – نخستین ویرایش رسمی
۲۰۰۰ – ویرایش ۲۰۰۰
۲۰۰۴ – ویرایش ۳
۲۰۰۸ – ویرایش ۴
۲۰۱۳ – ویرایش ۵
۲۰۱۷ – ویرایش ۶
۲۰۲۱ – ویرایش ۷
ویرایش نخست پم‌باک مدیریت پروژه را با ۳۷ فرآیند توضیح می‌داد. هر فرآیند شماری ورودی، ابزار و روش، و خروجی داشت. فرآیندها به دو شکل دسته‌بندی شده بودند:
گروه‌های فرآیندی: دسته‌بندی بر پایه جایگاه فرآیند در چرخه حیات پروژه
آغازش
برنامه‌ریزی
اجرا
کنترل
پایان
حوزه‌های دانش: دسته‌بندی بر پایه موضوع فرآیند
یکپارچگی
گستره
زمان
هزینه
کیفیت
منابع انسانی
ارتباطات
ریسک
تدارکات
پنج ویرایشی که پس از آن منتشر شدند همگی ساختار نخستین را بهبود می‌دادند. شمار فرآیندها به‌تدریج از ۳۷ به ۴۹ رسید. حوزه دانش ارتباطات به ارتباطات و ذی‌نفعان تقسیم شد و برخی عنوان‌ها نیز اصلاح شدند. سرانجام، کتاب از ۱۷۶ صفحه در ویرایش نخست به ۷۵۶ صفحه در ویرایش ششم رسید.
برخلاف ویرایش‌های پیشین، محتوای ویرایش هفتم بهبودیافته و دقیق‌شده محتوای پیشین نبود، بلکه کار را …
بسیاری رهبری را از ویژگی‌های مدیران می‌دانند، ولی در ادبیات مدرن به هرکسی که افراد را به سمت نتایج مطلوب هدایت کند رهبر گفته می‌شود.
این تعریف نوین از این رو اهمیت دارد که در هر گروهی عده‌ای علاقه‌مند به رهبری وجود دارد که گذشته از سمت و مسئولیت خود به همگی کمک می‌کنند زیرا این رفتار برایشان خوشایند است. متاسفانه این افراد در بسیاری از سازمان‌ها نادیده گرفته می‌شوند، با این‌که اگر از آن‌ها پشتیبانی کنیم و قدرت بیشتری در اختیارشان بگذاریم می‌توانند بیش از پیش به سازمان یا پروژه کمک کنند. دست‌کم، اگر از آن‌ها پشتیبانی نمی‌کنید، چنان زیر فشارشان نگذارید که مانند خانمی که در نمونه پیشین گفته شد بگذارند و بروند.
بسیاری از منابع امروزی درباره روش‌های ترکیبی (hybrid) سخن می‌گویند؛ روش‌هایی که از ترکیب روش‌های متعین و چابک به وجود می‌آید. در عمل نمی‌توان چنین ترکیبی داشت، زیرا برای تطبیقی بودن در پروژه باید همه عناصر آن تطبیقی باشند و همین‌که جنبه‌ای از آن را ثابت و متعین کنیم، انعطاف‌پذیری و انطباق‌پذیری همه بخش‌ها از بین می‌روند. اگر بتوان بخشی را متعین کرد بدون این‌که تطبیق‌پذیری بخش‌های دیگر را از بین ببرد، آن دو بخش استقلال مفهومی، عملکردی و تولیدی کامل دارند و درنتیجه با دو محصول سروکار داریم که نیاز به دو پروژه مختلف دارند، و هیچ منعی برای استفاده از دو روش ساخت متفاوت در دو پروژه وجود ندارد، ولی آن را نمی‌توان «روش ترکیبی» دانست. وقتی با یک پروژه و یک محصول سروکار داریم، روش ساخت یا متعین خواهد بود، یا تطبیقی.
کسانی که از روش‌های ترکیبی سخن می‌گویند معمولا توجهشان معطوف ظواهر است و هرگاه ترکیبی از برچسب‌ها، اسناد، و مراسم که از دو روش آمده باشند بینند، آن را روشی ترکیبی می‌نامند. مدیر پروژه خبره می‌داند که توجه به ظواهر بارپرستی است و باید به‌جای آن به عملکردهای واقعی و ذات مسایل توجه داشت.
متاسفانه پم‌باک ۷ نیز پیروی سوتفاهم رایجی که در این باره وجود دارد درباره روش‌های ترکیبی سخن می‌گوید. کوشش من برای قانع کردن تیم و حذف این اشتباه نیز به جایی نرسید.
داستان تاسف‌آوری که تعریف کردم نتیجه یکی از عدم‌قطعیت‌های پروژه بود؛ این‌که در مدتی که دیوار بیرونی طبقه‌ای ساخته نشده باشد، احتمال دارد کسانی که در آن طبقه کار می‌کنند به پایین پرت شوند.
عدم‌قطعیت‌هایی که می‌توانند بر پروژه اثر مثبت یا منفی بگذارند ریسک نامیده می‌شوند. شیوه مدیریت این موارد با آنچه قطعیت دارد (برای نمونه، این‌که می‌دانیم حتما باید دیوار بیرونی آن طبقه را بسازیم) تفاوت دارد و از این رو مبحثی برای مدیریت ریسک وجود دارد.
مدیریت ریسک مانند مدیریت کیفیت و سایر جنبه‌های مدیریتی منافع فراوانی دارد، ولی هرگاه به لزوم مدیریت ریسک شک کردید، آن جوانی که گفته شد را به یاد بیاورید و به این نکته بیندیشید که اگر مدیریت ریسک بهتر انجام شده بود شاید هنوز زنده می‌بود و در کنار همسر و دو فرزندش زندگی می‌کرد.
تحویل یک‌باره در پایان پروژه ریسک‌های فراوانی دارد، زیرا اگر عنصری از پروژه مناسب نباشد و در زمان تحویل کشف شود، اصلاحش می‌تواند بسیار پرهزینه باشد. پروژه‌های تطبیقی که تحویل تدریجی دارند چنین ریسکی ندارند، اما در پروژه‌های متعین باید مراقب آن بود.
با این‌که در بسیاری از پروژه‌های متعین نمی‌توان تحویل در میانه کار داشت، بازهم می‌توان روندی دوره‌ای برای بررسی وضعیت تازه محصول و دریافت تاییدی ضمنی از کارفرما داشت. این مسئله چنان مهم است که بسیاری از متدولوژی‌ها روندی برای این منظور دارند. اگر متدولوژیتان چنین جنبه‌ای را پوشش نداده باشد، بهتر است آن را بیفزایید، به‌ویژه اگر پیش‌بینی می‌کنید که میان کارفرما و پیمانکار اختلاف‌نظر به وجود خواهد آمد.
چه زمانی باید سیستم را اختصاصی‌سازی کرد؟ پاسخ بستگی به متدولوژی‌ای دارد که انتخاب کرده‌اید:
در سیستم‌های ماکسیمالیستی، مانند پرینس۲، عناصر فراوانی وجود دارد که کمابیش هر نوع پروژه‌ای را پوشش می‌دهد. از این رو، لازم است که در آغاز و پیش از به کارگیری سیستم آن را اختصاصی‌سازی کرد.
سیستم‌های مینیمالیستی، مانند P3.express، حداقل عناصری که در پروژه‌های مخاطبشان کلیدی و مشترک باشند را پوشش می‌دهند. از این رو، نیازی نیست که در آغاز سیستم را اختصاصی‌سازی کرد و به‌جای آن باید پس از مرور زمان و بر پایه بازخورد محیطی به تدریج دست‌به‌کار اختصاصی‌سازی شد.
حتی زمانی که سیستم نیاز به اختصاصی‌سازی آغازین داشته باشد، باز هم لازم است که اختصاصی‌سازی تدریجی در هنگام کار داشته باشید. از سوی دیگر، اختصاصی‌سازی آغازین کار پر ریسکی است؛ چالش رایج این است که اختصاصی‌سازی‌های نخستین غیرواقع‌بینانه و زیاد از حد پیچیده و سنگین می‌شوند و کارکرد سیستم را مختل می‌کنند. از این رو، بهتر است که اگر نیاز به اختصاصی‌سازی آغازین دارید، آن را ساده و حداقلی انجام دهید و باقیمانده آن را در هنگام کار پیش ببرید.
دیر یا زود، محصول نهایی پروژه، شامل همه تحویل‌شدنی‌هایش، به کارفرما تحویل می‌شود و در اختیار کاربران نهایی قرار می‌گیرد. با این‌همه، زمان، چگونگی، و بسامد تحویل همیشه یکسان نیست:
پروژه‌های متعین: به دلیل روند کمابیش خطی این نوع پروژه، معمولا محصول نهایی پروژه یک‌باره و در پایان کار تحویل می‌شود. برخی پروژه‌های متعین چند بخش کمابیش جدا از هم دارند و در فازهای مختلف انجام شده، جداگانه و در طول انجام پروژه تحویل می‌شوند.
پروژه‌های تطبیقی: در هنگام اجرای پروژه‌های تطبیقی باید نسخه‌های قابل استفاده محصول نهایی ساخته شده، در اختیار همه یا بخشی از کاربران نهایی قرار گیرد تا بر پایه بازخوردهای دریافتی مسیر پیش روی پروژه تعیین گردد. این نسخه‌ها باید قابل استفاده باشند، وگرنه بازخورد فراهم شده اطمینان‌پذیر نخواهد بود. از آنجایی که نسخه‌ها قابل استفاده هستند، می‌توان آن‌ها را تحویل نیز داد و عملیاتی کرد. اینگونه، تحویل در پروژه‌های تطبیقی می‌تواند تدریجی باشد.
پروژه‌ای که نتواند نسخه‌های قابل استفاده محصول را بسازد نمی‌تواند تطبیقی باشد. فراموش هم نکنید که هر نسخه قابل استفاده مجموعه‌ای از تحویل‌شدنی‌هاست، ولی هر مجموعه‌ای از تحویل‌شدنی‌ها نسخه‌ای قابل استفاده نیست.
حامی پروژه: این فرد یکی از مدیران ارشد سازمان با رویکرد کسب و کار است که تصمیم‌گیری‌های کلان و مسئولیت فراهم کردن منابع را بر دوش دارد.
مدیر پروژه: این فرد مسئول مدیریت مسایل روزمره است.
رهبران تیم‌ها: چنانچه پروژه تیم‌هایی متشکل از افراد درونی سازمان داشته باشد، برای هر تیم رهبری انتخاب می‌شود که در مسایل مدیریتی با مدیر پروژه هماهنگ شود.
مدیران پروژه پیمانکار: اگر پروژه پیمانکارانی داشته باشد، هر پیمانکار جز مانند یک تیم عمل خواهد کرد و فردی که در راس آن تیم باشد مدیر پروژه پیمانکار نامیده می‌شود.
توجه داشته باشید که هرکدام از ارکان پروژه که از P3.express استفاده کنند زاویه دید خود را خواهند داشت و ساختار، اسناد، و فرآیندهایش نیز بر همان پایه خواهد بود. برخلاف آن، در حالت پیش‌فرض پرینس۲، ساختاری یکه برای ترکیب همه ارکان پروژه وجود دارد.
اگر لازم باشد می‌توانید نقش‌های بیشتری به سیستم بیفزایید، ولی مراقب باشید که این کار را به تدریج، بر پایه بازخوردهایی که از محیط دریافت می‌کنید و بدون پیچیده کردن سیستم انجام دهید.
در پرینس۲ سه سطح مدیریتی درون پروژه، پایین‌تر از سطح مدیریتی سازمان وجود دارد. نقش‌های متعددی در این لایه‌ها تعریف شده است، ازجمله:
لایه هدایت
هیئت پروژه
مدیر ارشد: یکی از مدیران ارشد سازمان با گرایش کسب و کار است که مسئولیت تصمیم‌های کلان پروژه و فراهم‌آوری منابع را بر دوش دارد.
کاربران ارشد: این افراد نمایندگانی از کاربران نهایی محصول پروژه هستند یا کسانی که درک کاملی از کاربران نهایی دارند و این اطلاعات را به هیئت پروژه می‌آورند.
تامین‌کنندگان ارشد: این افراد یا نمایندگان کسانی هستند که محصول پروژه را می‌سازند، یا کسانی که درک کاملی از آن‌ها دارند و این اطلاعات را به هیئت پروژه می‌آورند.
لایه مدیریت
مدیر پروژه: این فرد مسئول مدیریت مسایل روزمره پروژه است.
پشتیبانی پروژه: این افراد در مدیریت پروژه به مدیر پروژه کمک می‌کنند.
لایه ساخت
رهبران تیم‌ها: این افراد تیم‌های اجرایی درونی و بیرونی را رهبری می‌کنند و با مدیر پروژه در ارتباط هستند.
می‌توانید با شکستن هرکدام از نقشها، نقش‌های تازه‌ای به وجود آورید یا با ادغام کردن آن‌ها در هم سیستم سیستم را ساده‌تر کنید. برای این کار محدودیت‌هایی نیز وجود دارد؛ برای نمونه، نباید نقش مدیر پروژه و مدیر ارشد در هم ادغام شوند زیرا هم تضاد منافع به وجود می‌آید و هم این‌که برای یک نفر دشوار است که هم به جنبه‌های بسیار کلان توجه کند و …
اسکرام مستر: این فرد شیوه کارکرد تیم را زیر نظر دارد و آن‌ها را هدایت می‌کند که از اسکرام به‌درستی استفاده کنند. افزون بر آن، مسئولیت تسهیل‌گری و رفع چالش‌ها را نیز بر دوش دارد.
مالک محصول: این فرد درک کاملی از کسب و کار دارد و از یک سو با دیگر اعضای تیم در تماس است و از سوی دیگر با ذی‌نفعان بیرونی تیم. با پیگیری‌هایش نیازهای کارفرما را درک کرده، در تیم بازتاب می‌دهد. افزون بر آن، نیازها را بر پایه پتانسیل ارزششان اولویت‌بندی می‌کند تا تیم همیشه بر باارزش‌ترین قابلیت‌ها متمرکز شود.
توسعه‌دهندگان: این افراد کسانی مانند برنامه‌نویسان، طراحان رابط کاربری، و معماران نرم‌افزار هستند که ساخت محصول را بر دوش دارند. البته در کنار کار فنی، مسئولیت‌هایی مدیریتی نیز دارند.
سیستم مدیریتی اسکرام غیرمتمرکز است؛ به این معنی که به‌جای داشتن فرد و گروهی که مسئولیت اصلی هماهنگی‌ها و مدیریت پروژه را بر دوش داشته باشند، این مسئولیت‌ها در میان همه اعضای تیم پخش شده است.
به دلیل ساختاری که اسکرام دارد، افزودن نقش‌های دیگر به سازگاری درونی آن آسیب می‌زند و بنابراین مجاز نیست.
تحویل‌شدنی‌های بسیاری از پروژه‌ها به اندازه‌ای پرشمارند که اگر در فهرستی ساده و تک‌سطحی قرار داده شوند فهرست آنقدر بلند می‌شود که قابل استفاده نخواهد بود. راهکار معمول در چنین مواقعی، دسته‌بندی کردن آیتم‌های فهرست است و برای تحویل‌شدنی‌ها نیز می‌توان چنین کاری کرد. به‌جای یک سطح دسته‌بندی هم می‌توانید چندین سطح داشت که اصلاحا سلسله‌مراتبی نامیده می‌شود.
بسیاری از متدولوژی‌های مدیریت پروژه استفاده از دسته‌بندی‌های سلسله مراتبی را پیشنهاد می‌کنند. در چنین دسته‌بندی‌هایی محصول اصلی پروژه به چند تحویل‌شدنی کلان تقسیم می‌شود، هرکدام از آن‌ها به چند تحویل‌شدنی کوچک‌تر و روند به همین ترتیب ادامه پیدا می‌کند تا به جزئی‌ترین تحویل‌شدنی‌ها برسیم.
این دسته‌بندی‌های سلسله‌مراتبی نام‌های مختلفی دارند:
بیشتر منابع: ساختار شکست کار (work breakdown structure)
به‌کارگیری چنین ساختارهایی بسیار کارآمد است، ولی بازهم باید توجه داشته باشید که لیست‌های تک سطحی برای پروژه‌های بسیار کوچک کافی و مناسب‌تر هستند. از این رو، در متدولوژی micro.P3.express، که نسخه ویژه‌ای از P3.express برای پروژه‌های بسیار کوچک است، وجود نقشه تحویل‌شدنی‌ها الزامی نیست.
در هر زمان شماری تحویل‌شدنی نیمه‌کاره در پروژه وجود دارد. برخی پروژه‌ها حساسیتی به خرج نمی‌دهند و تحویل‌شدنی‌های پرشماری را به‌موازت هم پیش می‌برند که باعث افت بهره‌وری کلی پروژه می‌شود.
محدود کردن کار نیمه‌کاره یکی از اصل‌های زیربنایی در تولید Lean است، که تاثیر بزرگی هم در پروژه‌های چابک گذاشته است. با این‌همه، کاربرد آن محدود به پروژه‌های چابک نیست و در همه پروژه‌ها باید به آن توجه داشت.
یکی از مسایل اصلی درباره افزایش بیش از اندازه شمار کارهای موازی این است که وقتی چنین فرهنگی در پروژه وجود داشته باشد، هرگاه اعضای تیم در ساخت تحویل‌شدنی‌ای به دشواری بر بخورند به‌جای گره‌گشایی به سراغ انجام تحویل‌شدنی دیگری می‌روند که خروجی کارشان به ظاهر بالاتر باشد. هرچه بیشتر از زمان بروز دشواری بگذرد، حلش سخت‌تر می‌شود و از این رو چنین روندی مناسب نیست. همیشه به یاد داشته باشید که هدف زودتر آغاز کردن کارها نیست، بلکه زودتر به پایان رساندن آن‌هاست.
برخی از متدولوژی‌ها عناصری دارند که تیم پروژه را تشویق می‌کند که تحویل‌شدنی‌های نیمه‌کاره را به سرانجام برسانند و پس از آن دست به کار تحویل‌شدنی‌های تازه بشوند. چنین عنصری را می‌توان به روندی ضمنی برای دریافت تایید نیز متصل کرد که خود مانع بروز بسیاری از دشواری‌های زمان تحویل نهایی می‌شود و در بخش گذشته بررسی شد. اگر متدولوژیتان چنین جنبه‌ای را …
گاهی شناسایی ذی‌نفعان کار ساده‌ای نیست. نمونه‌اش پناهگاه کوهستانیست که پیش از این طرح شده بود.
باید در آغاز کار زمان کافی صرف شناسایی ذی‌نفعان کلیدی کرد، زیرا برخی از ذی‌نفعان، مانند قانون‌گذاران، چنان تاثیرهای کلانی بر پروژه می‌گذارند که ممکن است توجیه‌پذیری آن را از بین ببرند. اگر این ذی‌نفعان در آغاز کار شناسایی شوند، شاید متوجه شوید که بهتر است زمان و هزینه‌ای صرف پروژه نشده، لغو شود.
گذشته از شناسایی نخستین، باید دایما در هنگام اجرای پروژه نیز به فکر شناسایی ذی‌نفعان تازه باشید، زیرا
شاید برخی از ذی‌نفعان را از قلم انداخته باشید، و
شاید تغییرهایی در محیط پروژه به وجود آمده، ذی‌نفعان تازه‌ای به وجود آورده باشد.
مانند بسیاری دیگر از حوزه‌های مدیریت پروژه، بهتر است به اسناد پروژه‌های همانند که در گذشته اجرا کرده‌اید نیز مراجعه کنید تا ببینید چه کسانی بر آن اثر گذاشته‌اند. اینگونه می‌توانید ذی‌نفعان بیشتری شناسایی کنید که شاید بدون آن از قلم بیفتند. این مسئله یکی از دلایل فراوانیست که بر لزوم مستندسازی و بایگانی مناسب اسناد پروژه‌ها پافشاری می‌کنیم.
متدولوژی خود را بررسی کنید تا ببینید که روندی که برای شناسایی ذی‌نفعان دارد برای شرایط پروژه‌تان مناسب است یا نه، و اگر لازم است، فعالیت‌های ساخت‌یافته‌تری برای این منظور به آن بیفزایید.