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