این فایل به طور خودکار بر اساس آخرین ویرایش آنلاین کتاب ساخته شده است. برای دریافت جدیدترین نسخه یا مطالعه آنلاین کتاب به این آدرس مراجعه کنید: https://khorramirad.com/ebooks/pmbok-7/
تالیف نادر خرمی راد
ویرایش نخست: بهار ۱۴۰۲
این کتاب آزاد و رایگان، با پروانه CC-BY منتشر شده است. استفاده، پخش، تغییر، و بازنشر آن با نام بردن نویسنده و آدرس سایت و ذکر دست‌خورده یا دست‌نخورده بودن محتوا بی‌اشکال و باعث خوشوقتی نویسنده خواهد بود.
درباره نویسنده
سال ۱۳۷۶ کار بر روی پروژه‌ها را آغاز کردم. در آغاز مشغولیتم برنامه‌ریزی و کنترل پروژه بود و در کنار آن کتاب‌های متعددی در این حوزه ترجمه و تالیف کردم که تا امروز به حدود ۵۰ عنوان رسیده است. در این مدت بیشتر در پروژه‌های کارخانه‌های فرآوری و ساختمانی مشغول بودم و در کنار آن‌ها چند پروژه نرم‌افزاری را هم تجربه کردم.
پس از چندی به جنبه‌های کلان‌تر مدیریت پروژه علاقه‌مند شدم و فعالیتم را در آن حوزه ادامه دادم. سال ۱۳۹۳ به بلژیک نقل‌مکان کردم. در اینجا همراه با همکارم شرکت کوچکی به نام Management Plaza داریم که سازنده دوره‌های الکترونیکی مدیریت پروژه است. افزون بر آن، بخش بزرگی از زمانم صرف همکاری در توسعه استانداردها و روش‌ها شده است، از جمله:
برای اطلاعات بیشتر به سایت فارسی‌ام در https://khorramirad.com و درباره فعالیت‌های بین‌المللی‌ام به https://nader.pm یا gemini://nader.pm مراجعه کنید.
رسمیت این کتاب
همه مطالب این کتاب دیدگاه شخصی نویسنده است و دیدگاه رسمی PMI یا تیم تالیف پم‌باک ۷ نیست. برخی از مفاهیم طرح‌شده در این کتاب چالش‌برانگیز بوده، همگان درباره‌شان هم‌رای نیستند.
در دهه هفتاد میلادی مفهوم مدیریت پروژه جدیت بیشتری پیدا کرد و از سوی بسیاری به‌عنوان حرفه‌ای مستقل به رسمیت شناخته شد.
عده‌ای از دست‌اندرکاران مدیریت پروژه در آمریکا آغاز به برگزاری گردهمایی‌ها و کنفرانس‌هایی در این حوزه کردند که به‌تدریج رونق بیشتری گرفت و سرانجام منجر به بنیان‌گذاری موسسه‌ای به نام Project Management Institute شد که کوتاه‌شده PMI نامیده می‌شود.
تمرکز اصلی PMI بر برگزاری کنفرانس‌هایی بود که دست‌اندرکاران را گرد هم می‌آورد. این سنت همچنان ادامه دارد و در هر شهر یا کشوری که شعبه‌ای از PMI وجود داشته باشد معمولا یک کنفرانس بزرگ سالانه و چند کنفرانس کوچک محلی برگزار می‌شود.
مدتی پس از بنیان‌گذاری PMI، ایده راه‌اندازی گواهی‌ای برای مدیریت پروژه شکل گرفت. این گواهی، با نام Project Management Professional (حرفه‌ای در مدیریت پروژه)، که کوتاه‌شده PMP نامیده می‌شود، در ۱۹۸۴ شکل گرفت. گواهی به‌سرعت محبوبیت فراوانی پیدا کرد و همچنان یکی از مطرح‌ترین گواهی‌های مدیریت پروژه جهان به شمار می‌رود.
آزمون PMP درباره اطلاعات عمومی مدیریت پروژه بود. پس از مدتی، PMI برآن شد که این اطلاعات را سازمان‌دهی و در قالب راهنمایی منتشر کند. نخستین پیش‌نویس آن در ۱۹۸۷ و ویرایش نهایی‌اش پس از اصلاح‌های زیربنایی در ۱۹۹۶ منتشر شد. پس از آن هر چهار تا پنج سال یک‌بار ویرایش تازه‌ای جانشین پیشین شد:
ویرایش نخست پم‌باک مدیریت پروژه را با ۳۷ فرآیند توضیح می‌داد. هر فرآیند شماری ورودی، ابزار و روش، و خروجی داشت. فرآیندها به دو شکل دسته‌بندی شده بودند:
پنج ویرایشی که پس از آن منتشر شدند همگی ساختار نخستین را بهبود می‌دادند. شمار فرآیندها به‌تدریج از ۳۷ به ۴۹ رسید. حوزه دانش ارتباطات به ارتباطات و ذی‌نفعان تقسیم شد و برخی عنوان‌ها نیز اصلاح شدند. سرانجام، کتاب از ۱۷۶ صفحه در ویرایش نخست به ۷۵۶ صفحه در ویرایش ششم رسید.
برخلاف ویرایش‌های پیشین، محتوای ویرایش هفتم بهبودیافته و دقیق‌شده محتوای پیشین نبود، بلکه کار را از صفر آغاز کردیم و به‌جای روندی فرآیند محور از روندی اصل محور بهره بردیم تا هم محتوا در همه پروژه‌ها کارا باشد و هم جلوی برخی دشواری‌های رایج در رویکرد فرآیند محور را بگیرد.
این کتاب بر مفهوم پم‌باک ۷ متمرکز است و مباحث چندانی درباره ویرایش‌های پیشین یا تفاوت آن‌ها با ویرایش تازه ندارد. اگر علاقه‌مند به یادگیری فرآیندهای PMI باشید می‌توانید به ویرایش‌های پیشین پم‌باک یا به کتاب تازه‌ای که PMI با نام Process Groups: A Practice Guide منتشر کرده است مراجعه کنید.
پس از موفقیت پم‌باک و آزمون PMP، فعالیت‌های PMI با افزایش موارد زیر ادامه پیدا کرد:
گواهی‌ها
استانداردهای زیربنایی
استانداردهای عملی
راهنماهای کاربردی
به‌جز گواهی PMI-ACP، هیچ‌کدام از موارد بالا به درجه‌ای از پذیرش همگانی در سطح پم‌باک و PMP نرسید.
منابع ساخت‌یافته درباره مدیریت پروژه را به دو دسته می‌توان تقسیم کرد:
نخستین عنصری که نیاز دارید متدولوژی است. پس از استقرار متدولوژی مناسب، می‌توانید از راهنماها برای افزایش کارآیی سیستم کمک بگیرید.
پم‌باک راهنماست و نه متدولوژی. همواره کسان زیادی کوشش کرده‌اند که آن را به‌شکل یک متدولوژی به کار ببرند و هیچ‌گاه نیز موفق نبوده‌اند. این مسئله چنان حاد بود که توضیحی به مقدمه ویرایش‌های پیشین افزوده شد و متدولوژی نبودن پم‌باک و لزوم بهره‌مندی از یک متدولوژی در کنار آن را توضیح داد. بااین‌همه، رویکرد فرآیند محور پم‌باک همچنان سوتفاهم ایجاد می‌کرد و کماکان کسان زیادی آن را با یک متدولوژی اشتباه می‌گرفتند. یکی از اهداف تدوین نسخه هفتم این بود که به‌گونه‌ای زیربنایی جلوی این اشتباه گرفته شود و گمان می‌کنم در این کار موفق بوده‌ایم! ساختار اصل محور نسخه هفتم را دیگر نمی‌توان با متدولوژی اشتباه گرفت.
پم‌باک به دو شکل می‌تواند به شما کمک کند:
از این رو، در ادامه کتاب این سه فصل اصلی وجود دارد:
پم‌باک و سایر استانداردهای PMI با روندی مطابق با آنچه برای تدوین استانداردها در موسسه استاندارد آمریکا (ANSI) تعریف شده مدیریت می‌شوند. در ویرایش‌های نخستین تلاش بر این بود که این روند تا جای ممکن با آنچه موسسه بین‌المللی استانداردسازی (ISO) انتظار دارد نیز همخوان باشد، ولی متاسفانه این توجه در سال‌های اخیر کمتر شده است.
متاسفانه PMI در عمل موسسه‌ای بین‌المللی نیست، بلکه موسسه‌ایست آمریکایی که بیشتر نقاط جهان فعال و شناخته‌شده است. این مسئله از سوی بسیاری کمبودی زیربنایی به شمار می‌رود.
تیم تالیف پم‌باک دوازده عضو داشت و من هم یکی از این افراد بودم. اعضای تیم از نقاط مختلف جهان و با پس‌زمینه‌ها و مهارت‌های گوناگون انتخاب شده بودند و تدوین استاندارد را بردوش داشتند. تیمی هم برای رهبری پروژه وجود داشت که مسئول هماهنگی‌ها، نظارت بر مطابقت کارها با الزامات موسسه و همانند آن بود.
گروهی حدودا هفتاد نفره مسئولیت مرور خروجی‌های تیم تالیف را در زمان کار داشت. در پایان، پیش‌نویسی از محتوا در اختیار عموم قرار گرفت و حدود ششصد نفر دیدگاه‌هایشان را در اختیارمان قرار دادند. دیدگاه‌ها گونه‌ای میان اعضای تیم تالیف بخش شد که هر دیدگاه را دو نفر مستقل از هم بررسی کنند و درباره آن تصمیم بگیرند. اگر تصمیم آن دو عضو یکسان نمی‌بود، نفر سومی هم دیدگاه را بررسی می‌کرد و بر پایه رای اکثریت در میان این سه عضو درباره اعمال کردن یا نکردن دیدگاه دریافتی تصمیم گرفته می‌شد.
پس از بهبود پیش‌نویس بر پایه دیدگاه‌های دریافتی، نسخه نهایی آماده و در ۲۰۲۱ منتشر شد. بر پایه قواعد ANSI، مشابه این روند باید حداکثر تا پنج سال دیگر تکرار و ویرایش تازه‌ای از استاندارد منتشر گردد.
چند سال پیش مجموعه مقاله‌ای را از فیزیکدان نامدار، ریچارد فاینمن، مطالعه می‌کردم. در بخشی از مقاله مشکلی که در میان فیزیکدانان مشاهده کرده بود را به مفهومی به نام بارپرستی (Cargo Cult) تشبیه کرد. وقتی در حال مطالعه بودم، همه اندیشه‌ام این بود که این مشکل تا چه اندازه در پروژه‌ها جدیست.
شکل‌گیری مفهوم بارپرستی به جنگ‌های جهانی اول و دوم بازمی‌گردد. گروهی از مردمان بدوی که در گینه‌نو و برخی جزیره‌های دیگر در حوالی استرالیا می‌زیستند و با جهان بیرون ارتباط نداشتند ناگهان پدیده عجیبی مشاهده کردند: ارتش‌های ژاپن و آمریکا در برخی از این جزیره‌ها پایگاه‌های نظامی موقت راه‌اندازی کرده بودند. هر از چندی، هواپیماهای باری در جزیره فرود می‌آمدند. مشاهده ماشین‌های بزرگی که در هوا پرواز می‌کنند برای آن مردمان بدوی شگفت‌انگیز بود. افزون بر آن، سربازان گاهی بخشی از کالاهای رسیده که نیاز نداشتند را به بدویان هدیه می‌داند یا با آن‌ها دادوستد می‌کردند.
بدویان به کالاهای از هوا رسیده بسیار دلبسته شدند، ولی پس از چندی جنگ پایان گرفت و ارتش جزیره‌شان را ترک کرد. دیگر خبری از هواپیماهای باری و کالاهای چشمگیرشان نبود. بدویان که شیفته آن کالاها شده بودند کوشیدند به شکلی هواپیماهای باری را به جزیره بازگردانند. برای دستیابی به این آرزو، چیزی همانند باند پرواز ساختند و در کنارش برج‌های مراقبت چوبی و ماکت‌های چوبی هواپیما. هر از چندی مراسم ویژه‌ای داشتند و با مشعل دو سوی باند پرواز را نورانی می‌کردند و مانند سربازان در کنارش رژه می‌رفتند و گروهی دیگر در انتظار فرود آمدن هواپیمای باری در کنجی می‌نشستند.
آن بدویان گمان می‌کردند که بازسازی ظاهر آنچه دیده بودند برای دستیابی به نتیجه کافیست، با این‌که بی‌گمان این‌چنین نیست. اگر به آنچه در پروژه‌ها می‌گذرد ژرف بنگریم، مشاهده می‌کنیم که بسیاری از افراد تنها ظاهر آنچه در پروژه‌های موفق وجود دارد را بازسازی می‌کنند و انتظار دارند موفق باشند. چنین کسانی همان اندازه موفق هستند که آن بدویان بارپرست بودند.
برخی گمان می‌کنند که اگر چیزهایی همانند برنامه‌زمانی، انگیزه تجاری (business case) و منشور پروژه (project charter) داشته باشند مدیریت پروژه خوبی دارند و موفق خواهند شد. پروژه‌های چابک (Agile) در این زمینه مشکل‌های بزرگ‌تری هم دارند و بسیاری از کسانی که خود را «چابک‌کار» می‌دانند گمان می‌کنند داشتن انبوهی از برگه‌های رنگ‌ووارنگ روی تخته‌های بزرگ، استفاده از برچسب‌های رایج در اسکرام، و برگزاری مراسم ویژه روزانه برای چابک بودن بس است. (در ادامه کتاب مفهوم چابکی را بررسی خواهیم کرد.)
آنچه در همه این موارد، از بدویان گرفته تا چابک‌کاران ظاهری و مدیر پروژه‌های سطحی از قلم افتاده است، توجه به ماهیت راستین کارها و فرآیندهای پشت‌پرده است. اسناد و مراسم فقط ابزارهایی برای به جریان انداختن روند ویژه‌ای از کار هستند و نه هدف غایی در مدیریت پروژه.
توجه به اصل‌ها راه خوبی برای تمرکز بر مسایل واقعیست. ترجیح می‌دهیم که روند اندیشه‌مان را با اصل‌ها آغاز کنیم و بر پایه آن به‌تدریج فرآیند کار و سرانجام اسناد و مراسم را شکل دهیم تا گرفتار بارپرستی نشویم. از این روست که پم‌باک ۷ اصل محور شده است.
محتوای اصلی پم‌باک ۷ اصل‌های مدیریت پروژه و هدف آن، دست‌کم از دیدگاه من، جلوگیری از بارپرستی در پروژه‌هاست. این اصل‌ها را در ادامه این فصل بررسی می‌کنیم و پیش از پایان دادن به این فصل، چکیده‌ای از برخی مجموعه اصل‌های دیگر را هم بررسی می‌کنیم تا دید بازتری به این موضوع پیدا کنید.
پم‌باک ۱۲ اصل دارد. برخی از این اصل‌ها درباره مفاهیمی هستند که به‌سادگی قابل‌نام‌گذاری نیستند و از این رو شاید نام برخی از آن‌ها برایتان نامفهوم باشد. ولی نگران نباشید، چون همه آن‌ها را به‌تفصیل بررسی خواهیم کرد.
اصل‌های پم‌باک ازاین‌قرارند:
موردی که در این فهرست به چشم نمی‌خورد، اخلاق و رفتار حرفه‌ای است. دلیلش این است که اخلاق به‌موازات این موارد نیست، بلکه در سطحی بالاتر قرار می‌گیرد و بر همه این اصل‌ها اثر می‌گذارد. گذشته از این‌که اخلاق در چه جایگاهی قرار می‌گیرد، همیشه باید به آن توجه داشته باشید.
پیشنهاد می‌کنم درباره این موضوع آیین‌نامه اخلاق و رفتار حرفه‌ای PMI را مطالعه کنید: https://www.pmi.org/codeofethics
اگر از صدها نفر که در پروژه‌ها کار کرده‌اند بپرسید که چه تجربه‌ای در کار با مدیران پروژه‌ها دارند، دست‌کم برخی‌شان می‌توانند داستان‌های فراوانی بگویند از مدیران پروژه ناکارآمدی که هیچ درکی از کار ندارند و بااین‌همه در کارهای فنی دخالت می‌کنند و از افراد انتظارهای غیرواقعی دارند. به دلایلی، این چالش‌ها در پروژه‌های نرم‌افزاری حادتر بوده‌اند، تااندازه‌ای که برخی از روش‌های کمابیش نوین مدیریت پروژه‌های نرم‌افزاری با وجود نقش مدیر پروژه مخالفت می‌کنند.
از سوی دیگر، بیشتر افراد سازمان‌های بسیاری را می‌شناسند که خبره‌ترین متخصصان فنی خود را به‌عنوان مدیر پروژه انتخاب می‌کنند. برخی هم باور دارند که مدیر پروژه شدن، یا به‌طورکلی مدیر شدن، روند طبیعی رشد حرفه‌ای برای یک متخصص فنیست. متاسفانه در این روند سازمان‌ها متخصص‌های فنی خبره خود را از دست می‌دهند و به‌جایش مدیرانی ناکارآمد به دست می‌آورند.
هنگامی که متخصصی فنی تبدیل به مدیر می‌شود، ارتقای مقام پیدا نکرده، بلکه حرفه‌اش تغییر کرده است. خبرگی در مسایل فنی تضمینی برای خبره بودن در مسایل مدیریتی نیست، زیرا این دو نیاز به مهارت‌ها و شخصیت‌های کاملا متفاوتی دارند. علاقه واقعی برخی افراد به انجام کارهای فنیست و مدیر شدن، که گاهی ناچارند به دلیل فشارهای محیطی بپذیرند، کار را برایشان تلخ می‌کند. از سوی دیگر، چنین کسانی بیشتر اوقات نیز مدیران خوبی نمی‌شوند و به موفقیت پروژه‌ها آسیب می‌زنند.
رویکرد مناسب این است که افرادی که علاقه به کار فنی دارند در حرفه خود باقی بمانند و از راه‌های دیگری ارتقای مقام پیدا کنند. از سوی دیگر، هر سازمانی باید بر یافتن و پرورش مدیر سرمایه‌گذاری کند. وجود رشته‌های مدیریتی مناسب در دانشگاه‌ها نیز به دستابی به این هدف کمک می‌کند.
مدیر پروژه واقعی رئیس نیست! هر چه باشد، بیشتر سازمان‌ها کمبود رئیس ندارند. آنچه به‌عنوان مدیر پروژه نیاز داریم، کسانی هستند که بتوانند از تیم پروژه پشتیبانی کنند و با تسهیل‌گری و گره‌گشایی زمینه‌ای فراهم کنند که اعضای تیم پروژه بتوانند کارهای تخصصی خود را به بهترین شکل انجام دهند.
هر برچسبی بار معنایی ویژه خود را دارد که در طی سال‌ها بر پایه تجربه‌ها و رویدادهای فراوان شکل گرفته است. اگر گمان می‌کنید برچسب «مدیر پروژه» بار معنایی مناسبی در سازمانتان ندارد، می‌توانید به‌جای آن از برچسب دیگری استفاده کنید. پیشنهاد همیشگی من برای جانشینی این برچسب، «تسهیل‌گر ارشد پروژه» است. بهره‌مندی از چنین برچسبی دایما مفهوم واقعی مدیر پروژه را به او و دیگران یادآوری می‌کند. البته به یاد داشته باشید که این پیشنهاد من بیشتر برای شرکت‌های نرم‌افزاریست که تصویر ناپسندی از مدیر پروژه دارند، وگرنه مفهوم مدیر پروژه در سایر پروژه‌ها، به‌ویژه در ایران، بار معنایی منفی ندارد (دست‌کم تا جایی که من اطلاع دارم) و بنابراین نیازی به این راهکار نخواهند داشت.
اگر انتظارمان از مدیر پروژه پشتیبانی و تسهیل‌گری غیرفنی باشد، قاعدتا بسیاری از این افراد اطلاعات فنی کافی برای برنامه‌ریزی و کنترل پروژه یا تصمیم‌گیری‌های کلان فنی نخواهند داشت. از این رو، به‌جای این‌که شخصا چنین کارهایی را انجام دهند، باید از اعضای تیم پروژه کمک بگیرند. باید با مهارتی که در برنامه‌ریزی، تسهیل‌گری و سایر موارد مدیریتی دارند به این افراد کمک کنند تا خودشان پروژه را به شکل مناسب بسازند. منظور از مدیریت پروژه واقعی این است.
آیا به نظرتان مدیر پروژه باید اطلاعات فنی داشته باشد؟
سه پاسخ برای این پرسش ممکن است:
نخستین پاسخ رویکردی سنتیست که چه‌بسا در بسیاری از سازمان‌ها دیده باشید. این رویکرد محدود به ایران هم نیست و در همه کشورها وجود دارد.
رویکرد دوم کمابیش نوین و بااین‌همه کمی محافظه‌کارانه است. این رویکرد با آنچه تاکنون گفته شد هماهنگ است و می‌توان گفت که PMI هم چنین دیدگاهی دارد.
سومین پاسخ رویکردی کاملا پیشروست که درکش برای بسیاری از افراد چالش‌برانگیز است. گروهی، ازجمله من، از آن طرفداری می‌کنند.
فرض کنید مدیر پروژه‌ای هستید که در جنبه‌های فنی‌اش نیز تخصص دارید. اگر ببینید که کاری که تیم پروژه انجام داده است از نظر فنی ایده‌آل نیست چه می‌کنید؟ آیا می‌توانید جلوی خود را بگیرید و وارد مسایل فنی نشوید؟ بیشتر افراد نمی‌توانند و بیشتر و بیشتر درگیر کارهای فنی پروژه می‌شوند. در پایان، مسئله چنان گسترده می‌شود که در عمل آن فرد نقش یک متخصص ارشد را بازی می‌کند و سمت مدیر پروژه به حال خود رها می‌شود. وقتی از این زاویه به مسئله نگاه کنیم روشن می‌شود که بهتر است آن فرد را وادار به پذیرفتن سمت مدیریتی نکنیم تا کاری که برایش جذاب‌تر است را انجام دهد (نکته‌ای که پیشتر مطرح شد) و فردی قابل برای هماهنگی‌ها و تسهیل‌گری‌های پروژه انتخاب کرده، به سمت مدیر پروژه منصوب کنیم.
اگر مدیر پروژه در مسایل فنی پروژه خبره نباشد، چالشی که گفته شد به وجود نخواهد آمد و آن فرد به‌سادگی می‌تواند بر جنبه‌های مدیریتی تمرکز کند. از این روست که برخی رویکرد سوم را ترجیح می‌دهند.
اگر استدلال بخش پیشین برایتان پذیرفتنی باشد، باز هم دو چالش کلان در عمل وجود خواهد داشت. نخستین چالش این است که بسیاری از کسانی که در پروژه‌ها کار می‌کنند مدیر پروژه‌ای که مهارت فنی نداشته باشد را نمی‌پذیرند. اگر چنین مدیر پروژه‌ای باشید، باید در نظر داشته باشید که ریشه دشواری این است که این افراد چه‌بسا هیچ‌گاه مدیر پروژه واقعی ندیده‌اند. همه مدیر پروژه‌هایی که داشته‌اند متخصص‌های ارشدی بوده‌اند که تصمیم‌گیری‌های کلان فنی بر دوششان بوده است و به‌جای کل تیم برنامه‌ریزی می‌کرده‌اند. قاعدتا برای انجام چنین کاری باید مهارت فنی داشت و از این روست که گمان می‌کنند فردی غیرفنی نمی‌تواند پروژه‌شان را مدیریت کند.
راهکار این است که از آغاز با شفافیت مسئله را برایشان روشن کنید. توضیح دهید که قرار نیست برایشان تصمیم‌گیری‌های فنی انجام دهید، بلکه نقشتان پشتیبانی از تیم پروژه و فراهم کردن فضای کاری مناسب است. بی‌گمان سخن گفتن در این باره کافی نیست و نیاز است که هر چه زودتر آن را در عمل به تیم نشان دهید تا بتوانید اعتمادشان را جلب کنید. اگر این کار را به‌درستی انجام دهید، پس از چند هفته تا چند ماه پذیرفته خواهید شد.
زمانی یکی از بهترین مدیر پروژه‌هایی که می‌شناختم برای مدیریت پروژه‌ای نرم‌افزاری انتخاب شد و اعضای تیم کاملا در برابرش جبهه‌گیری کرده بودند زیرا او همیشه در پروژه‌های سازمانی کار کرده بود. در آغاز کار آنچه در بالا گفته شد را به اعضای تیم توضیح دادم و از همگی خواهش کردم که به او فرصتی دهند که پروژه را مدیریت کند و بدون پیش‌داوری برخورد کنند. هنگامی که پس از دو هفته به پروژه برگشتم و از افراد جویای حال شدم، همگی ابراز خرسندی کردند و گفتند که گمان نمی‌کردند که کار کردن در پروژه بتواند تا این اندازه ساده و خوش‌آیند باشد! یکی از اعضای تیم گفت که نگران است چگونه پس از پایان این پروژه به وضعیت رایج برگردد و بدون کمک چنین مدیر پروژه‌ای کار کند.
در بخش پیش نخستین چالش کلان که پذیرش تیم بود را بررسی کردیم. چالش دیگری هم وجود دارد: شاید فردی فنی باشید که به دلیل علاقه به مدیریت پروژه چنین سمتی را پذیرفته است. با توجه به ریسک‌هایی که مدیریت پروژه برای افراد فنی دارد و پیش‌ازاین بررسی‌اش کردیم، چه باید بکنید؟
در چنین حالتی باید کاملا درباره دوگانگی مسایل فنی و مدیریتی خودآگاه باشید. هر زمان که قرار است سخنی بگویید، کاری انجام دهید، یا تصمیمی بگیرید، از خود بپرسید که موضوع فنیست یا مدیریتی، و اگر مدیریتی نبود، آن را بر دوش فرد مسئولش بگذارید. این مسئله با تمرین درونی می‌شود و پس از مدتی ناخودآگاه درست عمل خواهید کرد.
یکی از مدیر پروژه‌های خبره‌ای که می‌شناختم معمار بود. در یکی از پروژه‌ها که جنبه‌های معمارانه حساسی داشت مدیر پروژه بود. در یکی از جلسه‌ها، دو شرکت مشاور مسئول در پروژه درگیر بحثی طولانی درباره یکی از جنبه‌های معماری پروژه شده بودند. بهیکباره یکی از افراد جلسه از مدیر پروژه پرسید «آقای دکتر، دیدگاه شما چیست؟ هرچه باشد شما هم معمار هستید!» و او در پاسخ گفت «من اینجا به‌عنوان مدیر پروژه در کنار شما هستم و نه به‌عنوان معمار. در نقش مدیر پروژه می‌توانم به شما بگویم که بهتر است در این باره جلسه جداگانه‌ای برگزار کنید و با سنجش همه موارد به رای نهایی برسید. نکات مثبت و منفی تصمیم را هم مکتوب کرده، برایم بفرستید. اگر نتوانستید به توافق برسید، تصمیم‌گیری بر دوش …… خواهد بود، زیرا این شرکت مسئولیت طراحی پایه پروژه را دارد و این مسئله بیشتر به طراحی پایه مربوط می‌شود. لطفا این مسئله را تا پایان هفته به نتیجه برسانید، وگرنه باعث تاخیر پروژه خواهد شد.»
اگر فردی فنی هستید و سمت مدیریت پروژه را می‌پذیرید، باید به اندازه این فرد بر خود تسلط داشته باشید.
من زمانی مدیر پروژه‌ای با هدف استقرار سیستم مدیریت پروژه در یک سازمان بودم. کار من مدیریت پروژه و جنبه فنی پروژه هم مدیریت پروژه بود. با سایر افراد تیم در این باره گفتگو کردم که اگر قرار باشد درباره سیستم مدیریت پروژه‌ای که مستقر می‌کنند دخالت کنم، مانند هر دخالت فنی دیگری، چه‌بسا از مدیریت خود پروژه غافل خواهم شد. همگی در این باره توافق کردیم. بااین‌همه، شاید بتوانید حدس بزنید که جدا کردن این دو مورد به دلیل همگن بودنشان چه‌اندازه سخت بود. قدر پروژه‌های معمول که جنبه فنی‌شان گونه دیگری دارد را بدانید.
هنگامی که همه جنبه‌های فنی بر دوش متخصصان فنی پروژه گذاشته شود، چه کاری برای مدیر پروژه باقی می‌ماند؟ هماهنگی، حل اختلاف، مذاکره و تسهیل‌گری برخی از موارد نسبتا بدیهی هستند، ولی مسئولیت مدیر پروژه به این موارد محدود نمی‌شود.
یکی دیگر از مسئولیت‌های مدیر پروژه این است که فضای مناسبی برای رشد حرفه‌ای اعضای تیم فراهم کند. بله، مدیر پروژه در این باره مسئول است. این یکی از جنبه‌های اخلاق و رفتار حرفه‌ایست. برای اطلاعات بیشتر می‌توانید به این منابع مراجعه کنید:
خلاصه این‌که از اعضای تیم پروژه و منابعی که در اختیار پروژه گذاشته شده است مراقبت کنید. امانت‌دار و قابل‌اعتماد باشید و الزامات و قوانین را تا جایی که خلاف اخلاق نباشند پاس دارید.
نکته پایانی این است که برای انجام همه این موارد باید شنونده خوبی باشید. برای پاسخ دادن گوش نکنید، بلکه برای فهمیدن گوش کنید. منتظر نمانید که برای گفتگو به شما رجوع کنند، بلکه برایش پیش‌قدم شوید تا هر دشواری یا کمبودی را در زودترین زمان و پیش از آن‌که پیچیده‌تر شود حل کنید.
آنچه باعث موفقیت پروژه می‌شود افراد توانمند نیستند، بلکه تیمی توانمند است.
چگونه می‌توان تیمی توانمند و کارآمد ساخت؟
به فعالیت‌هایی که وضعیت تیم را بهبود می‌دهند «تیم‌سازی» (team building) گفته می‌شود. برخی سازمان‌ها فعالیت‌هایی ویژه این کار ترتیب می‌دهند. این فعالیت‌ها معمولا با کمک مربی‌هایی انجام می‌شود که در تیم‌سازی خبره هستند. برای نمونه، همه افراد تیم به یک بازی دست جمعی یا برنامه‌ای آموزشی مانند آشپزی دعوت می‌شوند و تیم‌سازی در خلال این کار انجام شود.
بهتر است به‌جای فعالیت‌های مختص تیم‌سازی تا حد امکان آن را با فعالیت‌های معمول پروژه ترکیب کنید تا کارآمدتر شود. هرگاه درگیر ترتیب دادن فعالیتی هستید، از خود بپرسید که چگونه می‌توانید از آن فعالیت برای تیم‌سازی نیز کمک بگیرید.
برای نمونه، فرض کنید درگیر برنامه‌ریزی عنصری در پروژه هستید. می‌توانید برای این کار با پنج عضو تیم جداگانه ملاقات کنید، اطلاعات لازم را گردآوری کرده، برنامه را بر آن پایه آماده کنید. گزینه دیگر این است که کارگاهی تسهیل‌شده ترتیب دهید و آن پنج نفر را دعوت کنید تا با هم همفکری کرده، برنامه را آماده کنند. گزینه دوم، هنگامی‌که به خوبی انجام شود، فرصت خوبی برای تقویت کار گروهی، بهبود روابط میان افراد، و حرکت به سوی شکل‌دهی تیمی توانمند است.
امتیاز اصلی ترکیب تیم‌سازی با فعالیت‌های معمول این است که آهسته و پیوسته انجام می‌شود.
در متدولوژی P3.express چرخه‌هایی ماهانه برای کار پروژه وجود دارد. هر چرخه شماری فعالیت پایانی دارد و یکی از این فعالیت‌ها ارزیابی رضایت ذی‌نفعان است. برای این کار رضایت ذی‌نفعان درونی (اعضای تیم) و بیرونی پروژه با نظرسنجی‌های بی‌نام ارزیابی می‌شوند. پس‌ازآن، فعالیت دیگری وجود دارد تا با کمک این اطلاعات برنامه‌ای برای بهبود پروژه در چرخه بعد طراحی شود.
پیشنهاد P3.express این است که برای ساخت برنامه بهبود اعضای تیم را گرد هم آورید، اطلاعات را در اختیارشان بگذارید و با تسهیل‌گری با روش‌هایی مانند دلفی (Delphi technique) از ایشان درخواست کنید که برنامه‌های بهبود را طراحی کنند.
چنین کاری امتیازهای فراوانی دارد، ازجمله:
بسته به شرایط، شاید کارهای دیگری هم برای بهبود وضعیت تیم نیاز باشد. برای نمونه، وقتی تیم زیاد از حد کوچک نباشد بهتر است که انتظارهایی که از هرکس می‌رود و انتظارهایی که آن فرد از دیگران می‌تواند داشته باشد مشخص و شفاف باشد. به عبارت دیگر، باید نقشها و مسئولیت‌ها را به‌خوبی تعریف کنید. این نکته یکی از اصل‌های متدولوژی مدیریت پروژه پرینس۲ (PRINCE2) نیز هست.
افزون بر نقش و مسئولیت‌ها، شاید نیاز باشد که فرآیندهای کارهای رایج پروژه را نیز تدوین کنید. برای نمونه: «هر سندی که طراحی می‌شود باید برای بررسی نخستین به …… فرستاده شود، این بررسی باید در …… روز کامل شده و پس از آن…»
نکته دیگری که شاید نیاز باشد تدوین قواعد رفتاری (ground rules) است . برای نمونه، «با صدای بلند پشت تلفن صحبت نکنید.»
شاید به این بیندیشید که تدوین و ابلاغ چنین قواعدی تحکمی و برخلاف آنچه در اصل پیش بررسی کردیم است. وضعیت اینگونه خواهد بود اگر این موارد را به تنهایی یا همراه با عده‌ای انگشت‌شمار آماده کرده، به همگی حکم کنید. راه مناسب این است که با تسهیل‌گری مناسب از خود اعضای تیم درخواست کنید که چنین مواردی را برای خودشان تدوین کنند. اینگونه، هم قواعد واقع‌بینانه‌تر و کاراتر خواهند بود و هم امکان موفقیت بیشتری خواهند داشت چون به افراد تحمیل نشده‌اند. برای نمونه، آیین‌نامه اخلاق P3.express به کمک همگان ساخته شده است و نه گروهی انگشت‌شمار.
برخی واژه «ذی‌نفع» (stakeholder) را برابر «کارفرما» می‌دانند، با این‌که در ادبیات مدیریت پروژه به هر فرد یا مجموعه‌ای که با پروژه سر و کار داشته باشد و بتواند بر آن اثر بگذارد «ذی‌نفع» گفته می‌شود. اعضای تیم، کارفرما، پیمانکاران، فروشندگان مصالح و تجهیزات، رقبا، و قانون‌گذاران نمونه‌هایی از ذی‌نفعان پروژه هستند.
زمانی با سازمانی همکاری می‌کردم که در کنار پروژه‌های خودش از برخی پروژه‌های غیرانتفاعی هم پشتیبانی مالی می‌کرد. یکی از این پروژه‌ها ساخت پناهگاهی کوهستانی بود. هر از چندی نماینده‌ای از آن پروژه به دفتر ما می‌آمد، گزارشی از کارهای انجام شده و پیش رو و برآوردی از بودجه لازم برای دوره بعد ارائه می‌کرد. زمانی متوجه شدم که مدت زیادی می‌گذرد و خبری از نمایندگان آن پروژه نیست. هنگامی که با آن‌ها تماس گرفتیم، باخبر شدیم که سازمان میراث فرهنگی پروژه را متوقف کرده است، زیرا پناهگاه بر روی جاده‌ای باستانی قرار گرفته بود. متاسفانه هزینه فراوانی که صرف ساخت بخشی از پناهگاه شده بود از دست رفته (هزینه ساخت در کوهستان بسیار زیاد است) و جاده‌ای باستانی هم آسیب دیده بود.
جاده باستانی را به‌سختی می‌شد تشخیص داد و تفاوت چندانی با پاکوبه‌هایی که به‌تدریج با رفت و آمد کوهنوردان به وجود می‌آمد نداشت. با این‌همه، همان اثر جزئی از جاده هم بازتاب تاریخی طولانی بود و میراثی فرهنگی که نیاز به حفاظت داشت.
چگونه می‌شد از بروز چنین چالشی در پروژه جلوگیری کرد؟
پیش از اجرای چنین پروژه‌ای، می‌توان مدتی به محل رفت و با کوهنوردان خبره‌ای که در آنجا رفت و آمد می‌کنند گفتگو کرد و دیدگاهشان را جویا شد. بی‌گمان برخی از کوهنوردان از جاده اطلاع داشتند و می‌توانستند در آن باره اطلاع‌رسانی کنند. افزون بر آن، شاید بتوان اطلاعات مفید دیگری هم برای ساخت پناهگاه از چنین کسانی گرفت. می‌شد پیش از آغاز کار تابلویی هم در محل نصب کرد، برنامه ساخت پناهگاه را اطلاع داد و از همگان درخواست کرد که پیشنهادهایشان را بفرستند.
چنین اقدام‌هایی آغاز پروژه را به تاخیر می‌اندازند، ولی جلوی بروز بسیاری از چالش‌ها را می‌گیرند. توجه کردن به چنین مسایلی مدیر پروژه‌های برجسته را از مدیر پروژه‌های معمولی متمایز می‌کند.
به یاد داشته باشید که هدف آغاز زودتر پروژه نیست، بلکه زودتر به پایان رساندن کار با کیفیت و هزینه مناسب است.
همیشه باید زمان و توان بایسته صرف شناسایی و مشارکت دادن ذی‌نفعان پروژه کنیم. گام نخست، یعنی شناسایی ذی‌نفعان، کار ساده‌ای نیست و باید برایش از اعضای تیم کمک بگیرید. همانگونه که در اصل پیش بررسی کردیم، این کار را به شکلی انجام دهید که کارکرد تیم‌سازی هم داشته باشد.
باید با ذی‌نفعان شناسایی‌شده به شکل‌های مختلف ارتباط برقرار کرد. نوع مناسب ارتباط بستگی به نوع ذی‌نفع دارد. گاهی ارتباط رسمی مناسب‌تر است و گاهی غیررسمی. گاهی ارتباط باید با جزئیات فراوان باشد و گاهی کلان. گاهی باید جنبه‌های پیچیده فنی را در ارتباط وارد کنید و گاهی باید از آن خودداری کنید.
یکی از راه‌های ارتباط که برای بسیاری از ذی‌نفعان کاربرد دارد، فرستادن گزارش است. به یاد داشته باشید که گوناگونی افراد بیش از آن است که یک نوع گزارش برای همه آن‌ها مناسب باشد و درنتیجه بهتر است بیشتر از یک نوع گزارش طراحی کنید.
فردی آغاز به ساخت و پیش‌فروش مجموعه آپارتمانی بزرگ و کمابیش کم‌هزینه‌ای کرده بود. پس از فراری شدن سازنده مشخص شد که حدود ۵۰۰ آپارتمانی که در حال ساخت بود (اگر شمارشان را درست به یاد بیاورم) به هزاران نفر پیش‌فروش شده بود! خریدارانی که بیشتر اندوخته مالی خود را در اختیار این کلاه‌بردار قرار داده بودند بسیار آزرده و خشمگین بودند و به‌تدریج درگیر تحصن و اعتراض شدند. قوه قضائیه برآن شد که پادرمیانی کند. برنامه این بود که بودجه لازم فراهم شود و به شمار پیش‌فروش شده آپارتمان‌هایی ساخته شده، در اختیار خریداران قرار بگیرد. برای این کار مناقصه‌ای عمومی برگزار شد و پیمانکاران خصوصی رتبه بالا به آن دعوت شدند.
یکی از شرکت‌های همکارم برنده مناقصه شد. از آغاز، نگرانی اصلی من مدیریت هزاران ذی‌نفع زخم‌خورده و خشمگین پروژه بود! برنامه‌ای که در نظر گرفتیم این بود که سایتی اینترنتی ساخته شود که خریداران هر زمان که مایل بودند بتوانند وضعیت پیشرفت آپارتمان خود را در آن ببینند. افزون بر آن، قرار شد اتاقکی در ورودی پروژه ساخته شود، همراه با فردی که مسئول پاسخگویی به تماس‌های تلفنی و مراجعه‌کننده‌های حضوری باشد. همچنین، برنامه‌ریزی کردیم که ماهی یک‌بار امکان بازدید از پروژه نیز برای همگان فراهم باشد.
این موارد از این رو لحاظ شدند که همیشه این ریسک وجود داشت که با وجودی که پیمانکار شرکتی معتبر بود و در این پروژه زیرنظر قوه قضائیه کار می‌کرد، خریداران خشم خود را معطوف به او کنند یا حتی او را هم به کلاه‌برداری متهم کنند.
به یاد داشته باشید که خوب کار کردن کافی نیست و باید به ذی‌نفعان نشان دهید که خوب کار می‌کنید.
بر پایه اصل‌های NUPP، باید برای هر کاری که انجام می‌دهیم هدفی داشته باشیم. هدف از مشارکت دادن ذی‌نفعان چیست؟
مشارکت دادن ذی‌نفعان چندین هدف دارد:
برخی ذی‌نفعان از آغاز جبهه‌گیری مثبتی نسبت به پروژه دارند، ولی بازهم باید از آن‌ها مراقبت کرد که همچنان مثبت باقی بمانند. برخی دیگر جبهه‌گیری منفی دارند و شاید بتوانیم با اقدام‌های سنجیده تغییرشان دهیم.
زمانی مسئول پیاده‌سازی سیستم مدیریت پرتفولیو در سازمانی بزرگ بودم. در میانه کار باخبر شدم که یکی از مدیران ارشد با کارمان موافق نیست و با آن دشمنی می‌کند. درباره‌اش پرس و جو کردم و به من توضیح دادند که او همیشه فردی منفی‌نگر است و با بیشتر کارها مخالفت می‌کند. از سوی دیگر، برخلاف بسیاری از مدیران و کارکنان دیگر که پس‌زمینه فنی یا کسب و کار داشتند، پس‌زمینه‌ای سیاسی داشت و پس از سال‌ها کار در پارلمان اروپا جذب این سازمان شده بود که در تصمیم‌گیری‌های بین‌المللی و سیاسی کمک کند. به دلیل پس‌زمینه‌اش، از سایر افراد شرکت جدا افتاده بود.
با این‌که دیدگاه همگی این بود که نباید به دشمنی‌اش اهمیت داد، با او تماس گرفتم و درخواست جلسه کردم. در آغاز جلسه به او گفتم که ما در حال گردآوری فهرستی از مواردی هستیم که می‌توانند به موفقیت پروژه آسیب بزنند و این‌که اگر می‌تواند موارد بیشتری در اختیارمان بگذارد. در طول جلسه به‌دقت به گفته‌هایش گوش کردم و یادداشت برداشتم و بااینکه برخی از ریسک‌هایی که مطرح می‌کرد پاسخ‌هایی داشتند، هیچ چیز نگفتم. فقط گاهی برای برخی موارد درخواست توضیح بیشتر می‌کردم. در پایان سپاسگزاری و جلسه را ترک کردم. در این جلسه توانستم دو ریسک تازه به کمک او پیدا کنم که خود نتیجه‌ای با ارزش بود، ولی هدف اصلی من بهبود روابط بود.
هفته بعد درخواست جلسه دیگری کردم. در جلسه توضیح دادم که به همراه تیم واکنش‌هایی برای ریسک‌های فهرست شده تعریف کرده‌ایم، ولی مطمئن نیستم که کارایی درخور داشته باشند. گفتم که اگر امکان‌پذیر باشد واکنش‌های ریسک را همراه هم مرور کنیم و نظرش را درباره آن‌ها بگوید. این بار وضعیت گفتگو وارونه شد و تمرکزش معطوف ارائه انواع راهکار برای ریسک‌ها شد.
این روند به شکل‌های مختلف ادامه پیدا کرد و او پس از یک ماه تبدیل به یکی از بزرگ‌ترین پشتیبانان پروژه شد. با پشتیبانی‌هایش منابع فراوانی در اختیار پروژه قرار گرفت و کمک بزرگی به پیروزی پروژه کرد. افزون بر آن، این موفقیت از سوی او به گوش برخی از اعضای پارلمان اروپا هم رسید و فرصت‌های بیشتری برای پروژه‌های مشابه فراهم کرد.
باید دایما با ذی‌نفعان در ارتباط بود. منتظر نمانید که به شما مراجعه کنند، چون آن زمان شاید دیر باشد و هر چه زودتر انتظارها و مشکل‌ها را کشف کنید آسان‌تر می‌توانید در پروژه لحاظشان کنید. یک راهکار که در متدولوژی P3.express به‌کار گرفته می‌شود ارزیابی ماهانه رضایت ذی‌نفعان است. این ارزیابی سرنخ‌های فراوانی برای یافتن مشکل‌ها در اختیارتان می‌گذارد.
راهکار دیگری که در P3.express وجود دارد ارتباط متمرکز است. این فعالیت در پایان هرکدام از گروه‌های فعالیتی اجرا می‌شود و در هر زمان پیام ویژه‌ای را برای مخاطبان از پیش‌تعیین شده می‌فرستد. اطلاعاتی که اینگونه مکاتبه می‌شود از بروز بسیاری مشکل‌ها جلوگیری می‌کند.
وقتی افراد قدرت تصمیم‌گیری داشته باشند بیشتر مشارکت و همکاری می‌کنند. از این رو، نیاز است که سیستم تفویض اختیار مناسبی در پروژه داشت. متدولوژی پرینس۲ ساختار جالب و مناسبی برای این منظور دارد: چندین سطح تصمیم‌گیری در پروژه وجود دارد و هر سطح اختیار تصمیم‌گیری ویژه خود را دارد. برای این منظور حدی از اثر تصمیم بر زمان، هزینه، کیفیت، ریسک و منافع برای هر سطح در نظر گرفته می‌شود. اگر اثر از حد تعیین شده پایین‌تر باشد، افراد سطح بالاتر نباید در تصمیم‌گیری دخالت کنند، و اگر اثر بزرگتر باشد، باید تصمیم را به سطح بالاتر فرستاد.
در یکی از پروژه‌ها پیچیدگی‌های ویژه‌ای در سازه بتنی وجود داشت. برای به پایان رساندن بهنگام پروژه نیاز بود که بتن‌ریزی‌ها بسیار بهینه انجام شوند. یک‌بار که برای بازدید به پروژه رفته بودم دیدم که همه قالب‌های بتن بسته شده، آماده بتن‌ریزی‌اند. در آن پروژه انتظار داشتیم که بتن‌ریزی بی‌درنگ انجام شود تا قالب‌ها در زودترین زمان ممکن آزاد شده، در ناحیه بعدی به‌کار گرفته شوند. با این حال، اثری از بتن‌ریزی نبود. وقتی پرسیدم، به من گفتند که قالب‌ها سه روز پیش بسته شده‌اند، ولی نمی‌توانند بتن‌ریزی کنند چون نیاز به مصالح تکمیلی ساده‌ای دارند که فعلا در کارگاه موجود نیست.
مدیر پروژه، که در کارگاه مستقر بود، اختیار خرید مصالح نداشت و باید درخواست را به دفتر مرکزی می‌فرستاد و در این باره هم درخواست دیر فرستاده شده بود و هم دفتر مرکزی تاخیر داشت. وقتی درباره قیمت آن مصالح پرسیدم، متوجه شدم که بسیار ارزان است؛ معادل قیمت ده پیتزا برای بتن‌ریزی آن محدوده (به دلیل تغییر شدید ارزش ریال، از «پیتزا» به عنوان واحد مالی استفاده خواهم کرد!) بااینکه هزینه هر روز تاخیر در پروژه حدود هزار پیتزا بود. از جیبم پولی معادل بیست پیتزا درآوردم و به مدیر پروژه دادم که کسی را برای خرید آن مصالح به شهر بفرستد. به من گفت «ولی شاید شرکت پولت را پس ندهد» و پاسخ من این بود که «اگر شرکت آنقدر بی‌منطق باشد، ترجیح می‌دهم همکاری‌ام را با آن متوقف کنم.»
اگر مدیر پروژه یا هر فرد دیگری به‌اندازه اختیار نداشته باشد، کارها به خوبی پیش نخواهند رفت.
فرض کنید درگیر اجرای پروژه‌ای هستید که حتما باید در تاریخ خاصی پایان یابد تا در مراسمی مانند مسابقه ورزشی به‌کار رود. در تازه‌ترین ارزیابی پیشرفت متوجه می‌شوید که پروژه دو ماه تاخیر خواهد داشت. پس از بررسی همه جوانب، به دو راهکار می‌رسید:
کدام راه را انتخاب می‌کنید؟
با اطلاعات موجود نمی‌توان پاسخ مناسبی به این پرسش داد زیرا نمی‌دانیم که هدف از اجرای پروژه چیست. اگر هدف افزایش اعتبار شرکت و ورود به بازاری تازه باشد، شاید باید گزینه دوم را انتخاب کرد زیرا دیگری نقض غرض است. از سوی دیگر، اگر پروژه فقط با هدف مالی انجام می‌شود، شاید گزینه نخست مناسب‌تر باشد.
پیش از اجرای هر پروژه‌ای باید چرایی انجام آن را به‌خوبی درک کرد زیرا هرآنچه در پروژه انجام می‌شود باید با آن همسو باشد و تصمیم‌های کلان بر آن پایه گرفته شوند. این درک محدود به مدیر پروژه نیست و همه اعضای تیم به آن نیاز دارند.
چندی پس از آغاز پروژه ناسا برای فرستادن اولین فضانورد به ماه، رییس جمهور وقت آمریکا، کندی، از ناسا بازدید کرد. در هنگام بازدید، یکی از مستخدم‌های ناسا را جارو به دست دید و مانند هر رییس جمهور دیگری که همیشه کوشش می‌کند خود را مردمی جلوه دهد، با او سلام و احوال‌پرسی کرد. از مستخدم پرسید که کارش چیست و او در پاسخ گفت «کمک می‌کنم که فضانورد به ماه بفرستیم!»
اگر بتوانید بستری در پروژه به وجود آورید که همه برخوردی همانند آن مستخدم داشته باشند، احتمال موفقیتتان به‌مراتب بالاتر خواهد بود.
همه راهنماها و متدولوژی‌های مدیریت پروژه بر اهمیت درک چرایی پروژه‌ها پافشاری می‌کنند، ولی آن را به شکل یکسانی در سیستم خود بازتاب نمی‌دهند. راه متداول این است که بر توجیه‌پذیری پروژه تمرکز کنیم که یکی از اصل‌های پرینس۲ هم هست. توجیه‌پذیری پروژه معمولا در سندی با نام انگیزه تجاری (business case) ثبت می‌شود. این سند باید دایما بر پایه تازه‌ترین پیش‌بینی‌های زمان و هزینه و دیگر متغیرهای پروژه بازبینی و سپس برای مدیران ارشد فرستاده شود تا درباره توجیه‌پذیری پروژه تصمیم بگیرند.
نسخه هفتم پم‌باک به جای «توجیه‌پذیری» بر ارزش یا به عبارت دیگر ارزش‌آفرینی متمرکز است و توجیه‌پذیری را مقوله‌ای زیرمجموعه آن می‌داند.
ارزش تعریفی یکه ندارد، ولی بهترین تعریف برای آن که با منابع تخصصی نیز سازگار است، نسبت منافع به هزینه است. برای نمونه:
در این حالت ارزش پروژه دوم دو برابر پروژه نخست است و می‌توان گفت که پروژه دوم باارزش‌تر است.
توجه داشته باشید که در گفتار روزمره بسیاری از افراد، «ارزش» برابر «منفعت» است. متاسفانه حتی در برخی از منابع مربوط به پروژه، به‌ویژه منابع چابک، ارزش به هر دو معنی به کار می‌رود و باعث سردرگمی فراوان می‌شود. در این کتاب ارزش به معنی نسبت منافع به هزینه‌ها به کار می‌رود.
منظور از ارزش، نسبت منافع به هزینه است. هزینه مقوله کمابیش سرراستی است، ولی مفهوم منفعت را باید بیشتر بررسی کرد.
پولی که برای کاری دریافت می‌کنید نمونه‌ای از منفعت است، ولی منفعت به این مورد ساده محدود نمی‌شود. برخی پروژه‌ها منفعت‌هایی مانند نجات دادن جان افراد، بهبود وضعیت زندگی، و کمک به محیط زیست دارند. همه این موارد، یا دست‌کم شکل کمی شده آن‌ها، منفعت به شمار می‌رود. اگر اعتبار شرکتتان با انجام پروژه بهبود پیدا کند، آن هم نوعی منفعت است، یا دست‌کم نتیجه‌ای که می‌تواند منجر به منفعت شود.
هر سازمان مجموعه‌ای از معیارهای ارزش (value drivers) دارد. این معیارها در سازمان‌های متفاوت یکسان نیستند. برای نمونه، بهبود وضعیت زندگی را در نظر بگیرید:
به عبارت دیگر، ارزش و منفعت عینی نیستند.
از آنجایی که ارزش عینی نیست و برای هرکس متفاوت است، برای ارزیابی ارزش پروژه باید دیدی همه‌جانبه داشت و آن را در بستر کلی سازمان سنجید و نه تنها درون پروژه.
ارزش هر پروژه‌ای، گذشته از مشخصات خود پروژه، بستگی به دیگر پروژه‌ها و عملیات سازمان نیز دارد، هم موارد کنونی و هم مواردی که شاید در آینده به وجود آیند. گاهی سیاست‌های کشور و مسایل جهانی هم بر ارزش پروژه اثر می‌گذارند. شاید برای پروژه‌تان در آغاز ارزشی پیشبینی کنید، ولی کمی بعد با افزوده شدن پروژه‌ای تازه برهمکنشی رخ دهد که ارزش پروژه پیشین نیز بیشتر شود.
سال‌های آغازینی که ترجمه و تالیف می‌کردم با دو ناشر بسیار خوب کار می‌کردم. از روند کار خرسند بودم، ولی محدودیت‌های طبیعی نشر سنتی، از جمله این‌که دسترسی به کتاب‌ها در برخی شهرها دشوار بود، باعث شد که کم‌کم به فکر نشر الکترونیکی کتاب‌هایم بیفتم. این گزینه به نظر خیلی‌ها ترسناک بود، ولی در عمل نتیجه بسیار خوبی داشت و منافع برآمده از نشر الکترونیکی برایم حدود ۲۰ برابر بیشتر از نشر سنتی شد. سال‌ها ماجرا اینگونه پیش رفت تا این‌که ارزش فرصت و معیارهای ارزشم به‌گونه‌ای تغییر کرد که درآمدزایی از نشر کتاب دیگر گزینه توجیه‌پذیری برایم نیست و از این رو اکنون کتاب‌ها را آزاد و رایگان منتشر می‌کنم.
از همه این مسایل که بگذریم، هدفم ارائه نمونه‌ای جالب از برهمکنش‌ها بود: به ازای هر کتاب تازه‌ای که منتشر می‌کردم فروش دیگر کتاب‌ها از ۵ تا ۱۵ درصد افزایش پیدا می‌کرد! یکی از کتاب‌ها را در نظر بگیرید و تصور کنید پروژه بزرگیست که صدها نفر در آن فعالیت می‌کنند. آیا می‌توانیم ارزش این پروژه را تنها درون مرزهای پروژه ارزیابی و درک کنیم یا نیاز است دیدی کلان و همه‌جانبه در سطح سازمان داشته باشیم؟
فرض کنید منبع‌هایی که دارید تنها برای انجام یکی از دو پروژه زیر بسنده می‌کند:
کدام پروژه را انتخاب می‌کنید؟
اگر پیش از این تنها روی پروژه‌های بلندمدت سرمایه‌گذاری کرده باشید نیاز به درآمد کوتاه‌مدت خواهید داشت و از این رو شاید گزینه نخست بهتر باشد. اگر شرکت دچار چالش مالی و در شرف ورشکستگی باشد، بی‌گمان گزینه نخست بهتر خواهد بود. اگر چالشی در درآمدهای کوتاه‌مدت وجود نداشته باشد، شاید گزینه دوم را ترجیح دهید.
این نمونه دیگری از مواردیست که ارزیابی ارزش پروژه بستگی به وضعیت کلان سازمان پیدا می‌کند و بنابراین نیاز است که ارزیابی در آن سطح انجام شود.
کسانی که در چنین تصمیم‌گیری‌هایی مشارکت می‌کنند هم باید با دقت انتخاب شوند. مشکلی رایج در برخی سازمان‌های بزرگ این است که فردی مشهور را به طور کوتاه‌مدت به‌عنوان مدیرعامل انتخاب می‌کنند. او که می‌داند بیش از چند سال مدیرعامل نخواهد بود، تنها هدفش ایجاد سابقه بهتر برای خودش خواهد بود و درنتیجه به جای این‌که ترکیبی از بهترین پروژه‌ها را انتخاب کند، فقط روی پروژه‌هایی با بازگشت کوتاه‌مدت تمرکز می‌کند. برخی از آن‌ها حتی آینده بلندمدت سازمان را فدای درخشش بیشتر کوتاه‌مدت می‌کنند. پس از چندی، ارزیابی‌های ناشیانه نشان می‌دهند که در زمان مدیریت آن فرد منافع سازمان چندین برابر شده بود و پس از این‌که سازمان را ترک کرد همه‌چیز افت کرد و از این مسئله نتیجه می‌گیرند که مدیریت وی بسیار خوب بوده است، در حالی که این‌چنین نیست.
دلیل از طرح مسایل و پیچیدگی‌های بخش پیش این بود که مشخص شود بررسی ارزش، منافع و توجیه‌پذیری پروژه را نمی‌توان تماما درون مرزهای پروژه انجام داد. این کار باید در سطح مدیریت پرتفولیو انجام شود. این سطح مسئول انتخاب و اولیت‌دهی پروژه‌هاست و اعضای آن معمولا از مدیران ارشد و سهام‌داران سازمان هستند.
با این‌همه، چرا در پم‌باک و سایر منابع مدیریت پروژه چنین مسایلی را بررسی می‌کنیم؟ دلیلش این است که با این‌که ارزیابی‌ها و تصمیم‌گیری‌های اصلی باید در لایه‌های بالاتر سازمان انجام شوند، وابسته به اطلاعاتی هستند که از سوی پروژه‌ها فرستاده می‌شوند و مدیر پروژه باید بتواند با ارائه اطلاعات مناسب به مدیریت پرتفولیو کمک کند. از سوی دیگر، همه افراد دست‌اندرکار پروژه باید با این موارد آشنا باشند و خود را با آن همسو کنند.
فرصتی در اختیارتان قرار گرفته است که یکی از دو بازی زیر را انتخاب کرده، فقط یک‌بار بازی کنید. در هر دو بازی، خودتان سکه‌ای انتخاب می‌کنید و آن را می‌اندازید.
کدام بازی را انتخاب خواهید کرد؟
مسئله پیش از دوره رایگانی که درباره مدیریت ریسک منتشر کرده‌ام آماده است. در زمان نوشتن این کتاب حدودا سه هزار نفر این دوره را گذرانده‌اند و از میان این افراد ۷۸٪ بازی نخست را انتخاب کرده‌اند. آیا به نظر شما این بازی بهترین گزینه است؟
برای پاسخ دادن به پرسش باید امید ریاضی (expected value) بازی‌ها را محاسبه کنیم:
مانند $ و ¥ و €، نشان ¤ هم برای مقادیر مالیست، ولی برخلاف آن‌ها اشاره به ارز خاصی نمی‌کند و در نمونه ما معادل قیمت پیتزا به کار می‌رود.
امید ریاضی بازی دوم دو برابر بازی نخست است، به این معنی که اگر این دو بازی را هزاران بار انجام دهیم، درآمد بازی دوم به احتمال زیاد دو برابر بازی نخست خواهد بود. بنابر این اگر قرار باشد بازی را هزاران بار انجام دهیم، بی‌گمان بازی دوم بهتر خواهد بود.
تا اینجای استدلال ساده است، ولی درباره این مسئله که قرار است بازی را فقط یک‌بار انجام دهیم چگونه می‌توان استدلال کرد؟
این بازی را یک‌بار انجام خواهیم داد، ولی در کار و زندگی شخصی هزاران هزار بازی اینچنینی می‌کنیم. اگر استراتژی همیشگی‌مان این باشد که گزینه‌های با امید ریاضی بالاتر را انتخاب کنیم، درمجموع برنده خواهیم بود. از این رو، بهتر است که در این بازی هم گزینه دوم را انتخاب کنیم.
آنچه در بالا گفته شد روندی کلیست، ولی برای آن تبصره‌های گوناگونی هم بسته به توان ریسک کردن (risk capacity) فرد وجود دارد. برای نمونه، اگر کل داراییتان معادل ده هزار پیتزا باشد، نباید گزینه‌ای که احتمال باخت نزدیک به ده هزار پیتزا دارد را انتخاب کنید، حتی اگر امید ریاضی بالاتری داشته باشد. دلیلش این است که کاربرد پول برای فرد در آستانه‌ها مقدار خطی ندارد.
باوجود استدلال‌های بخش پیش، چه‌بسا هنوز هم احساس بهتری درباره بازی نخست داشته باشید که طبیعیست و ترس از دست دادن (loss aversion) نام دارد. بار احساسی از دست دادن بیشتر از به دست آوردن است. این نسبت در فرهنگ‌ها و افراد مختلف یکسان نیست، ولی این مقدار برای بسیاری افراد حدود دو و نیم است. در نمونه پیشین، امید ریاضی گزینه دوم دو برابر گزینه نخست بود که کمتر از آستانه دو و نیم برابر است و از این رو، بسیاری از افراد گزینه نخست را ترجیح می‌دهند.
ترس از دست دادن گرایشی طبیعیست که در همه ما وجود دارد. این گرایش به شکل تکاملی در اجدادمان که در جنگل و غار زندگی می‌کردند و جانشان دایما درخطر بود شکل گرفته است و در دنیای امروزی کاربرد کمتری دارد. این گرایش یکی از فریب‌های ذهنی (cognitive bias) است. موارد زیر نمونه‌های دیگری از فریب‌های ذهنی‌اند:
اگر علاقه‌مند باشید می‌توانید به فهرست فریب‌های ذهنی در ویکی‌پدیا مراجعه کنید تا این موارد بیشتر آشنا شوید. در این باره کتاب‌های ارزشمندی نیز وجود دارد.
اندیشه انتقادی حوزه‌ای درباره تصمیم‌گیری و ایده‌پردازی سنجیده و به‌دور از فریب‌های ذهنیست. اگر قرار باشد این کتاب فقط یک اثر بر شما داشته باشد، امیدوارم این اثر علاقه‌مند کردنتان به مطالعه درباره اندیشه انتقادی باشد! این مهارت کمک‌های فراوانی به پروژه‌هایتان خواهد کرد و افزون بر آن در زندگی شخصی‌تان هم کارآمد خواهد بود.
اندیشه انتقادی یکی از جنبه‌های اندیشه سیستمی است؛ دست‌کم، پم‌باک آن را اینگونه مدل می‌کند.
عنوان نخستین این اصل اندیشه سیستمی بود، ولی برای یکسان‌سازی عنوان‌ها و تبدیل آن‌ها از حالت اسمی به امری، به جمله بلندی که هم‌اکنون وجود دارد تبدیل شد. از آن گذشته، موضوع این اصل همچنان اندیشه سیستمیست.
اندیشه سیستمی درباره اندیشه‌ورزی همه‌جانبه درباره پیچیدگی‌هاست. بررسی همه‌جانبه مفهوم پیچیده «ارزش» در بخش‌های پیشین نمونه‌ای از اندیشه سیستمیست.
اندیشه سیستمی حوزه‌ای گسترده و کمابیش پیچیده است. مهم‌ترین مسایل در اندیشه سیستمی در مدیریت پروژه از این قرارند:
خانم میان‌سالی در یکی از شرکت‌هایی که می‌شناختم کار می‌کرد؛ فردی باشخصیت، با رفتاری مادرانه. سمت رسمی‌اش «منشی» بود، ولی در عمل بسیاری از کارهای شرکت را تسهیل می‌کرد.
پس از سال‌ها کار در شرکت، بهیکباره آن را ترک کرد. ظاهرا مشکل این بود که باوجود کار خوبی که انجام می‌داد مدت‌ها بود که افزایش حقوق نداشت و شرکت‌های دیگری آماده بودند تا دو برابر به او حقوق پرداخت کنند. مدیریت شرکت حساسیت ویژه‌ای در این باره به خرج نداد و او را از دست داد؛ هر چه باشد، از دیدشان فقط یک «منشی» بود.
کمی پس از رفتنش به‌تدریج کارهای گوناگونی که پیشتر به خوبی انجام می‌شدند گره خوردند، ازجمله کارهایی که در ظاهرا هیچ ارتباطی به او نداشت. کم‌کم به جای آن یک نفر پنج نفر استخدام کردند ولی آن پنج نفر همراه هم نمی‌توانستند جای خالی او را پر کنند.
آن خانم هم در گره‌گشایی خبره بود و هم با علاقه درونی در هر زمینه‌ای که می‌توانست به همه کمک می‌کرد؛ خیلی فراتر از آنچه رسما مسئولیتش بود. چنین رفتاری را رهبری می‌نامیم.
بسیاری رهبری را از ویژگی‌های مدیران می‌دانند، ولی در ادبیات مدرن به هرکسی که افراد را به سمت نتایج مطلوب هدایت کند رهبر گفته می‌شود.
این تعریف نوین از این رو اهمیت دارد که در هر گروهی عده‌ای علاقه‌مند به رهبری وجود دارد که گذشته از سمت و مسئولیت خود به همگی کمک می‌کنند زیرا این رفتار برایشان خوشایند است. متاسفانه این افراد در بسیاری از سازمان‌ها نادیده گرفته می‌شوند، با این‌که اگر از آن‌ها پشتیبانی کنیم و قدرت بیشتری در اختیارشان بگذاریم می‌توانند بیش از پیش به سازمان یا پروژه کمک کنند. دست‌کم، اگر از آن‌ها پشتیبانی نمی‌کنید، چنان زیر فشارشان نگذارید که مانند خانمی که در نمونه پیشین گفته شد بگذارند و بروند.
پشتیبانی از رهبران نامرئی که در بخش پیش مطرح شد مبحث مهمی در حوزه رهبریست، ولی از آن گذشته، باید بر رشد توانایی‌های رهبری خودتان نیز تمرکز کنید.
برای نمونه، به‌عنوان یک رهبر، باید بتوانید در افراد انگیزه ایجاد کنید. فرض کنید یکی از اعضای تیم کار درخشانی در پروژه انجام داده است و می‌خواهید از او قدردانی کنید. چگونه این کار را خواهید کرد؟ با پرداخت پاداش مالی؟
پاسخ بستگی به مسایل فراوانی دارد. پاداش مالی هنگامی کارآمد است که مقدارش نسبت به نیاز مالی فرد مناسب باشد، وگرنه اثر معکوس خواهد داشت، زیرا کم بودن پاداش به معنی دست‌کم گرفتن کار فرد به شمار خواهد رفت. فرض کنید بودجه بسیار محدودی دارید و فقط می‌توانید معادل چهار پیتزا برای قدردانی از آن فرد هزینه کنید. پرداخت چنین پاداشی شایسته نیست، ولی با همان بودجه می‌توانید خودکاری برازنده سفارش دهید که نام آن فرد رویش حک شده باشد، آن را هدیه دهید و با چند جمله زیبا قدردانی خود را نشان دهید.
سوتفاهم‌های فراوانی درباره مفهوم رهبری وجود دارد. برای نمونه، داشتن کاریزما برای رهبران سودمند است، ولی کاریزما محدود به داشتن شخصیتی سرسخت، پرابهت و گاهی بداخلاق نیست. شکل‌های مختلفی از کاریزما وجود دارد و برخی از آن‌ها وابسته به دانش، مهربانی، دلسوزی و هماهنند آن‌ها هستند. بهتر است به جای الگوبرداری از شخصیت‌های کاریزماتیک فیلم‌ها، نوع کاریزمای مناسب شخصیت خود را بیابید و روی آن سرمایه‌گذاری کنید.
مدیر پروژه نیاز به مهارت‌های انسانی گوناگونی دارد. برای نمونه، APMbok، که راهنمایی همانند پم‌باک است، چنین دسته‌بندی‌ای ارائه می‌کند:
دسته‌بندی مهارت‌های انسانی کار ساده‌ای نیست. برای نمونه، «تاثیرگذاری» در دسته‌بندی بالا از «رهبری» جداست، با این‌که برخی آن را زیرمجموعه‌ای از مهارت‌های رهبری می‌دانند. گذشته از این‌که چگونه مهارت‌های انسانی را دسته‌بندی کنید، مهارت داشتن در همه آن‌ها برای رهبران لازم است.
برای همه این موارد کتاب‌های فراوانی وجود دارد. اگرچه متاسفانه این دامنه عینی نیست و از این رو متخصص‌های دروغین فراوان دارد و باید در انتخاب منابع دقت کنید.
شرکتی با اندازه متوسط می‌شناختم که زمانی مدیر موفقی را از شرکتی نامدار و بزرگ که در زمینه مشابهی کار می‌کرد جذب کرد. آن فرد بی‌درنگ آغاز به پیاده‌سازی سیستم مدیریتی‌ای کرد که در شرکت پیشین شناخته بود و به همان سرعتی که کار را آغاز کرد شکست خورد.
کاری که کرده بود دو مشکل کلان داشت:
مشکل دوم به شیوه پیاده‌سازی تغییر سازمانی برمی‌گردد که موضوعی در مدیریت طرح است و ارتباط مستقیمی به موضوع فعلی ما ندارد. مشکل نخست، نبود اختصاصی‌سازی (tailoring) است که موضوع این اصل است.
آیا تا کنون چیزی همانند «نه، ما از پرینس۲ استفاده نمی‌کنیم چون برای شرکت ما زیاد از حد پرهزینه است» شنیده‌اید؟
پرینس۲ و همه متدولوژی‌های دیگر ساخته شده‌اند تا به شکل‌های گوناگون، از جمله کاهش هزینه، به شرکت‌ها کمک کنند. اگر سیستمی اینچنینی پیاده‌سازی کنید و به نظرتان سربارش بیشتر از نتیجه باشد، به این معنیست که آن را به خوبی اختصاصی‌سازی نکرده‌اید.
اختصاصی‌سازی چیست؟
برای نمونه، پرینس۲ گزارشی به نام checkpoint report دارد که در دوره‌های زمانی از پیش تعیین شده از سوی مدیران تیم‌ها برای مدیر پروژه فرستاده می‌شود. پرینس۲ برای آن و دیگر موارد به‌جای عبارت «سند» از عبارت محصول مدیریتی استفاده می‌کند، زیرا الزامی نیست که آن‌ها را در قالب سند بسازید. اگر پروژه پیچیده و بزرگ باشد، شاید آن را مستند کنید، ولی در پروژه‌های کوچک‌تر حتی یک تماس تلفنی میان مدیر تیم و مدیر پروژه برای این منظور کفایت می‌کند. تنها الزام این است که تماس تلفنی در بازه‌های زمانی از پیش تعیین شده گرفته شود و در طی گفتگو موضوع‌های این گزارش بررسی شوند. هنگامی‌که نوع گزارش را تعیین می‌کنید، در عمل پرینس۲ را اختصاصی‌سازی کرده‌اید.
اختصاصی‌سازی سیستم بحثی کمابیش طولانیست و در فصل چهارم با تفصیل بیشتری به آن خواهیم پرداخت. اکنون بر موضوع دیگری تمرکز می‌کنیم: فرآیند و روش اختصاصی‌سازی.
در پم‌باک ۷ روشی دومرحله‌ای برای اختصاصی‌سازی پیشنهاد کرده‌ایم:
برای نخستین مرحله اختصاصی‌سازی نیاز به مرکزی در سازمان دارید. این مرکز را می‌توان مرکز تعالی (center of excellence) نامید. بسیاری علاقه وافر به عبارت PMO دارند (مخفف project management office یا عبارت‌های دیگر). اگر سازمان PMO داشته باشد، مدیریت نخستین مرحله اختصاصی‌سازی می‌تواند از وظایف اصلی آن به شمار برود.
متاسفانه واقعیت این است که اختصاصی‌سازی کار ساده‌ای نیست. برخی گمان می‌کنند که اختصاصی‌سازی به معنی انتخاب هیجان‌انگیزترین عناصر از سیستم‌های مختلف و کنار هم قرار دادن آن‌هاست، با این‌که چنین کاری سازگاری درونی سیستم و بنابراین کارآیی آن را از بین می‌برد. اختصاصی‌سازی نوعی ساخت سیستم است و همچون هر ساخت سیستم دیگری باید با دیدی همه‌جانبه و موشکافانه انجام شود.
در بیشتر سیستم‌ها مسئولیت اختصاصی‌سازی با مدیر پروژه است، ولی کسی که از هر جهت دیگر مدیر پروژه بسیار خوبی باشد شاید توانایی ساخت سیستم نداشته باشد. این‌که از مدیر پروژه‌ها انتظار داشته باشیم که بتوانند سیستم‌ها را اختصاصی‌سازی کنند همیشه واقع‌بینانه و منصفانه نیست. این مسئله در DSDM که یکی از متدولوژی‌های چابک نسل نخست است به رسمیت شناخته شده است، و از این رو، در انتخابی هوشمندانه، نقشی با نام مربی DSDM به متدولوژی افزوده‌اند که مسئولیت اختصاصی‌سازی و برخی مسایل دیگر را بر دوش دارد.
چه زمانی باید سیستم را اختصاصی‌سازی کرد؟ پاسخ بستگی به متدولوژی‌ای دارد که انتخاب کرده‌اید:
حتی زمانی که سیستم نیاز به اختصاصی‌سازی آغازین داشته باشد، باز هم لازم است که اختصاصی‌سازی تدریجی در هنگام کار داشته باشید. از سوی دیگر، اختصاصی‌سازی آغازین کار پر ریسکی است؛ چالش رایج این است که اختصاصی‌سازی‌های نخستین غیرواقع‌بینانه و زیاد از حد پیچیده و سنگین می‌شوند و کارکرد سیستم را مختل می‌کنند. از این رو، بهتر است که اگر نیاز به اختصاصی‌سازی آغازین دارید، آن را ساده و حداقلی انجام دهید و باقیمانده آن را در هنگام کار پیش ببرید.
آیا تاکنون از کسی شنیده‌اید که بگوید مدیریت کیفیت زیاد از حد پرهزینه است؟
چنین مسئله‌ای نمونه دیگری از اختصاصی‌سازی نامناسب در پروژه است. انجام فعالیت‌های مدیریت کیفیت هزینه و کوششی نیازی دارد و در ازایش با کم کردن ایرادها به کاهش هزینه کمک می‌کند. مانند هر عنصر دیگری در مدیریت پروژه، باید بازگشتی که از آن دریافت می‌کنید بیشتر از سرمایه‌ای باشد که صرفش می‌کنید. اگر زمانی متوجه شدید که مدیریت کیفیت زیاد از حد پرهزینه یا پردردسر است، به این معنیست که آن را به‌خوبی اختصاصی‌سازی نکرده‌اید.
برخی گمان می‌کنند که مدیریت کیفیت فقط به معنی آزمایش خروجی‌های پروژه و مطمئن شدن از درستی آن‌هاست. آزمایش‌ها بخشی از مدیریت کیفیت هستند، ولی فقط واپسین گام. هدف اصلی مدیریت کیفیت این است که کار را به گونه‌ای انجام دهیم که احتمال نامناسب بودن خروجی تا حد معقولی کم شود. هدف اصلی پیشگیریست و نه درمان و جنبه‌ای که به کاهش هزینه‌ها کمک می‌کند نیز همان بخش پیشگیریست.
مدیریت کیفیت، مانند همه حوزه‌های دیگر در مدیریت، باید غیرانفعالی انجام شود تا کارآمد باشد. برخورد غیرانفعالی با کار یکی از اصل‌های NUPP نیز هست که در ادامه این فصل به‌کوتاهی بررسی خواهد شد.
اگر سیستم مدیریت پروژه خود را شکل دهید و سپس به این بیندیشید که چگونه می‌توان عناصری برای مدیریت کیفیت به آن افزود، احتمالا چندان موفق نخواهید بود. مدیریت کیفیت باید عنصری یکپارچه در سیستم بوده، از آغاز در شکل‌دهی آن لحاظ شده باشد.
مدیریت کیفیت باید دو موضوع متفاوت را پوشش دهد:
یکی از دو موضوع مدیریت کیفیت، محصول و شیوه ساخت آن است که موضوعی فنیست وابسته به نوع محصول؛ برای نمونه:
به عنوان مدیر پروژه‌ای که الزاما فنی هم نیست چگونه می‌توانید از این جنبه‌های فنی اطلاع داشته باشید؟
مانند همیشه، نیازی نیست که شخصا همه این موارد را بشناسید، بلکه باید از تیم متخصصی که در کنار خود دارید کمک بگیرید. آنچه برای شما لازم است این است که مطمئن باشید روند مدیریت کیفیت فنی به‌خوبی شناسایی، مستند، و اجرا شده است. آیا کارفرما انتظارهای کیفی ویژه‌ای از پروژه دارد؟ آیا آیین‌نامه‌هایی وجود دارد که ملزم به رعایتشان باشید؟ آیا استانداردهایی وجود دارد که رعایتشان به نفعتان باشد؟ آیا سازمان دستورالعمل‌هایی درباره کیفیت دارد و انتظار دارد که همه پروژه‌ها رعایتشان کنند؟ به‌عنوان مدیر پروژه باید این موارد را کنترل کنید و پاسخ مناسبی برایشان داشته باشید.
کیفیت محصول و شیوه ساخت آن را به‌کوتاهی بررسی کردیم. عنصر دیگری که باید در مدیریت کیفیت مد نظر باشد، کیفیت سیستم مدیریت پروژه است. بله، این مسئله حتی دربرگیرنده کیفیت سیستم مدیریت کیفیت هم می‌شود!
نمونه خوبی از مدیریت کیفیت مدیریت پروژه در P3.express همتاداوری (peer review) دوره‌ایست. در آغاز هر ماه، پس از این‌که برنامه‌های کلان بازبینی و برنامه تفصیلی ماه پیش رو آماده شود، مدیر پروژه باید از یکی دیگر از مدیر پروژه‌هایی که در سازمان وجود دارد درخواست همتاداوری کند. مدیر پروژه دوم زمانی را صرف می‌کند و همراه هم کارهای انجام شده را بررسی می‌کنند تا اگر مشکلی وجود داشت کشف شود. پیشنهاد P3.express این است که در صورت امکان هر ماه از فرد تازه‌ای برای همتاداوری دعوت کنید.
یکی از امتیازهای همتاداوری کشف زودهنگام مشکل‌های احتمالیست، ولی افزون بر آن، در طی این فرآیند هر دو فرد از یکدیگر نکته‌های جالبی می‌آموزند. این فرصت طلایی را به هیچ وجه نباید از دست بدهید. پیشنهاد می‌کنم که به هر متدولوژی‌ای که دارید همتاداوری هم بیفزایید.
در یکی از پروژه‌های ساختمانی‌ای که همکاری می‌کردم کارگر آرماتوربند خوش‌رویی کار می‌کرد. گاهی سلام و احوال‌پرسی می‌کردیم. با این‌که کمابیش جوان بود، همسر و دو فرزند داشت که در شهر دوری زندگی می‌کردند. همیشه چشم انتظار تعطیلات بود که به شهرش برود و مدتی در کنار اعضای خانواده‌اش باشد.
یک روز که به کارگاه رفتم دیدم که همه به سمتی می‌دوند. من هم به آنجا رفتم و یکی از اندوه‌بارترین صحنه‌های زندگی‌ام را دیدم: آن کارگر در زمان کار در طبقه چهارم، که هنوز دیوار نداشت، لغزیده و به پایین افتاده بود. ده‌ها آرماتور خم‌شده که بر روی زمین پراکنده بود در بدن بی‌جانش فرو رفته بود و استخری از خون ساخته بود.
داستان تاسف‌آوری که تعریف کردم نتیجه یکی از عدم‌قطعیت‌های پروژه بود؛ این‌که در مدتی که دیوار بیرونی طبقه‌ای ساخته نشده باشد، احتمال دارد کسانی که در آن طبقه کار می‌کنند به پایین پرت شوند.
عدم‌قطعیت‌هایی که می‌توانند بر پروژه اثر مثبت یا منفی بگذارند ریسک نامیده می‌شوند. شیوه مدیریت این موارد با آنچه قطعیت دارد (برای نمونه، این‌که می‌دانیم حتما باید دیوار بیرونی آن طبقه را بسازیم) تفاوت دارد و از این رو مبحثی برای مدیریت ریسک وجود دارد.
مدیریت ریسک مانند مدیریت کیفیت و سایر جنبه‌های مدیریتی منافع فراوانی دارد، ولی هرگاه به لزوم مدیریت ریسک شک کردید، آن جوانی که گفته شد را به یاد بیاورید و به این نکته بیندیشید که اگر مدیریت ریسک بهتر انجام شده بود شاید هنوز زنده می‌بود و در کنار همسر و دو فرزندش زندگی می‌کرد.
نخستین گام مدیریت ریسک، شناسایی ریسک‌هاست. باید در آغاز پروژه کارگاه‌هایی برگزار کرد و با کمک اعضای تیم پروژه به عدم‌قطعیت‌ها اندیشید. با این همه، هرچه هم که در آغاز کار زمان صرف شناسایی ریسک‌ها کنیم، باز هم مواردی شناسایی نشده باقی می‌مانند و فقط هنگامی که به آن‌ها نزدیک‌تر شویم از آن‌ها آگاه می‌شویم. گاهی هم ریسک‌های تازه‌ای به دلیل تغییر شرایط محیطی به وجود می‌آیند. از این رو، لازم است که روند شناسایی ریسک‌ها دایما تکرار شود.
یک راه خوب این است که بخش کوچکی برای شناسایی ریسک‌های تازه به انتهای بیشتر جلسه‌ها و کارگاه‌ها بیفزایید.
پس از شناسایی ریسک‌ها باید برنامه‌های واکنشی برایشان طراحی کنیم. اگر می‌دانیم که نبود دیوار بیرونی در طبقه‌هایی که به تازگی ساخته شده‌اند ریسک حادثه به وجود می‌آورد، چه کاری باید برایش بکنیم؟
یک واکنش این است که فعالیت تازه‌ای به پروژه اضافه کنیم و بی‌درنگ پس از ساخته شدن کف هر طبقه نرده‌هایی موقت در حاشیه آن نصب کنیم. این کار احتمال حادثه را کمتر می‌کند، ولی کافی نیست. شاید بتوانیم روند کارها را کمی تغییر دهیم که ساخت دیوارهای بیرونی در زودترین زمان ممکن انجام شوند. این کار باز هم احتمال رخداد ریسک را کمتر می‌کند. شاید حتی بتوانیم فعالیت‌های دیگر را کمی جابجا کنیم که تا وقتی که دیوارهای بیرونی ساخته نشده‌اند رفت و آمد در طبقه حداقل شود.
به موازات این مسایل، فکر خوبیست که اعضای تیم پروژه آموزش ایمنی هم ببینند. این واکنش افزون بر ریسک مدنظرمان بر بسیاری ریسک‌های دیگر هم اثر می‌گذارد و از این رو بسیار مفید است. اگر پروژه بزرگ و دورافتاده باشد، فکر خوبیست که امکاناتی برای کمک‌های اولیه و حتی پرستاری مقیم هم در نظر گرفته شود تا هنگامی‌که حادثه‌ای رخ می‌دهد اثرش کاهش یابد.
افزون بر اثر مالی و زمانی حادثه‌ها، مسئولیت اجتماعی ما نیز حکم می‌کند که با ریسک حادثه با جدیت برخورد کنیم. با این‌همه، وقتی همه واکنش‌های منطقی را انجام دهید باز هم احتمال حادثه وجود دارد. بنابراین برای حفاظت از پروژه در برابر آسیب مالی، می‌توانید آن را بیمه نیز بکنید.
آنچه توضیح داده شد، مدیریت ریسک است؛ این‌که افزون بر آنچه می‌دانیم باید روی دهد، به آنچه شاید روی دهد نیز بیندیشیم و به جای این‌که دست روی دست بگذاریم، برایشان فکری کنیم.
به نظر شما بزرگ‌ترین عامل پیچیدگی در پروژه چیست؟
نمی‌دانم نظر شما چیست، ولی به نظر من بزرگ‌ترین عامل پیچیدگی وجود انسان در پروژه است! انسان‌ها پیچیده‌اند و هنگامی‌که در کنار هم قرار می‌گیرند پیچیدگی‌هایشان چند برابر می‌شود. این چالشیست که از زاویه دیدهای مختلف در سه اصل نخستین بررسی شد.
روابط غیرخطی عناصر پروژه عامل دیگری در پیچیدگی‌های پروژه است. از این روست که همیشه باید با دیدی همه‌جانبه و موشکافانه با مسایل برخورد کنیم. این مسئله را در اصل اندیشه سیستمی بررسی کردیم.
عنصر دیگری که مایه پیچیدگی پروژه می‌شود عدم‌قطعیت‌های آن است که موضوع اصل پیشین بود.
درواقع همه اصل‌ها راه‌هایی برای کنار آمدن با پیچیدگی‌های پروژه هستند و از این رو شخصا با افزودن این اصل به پم‌باک موافق نبودم. با این همه، سایر اعضای تیم باور داشتند که این موضوع اهمیت فراوان دارد و بهتر است برای تاکید در قالب اصلی جداگانه افزوده شود.
اینگونه، چند سال پس از آن مذاکره ناموفق در حال نوشتن کتابی درباره پم‌باک هستم، به این اصل رسیده‌ام، و هیچ مطلب تازه‌ای ندارم که برایش ارائه کنم!
سال‌های اخیر همگی از چابکی (Agility) سخن می‌گویند. البته تب چابکی در دنیا کمابیش رو به فروکش است، ولی همچنان مبحث مهمیست. به نظر شما چابکی چیست؟
بیشتر افراد، به‌ویژه کسانی که در حوزه چابکی کار می‌کنند، پاسخ درخوری برای این پرسش ندارند. از این رو، بهتر است پیش از ادامه دادن مبحث کمی معنای واقعی چابکی را بررسی کنیم.
دو راه کلی برای ساخت محصول پروژه وجود دارد، متعین (predictive) و تطبیقی (adaptive):
نام رایج برای روش تطبیقی، «چابک» (Agile) است. کسانی که با روش‌های چابک سر و کار دارند شیوه متعین را «آبشاری» (waterfall) و «سنتی» می‌نامند.
هرکدام از این دو روش برای نوعی از محصول مناسب است. از این رو، در پم‌باک هردو را به رسمیت شناخته‌ایم و آن را گونه‌ای طراحی کرده‌ایم که با هردو سازگار باشد. از اصطلاح‌های «آبشاری» و «سنتی» هم برای اشاره کردن به روش متعین استفاده نمی‌کنیم چون بار معنایی منفی دارند.
نسخه‌های نخستین پم‌باک برای پروژه‌های متعین تدوین شده بودند. پس از این‌که شیوه‌های تطبیقی پذیرش همگانی پیدا کردند، به‌تدریج مطالبی درباره‌شان به پم‌باک افزوده شد، ولی این موارد هیچ‌گاه با بدنه اصلی پم‌باک یکپارچه نشده بودند، بلکه به آن تحمیل شده بودند. از آنجایی که نسخه هفتم پم‌باک را از آغاز تدوین کردیم و به‌روزرسانی محتوای پیشین نیست، آن را از بنیان به‌گونه‌ای ساختیم که با هردو روش ساخت محصول سازگار باشد.
برخی گمان می‌کنند که «پم‌باک ۷ چابک شده است»، که کاملا اشتباه است. پم‌باک ۷ با هردو روش سازگار است و حتی بهتر است بگوییم رویکردش به مسایلیست که تاثیر چندانی از تطبیقی یا متعین بودن نمی‌گیرند.
شاید تعجب کنید که هنگامی که پم‌باک با هر دو روش ساخت محصول تطبیقی و متعین سازگار است، باز هم اصلی درباره تطبیق‌پذیری دارد. دلیلش این است که تطبیق‌پذیری به دو مقوله قابل حمل است:
برخی محصول‌ها را بهتر است تطبیقی ساخت و برخی را باید متعین ساخت، ولی سیستم مدیریت پروژه همیشه باید تطبیقی باشد زیرا با رفتارها و برداشت‌های پیچیده انسانی سر و کار دارد. موضوع واقعی این اصل سیستم مدیریت پروژه است.
این اصل به این معنیست که به‌جای ساخت یک سیستم تفصیلی برای مدیریت پروژه، بهتر است سیستمی ساده و حداقلی بسازید و کار را با آن آغاز کنید. پس از آن به‌تدریج جزئیات بیشتر را برای تطبیق دادن آن با محیطش بیفزایید.
فرض کنید در سازمانی کار می‌کنید که بودجه‌ای ثابت برای ساخت ده درمانگاه در نقاط دورافتاده دارد. اگر پروژه‌ها را به‌خوبی مدیریت کنید، شاید بتوانید به اندازه‌ای در هزینه‌ها صرفه‌جویی کنید که به‌جای ده درمانگاه، یازده درمانگاه بسازید. درمانگاه یازدهم به دلیل مدیریت پروژه موفق وجود دارد و اگر زمانی جان کسی را نجات دهد، بخشی از آن مدیون مدیریت پروژه خواهد بود.
در سال‌های اخیر، به ویژه در حوزه پروژه‌های چابک، همه توجه‌ها به پروژه‌هایی مانند آنچه در Netflix و Spotify انجام می‌شود جلب شده است. این شرکت‌ها محصول‌هایی تفریحی دارند که بی‌گمان جایگاه و ارزش خود را دارد، ولی نباید فراموش کنیم که پروژه‌های بسیار جدی‌تری هم برای بهبود کیفیت زندگی، فراهم کردن امکان آموزش برای کودکان، یافتن راهکار برای بیماری‌های کشنده و همانند آن‌ها وجود دارد. تسری دادن کورکورانه روش‌های شکل‌گرفته در پروژه‌های غیرحساس به همه پروژه‌ها بسیار پرریسک است.
هر پروژه محصول تازه‌ای می‌سازد یا محصولی که وجود دارد را دگرگون می‌کند. هر پروژه تغییری ساخت‌یافته است. با این حال، هنگامی که درباره تغییر سخن می‌گوییم، بیشتر منظورمان نتیجه تغییر است. برای نمونه، اگر سیستمی برای مدیریت اسناد در سازمانتان راه‌اندازی کنید، خروجی یا محصول پروژه سیستم مدیریت اسناد خواهد بود که تغییری در وضعیت شرکت به شمار می‌رود (زمانی این سیستم وجود نداشت و تغییر این است که اکنون وجود دارد). نتیجه این تغییر، اگر همه‌چیز به‌خوبی پیش برود، دسترسی آسان‌تر و سریع‌تر به اسناد، کاهش اشتباه‌ها و مانند آن خواهد بود.
آنچه انتظار داریم نتیجه مطلوب است و نه تنها تغییر. با این‌همه، این دو مفهوم همیشه با هم اشتباه گرفته می‌شوند که خود منشا چالش‌های فراوانیست.
در بخش پیشین، دوگانگی تغییر و نتیجه را بررسی کردیم: آنچه واقعا انتظار داریم نتیجه است و نه تغییر. بیشتر منابعی که درباره تغییر سخن می‌گویند درواقع منظورشان نتیجه تغییر است و نه خود تغییر. متاسفانه پم‌باک هم مستثنا نیست. موضوع واقعی این اصل نتایج تغییر است و نه خود تغییر.
آنچه در پروژه ساخته می‌شود محصول یا خروجی آن است. خروجی پروژه پتانسیلی برای ایجاد نتایج دارد، ولی تحقق نتایج معمولا به مسایل فراوانی، گاهی بیرون محدوده پروژه، وابسته است (برای نمونه، آموزش مناسب برای استفاده از سیستمی که در پروژه ساخته شده است). برای تحقق نتایج معمولا باید بیشتر از یک پروژه انجام داد و بیشتر از یک خروجی ایجاد کرد. در بسیاری از موارد، یکی از پروژه‌ها به‌مراتب بزرگتر از پروژه‌های دیگر است، در حدی که پروژه‌های دیگر در سایه آن پروژه اصلی گم می‌شوند و خیلی اوقات غیررسمی و بدون پروژه نامیده شدن انجام می‌شوند. از آنجایی که دستیابی به نتایج وابسته به انجام چند پروژه است، تحقق نتایج نیز موضوع اصلی مدیریت طرح است و نه مدیریت پروژه.
پیش از این مبحث دیگری درباره توجیه‌پذیری پروژه داشتیم و این‌که ارزیابی و مدیریت ارزش، منافع و توجیه‌پذیری پروژه‌ها را باید در سطح مدیریت پرتفولیو انجام داد و مدیریت پروژه برای این کار کافی نیست را بررسی کردیم. سیستم مدیریت پروژه باید در این فرآیند با سیستم مدیریت پرتفولیو همکاری کند و اعضای تیم پروژه نیز با این موارد آشنا باشند و خود را همسو کنند. همانند این مسئله برای تحقق نتایج نیز وجود دارد: این کار وظیفه اصلی سیستم مدیریت طرح است، ولی سیستم مدیریت پروژه باید با آن همکاری کند و اعضای تیم پروژه نیز باید برای تحقق نتایج کوشش کنند.
در بخش پیش اصل‌های پم‌باک را مرور کردیم. برای به دست آوردن دیدی بازتر به مفهوم و جایگاه اصل‌ها در مدیریت پروژه، اصل‌های منبع دیگری با نام NUPP را در این بخش مرور خواهیم کرد. NUPP مخفف Nearly Universal Principles of Projects (اصل‌های کمابیش فراگیر پروژه‌ها) و مجموعه‌ای از اصل‌هاست که کمابیش به همه پروژه‌ها، مستقل از متدولوژی مدیریت پروژه‌شان، قابل تسریست.
این مجموعه منبعی آزاد و رایگان بوده، ترجمه آن به زبان‌های متعدد، ازجمله فارسی، در https://nupp.guide وجود دارد.
اصل‌های NUPP از این قرارند:
در ادامه نگاهی کوتاهی به هریک از این اصل‌ها خواهیم کرد.
برخی حیوانات می‌توانند به‌تنهایی زندگی کنند، ولی برخی دیگر، مانند انسان‌ها، نمی‌توانند به‌تنهایی از پس نیازهای زندگی برآیند و نیاز دارند که در گروهی از موجودات همانند خود باشند. انسان‌های نخستینی که گرایش کمتری به تعلق در گروه‌ها داشتند شانس بقای کمتری داشتند و آن‌هایی که به زندگی خود ادامه دادند و تولیدمثل بیشتری کردند این گرایش را به نسل‌های بعدی خود منتقل کردند. این انتخاب طبیعی باعث شده است که گونه انسانی حسی قوی برای تعلق به گروه‌های مختلف داشته باشد و ترد شدن را به‌مثابه مرگ بپندارد.
این مورد، مانند هر گرایش طبیعی دیگری، از محدوده خود فراتر می‌رود و باعث می‌شود انسان‌ها ارزش‌های فراوانی را قربانی عضویت در گروه‌ها کنند. در بسیاری از این موارد، آنچه فرد از تعلق شدید به گروه به دست می‌آورد بسیار کمتر از آن است که قربانی می‌کند.
این گرایش درونی در حوزه مدیریت پروژه باعث می‌شود که افراد خود را وابسته به گروهی بدانند که از روشی ویژه‌ای برای اجرای پروژه استفاده می‌کند و به‌تدریج آن را تبدیل به تعصب و دشمن‌تراشی کنند. مدیر پروژه‌ای که خود را وارد چنین بازی‌های ایدئولوژیکی‌ای نکند و اندیشه‌اش را به روی همه منابع و ایده‌ها باز بگذارد، از آن‌ها بیاموزد و در هر شرایطی بسته به نیاز از آموخته‌های خود بهره گیرد، به‌مراتب موفق‌تر خواهد بود.
همانند منابع پروژه که محدودند، توان اندیشیدنمان هم محدود است. همانگونه که کوشش می‌کنیم از منابع پروژه بهینه استفاده کنیم، باید مراقب استفاده از توان اندیشیدنمان هم باشیم. در نقش مدیر پروژه باید به اعضای تیم پروژه نیز کمک کنید تا از توان ذهنی خود بهینه استفاده کنند.
اگر خود را درگیر ریزه‌کاری‌های پروژه و جنبه‌های فنی کنید، بخشی از توان اندیشیدنتان صرف خواهد شد و توان کمتری برای وظایف واقعیتان باقی می‌ماند. البته به جز آن دشواری‌های دیگری هم ایجاد می‌شود که پیش از این بررسیشان کردیم. فرض کنید توان اندیشیدنتان مبلغ محدودیست و برآنید که آن را در بهترین حوزه‌ها سرمایه‌گذاری کنید.
آیا قاعده ۸۰/۲۰ را می‌شناسید؟ بر پایه این قاعده، حدود ۸۰ درصد منافع بسیاری از دامنه‌ها با حدود ۲۰ درصد عناصرش به وجود می‌آیند. به آنچه شخصا در پروژه‌ها انجام می‌دهید بیندیشید: احتمالا حدود ۸۰ درصد نتایج مناسبی که می‌گیرید با ۲۰ درصد از کارهایی که کرده‌اید به دست آمده‌اند. بنا بر این، شاید بتوانید در فعالیت‌های خود بازبینی کنید و با حذف برخی از آن‌ها که نتیجه چندانی در بر ندارند، عناصر پربار را تقویت کنید.
قاعده ۸۰/۲۰ یکی از راهنماهای تدوین متدولوژی P3.express هم بوده است. به‌جای هدف قرار دادن ۱۰۰ درصد منافع مدیریت پروژه ساخت‌یافته با ۱۰۰ درصد کوشش، سیستمی ساخته شده است که با کمک آن بتوانید ۸۰ درصد منافع را با صرف ۲۰ درصد کوشش به دست آورید. از این روست که استفاده از P3.express بسیار ساده‌تر از بسیاری متدولوژی‌های دیگر است.
ما روزانه با مسایل فراوانی سر و کار داریم و هیچ‌کس توان بایسته برای واکنش نشان دادن به همه آن‌ها ندارد. در عمل با بسیاری از مسایل اطراف خود انفعالی برخورد می‌کنیم، یعنی کاری در برابر آن‌ها نمی‌کنیم، مگر این‌که به درجه‌ای برسند که نیاز به پادرمیانی ما داشته باشند. این برخورد طبیعیست و تنها راهکار برای زندگی. با این‌همه، مانند همیشه، ذهنمان آن را به همه مسایل تسری می‌دهد و در پروژه‌ها نیز این‌چنین برخورد می‌کنیم، ولی وقتی مدیریت موضوعی بر دوش ما باشد باید با آن غیرانفعالی برخورد کنیم.
برخورد غیرانفعالی الزاما به معنی اقدام کردن نیست. برخورد غیرانفعالی این است که هرگاه با مسئله‌ای روبرو می‌شوید به‌جای این‌که از آن چشم‌پوشی کنید، به آن بیندیشید و تصمیم بگیرید که اقدامی نیاز دارد یا نه. مدیریت ریسک نمونه‌ای از برخورد غیرانفعالی در پروژه است.
این اصل به این معنیست که در همه کارهایی که در مدیریت پروژه انجام می‌دهید غیرانفعالی برخورد کنید.
مدیریت پروژه جنبه‌های فراوانی دارد که دست به دست هم کار می‌کنند. اگر فقط یکی از این جنبه‌ها نادیده گرفته شود، جنبه‌های دیگر نیز کارایی خود را از دست می‌دهند. از این رو، باید مدیریت پروژه‌تان همه‌جانبه باشد و نه محدود به یک یا چند جنبه به ظاهر مهم‌تر مانند زمان‌بندی.
در فصل آینده، حوزه‌های عملکردی (performance domains) پم‌باک را بررسی می‌کنیم که نوعی دسته‌بندی از انواع جنبه‌هاییست که باید در مدیریت پروژه لحاظ شود:
زاویه دیدهای گوناگونی برای دسته‌بندی حوزه‌ها وجود دارد و بهتر است مسئله را از چند زاویه ببینید تا نقاط کور برایتان مشخص شوند. برای نمونه، ایزو ۲۱۵۰۰ و نسخه‌های پیشین پم‌باک چنین دسته‌بندی‌ای دارند:
پرینس۲ چنین دسته‌بندی‌ای دارد:
راهنمای APMbok مسایل را اینگونه تقسیم‌بندی می‌کند:
آیا به همه این جوانب در پروژه‌های خود توجه می‌کنید؟
هر کاری که در پروژه انجام می‌دهید باید هدفی توجیه‌پذیر داشته باشد. این‌که دیگران کاری را انجام می‌دهند دلیلی برای انجامش نیست. اگر منابعی مانند پم‌باک یا متدولوژی‌های مدیریت پروژه آن‌ها را پیشنهاد می‌کنند نیز دلیلی برای انجامشان نیست، بلکه باید با مطالعه دقیق آن منابع درک کنید که چرا آن اقدام پیشنهاد شده است و آن را هدفمند انجام دهید.
در زمان تصمیم‌گیری چنین روندی را طی کنید: دو جهان موازی تجسم کنید که فقط در یکی از آن‌ها اقدام مدنظر را انجام می‌دهید. باید بتوانید توضیح دهید که نتایج پروژه به چه شکل در این دو جهان موازی متفاوت خواهند بود. پس از آن، به این بیندیشید که نتیجه مثبتی که در یکی از این دو جهان به دست می‌آید توجیه‌کننده کار اضافه‌ای که قرار است انجام دهید هست یا خیر.
برای نمونه، پرینس۲ گزارشی با نام highlights report دارد. می‌توانید با کمی جستجو در اینترنت تمپلیت‌هایی برایش بیابید، آن‌ها را پر کرده، برای گیرندگان بفرستید. این کار نمونه‌ای از بارپرستی است که در آغاز کتاب بررسی کردیم. راه درست این است که با مطالعه پرینس۲ بیاموزید که این گزارش چه هدفی دارد و چگونه با دیگر عناصر یکپارچه می‌شود. سپس، بدون نیاز به تمپلیت، می‌توانید گزارش مناسبی آماده کنید که اهداف را محقق کند.
اگر هر بار که قرار است کاری انجام دهید روند آن را دوباره کشف و تدوین کنید، انرژی فراوانی لازم خواهد بود و احتمال اشتباه نیز بالا می‌رود. به جای آن بهتر است که جنبه‌های مشترک کارها را با عناصر تکرارپذیر مستند کرده، به‌تدریج بهبود دهید.
نمونه خوبی برای عناصر تکرارپذیر، چک‌لیست است. برای نمونه، اگر قرار است اسناد مهندسی فراوانی در شرکت ارزیابی شوند، هرآنچه باید چک شود را در چک‌لیستی مستند کنید و هر بار که فرآیند تکرار می‌شود به‌جای اندیشیدن به الزامات کنترلی، از آن لیست کمک بگیرید. در زمان به کارگیری لیست، چه‌بسا موارد بهبودی نیز به ذهنتان برسد که می‌توانید در چک‌لیست اعمال کرده، هم برای مورد در دست اقدام و هم برای موارد آینده به کار ببرید.
نمونه دیگر وجود چرخه‌های تکرارپذیر در متدولوژی‌هایی مانند P3.express است. فعالیت‌هایی که هر ماه یا هر هفته با روند ویژه‌ای تکرار می‌شوند به‌تدریج تبدیل به عادت می‌شوند و توان ذهنی کمتری نیاز خواهند داشت. توانی که اینگونه صرفه‌جویی کرده‌اید را می‌توانید صرف حل مسایل دیگر کنید.
پرینس۲ متدولوژی‌ای خوش‌ساخت و پرقدمت است و در بیشتر پروژه‌ها کاربرد دارد. در فصل بعد پرینس۲ را به‌کوتاهی مرور خواهیم کرد.
پرینس۲ هم مجموعه‌ای از اصل‌ها دارد:
این اصل‌ها کمابیش در همه پروژه‌ها کاربرد دارند، ولی هدف از تدوین آن‌ها، برخلاف اصل‌های پم‌باک و NUPP، ساخت مجموعه‌ای که راهنمای همه نوع پروژه باشد نبوده است. به جای آن، هدف از این اصل‌ها پشتیبانی از روند ویژه اجرای پروژه در پرینس۲ بوده است. از این رو، برخی از این اصل‌ها به‌سادگی در همه پروژه‌ها به کار نخواهند رفت.
فقط پروژه‌هایی که توجیه‌پذیر باشند را باید آغاز کرد. با این‌همه، توجیه‌پذیر بودن در آغاز پروژه کافی نیست، زیرا گاهی با شناخت بهتر پروژه می‌توان برداشت واقع‌بینانه‌تری از بازگشت سرمایه آن به دست آورد و گاهی هم به دلیل تغییر شرایط بیرونی پروژه توجیه‌پذیری‌اش تغییر می‌کند. از این رو، باید دایما توجیه‌پذیری پروژه را بازنگری کرده، بسته به نیاز پروژه را متوقف کرد.
بسیاری از پروژه‌های در حال انجامی که توجیه‌پذیری خود را از دست می‌دهند به دو دلیل متوقف نمی‌شوند:
باید توجیه‌پذیری هر پروژه‌ای را دوره‌ای کنترل کرد. این کار هم به یافتن پروژه‌هایی که توجیه‌پذیریشان را از دست داده‌اند کمک می‌کند و هم به همگان دایما هدف پروژه و لزوم هم‌راستا شدن با آن را یادآوری می‌کند.
تمدن بشری وابسته به انتقال آموخته‌هاست. اگر قرار بود هر دانشمندی همه علوم را از آغاز به تنهایی کشف کند، هیچ‌گاه نمی‌توانست از حدی جلوتر برود. به‌جای تکرار آنچه دیگران به دست آورده‌اند، هر دانشمندی یافته‌های پیشین را می‌آموزد و سپس گامی جلوتر می‌رود. همین مسئله باید در مدیریت پروژه هم وجود داشته باشد:
برخی گمان می‌کنند که ثبت درس آموخته به این معنیست که در پایان پروژه اندکی به خاطرات گذشته بیندیشند و از آن یادداشت بردارند. چنین کاری به هیچ وجه کارا نیست. به جای آن، ثبت درس آموخته باید دایمی و تدریجی باشد.
اگر پروژه کوچک و ساده نباشد، بهتر است که هر عضوی از تیم پروژه دقیقا بداند که چه انتظاری از او می‌رود و چه انتظاری می‌تواند از دیگران داشته باشد. اینگونه، جلوی بسیاری از سوتفاهم‌ها و مشکل‌ها گرفته می‌شود و از این روست که تعیین نقشها و مسئولیت‌ها یکی از اصل‌ها در پرینس۲ به شمار می‌رود.
معمولا نمی‌توان پروژه‌های طولانی را از آغاز به‌تفصیل برنامه‌ریزی کرد، زیرا برخی جزئیات را فقط زمانی می‌توان دانست که به آن‌ها نزدیک شده باشیم. از این رو، روند معمول برنامه‌ریزی در پرینس۲ این است که در آغاز پروژه برنامه‌ای کلان و پیش از آغاز هر دوره برنامه‌ای تفصیلی برای آن دوره آماده شود.
برخلاف آنچه برخی می‌پندارند، این شیوه برنامه‌ریزی بسیار رایج و فراگیر است. برنامه‌ریزی در P3.express نیز به همین ترتیب است. P3.express چرخه‌های ثابت ماهانه دارد، ولی مدت زمان دوره‌های پرینس۲ متغیرند.
همیشه باید به شکل مناسب تفویض اختیار کنید، وگرنه هم حجم کارتان بی‌دلیل بالا می‌رود و هم مشارکت اعضای تیم و درنتیجه احتمال موفقیت کاهش می‌یابد.
در پرینس۲ برای هر سطح مدیریتی مجموعه‌ای از حدود تصمیم‌گیری بر پایه زمان، هزینه، گستره، کیفیت، ریسک و منافع ناشی از تصمیم لحاظ می‌شود. پس از آن، اگر اثر تصمیم کمتر از آن حد باشد، فرد پایین‌دست مسئول تصمیم‌گیری خواهد بود، وگرنه باید مسئله را به‌عنوان موردی ویژه (exception) به فرد بالادست ارجاع داد.
بسیاری فقط بر فعالیت‌ها تمرکز دارند، ولی بهتر است تمرکز بر محصول و تحویل‌شدنی‌های پروژه باشد. این اصل از این روست که راه‌های فراوانی برای ساخت هر تحویل‌شدنی وجود دارد و بهتر است گزینه‌های خود را بی‌درنگ محدود نکنیم. هنگامی که تمرکز بر محصول و تحویل‌شدنی‌ها باشد، دید بهتری بر راهکارها خواهیم داشت و می‌توانیم بهترین را انتخاب کنیم، ولی اگر تمرکزمان بر فعالیت‌ها باشد در عمل تسلیم گزینه پیش‌فرضی که در فعالیت‌ها پنهان است خواهیم شد.
سیستم‌های ماکسیمالیستی، ازجمله پرینس۲، بدون اختصاصی‌سازی نخستین کاربردی نیستند و کسانی که می‌کوشند پروژه خود را عینا همانند ظواهر آنچه در منوآل پرینس۲ گفته شده است پیش ببرند به نتیجه مطلوبی نخواهند رسید.
گذشته از اختصاصی‌سازی نخستین، باید دایما در طول کار هم مشغول اختصاصی‌سازی تدریجی باشید تا سیستم مدیریت پروژه با شرایط محیطی انطباق پیدا کند.
پم‌باک متدولوژی نیست، به این معنی که مسیرتان را در پروژه مشخص نمی‌کند. به‌جای آن به دو شکل زیر کمکتان می‌کند:
مورد نخست را در فصل گذشته بررسی کردیم و دومی موضوع فصل بعدیست. در این فصل برخی از متدولوژی‌های مدیریت پروژه، یعنی P3.express، پرینس۲، DSDM و اسکرام را به‌کوتاهی بررسی می‌کنیم تا درک بهتری از هدف فصل آینده داشته باشیم.
درباره واژه «متدولوژی» باید این موارد را در نظر داشت:
گذشته از این‌که چه عبارتی به کار می‌رود، تمرکزمان در این فصل بر سیستم‌هاییست که مسیر پروژه را نشان می‌دهند و برای سادگی آن‌ها را متدولوژی خطاب خواهیم کرد.
درباره سیستم‌هایی که در این فصل مطرح می‌شوند نیز به این موارد دقت کنید:
سرانجام، این را هم در نظر داشته باشید که مطالب این فصل بسیار کوتاه است و فقط برای آشنایی مختصر با متدولوژی‌ها، در حدی که برای درک بهتر مطالب فصل بعد کفایت کند، وگرنه یادگیری هریک از این متدولوژی‌ها نیاز به تفصیل بسیار بیشتری دارد.
P3.express متدولوژی‌ای مینیمالیستی برای مدیریت پروژه است که برای پروژه‌های کوچک، متوسط، و بزرگ طراحی شده است. پروژه‌های بسیار کوچک و بسیار بزرگ مخاطب اصلی سیستم نیستند و نیازمند اختصاصی‌سازی‌های فراوان خواهند بود. البته برای پروژه‌های بسیار کوچک نوع ویژه‌ای از آن با نام micro.P3.express طراحی و ارائه شده است.
یکی از تمایزهای P3.express با گزینه‌های دیگری مثل پرینس۲ این است که نیاز به اختصاصی‌سازی نخستین ندارد. به‌جایش، کاربران می‌توانند از آن به همان شکلی که هست در پروژه‌های خود استفاده کنند و فقط پس از پیاده‌سازی کامل و جا افتادن سیستم آغاز به اختصاصی‌سازی تدریجی آن کنند.
P3.express برخلاف برخی منابع دیگر، مانند پم‌باک و پرینس۲، منبعی آزاد است و علاقه‌مندان می‌توانند بدون محدودیت کپی‌رایت از آن بهره‌مند شوند. این منبع به یاری داوطلبان به بیش از بیست زبان ترجمه شده است و در آن میان ترجمه فارسی نیز وجود دارد: https://p3.express
نقش‌های تعریف شده در P3.express از این قرارند:
توجه داشته باشید که هرکدام از ارکان پروژه که از P3.express استفاده کنند زاویه دید خود را خواهند داشت و ساختار، اسناد، و فرآیندهایش نیز بر همان پایه خواهد بود. برخلاف آن، در حالت پیش‌فرض پرینس۲، ساختاری یکه برای ترکیب همه ارکان پروژه وجود دارد.
اگر لازم باشد می‌توانید نقش‌های بیشتری به سیستم بیفزایید، ولی مراقب باشید که این کار را به تدریج، بر پایه بازخوردهایی که از محیط دریافت می‌کنید و بدون پیچیده کردن سیستم انجام دهید.
در P3.express مجموعه فعالیت‌هایی برای آغازش پروژه و پایان پروژه وجود دارد. در میان این دو، چرخه‌هایی ماهانه برای انجام کار پروژه وجود دارد، با گروه فعالیت‌هایی برای آغازش ماهانه و پایان ماهانه. درون چرخه‌های ماهانه نیز فعالیت‌هایی برای مدیریت هفتگی و مدیریت روزانه وجود دارد. پس از پایان پروژه شماری فعالیت مدیریت پساپروژه برای ارزیابی منافع پروژه و طراحی اقدام‌های تازه وجود دارد.
برای آغازش پروژه باید اعضای کلیدی تیم منصوب و به کمک آن‌ها برنامه‌ای کلان آماده شود. برنامه برای حامی پروژه فرستاده می‌شود تا درباره اجرا کردن یا نکردن پروژه تصمیم بگیرد.
ترجیح بر این است که برنامه نخستین کلان باشد و سپس در هر آغازش ماهانه بازبینی شده، برای ماه پیش رو تفصیلی شود. اطلاعات بازبینی و تفصیلی شده در پایان آغازش ماهانه برای حامی پروژه فرستاده می‌شوند تا درباره ادامه دادن یا متوقف کردن پروژه تصمیم بگیرد.
در طول ماه بر روی محصول پروژه کار می‌کنیم و هر هفته پیشرفت آن را ارزیابی کرده، به انحراف‌ها واکنش نشان می‌دهیم. فعالیت‌هایی روزانه نیز برای تایید تحویل‌شدنی‌های کامل شده و پیگیری اقلام قابل‌پیگیری (ریسک‌ها، مسایل، درخواست‌های تغییر، برنامه‌های بهبود، و درس آموخته‌ها) وجود دارد.
در زمان پایان ماهانه، رضایت ذی‌نفعان را ارزیابی کرده، بر آن پایه برنامه‌هایی برای بهبود پروژه در ماه بعد طراحی می‌کنیم.
وقتی محصول پروژه کامل شود یا قرار باشد آن را متوقف کنیم، فعالیت‌های پایان پروژه را اجرا می‌کنیم تا تشریفات پایانی را انجام دهند، رضایت ذی‌نفعان را ارزیابی کنند، محصول را به کارفرما تحویل دهند، اسناد را بایگانی کنند و …
چرخه مدیریت پساپروژه بسته به نوع محصول و محیط آن هر ۳ تا ۶ ماه به مدت ۱ تا ۵ سال تکرار می‌شود. در این چرخه منافع برآمده از محصول پروژه را ارزیابی می‌کنیم و بر آن پایه کارهای اضافه‌ای که شاید منافع را افزایش دهند شناسایی می‌کنیم. انجام فعالیت‌های خرد بر دوش تیم‌های عملیاتی گذاشته می‌شود و برای فعالیت‌های بزرگتر پروژه‌های تازه می‌سازیم.
هرکدام از هفت گروه فرآیندی گفته شده به‌جز مدیریت روزانه با فعالیتی به نام ارتباط متمرکز پایان می‌یابد. در این فعالیت پیامی حاوی اطلاعات ویژه برای ذی‌نفعان از پیش تعیین شده فرستاده می‌شود تا همگان از وضعیت پروژه آگاه باشند.
در آغازش پروژه و آغازش ماهانه فعالیتی با نام همتاداوری (peer review) وجود دارد که نقشی کلیدی در P3.express دارد. در این فعالیت از یکی دیگر از مدیران پروژه‌های سازمان درخواست می‌کنید که کارهایی را که در طی آن مدت انجام داده‌اید بررسی کرده، نظر بدهد. اگر می‌توانید، هر بار از فرد متفاوتی برای همتاداوری کمک بگیرید. این فعالیت هم احتمال رخ دادن اشتباه را کاهش می‌دهد و هم روش بسیار خوبیست برای این‌که این دو نفر از یکدیگر بیاموزند.
محصول‌های مدیریتی P3.express از این قرارند:
پرینس۲ متدولوژی‌ای خوش‌ساخت، پیشرفته و پیچیده است و از آن می‌توان در بیشتر پروژه‌ها استفاده کرد.
پرینس۲ را بدون اختصاصی‌سازی نخستین نباید به کار برد. از آنجایی که بیشتر برای پروژه‌های بزرگ و بسیار بزرگ طراحی شده است، اختصاصی‌سازی آن برای پروژه‌های متوسط و کوچک نیاز به کوشش بیشتری دارد.
در پرینس۲ سه سطح مدیریتی درون پروژه، پایین‌تر از سطح مدیریتی سازمان وجود دارد. نقش‌های متعددی در این لایه‌ها تعریف شده است، ازجمله:
می‌توانید با شکستن هرکدام از نقشها، نقش‌های تازه‌ای به وجود آورید یا با ادغام کردن آن‌ها در هم سیستم سیستم را ساده‌تر کنید. برای این کار محدودیت‌هایی نیز وجود دارد؛ برای نمونه، نباید نقش مدیر پروژه و مدیر ارشد در هم ادغام شوند زیرا هم تضاد منافع به وجود می‌آید و هم این‌که برای یک نفر دشوار است که هم به جنبه‌های بسیار کلان توجه کند و هم مسایل روزمره.
منوآل پرینس۲ برای هرکدام از فعالیت‌های مدیریتی جدولی از مسئولیت‌ها نیز دارد که عملکرد هر نقش را در ازای فعالیت مشخص می‌کند.
وقتی ایده پروژه‌ای شکل می‌گیرد و به نظر جالب می‌رسد و پیش از آن‌که تصمیم نهایی درباره آن گرفته شود، فرآیند راه‌اندازی پروژه اجرا می‌شود. در این فرآیند برخی اعضای کلیدی تیم منصوب می‌شوند و همراه هم اطلاعاتی کلان گردآوری می‌کنند که در پایان در سندی با نام خلاصه پروژه (project brief) ذخیره خواهند شد. این سند اطلاعاتی تقریبی درباره توجیه‌پذیری پروژه و شیوه اجرای مناسب آن دارد.
مدیر ارشد و سایر افراد تصمیم‌گیرنده بر پایه اطلاعات گردآوری شده تصمیم می‌گیرند که پروژه ارزش بررسی دقیق‌تر دارد یا خیر. اگر داشته باشد، فرآیند آغازش پروژه اجرا می‌شود.
در آغازش پروژه برنامه کلان آماده می‌شود و بر آن پایه می‌توان توجیه‌پذیری پروژه را با اطمینان بیشتر برآورد کرد. این اطلاعات در سندی با نام سند آغازش پروژه (project initiation documentation) ذخیره می‌شود. این سند نیز در اختیار مدیر ارشد و سایر تصمیم‌گیرندگان گذاشته می‌شود که تصمیم نهایی را برای آغاز کردن یا نکردن کار اجرایی پروژه بگیرند.
همانگونه که می‌بینید، پروژه در دو مرحله ارزیابی می‌شود. در مرحله نخست به‌سرعت و با صرف توان محدود آن را بررسی می‌کنیم تا پروژه‌هایی که اصلا توجیه‌پذیر نیستند حذف شوند. در مرحله دوم، با صرف زمان و انرژی بیشتر، پروژه را به دقت بررسی می‌کنیم و بر آن پایه تصمیم نهایی را می‌گیریم.
پروژه‌ها در پرینس۲ مرحله به مرحله انجام می‌شوند. پیش از اجرای هر مرحله فرآیند مدیریت شرایط حدی اجرا می‌شود تا برنامه کلان را بازبینی کرده، برنامه‌ای تفصیلی برای مرحله پیش رو بسازد. بر پایه این تغییرها، توجیه‌پذیری پروژه بازبینی و برای دریافت اجازه اجرای مرحله بعد برای تصمیم‌گیرندگان فرستاده می‌شود.
همه تصمیم‌های کلان پروژه که مستقیم یا غیرمستقیم از سوی مدیر ارشد گرفته می‌شوند در فرآیندی کلی به نام هدایت پروژه قرار دارند.
در طول مرحله، فرآیندی به نام کنترل مرحله کارهای روزانه را انجام می‌دهد. در این فرآیند کارهایی که لازم است تیم‌ها انجام دهند را برایشان می‌فرستیم و در لایه ساخت محصول نیز فرآیندی با نام مدیریت ساخت محصول برای رهبران تیم‌ها وجود دارد که با فرآیند لایه مدیریتی تعامل می‌کند.
فرآیند کنترل مرحله وضعیت پروژه را نیز ارزیابی می‌کند، گزارش‌های پیشرفت آماده می‌کند، و برای اصلاح انحراف‌ها نیز تصمیم می‌گیرد. هنگامی که انحرافی وجود داشته باشد که اثرش کمتر از حد تصمیم‌گیری مدیر پروژه باشد، خودش تصمیم می‌گیرد، وگرنه آن را برای لایه هدایت می‌فرستد.
هروقت محصول پروژه کامل شود یا لازم باشد که پروژه متوقف گردد، فرآیند پایان پروژه اجرا می‌شود تا تشریفات نهایی را انجام داده، محصول را به کارفرما تحویل دهد.
اسکرام یکی از سیستم‌های چابک نسل نخست است که برای پروژه‌های نرم‌افزاری با حداکثر ۱۰ نفر طراحی شده است. می‌توان ادعا کرد که این سیستم بیشتر لایه‌ای مدیریتی بود که برای هدایت سیستم eXtreme Programming (XP) که محبوب‌ترین سیستم چابک زمان خود بود ساخته شده بود، زیرا XP فقط در لایه فنی بود و جنبه‌های مدیریتی چندانی نداشت. اسکرام به‌تدریج دگرگون و در قالب سیستمی مستقل ارائه شد.
اسکرام سیستمی ساده و خوش‌ساخت است که حد مختصری از مدیریت پروژه را که برای برخی پروژه‌ها کافیست ارائه می‌کند. از این‌رو، باید همواره در نظر داشت که اسکرام همه جنبه‌های مدیریت پروژه را پوشش نمی‌دهد.
ویژگی‌های جالب اسکرام و برخی مسایل محیطی دست در دست هم آن را به رایج‌ترین سیستم چابک تبدیل کرده‌اند. اکنون کمابیش همه پروژه‌های چابک یا با اسکرام انجام می‌شوند یا با سیستم‌های نسل دومی که به شدت تحت تاثیر اسکرام بوده‌اند.
سه نقش در اسکرام وجود دارد:
سیستم مدیریتی اسکرام غیرمتمرکز است؛ به این معنی که به‌جای داشتن فرد و گروهی که مسئولیت اصلی هماهنگی‌ها و مدیریت پروژه را بر دوش داشته باشند، این مسئولیت‌ها در میان همه اعضای تیم پخش شده است.
به دلیل ساختاری که اسکرام دارد، افزودن نقش‌های دیگر به سازگاری درونی آن آسیب می‌زند و بنابراین مجاز نیست.
برخلاف بیشتر سیستم‌ها، اسکرام آغازش و پایانی رسمی و ساخت‌یافته تعریف نکرده است و فقط بر روند مناسب برای زمان اجرای پروژه تمرکز دارد. دلیل این مسئله این است که اسکرام برآن نیست که همه جنبه‌های مدیریت پروژه را پوشش دهد.
در آغاز پروژه، مالک محصول با ذی‌نفعان گفتگو می‌کند و فهرستی ساده و نخستین از قابلیت‌های مدنظرشان فراهم می‌کند. فهرست محصول (product backlog) به هیچ وجه کامل نیست و در طول اجرای پروژه دستخوش دگرگونی‌های فراوانی خواهد شد.
مالک محصول هم مسئول تدوین آیتم‌های فهرست است و هم مرتب کردن آن‌ها بر پایه ارزششان. آیتم‌های باارزش‌تر و مهم‌تر در بالای فهرست قرار می‌گیرند.
اسکرام نیز مانند پرینس۲ و P3.express چرخه‌ایست و چرخه‌هایش Sprint نام دارند. این چرخه‌ها مدت‌زمان ثابتی دارند و همیشه در زمان معین پایان می‌پذیرند، حتی اگر کار چرخه کامل نشده باشد. تعیین مدت‌زمان چرخه‌ها بر دوش تیم است، ولی این مدت نباید بیشتر از یک ماه باشد. برای مدت‌زمان چرخه‌ها هر بار تصمیم‌گیری نمی‌کنیم، بلکه همه چرخه‌ها را با مدت یکسان اجرا می‌کنیم، مگر این‌که پس از مدتی متوجه شویم که مدت تعیین شده برای نوع پروژه مناسب نیست و بهتر است آن را برای چرخه‌های بعد اصلاح کنیم.
هر چرخه با جلسه‌ای حداکثر ۸ ساعته برای برنامه‌ریزی چرخه آغاز می‌شود. اعضای تیم گرد هم می‌آیند و درباره آیتم‌هایی که در بالای فهرست قرار دارند گفتگو می‌کنند تا مطمئن شوند که درک مناسبی از آن‌ها دارند. پس از آن توسعه‌دهندگان برآورد می‌کنند که چند آیتم از بالای فهرست محصول را می‌توانند در طول چرخه انجام دهند و آن‌ها را جدا کرده، در فهرست چرخه (Sprint Backlog) قرار می‌دهند. این کار بسیار مفید است، زیرا فهرست محصول معمولا بسیار بلند است، ولی فهرست چرخه کوتاه و متمرکز بر آنچه قرار است در طول چرخه انجام شود.
برای چرخه هدفی نیز در نظر گرفته می‌شود تا به شکلی کلان اقدامات را همسو کند. این هدف در فهرست چرخه ثبت می‌شود. هماهنند آن، هدف کلی محصول نیز در فهرست محصول ثبت می‌شود.
پس از پایان برنامه‌ریزی چرخه، کار ساخت محصول آغاز می‌شود. توسعه‌دهندگان قابلیت‌های تازه را می‌سازند، اسکرام مستر به حل چالش‌هایشان کمک می‌کند، و مدیر محصول هم توضیح‌های تکمیلی ارايه می‌کند. در طول کار نیز جلسه‌های ۱۵ دقیقه‌ای روزانه‌ای به نام Daily Scrum وجود دارد که در آن اعضای تیم گرد هم می‌آیند و تک‌تک به‌کوتاهی توضیح می‌دهند که در روز گذشته چه کرده‌اند، در روز پیش رو چه خواهند کرد، و با چه دشواری‌هایی ممکن است روبرو شوند.
وقتی مدت مقرر چرخه به پایان برسد، از کار دست می‌کشیم، حتی اگر همه قابلیت‌های فهرست چرخه به پایان نرسیده باشند. درباره پایان یافتن آیتم‌ها نیز باید حساس بود، زیرا اگر آیتمی واقعا تکمیل نشده باشد نمی‌تواند بازخورد مناسبی ایجاد کند و برای تطبیق‌پذیری پروژه مانع ایجاد خواهد کرد. از این رو، آنچه از آیتم‌های کامل شده انتظار داریم را در سندی با نام Definition of Done مستند کرده، همواره از آن کمک می‌گیریم. هر آیتمی که کاملا به پایان نرسیده باشد را به فهرست محصول بازمی‌گردانیم تا در چرخه‌های بعدی کامل شود و پس از آن به سراغ دو جلسه پایانی چرخه می‌رویم.
برای نخستین جلسه پایان چرخه، که حداکثر ۴ ساعت است، از ذی‌نفعان بیرونی دعوت می‌کنیم و همراهشان محصول چرخه را مرور کرده، بازخوردی نخستین دریافت می‌کنیم. این بازخورد بسیار محدود است و لازم است که افزون بر آن محصول به شکل‌های مختلف در اختیار نمایندگان کاربران نهایی هم قرار بگیرد تا در فرصت بیشتر با آن کار کنند و بازخوردهای مستقیم و غیرمستقیم آن را گردآوری کنیم.
در جلسه دوم پایان چرخه، که حداکثر ۳ ساعت است، همه اعضای تیم گرد هم می‌آیند و پس از بررسی روند کار خود در طول چرخه، می‌کوشند راهی برای بهبود پروژه در چرخه بعد پیدا کنند.
متدولوژی DSDM نیز یکی از روش‌های چابک نسل نخست است. این سیستم، برخلاف بیشتر روش‌های چابک، برای پروژه‌های بزرگ و پیچیده طراحی شده است و ساختار آن نیز از پرینس۲ الهام گرفته است.
DSDM برای پروژه‌های نرم‌افزاری طراحی شده است. می‌توانید آن را برای سایر پروژه‌ها نیز اختصاصی‌سازی کنید، ولی این کار چندان ساده نخواهد بود.
ساختار تیم DSDM بسیار جالب، ولی پیچیده است:
افزون بر نقش‌های گفته شده، نقشی با نام تحلیل‌گر کسب و کار نیز وجود دارد که هم عضوی از سطح پروژه است و هم سطح تیم، هم تخصص کسب و کار دارد و هم تخصص فنی. این نقش جنبه‌های مختلف پروژه را به هم پیوند می‌زند.
کار در DSDM با فاز پیشاپروژه آغاز می‌شود. در این فاز توجیه‌پذیری پروژه را به‌کوتاهی بررسی و نتیجه را همراه با اطلاعات تکمیلی در سندی با نام terms of reference ذخیره می‌کنیم. تصمیم‌گیرندگان با کمک این اطلاعات فرمان توقف کار یا اجرای فاز بعدی را می‌دهند.
فاز بعدی، توجیه‌پذیری است. در این فاز زمان بیشتری صرف شناسایی پروژه و جنبه‌های کسب و کار، فنی، و مدیریتی آن می‌کنیم. اطلاعات گردآوری شده در سند ارزیابی توجیه‌پذیری ذخیره می‌شوند و برای تصمیم‌گیرندگان فرستاده می‌شوند تا فرمان توقف پروژه یا اجرای فاز بعد را بدهند.
فاز سوم شالوده است. در این فاز برنامه کلان پروژه را آماده می‌کنیم که شالوده پروژه به شمار خواهد رفت. بر پایه برنامه کلان می‌توان درک بهتری از توجیه‌پذیری آن نیز پیدا کرد و همه این اطلاعات در قالب سندی با نام چکیده شالوده در اختیار تصمیم‌گیرندگان قرار می‌گیرد.
اگر پروژه توجیه‌پذیر باشد، آن را در فازی تکرار شونده با نام توسعه تکاملی اجرا خواهیم کرد. در هر چرخه این فاز نسخه تازه‌ای از محصول پروژه آماده می‌شود و مانند همه پروژه‌های چابک برای گردآوری بازخورد و روشن کردن مسیر پیش رو به کار می‌رود.
فاز دیگر، انتشار است. این فاز را می‌توان پس از هر چرخه توسعه تکاملی یا با بسامدی کمتر تکرار کرد. در هر تکرار، تازه‌ترین نسخه نرم‌افزار در اختیار کاربران نهایی قرار می‌گیرد.
در DSDM فاز جداگانه‌ای برای پایان پروژه وجود ندارد و بخشی از آن از این روست که بسیاری از کارهای پایانی به تدریج در فاز انتشار انجام می‌شوند.
واپسین فاز، پساپروژه است که در آن منافع محصول پس از پایان پروژه رصد می‌شوند.
مدت‌زمان پروژه در DSDM ثابت است و حتی یک روز هم طولانی‌تر نمی‌شود. به عبارت دیگر، پروژه را تا زمانی که همه قابلیت‌ها ساخته شوند ادامه نمی‌دهیم، بلکه آن را تا زمان مقرر ادامه داده، حداکثر قابلیت‌هایی که امکان‌پذیر باشد را می‌سازیم. برای ساخت محصول در چنین سیستمی از تکنیک اولولیت‌بندی مسکو (MoSCoW) استفاده می‌شود. عبارت MoSCoW در این تکنیک مخفف این موارد است:
در فازهای توجیه‌پذیری و شالوده، فهرستی از قابلیت‌های کلی نرم‌افزار فراهم کرده، با کمک روش مسکو اولولیت‌بندی می‌کنیم. این فهرست اولویت‌بندی شده قابلیت‌ها به‌تدریج در هنگام کار تفصیلی‌تر می‌شود.
برای این‌که پروژه انعطاف‌پذیری به‌اندازه داشته باشد لازم است که حجم قابلیت‌های (M) کمتر از ۶۰٪ باشد و حداقل ۲۰٪ از آیتم‌ها از نوع (C) باشند. وقتی مدت‌زمان لازم برای پروژه برآورد می‌شود،
در هنگام کار، وضعیت پروژه دایما ارزیابی می‌شود و پیشبینی می‌کنیم که تا زمان پایان پروژه چه آیتم‌هایی تکمیل خواهند شد. اگر پیشبینی کنیم که تا پایان پروژه امکان تکمیل همه (M)ها وجود نخواهد داشت، باید مسئله را به مدیران ارشد اعلام کنیم که یا پروژه را لغو کنند یا تغییرهایی بنیادین در آن بدهند.
به عبارت دیگر، در چنین پروژه‌هایی تضمین می‌کنیم که همه (M)ها تکمیل خواهند شد، کوشش می‌کنیم (S)ها را نیز کامل کنیم، و اگر توانستیم (C)ها را هم خواهیم ساخت.
برخی از متدولوژی‌های مدیریت پروژه را در فصل پیش بررسی کردیم. متدولوژی‌ها با هدف نشان دادن مسیر در پروژه ساخته شده‌اند، که با هدف راهنماهایی مانند پم‌باک متفاوت است. یکی از هدف‌های اصلی راهنماها کمک به تقویت متدولوژی‌هاست، که موضوع این فصل است.
پم‌باک ۷ حوزه‌های عملکردی متعددی دارد که هرکدام یکی از موضوع‌های مدیریت پروژه را بررسی می‌کند:
متدولوژی‌ها معمولا همه این حوزه‌ها را پوشش می‌دهند، هرچند گاهی ضمنی و با حداقل‌هایی که از دیدشان در بیشتر پروژه‌ها لازم است. از این رو، می‌توانید هریک از این حوزه‌ها را بررسی کرده، شیوه پیاده‌سازی آن را با نیازهای پروژه سنجیده، بسته به نیاز تقویتش کنید.
در زمان تغییر دادن متدولوژی (اختصاصی‌سازی) مراقب موارد زیر باشید:
در ادامه این فصل حوزه‌های عملکردی پم‌باک را به‌تفصیل بررسی خواهیم کرد.
«ذی‌نفع» به فرد یا گروهی گفته می‌شود که به نوعی با پروژه سر و کار دارد و می‌تواند بر آن اثر بگذارد. بنابراین، اعضای تیم، سازمان، کارفرما، پیمانکاران، کاربران نهایی، رقبا، قانون‌گذاران و همانند آن‌ها ذی‌نفع به شمار می‌روند.
مدیریت ذی‌نفعان نقشی کلیدی در موفقیت پروژه دارد و پیش از این برخی جنبه‌های آن را بررسی کردیم. همه متدولوژی‌ها به گونه‌های مختلف مدیریت ذی‌نفعان را پوشش می‌دهند، به‌گونه‌ای که برای عموم پروژه‌ها و در شرایط عادی بایسته باشد.
در دیدگاه سنتی، مدیریت ذی‌نفعان عموما بر ذی‌نفعان بیرونی (غیر از اعضای تیم پروژه) متمرکز است. روش‌های چابک برخوردی وارونه دارند و بیشتر توجهشان به ذی‌نفعان درونیست. روش‌های نوین کوشش می‌کنند که به هر دو گروه ذی‌نفع به اندازه توجه کنند.
برای مدیریت مناسب ذی‌نفعان باید همه موارد زیر به نوعی لحاظ شوند:
این مراحل باید در متدولوژی لحاظ شده، دایما تکرار شوند.
گاهی شناسایی ذی‌نفعان کار ساده‌ای نیست. نمونه‌اش پناهگاه کوهستانیست که پیش از این طرح شده بود.
باید در آغاز کار زمان کافی صرف شناسایی ذی‌نفعان کلیدی کرد، زیرا برخی از ذی‌نفعان، مانند قانون‌گذاران، چنان تاثیرهای کلانی بر پروژه می‌گذارند که ممکن است توجیه‌پذیری آن را از بین ببرند. اگر این ذی‌نفعان در آغاز کار شناسایی شوند، شاید متوجه شوید که بهتر است زمان و هزینه‌ای صرف پروژه نشده، لغو شود.
گذشته از شناسایی نخستین، باید دایما در هنگام اجرای پروژه نیز به فکر شناسایی ذی‌نفعان تازه باشید، زیرا
مانند بسیاری دیگر از حوزه‌های مدیریت پروژه، بهتر است به اسناد پروژه‌های همانند که در گذشته اجرا کرده‌اید نیز مراجعه کنید تا ببینید چه کسانی بر آن اثر گذاشته‌اند. اینگونه می‌توانید ذی‌نفعان بیشتری شناسایی کنید که شاید بدون آن از قلم بیفتند. این مسئله یکی از دلایل فراوانیست که بر لزوم مستندسازی و بایگانی مناسب اسناد پروژه‌ها پافشاری می‌کنیم.
متدولوژی خود را بررسی کنید تا ببینید که روندی که برای شناسایی ذی‌نفعان دارد برای شرایط پروژه‌تان مناسب است یا نه، و اگر لازم است، فعالیت‌های ساخت‌یافته‌تری برای این منظور به آن بیفزایید.
پس از شناسایی هر ذی‌نفع، باید تحلیلش کنید:
وقتی در جستجوی پاسخ به چنین پرسش‌هایی هستید، به‌تدریج برنامه‌ای هم برای مشارکت‌دادن و جلب حمایت آن‌ها تدوین کنید. وقتی چنین کاری می‌کنید مراقب توجیه‌پذیری برنامه نیز باشید: آیا منافعی که از مشارکت و حمایت ذی‌نفع دریافت می‌کنید بیش از توانی که صرف می‌کنید هست؟ آیا بازگشت سرمایه در این فرآیند بیشتر از هزینه فرصت (opportunity cost) شما هست یا خیر؟ به عبارت دیگر، آیا کار دیگری با بازگشت بالاتر هست که بتوان به‌جای آن انجام داد؟
استثنایی که در تحلیل توجیه‌پذیری مشارکت ذی‌نفعان وجود دارد، مسایل اخلاقیست. فرض کنید قرار است ساختمان کوچکی در همسایگی پیرزنی بسازید. پیرزن نمی‌داند که چنانچه سر و صدا و مزاحمت کار بیش از اندازه یا بی‌موقع باشد می‌تواند از شما شکایت کند و شاید توان و حوصله این کار را نداشته باشد. آیا این مسئله به این معنیست که نیازی به محدود کردن آلودگی صوتی کارگاه ندارید؟ نه؛ باید جنبه اخلاقی مسئله را هم در نظر بگیرید.
اطلاعاتی که درباره تحلیل و برنامه‌ریزی ذی‌نفعان گردآوری کرده‌اید را برای ارجاع‌های بعدی مستند کنید. برخی متدولوژی‌ها سندی برای این کار دارند که می‌تواند نامی مانند فهرست ذی‌نفعان (stakeholder register) داشته باشد. برخی دیگر این اطلاعات را در دل اسنادی کلان‌تر ذخیره می‌کنند. اگر سند جداگانه‌ای برای این کار ندارید و باور دارید که مدیریت ذی‌نفعان پروژه‌تان پیچیدگی‌های فراوانی دارد، بهتر است سندی مستقل برایش بسازید.
مشارکت دادن ذی‌نفعان وابستگی فراوانی به ارتباطات دارد و در این باره باید به این دو جنبه توجه کنید:
ارتباطات انواع مختلفی نیز دارند:
نکته‌ای بسیار مهم درباره ارتباطات وجود دارد: هر ارتباطی باید ردپایی داشته باشد و اطلاعاتی که منتقل شده‌اند ماندگار باشند. برای نمونه، اگر جلسه‌ای رو در رو دارید، صورت جلسه‌ای آماده کنید که چکیده‌ای از اطلاعات رد و بدل شده را بازتاب دهد. اگر گفتگویی تلفنی انجام شده است، یادداشت کوتاهی بردارید و آنچه طرح شده بود را در آن ثبت کنید.
متاسفانه متوجه شده‌ام که در سال‌های اخیر استفاده از نرم‌افزارهای پیام‌رسان مانند واتس‌اپ در پروژه‌های ایرانی به شدت رایج شده و در عمل جای ایمیل و بسیاری بسترهای اطلاعاتی دیگر را گرفته است. پیشنهاد می‌کنم از این کار خودداری کنید، زیرا
اگر ذی‌نفعان پرشمار باشند، بد نیست آن‌ها را بر پایه توجیه‌پذیری برنامه‌ای که برای مشارکت‌دادنشان دارید، حدود اثرگذاری، و موارد مشابه آن اولویت‌بندی کنید تا اگر زمانی در میان اجرای پروژه توان کافی برای اجرای همه برنامه‌ها نبود، دست‌کم روی مهم‌ترین موارد تمرکز کنید.
به یاد داشته باشید که توجیه‌پذیری‌ها دایما تغییر می‌کنند و از این رو باید اولویت‌بندی‌ها را نیز اصلاح کنید.
برنامه‌ریزی کافی نیست و باید آن را اجرا کرد. متدولوژی خود را بررسی کنید و ببینید که برای مشارکت دادن ذی‌نفعان چه فعالیت‌هایی دارد (برای نمونه، ارتباطات) و در نظر هم داشته باشید که برخی اقدام‌ها ضمنی و نامرئی هستند. آیا این جنبه‌های متوولوژی برای درجه حساسیت مدیریت ذی‌نفعان در پروژه‌تان کافیست؟ اگر نباشد باید آن را تقویت کنید.
در کنار برنامه‌ریزی‌هایی که برای مشارکت دادن ذی‌نفعان می‌کنید، اقدام‌های موردی فراوانی نیز وجود خواهد داشت. مهارت‌های انسانی، مانند مذاکره و رفع اختلاف، در چنین مواردی کمک شایانی می‌کنند و بنابراین بهتر است بر بهبود مهارت‌های انسانی خود سرمایه‌گذاری کنید.
رفتارهایی غیراخلاقی مانند رشوه دادن راهی رایج برای مشارکت دادن ذی‌نفعان در برخی کشورهاست. فراموش نکنید که همیشه باید اخلاقی عمل کنید، حتی اگر هیچ‌کس دیگری در اطرافتان اخلاقی عمل نمی‌کند. رفتارهایی مانند رشوه دادن پذیرفتنی نیستند.
برخی رفتارهای به ظاهر بی‌گناه هم می‌توانند ذات رشوه دادن داشته باشند یا اینگونه برداشت شوند و درنتیجه باید مراقب آن‌ها هم باشید. این مسئله بستگی به نوع ذی‌نفع نیز دارد. برای نمونه، اگر مدیر شرکتی باشید و مدیران شرکتی همکار را به ضیافتی دعوت کنید، شاید مشکلی نداشته باشد، ولی اگر چنین کاری را با نمایندگان سازمانی قانون‌گذار انجام دهید پذیرفتنی نخواهد بود.
با این‌که اطلاع‌رسانی به ذی‌نفعان لازم است و بر لزوم شفاف بودن ارتباط‌ها پافشاری می‌کنیم، باید محرمانگی اطلاعات را هم در نظر داشته باشید. گروهی فعال در حوزه نرم‌افزارهای آزاد (متن‌باز) را در نظر بگیرید: این افراد معمولا به کنفرانس‌ها و انجمن‌های مختلف می‌روند و درباره پروژه‌هایشان با هر کسی که بتوانند گفتگو می‌کنند تا حمایت بیشتری به دست آورند. از سوی دیگر، برخی شرکت‌ها، مانند اپل، سختگیری‌های فراوانی درباره پروژه‌هایشان دارند و مایل نیستند کسی از آن‌ها باخبر شود. به‌عنوان مدیر پروژه، باید از سیاست‌های محرمانگی اطلاعات سازمانتان و هر نوع قانون و قاعده دیگری که در محیط اطرافتان وجود دارد باخبر باشید و تا جایی که خلاف اخلاق نیستند در کارهایتان اعمالشان کنید.
هنگامی که به جای واقعیت‌های عینی با جنبه‌های انسانی سر و کار داشته باشیم، روش‌های متعین کارایی کافی نخواهند داشت و لازم است که تطبیقی پیش برویم. از آنجایی که مدیریت ذی‌نفعان مسئله‌ای کاملا انسانیست، باید رویکردتان در این حوزه تطبیقی باشد و به‌جای ساخت برنامه‌ای کاملا تفصیلی در آغاز کار، برنامه‌ای ساده آماده کرده، زمینه‌ای فراهم کنید که بتوانید با اجرای آن برنامه بازخورد مناسب دریافت کرده، برنامه‌ها را برای دوره بعد بهبود دهید.
برای تطبیق با محیط باید دایما کارایی برنامه‌های مدیریت ذی‌نفعان را ارزیابی کنید. برای نمونه، اگر گزارشی برای گروهی از ذی‌نفعان می‌فرستید، با آن‌ها تماس بگیرید و گفتگو کنید تا مطمئن شوید که پیام اصلی گزارش به خوبی منتقل شده است. شاید به این نتیجه برسید که گزارش برای برخی از آن افراد کارآمد بوده است، ولی گروهی دیگر هنوز گزارش را مطالعه نکرده‌اند. شاید گروه دوم محدودیت زمان دارند و لازم است گزارش ساده‌تر و کوتاه‌تری برایشان بفرستید.
فکر خوبیست که در هر متدولوژی‌ای که دارید روند ارزیابی رضایت ذی‌نفعانی که در P3.express شرح داده شده است را نیز پیاده‌سازی کنید. در این سیستم، نظرسنجی گمنامی برای همه ذی‌نفعان درونی و بیرونی پروژه فرستاده می‌شود. از نتیجه نظرسنجی برای طراحی برنامه‌های بهبود در دوره بعد کمک گرفته می‌شود.
اعضای تیم پروژه نیز ذی‌نفعان آن هستند و درنتیجه همه مسایلی که در حوزه پیش بررسی کردیم به آن‌ها نیز اعمال می‌شود. با این‌همه، اعضای تیم نیاز به ملاحظات بیشتری دارند و آن جنبه‌ها در این حوزه بررسی می‌شوند.
مدیر پروژه به دو دلیل باید به این حوزه توجه کند:
به عبارت دیگر، بسیاری از کارهایی که برای اعضای تیم پروژه انجام می‌دهید سرانجام به نفع پروژه نیز خواهد بود، ولی نفع پروژه تنها دلیل برای انجام آن‌ها نیست. هیچ وقت برای ایجاد فضایی امن و سالم برای اعضای تیم پروژه به دنبال توجیه اضافه‌ای نگردید، بلکه آن را وظیفه اخلاقی خود بدانید. منفعتی که پروژه ممکن است از این مسئله ببرد صرفا امتیازی اضافه است.
مدیریت تیم مبحث گسترده‌ایست و در این بخش فقط به برخی از مهم‌ترین مسایل خواهیم پرداخت: ساختار تیم، بهبود تیم، و رهبری.
هر متدولوژی ساختار ویژه خود را برای تیم پروژه دارد و در فصل گذشته با برخی از آن‌ها آشنا شدید. بیشتر آن‌ها امکان بازبینی ساختار را نیز می‌دهند.
مثل همیشه، مراقب باشید که تغییری که اعمال می‌کنید سازگاری درونی متدولوژی را از بین نبرد و سیستم را بی‌دلیل پیچیده نکند.
چابکی رویکردی در ساخت محصول است. برخی از متدولوژی‌ها فقط برای ساخت چابک طراحی شده‌اند، برخی هم برای ساخت چابک و هم متعین، و برخی نیز بیشتر مناسب ساخت محصول متعین هستند.
بیشتر روش‌های چابک نسل نخست، مانند DSDM و XP، نقشی به‌عنوان مدیر پروژه دارند یا دست‌کم مخالفتی با چنین نقشی ندارند. با این‌همه، اسکرام چنین نقشی ندارد و افزودنش به اسکرام نیز سازگاری درونی آن را نابود می‌کند. این مسئله اهمیت فراوانی دارد، زیرا برخی گمان می‌کنند که با افزودن مدیر پروژه به اسکرام آن را تقویت کرده‌اند، با این‌که آن را ضعیف‌تر کرده‌اند.
از سوی دیگر، به دلیل گستردگی فراوان اسکرام و این واقعیت که بسیاری از روش‌های چابک نسل دوم از اسکرام الگوبرداری کردند، برخی می‌پندارند که وجود مدیر پروژه با ذات چابکی ناسازگار است، که کاملا اشتباهست. بسیاری از روش‌های چابک نیاز به مدیر پروژه دارند.
به یاد داشته باشید که پم‌باک درباره مدیریت پروژه است و نه مدیر پروژه. بیشتر پروژه‌ها مدیر پروژه دارند، ولی هیچ پروژه‌ای بدون مدیریت پروژه انجام نمی‌شود. حتی وقتی به مدیریت پروژه توجهی نشود، بازهم شکلی ضمنی از آن در پروژه وجود خواهد داشت.
مدیریت پروژه دو شکل کلی دارد:
هر دو حالت، چنانچه با دیگر اجزای متدولوژی و طبیعت پروژه هماهنگ باشند، پذیرفتنی هستند. سیستم‌های نامتمرکز را فقط در تیم‌های بسیار کوچک می‌توان به کار برد و نمی‌توان انتظار داشت پروژه‌ای با صدها نفر خودجوش و نامتمرکز مدیریت شود.
از سوی دیگر، بسیاری از افراد فنی علاقه‌ای به درگیر کردن خود در مسایل هماهنگی و مدیریتی ندارند و چنانچه وادار به چنین کاری شوند، درجه رضایتشان در پروژه کاهش خواهد یافت. چنین کسانی ترجیح می‌دهند در فضایی کار کنند که سیستمی متمرکز برای هماهنگی‌ها وجود داشته باشد و انواع خدمات مدیریتی را به آن‌ها بدهد تا بتوانند در فضایی امن بر کارهای تخصصی خود تمرکز کنند.
با توجه به این دو مسئله، کاربرد سیستم‌های نامتمرکز بسیار محدود می‌شود. برای نمونه، اگر کسب و کار کوچکی همراه با چند نفر دیگر راه انداخته باشید و در آن پروژه‌هایی انجام دهید، شاید سیستم نامتمرکز انتخاب خوبی برایتان باشد. این سیستم‌ها در پروژه‌های چابک محبوبیت بیشتری دارند. با این‌که متدولوژی‌هایی مانند DSDM سیستم مدیریتی متمرکز دارد، اسکرام اینگونه نیست. سیستم‌های تازه‌تر چابک هم با الگوبرداری از اسکرام می‌کوشند نامتمرکز باشند یا حداقل وانمود کنند که اینگونه هستند. این مسئله چالش‌های فراوانی برای سیستم‌های چابک نسل دومی که برای پروژه‌های بزرگتر طراحی شده‌اند ایجاد کرده است.
به هر روی، می‌توانید مدیر پروژه داشته باشید یا نداشته باشید، اما همیشه مدیریت پروژه خواهید داشت و بهتر است آن را ساخت‌یافته و کارآمد پیش ببرید.
برخی مدیر پروژه را بالاترین نقش پروژه می‌دانند، ولی بیشتر متدولوژی‌ها نقش دیگری بالاتر از مدیر پروژه دارند؛ مدیری ارشد که می‌تواند
این دو کار از بیشتر مدیر پروژه‌ها ساخته نیست، زیرا از یک سو معمولا قدرت سازمانی چندانی ندارند (مدیر ارشد نیستند) و از ریزه‌کاری‌های استراتژیک و برنامه‌های بلندمدت سازمان که گاهی فقط در اختیار مدیران ارشد و سهام‌داران است بی‌اطلاعند و از سوی دیگر بیشتر افراد نمی‌توانند در موضوعی یکه هم مسئولیت‌های انتزاعی و هم روزمره را بر دوش داشته باشند و در انجام یکی از این دو مورد (معمولا کارهای انتزاعی‌تر) سهل‌انگاری می‌کنند.
نقشی که در راس پروژه قرار می‌گیرد، در بسیاری از منابع، ازجمله P3.express، حامی پروژه (sponsor)، در پرینس۲ مدیر ارشد (executive) و در DSDM حامی کسب و کار (business sponsor) نامیده می‌شود.
در نظر داشته باشید که افراد و سازمان‌های مختلف برچسب‌هایی مانند «مدیر پروژه» و «حامی پروژه» را به شکل‌های گوناگونی به کار می‌برند. گاهی فردی که مدیر پروژه نامیده می‌شود درواقع نقش حامی پروژه را دارد و کارهای مدیریت پروژه را فردی انجام می‌دهد که برچسب رهبر تیم، رئیس کارگاه و همانند آن را دارد.
فریب برچسب‌ها را نخورید و اگر گمان می‌کنید برچسب‌های پیش‌فرضی که در متدولوژیتان وجود دارند با آنچه در محیط اطرافتان استفاده می‌شوند سازگار نیستند، برچسب‌های دیگری انتخاب کنید که سوتفاهم ایجاد نکنند. اگر وجود مدیر پروژه در متدولوژیتان اجباریست، به این معنی نیست که وجود برچسبی با آن نام الزامیست، بلکه به این معنیست که وجود نقشی با مسئولیت‌های تعریف شده الزامیست.
همیشه باید در حال بهبود تیم باشید. بسیاری از متدولوژی‌ها روش‌هایی ویژه و گاهی نامحسوس برای تیم‌سازی دارند که شاید در فعالیت‌های غیرانتزاعی‌تر مخفی شده باشند. چنین ترکیب‌هایی معمولا بهتر از برنامه‌هایی که فقط برای تیم‌سازی باشند عمل می‌کنند.
متدولوژی خود را بررسی کنید تا ببینید فعالیت‌های تیم‌سازی مستقیم و غیرمستقیم آن برای پروژه‌تان کافیست یا نه. اگر نبود، راه‌های نوآورانه‌ای برای آمیختن آن با فعالیت‌های موجود در متدولوژی بیابید.
یکی از بهترین روش‌ها برای تقویت تیم این است که حس هدف مشترک داشتن به وجود آورید. هنگامی که افراد حس کنند که همراه هم در راستای به‌سرانجام رساندن هدفی کوشش می‌کنند بهتر می‌توانند همکاری کنند تا زمانی که فقط بر فعالیت‌های تخصصی خود متمرکزند. برای نمونه، زمانی که موسسه‌های مختلف برای ساخت واکسن کرونا می‌کوشیدند، مدیر پروژه‌هایشان می‌توانستند از این فرصت بهره گیرند و با یادآوری دایمی این واقعیت که کل تیم برای حفظ جان انسان‌ها در تلاش است روابط درون‌تیمی را بهبود دهند.
همانگونه که پیش از این نیز طرح شد، دو موضوع اصلی در رهبری وجود دارد:
فهرستی از مهارت‌های رهبری، مانند ایجاد انگیزه، رفع اختلاف، حل مسئله، مذاکره، و تسهیل‌گری آماده کرده، آغاز به بهبود مهارت‌های خود در هریک از آن‌ها کنید. برای این کار منابع فراوانی وجود دارد و با مطالعه آن‌ها و تمرین در فضای واقعی پروژه به‌تدریج می‌توانید توانایی‌های خود را افزایش دهید. خوب است که چنین آموزش‌هایی را در اختیار برخی دیگر از اعضای تیم نیز بگذارید، به ویژه کسانی که پتانسیل کمک به مدیریت پروژه دارند.
برای نمونه، فرض کنید مهندس جوانی در پروژه وجود دارد که دوست دارد زمانی مدیر پروژه شود، و همانگونه که پیشتر گفته شد، مسئولیت دارید که فضای رشد در اختیار همه اعضای تیم بگذارید. از سوی دیگر، فرض کنید که در تسهیل‌گری چندان ماهر نیستید و فعلا زمان کافی برای بهبود این مهارت ندارید. شاید بتوانید از این فرصت استفاده کنید و اگر آن مهندس جوان علاقه‌مند است، برایش آموزش تسهیل‌گری فراهم کنید و پس از آن مسئولیت تسهیل‌گری کارگاه‌ها و جلسه‌ها را بر دوشش بگذارید. اینگونه، هم فرصتی به آن مهندس جوان داده‌اید و هم مشکلی که خود داشته‌اید را حل کرده‌اید.
راهکار پیشین نمونه‌ای از حالت برد-برد است. برخی گمان می‌کنند که اگر مهارت کافی در مذاکره داشته باشند باید بتوانند برنده همه مذاکره‌ها باشند، حتی به قیمت شکست طرف دیگر. یکی از ویژگی‌های مذاکره‌کننده ماهر این است که همیشه شرایط برد-برد به وجود آورد، زیرا اگر طرف دیگر برنده نباشد، برد خودش نیز همیشگی نخواهد بود و جایی مشکل ایجاد خواهد شد. آیا مایلید بیشتر درباره مذاکره بیاموزید؟ اگر مایل هستید، یکی از منابع خوبی که در این حوزه وجود دارد را انتخاب و مطالعه، و هرآنچه میاموزید را در عمل تجربه کنید.
موضوع چرخه حیات و روش ساخت محصول گسترده و کمابیش پیچیده است و چیرگی کامل بر آن‌ها برای بیشتر مدیر پروژه‌ها الزامی نیست. در این بخش فقط مسایلی که در این حوزه اهمیت بیشتری دارند و برای همه مدیر پروژه‌ها لازم هستند را بررسی می‌کنیم.
محصول پروژه را می‌توان به شیوه متعین یا تطبیقی (چابک) ساخت. پیش از این چگونگی این دو روش را بررسی کردیم و اگر آن را به یاد ندارید بهتر است پیش از ادامه دادن این بخش نگاه دوباره‌ای به آن بیندازید.
با این فرض که می‌دانید این دو روش چه هستند و چه تفاوت‌هایی با هم دارند، باید کمی بیشتر این‌که چه روشی برای چه نوع پروژه‌ای مناسب است را بررسی کنیم. البته پیش از آن نیاز به کمی اطلاعات پیرامونی هم داریم و بنابراین مبحث را با آن موضوع‌ها آغاز خواهیم کرد.
تمدن بشری همیشه از هر دو روش متعین و تطبیقی استفاده کرده است و نشانه‌های آن را می‌توان در بسیاری پروژه‌های باستانی دید. نخستین نسل کامپیوترها محدودیت‌های فراوان و مخاطب ویژه و اندکی داشتند که باعث می‌شد ساخت نرم‌افزارهایشان نیاز به روشی متعین داشته باشد. با پیشرفت سخت‌افزار، کاهش محدودیت‌ها، و دگرگونی نوع و گستردگی مخاطب نرم‌افزارها، روش‌های متعین دیگر گزینه خوبی برای ساخت نرم‌افزار نبودند، ولی دست‌اندرکاران این نوع پروژه‌ها همچنان به عادت گذشته می‌کوشیدند روش‌های متعین را به‌کار گیرند.
تحمیل روش‌های متعین بر پروژه‌های نرم‌افزاری همچنان ادامه پیدا کرد، تا زمانی که برنامه‌نویسان و مدیران تیم‌ها بیشتر و بیشتر از وضعیت ناراضی شدند و گرایش به ساخت محصول به شیوه تطبیقی پیدا کردند. سرانجام، گروهی از این افراد دورهم گرد آمدند تا به رویکرد خود رسمیت بخشند و برای آن نام چابک را انتخاب کردند.
متاسفانه اختلاف‌ها و مشکل‌های فراوانی که در این روند به وجود آمده بود ذهنیتی منفی درباره روش‌های متعین برای این افراد و کسانی که ادامه‌دهنده راهشان شدند به وجود آورد. به عبارت دیگر، به‌جای اصلاحی تدریجی، انقلابی خونین به وجود آمد. کمی پس از انقلاب هم گروهی کوچک مهره‌های اصلی را کنار زده، قدرت مطلق را به دست گرفتند. دایما هم درباره دشمن بیرونی هشدار می‌دهند! برای اطلاعات بیشتر می‌توانید به کتاب «قلعه حیوانات»، اثر جورج اورول مراجعه کنید.
روش‌های چابک مستقل و بدون کمک گرفتن از تجربه‌های سایر روش‌های ساخت شکل گرفتند. این ویژگی هم جنبه‌های مثبت دارد (نوآوری بیشتر) و هم منفی (اشتباه‌ها و تباه کردن منابع بیشتر). این روش‌ها اثبات کردند که سیستم‌های ساده می‌توانند کارآمدتر از سیستم‌های پیچیده باشند. جنبه‌های انسانی در بسیاری از سیستم‌های چابک نهادینه شده بودند که خود پیامدهای بسیار خوبی داشت، با این‌که بسیاری دیگر از سیستم‌ها درباره اهمیت مسایل انسانی سخن می‌گفتند، ولی آن‌ها را به شکلی کارا در سیستم خود به جریان نیانداخته بودند. این دو جنبه و برخی دیگر از یافته‌های این حوزه بسیار باارزشند و چه‌بسا بسیاری از سیستم‌هایی که در آینده ساخته می‌شوند نیز آن‌ها را به ارث خواهند برد.
از سوی دیگر، دیدگاه منفی افراد این حوزه به سیستم‌های متعین به‌تدریج افزایش یافت، به‌گونه‌ای که برای برخی ضدیت کردن با سیستم‌های متعین تبدیل به هویت شد. این رویکرد کم‌کم چابکی را تبدیل به فرقه و مذهبی کرد که پیروانش پذیرای هیچ ایده دیگری نیستند و همواره آماده جنگ با «دشمنان» بیرونی. مانند همه سیستم‌های دگماتیستی، خودشان نیز به گروه‌های فراوانی تقسیم می‌شوند و هریک دیگری را کافر می‌داند.
هرکدام از روش‌های متعین و تطبیقی برای نوع ویژه‌ای از محصول مناسب هستند و وقتی به‌درستی به کار گرفته شوند پذیرفتنی‌اند. چابک‌کارانی که گمان می‌کنند همه پروژه‌ها را می‌توان چابک اجرا کرد یا نمی‌دانند چابکی چیست یا تصوری از پروژه‌های غیرنرم‌افزاری ندارند. کسانی هم که چابکی را به‌کل رد می‌کنند چشمان خود را به روی فرصت‌های بزرگی می‌بندند.
بسیاری از منابع امروزی درباره روش‌های ترکیبی (hybrid) سخن می‌گویند؛ روش‌هایی که از ترکیب روش‌های متعین و چابک به وجود می‌آید. در عمل نمی‌توان چنین ترکیبی داشت، زیرا برای تطبیقی بودن در پروژه باید همه عناصر آن تطبیقی باشند و همین‌که جنبه‌ای از آن را ثابت و متعین کنیم، انعطاف‌پذیری و انطباق‌پذیری همه بخش‌ها از بین می‌روند. اگر بتوان بخشی را متعین کرد بدون این‌که تطبیق‌پذیری بخش‌های دیگر را از بین ببرد، آن دو بخش استقلال مفهومی، عملکردی و تولیدی کامل دارند و درنتیجه با دو محصول سروکار داریم که نیاز به دو پروژه مختلف دارند، و هیچ منعی برای استفاده از دو روش ساخت متفاوت در دو پروژه وجود ندارد، ولی آن را نمی‌توان «روش ترکیبی» دانست. وقتی با یک پروژه و یک محصول سروکار داریم، روش ساخت یا متعین خواهد بود، یا تطبیقی.
کسانی که از روش‌های ترکیبی سخن می‌گویند معمولا توجهشان معطوف ظواهر است و هرگاه ترکیبی از برچسب‌ها، اسناد، و مراسم که از دو روش آمده باشند بینند، آن را روشی ترکیبی می‌نامند. مدیر پروژه خبره می‌داند که توجه به ظواهر بارپرستی است و باید به‌جای آن به عملکردهای واقعی و ذات مسایل توجه داشت.
متاسفانه پم‌باک ۷ نیز پیروی سوتفاهم رایجی که در این باره وجود دارد درباره روش‌های ترکیبی سخن می‌گوید. کوشش من برای قانع کردن تیم و حذف این اشتباه نیز به جایی نرسید.
روش مناسب برای ساخت هر محصول فقط بستگی به نوع محصول دارد و نه مسایل دیگری مانند ترجیح تیم، مدیر پروژه، سازمان، یا کارفرما.
آیا می‌توانید محصولی که پاسخگوی نیازها و خواسته‌ها باشد را پیشبینی کنید یا با خواسته‌هایی پیش‌بینی‌ناپذیر سروکار دارید و لازم است که آن‌ها را به‌تدریج و با نمایش دادن نسخه‌هایی قابل استفاده از محصول (increment) کشف کنید؟ آیا اصلا امکان ساخت نسخه‌های قابل استفاده محصول برای ارزیابی خواسته‌های بازار وجود دارد؟
در روش تطبیقی باید بتوانیم نسخه‌های متعددی از محصول بسازیم، به‌گونه‌ای که هر نسخه قابلیت‌های بیشتری داشته باشد و همواره قابل استفاده باشد زیرا فقط اینگونه می‌توان بازخورد مناسب از محیط دریافت کرد. با بهره‌مندی از بازخورد هر نسخه، حدس میزنیم که بهترین کاری که در نسخه بعد می‌توان انجام داد چیست و بر آن پایه جلو می‌رویم. فراموش نکنید که هدف اصلی از گردآوری بازخورد در سیستم‌های متعین کشف مسیر مناسب برای آینده است و نه اصلاح گذشته. اصلاح گذشته بر پایه بازخورد در همه پروژه‌ها وجود دارد و به معنی تطبیقی بودن نیست.
برای این‌که بتوان به ترتیب گفته شده جلو رفت، باید در هر نسخه بر زیرمجموعه‌ای از ویژگی‌های تازه تمرکز کنیم و آن اجزا را جدا از سایر اجزا تعریف، طراحی، و تولید کرده، با خروجی‌های پیشین ترکیب کنیم. اگر فرآیندهای توسعه (تعریف، طراحی، …) را نتوانیم از هم جدا کنیم، اجزای سازنده پروژه آزادی کامل نخواهد داشت و سطحی از انعطاف‌پذیری که برای چابکی لازم است فراهم نخواهد شد.
برای نمونه، ساختمانی را فرض کنید: فونداسیون آن را نمی‌توان جدا از سایر عناصر طراحی کرد و ساخت، زیرا برای طراحی فونداسیون باید باری که بر آن وارد می‌شود را دانست و تنها راه برای دانستن آن این است که کل ساختمان طراحی شود. به عبارت دیگر، درجه‌ای از آزادی که برای چابکی لازم است در پروژه‌های ساختمانی وجود ندارد.
از سوی دیگر، در پروژه‌های ساختمانی نمی‌توان نسخه‌هایی نخستین از محصول آماده کرد که قابل استفاده باشند تا بر پایه آن‌ها بازخورد واقعی دریافت کرد؛ ساختمان فقط زمانی قابل استفاده است که کامل شده باشد. از این رو، حتی اگر آزادی عمل در چنین محصولی وجود می‌داشت، باز هم امکان چابک اجرا کردنش فراهم نمی‌شد.
اگر برآنید که نرم‌افزاری برای کاربرد همگان بسازید، پیشبینی پذیرش همگانی‌اش مکان‌پذیر نخواهد بود. اجزای سازنده نرم‌افزار را برخلاف ساختمان می‌توان مستقل از هم ساخت و نسخه‌هایی نخستین از نرم‌افزار ساخت که قابل استفاده باشند. این نسخه‌ها را می‌توان به کاربران محدودی نشان داد و بر پایه نوع استفاده و نظر آن‌ها حدس زد که گام بعدی چه باشد و بر آن پایه پیش رفت. چنین روشی برای این نوع پروژه بهترین نتیجه را می‌دهد و ریسک‌هایی که برآمده از پیچیدگی پیشبینی رفتار انسانیست را حداقل می‌کند.
هر پروژه نرم‌افزاری‌ای نیز نباید تطبیقی انجام شود. برای نمونه، اگر قرار است سیستم‌عامل و برخی دیگر از نرم‌افزارهای یک دیتاسنتر را تغییر دهید، خبری از پیچیدگی‌های رفتار انسانی نخواهد بود و بهتر است آن را متعین اجرا کنید. اگر قرار است نرم‌افزاری برای دستگاهی بیمارستانی یا نوعی هواپیما بسازید، هم پیچیدگی‌های گفته شده وجود ندارند و هم امکانی برای آزمایش و خطا ندارید، زیرا با جان انسان‌ها سروکار دارید؛ از آن‌رو، لازم است که محصول را به شیوه متعین و با تیزبینی و وسواس فراوان اجرا کنید.
برای پرهیز از اشتباه‌های رایج در این حوزه به این موارد توجه داشته باشید:
در پایان، به این موضوع هم توجه داشته باشید که منظور از روش ساخت محصول تطبیقی، روش ساختیست که درون یک پروژه و برای یک محصول به کار می‌رود. اگر یک پروژه‌ای را اجرا کنید و بر پایه آموخته‌هایتان پروژه بعدی را بهتر اجرا کنید، نوعی از انطباق وجود دارد، ولی این انطباق مفهوم دیگریست که ارتباط مستقیمی با انطباق مدنظر در روش‌های تطبیقی ندارد.
شیوه ساخت محصول کمابیش بر متدولوژی مدیریت پروژه اثر می‌گذارد. برخی متدولوژی‌ها، مانند P3.express، به‌گونه‌ای طراحی شده‌اند که با هر دو روش ساخت محصول سازگار باشند، ولی برخی، مانند DSDM، فقط از یکی از این دو روش ساخت محصول پشتیبانی می‌کنند. درنتیجه، در زمان انتخاب متدلوژی باید به شیوه ساخت محصول نیز توجه کنید.
موارد متعددی در سازگاری متدولوژی مدیریت پروژه و شیوه ساخت محصول اثر دارند و بررسی آن‌ها فراتر از هدف این کتاب است. برای نمونه، متدولوژی‌های مدیریت پروژه‌ای که خطی باشند را فقط برای ساخت محصول متعین که خطی است می‌توان به‌کار برد، ولی متدولوژی‌هایی که چرخه‌ای باشند را هم می‌توان برای ساخت محصول متعین استفاده کرد و هم تطبیقی.
هر پروژه محصولی را می‌آفریند یا محصولی که وجود دارد با تغییر می‌دهد. از این رو، چرخه حیات پروژه زیرمجموعه‌ای از چرخه حیات محصول خواهد بود. خوب است که در پروژه به چرخه حیات محصول هم توجه داشت؛ برای نمونه، شاید با صرف معادل ۵۰ هزار پیتزا هزینه بتوانید کاری کنید که هزینه استفاده از محصول پروژه در زمان بهره‌برداری معادل ۲ هزار پیتزا در ماه کاهش یابد. آیا این کار فکر خوبیست؟
تصمیم‌گیری درباره چنین مسایلی فراتر از مرزهای پروژه می‌رود و باید در سطوح مدیریتی مناسب با دید کلان و همه‌جانبه انجام شود. آنچه از لایه مدیریت پروژه انتظار داریم، شناسایی چنین فرصت‌هایی و گزارش دادن آن‌ها به لایه‌های تصمیم‌گیرنده است.
قرار بود به جلسه‌ای برویم و دیر شده بود. وقتی سوار ماشین شدیم، مشغول تنظیم GPS بودم که همکارم گفت «زود باش، دیر شده، وقت نداریم». با این‌همه، از این رو مشغول تنظیم GPS بودم که دیر شده بود و وقت نداشتیم. به کمک GPS می‌توانستیم از مسیرهایی که ترافیک سنگین موردی دارند دوری کنیم و سریع‌تر به مقصد برسیم.
برنامه‌ریزی هم این‌چنین است. کمبود وقت دلیلی برای برنامه‌ریزی نکردن نیست، بلکه دلیلی برای برنامه‌ریزی کردن است.
همه پروژه‌ها نیاز به برنامه‌ریزی دارند. برخی گمان می‌کنند پروژه‌های چابک نیاز به برنامه‌ریزی ندارند، ولی این‌چنین نیست؛ فقط برنامه‌ریزی آن‌ها با پروژه‌های متعین متفاوت است:
همه کارهایمان باید هدفمند باشند. برنامه‌ریزی با دو هدف کلی انجام می‌شود:
چگونگی هدایت پروژه به شیوه ساخت محصول بستگی دارد و ارزیابی وضعیت پروژه به متدولوژی مدیریت پروژه. برنامه‌ریزی مفهومی مستقل نیست و نمی‌توان درباره کیفیت برنامه مستقل از شیوه ساخت محصول و متدولوژی مدیریت پروژه قضاوت کرد. شاید برنامه‌ای برای یک بستر مناسب و برای بستری دیگر نامناسب باشد.
مستقل از این‌که از چه روشی برای ساخت محصول استفاده می‌کنید، برنامه‌ریزی باید مستمر باشد. برخی گمان می‌کنند که می‌توان در آغاز پروژه برنامه‌ای آماده کرد، نسخه‌ای از آن را چاپ و بر دیوار نصب کرد و تا پایان پروژه دست از کار برنامه‌ریزی کشید. برنامه‌ای که دایما بازبینی نشود به‌سرعت کاربرد خود را از دست می‌دهد، زیرا با این‌که اجرا بر پایه برنامه قرار است انجام شود، عدم‌قطعیت‌های اجرایی همیشه تفاوت‌هایی به وجود می‌آورند. این تفاوت‌ها را باید در برنامه بازتاب داده، آن را بازبینی کرد.
هر متدولوژی زمان مناسب و روند برنامه‌ریزی را توضیح می‌دهد، ولی گاهی محتوای برنامه‌هایشان چندان روشن نیست.
نسخه‌های پیشین پم‌باک مجموعه‌ای از حوزه‌های دانش داشتند که از برخی جهات مانند حوزه‌های عملکردی نسخه هفتم (موضوع این فصل) بودند، ولی یکسان نیستند. به نظر من حوزه‌های دانش دسته‌بندی بسیار خوبی برای شرح آنچه قرار است برنامه‌ریزی شود هستند:
این دسته‌بندی یکی از انواع دسته‌بندی است که می‌توانید در نظر داشته باشید. همه این موارد باید به‌نوعی در برنامه‌هایتان وجود داشته باشند. متدولوژیتان احتمالا همگی را پوشش دهد، ولی شاید برخی از این جنبه‌های پروژه‌تان حساس‌تر باشند و بنابراین نیاز باشد که آن‌ها را بسته به پیش‌فرضی که در متدلوژی وجود دارد قوی‌تر کنید.
فراموش نکنید که برنامه زمان‌بندی فقط یکی از این ۱۲ مورد است.
برنامه‌ریزی باید گستره، زمان، هزینه، کیفیت، منابع، ریسک و سایر حوزه‌ها را پوشش دهد. با این‌همه، زمان‌بندی یکی از عناصر مهم و مرکزی در برنامه‌ریزیست و معمولا موردی که چالش‌های ویژه خود را دارد و از این‌رو بیشتر از دیگر حوزه‌ها به آن پرداخته شده است.
زمان‌بندی به معنی تخصیص زمان آغاز و پایان یا ترتیب اجرا به فعالیت‌های پروژه است.
دو نوع زمان‌بندی می‌توان داشت:
فعالیت‌های بسیاری از پروژه‌ها وابستگی‌هایی ذاتی و گریزناپذیر به همدیگر دارند. برای نمونه، تا وقتی دیواری ساخته نشده باشد نمی‌توانید آن را رنگ کنید. چنین پروژه‌هایی را باید به شیوه وابستگی محور برنامه‌ریزی کرد. برای این کار شبکه‌ای از روابط میان فعالیت‌ها ساخته می‌شود و اطلاعاتی دیگر مانند مدت‌زمان آن‌ها نیز درج می‌شود. پس از آن با روش مسیر بحرانی (critical path method) و همانند آن تاریخ‌های آغاز و پایان به دست می‌آیند. نرم‌افزارهایی مانند پریماورا و مایکروسافت پراجکت نمونه‌هایی از ابزارهای رایج در این نوع برنامه‌ریزی‌اند.
فعالیت‌های برخی پروژه‌ها را می‌توان به شکلی ساخت که به هم وابسته نباشند. در این حالت می‌توانید آن‌ها را با روشی اولویت محور زمان‌بندی کنید. در این روش، اولویت هر فعالیت بر پایه مجموعه‌ای از پارامترها مانند ارزش و ریسک تعیین می‌شود و سپس فهرست فعالیت‌ها بر آن پایه مرتب می‌شود. نرم‌افزارهایی مانند ترلو بر این پایه عمل می‌کنند.
پروژه‌های تطبیقی فقط با زمان‌بندی‌های اولویت محور کار می‌کنند و اگر به نظرتان می‌آید که زمان‌بندی پروژه‌تان را نمی‌توانید به شیوه اولویت محور بسازید به این معنیست که محصول پروژه برای ساخت تطبیقی مناسب نیست.
پروژه‌های متعین می‌توانند از هر دو شیوه زمان‌بندی استفاده کنند. در این نوع پروژه‌ها حتی امکان ترکیب این دو حالت نیز وجود دارد: می‌توانید سطوح بالاتر برنامه را وابستگی محور و سطوح پایین‌تر را اولویت محور بسازید.
دو لایه برنامه‌ریزی وجود دارد:
محصول این دو لایه را می‌توان به ترتیب برنامه و متابرنامه نامید. برای نمونه، برنامه ریسک فهرستی از ریسک‌های شناسایی شده و واکنش‌هاییست که برایشان طراحی کرده‌اید. این برنامه می‌تواند در صفحه‌گسترده‌ای در اکسل و نرم‌افزارهای همانند آن باشد و فهرست ریسک (risk register) نامیده شود. از سوی دیگر، متابرنامه ریسک سندیست که شیوه مدیریت ریسک را توضیح می‌دهد: تکنیک‌هایی که استفاده می‌کنید، جریان کار، اسناد، و …
هر متدولوژی شیوه مدیریت هرکدام از حوزه‌ها را توضیح می‌دهد و اینگونه بخشی از متابرنامه‌ها در متدولوژی وجود دارد، ولی همه جنبه‌ها را نمی‌توان در متدولوژی لحاظ کرد و از این رو گاهی پیشنهاد می‌شود که برای هر حوزه متابرنامه‌ای نیز بسازید.
معمولا متدولوژی‌هایی مانند پرینس۲، که نیاز به اختصاصی‌سازی نخستین دارند، ساخت متابرنامه‌ها را نیز پیشنهاد می‌کنند، ولی آن‌هایی که مانند P3.express نیاز به اختصاصی‌سازی نخستین ندارند چنین پیشنهادی نیز نمی‌کنند. با این‌همه، حتی در مورد دوم هم اگر حوزه‌ای وجود دارد که حساسیت‌های ویژه‌ای در پروژه دارد، بهتر است برایش در آغاز متابرنامه آماده کنید. برای نمونه، اگر تدارکات پروژه چالش‌برانگیز است، شیوه برنامه‌ریزی، ارزیابی و کنترل آن را تعیین کرده، در سندی با نام برنامه مدیریت تدارکات یا استراتژی مدیریت تدارکات ثبت کنید.
معمولا متابرنامه‌های پروژه‌هایی که در یک سازمان اجرا می‌شوند همانندی‌های فراوانی دارند. از این رو، متابرنامه‌ای که در یک پروژه ساخته شده باشد برای سایرین نیز می‌تواند کارآمد باشد و بنابراین بهتر است برای هر پروژه از صفر آماده نشود. می‌توان متابرنامه‌های کلان را در مرکزی در سازمان آماده و نگهداری کرد و برای همه پروژه‌های تازه فرستاد. در زمان استفاده از آن‌ها در پروژه‌ها ایده‌های بهبودی نیز شکل می‌گیرند و می‌توان آن‌ها را به مرکز فرستاد تا در متابرنامه‌های عمومی بازتاب یافته، در همه پروژه‌ها تسری پیدا کنند.
آنچه در بالا شرح داده شد همان مرحله نخستین اختصاصی‌سازی است که پیش از این مطرح شده بود: اختصاصی‌سازی متدولوژی در سطح سازمان.
مرکزی که متابرنامه‌ها را تدوین و نگهداری می‌کند را می‌توان مرکز تعالی (center of excellence) نامید. برخی هم آن را PMO می‌نامند (مخفف project management office یا عبارتی مشابه آن).
نخست برنامه‌ریزی و سپس اجرا می‌کنیم. همه پروژه‌ها اینگونه هستند:
یکی از مسایل مهم در اجرای پروژه، توازن میان اجرا و برنامه‌ریزیست. پروژه‌های مختلف به یکی از شکل‌های زیر اجرا می‌شوند:
هرگاه برنامه را بر پایه واقعیت‌ها بازبینی می‌کنید، تغییر شکل داده، اطلاعات تازه‌ای ارائه می‌کند. این اطلاعات برای ارزیابی‌ها (موضوع حوزه بعدی) به کار می‌روند و بر آن پایه اقدام‌های اصلاحی و پیشگیرانه طراحی خواهید کرد.
همکنش و توازن میان برنامه‌ریزی و اجرا به چه شکلی در متدولوژیتان بازتاب یافته است؟ اگر عدم‌قطعیت‌های پروژه‌تان بیشتر از میانگین پروژه‌ها باشد، شاید لازم باشد به این حوزه توجه بیشتری کرده، آن را در متدولوژی خود تقویت کنید.
حد مناسبی از تفصیل برای برنامه‌هایی که در لایه مدیریت پروژه آماده می‌کنید وجود دارد و بهتر است باقیمانده جزئیات را به تیم‌اجرایی بسپارید تا خود به‌گونه‌ای ضمنی یا غیرضمنی برنامه‌ریزی کنند. با این کار هم حق انتخاب بیشتری به تیم‌ها می‌دهید که مانع از جبهه‌گیری‌های منفی می‌شود و هم برنامه‌های اصلی را ساده‌تر و کاراتر نگه می‌دارید.
برای نمونه، پرینس۲ برنامه‌ای کلان دارد که در آغاز پروژه ساخته می‌شود. سپس برای هر دوره برنامه‌ای کمابیش تفصیلی برای همان دوره تنظیم می‌شود. جزئیات کامل در برنامه سومی قرار دارد که ساخت و نگه‌داری‌اش بر دوش تیم‌های اجراییست و نه مدیر پروژه.
نکته پایانی این است که باوجود پافشاری فراوانی که بر اهمیت برنامه‌ریزی داشته‌ایم، نباید تصور کنید که همه‌چیز باید برنامه‌ریزی شود. عناصر کم‌اهمیت پروژه را می‌توان به طور موردی و بیرون برنامه‌ها هدایت کرد.
در حال اجرای پروژه با انواع اقلام قابل‌پیگیری (follow-up item) روبرو خواهید شد که باید آن‌ها را ثبت و مدیریت کنید. منظور از اقلام قابل‌پیگیری، عناصر زیر است:
فرقی نمی‌کند که پروژه تا چه اندازه ساده و کوچک باشد، بازهم باید این موارد را به محض شناسایی ثبت کرد، وگرنه هم امکان فراموش‌کاری وجود دارد و هم این‌که به خاطر سپردن آن‌ها بی‌دلیل بخشی از توان ذهنی‌تان را صرف خود خواهد کرد. پس از ثبت باید آن‌ها را پیگیری کرد، تا زمانی که بسته شوند.
در P3.express یک سند با نام فهرست پیگیری (follow up register) برای همه این موارد وجود دارد، ولی بسیاری از متدولوژی‌ها اسناد جداگانه‌ای برای این موارد دارند. در این متدولوژی، هر عنصری در این سند نیاز به یک متولی (custodian) دارد که وضعیت آن را پیگیری کرده، گزارش دهد. همانند آن، هرکدام از تحویل‌شدنی‌های پروژه نیز باید یک متولی داشته باشند.
برنامه‌ها دو کاربرد دارند:
اجرا بر پایه برنامه‌ها انجام می‌شود، ولی هیچ‌وقت انطباق کاملی وجود ندارد. از این رو، باید برنامه‌ها را دایما بر پایه واقعیت‌های اجرایی بازبینی کرد تا برای هدایت ادامه کار کاربرد داشته باشند. هنگامی که برنامه‌ها بازبینی می‌شوند، شاید متغیرهای پروژه مانند زمان تغییر کنند. برای نمونه، شاید تازه‌ترین پیشبینی برای پروژه‌ای که قرار بود ۲۲ ماهه به پایان برسد این باشد که در ۲۴ ماه به پایان خواهد رسید. در این حالت چه باید کرد؟
هرگاه تفاوت اجرا و برنامه انحرافی در متغیرهای پروژه مانند زمان و هزینه ایجاد کند، یا باید متغیرها را بازبینی کرد یا انحراف‌ها را از بین برد. هر متدولوژی روند ویژه‌ای برای این کار دارد. معمولا هنگامی که اثر انحراف از حدی کمتر باشد، اعضای تیم یا رهبران تیم‌ها برای انحراف تصمیم می‌گیرند، اگر اثر از حد آن‌ها بالاتر باشد مدیر پروژه، وگرنه حامی پروژه و افراد دیگر در لایه‌های بالاتر سازمان.
بسیاری از متدولوژی‌ها حدود تصمیم‌گیری دارند، ولی بسیاری برداشت اشتباهی درباره آن‌ها دارند. برای نمونه، حدود تصمیم‌گیری در پرینس۲ تلورانس نامیده می‌شوند، و بسیاری گمان می‌کنند که این تلورانس‌ها مانند تلورانس‌های مهندسی هستند و مشخص می‌کنند که چه مواردی نیاز به تصمیم‌گیری دارند و اگر اثر موردی کمتر از تلورانس باشد نیاز به اصلاح نخواهد داشت. چنین برداشتی درست نیست: هر انحرافی نیاز به اصلاح دارد و تلورانس‌ها فقط مشخص می‌کنند که چه کسی باید تصمیم‌گیری کند.
همیشه بهتر است انحراف‌ها در زودترین زمان اصلاح شوند، زیرا هرچه بیشتر روی هم انباشته شوند اصلاح کردنشان دشوارتر خواهد شد.
وقتی انحرافی وجود دارد، باید برایش اقدامی اصلاحی طراحی کنید. افزون بر آن، لازم است که اقدامی پیشگیرانه نیز طراحی کنید که احتمال بروز مشکل‌های همانندش را در آینده کم کند. متاسفانه بسیاری فقط به اقدام‌های اصلاحی توجه می‌کنند و نه پیشگیرانه.
اگر به هر دلیلی لازم باشد که میان اقدام اصلاحی و اقدام پیشگیرانه تنها یکی را انتخاب کنید، انتخاب درست، اقدام پیشگیرانه خواهد بود. اگر غیر از این عمل کنید، همیشه با انبوهی از دشواری روبرو خواهید بود و هیچ زمانی برای کارهای زیربنایی نخواهید داشت.
روند مناسب در رویارویی با هر انحرافی این‌چنین است:
نگاهی به متدولوژی خود بیندازید و ببینید که این دو مسئله چگونه پوشش داده شده‌اند. اگر گمان می‌کنید ممکن است طراحی اقدام‌های پیشگیرانه را فراموش کنید و این موضوع در متدولوژی به‌اندازه کافی روشن نیست، آن جنبه را تقویت کنید تا از قلم نیفتد.
یکی از معیارهای مهم در ارزیابی وضعیت پروژه، توجیه‌پذیری آن است. دایما باید این مسئله را کنترل کنید و هرگاه پروژه توجیه‌پذیری خود را از دست داد مسئله را به حامی پروژه اطلاع دهید.
متدولوژیتان احتمالا کنترل‌هایی دوره‌ای برای توجیه‌پذیری پروژه دارد. اگر اینگونه نیست، لازم است آن را بیفزایید.
درباره متغیرهای پروژه چه باید کرد؟
متغیرهای پروژه جنبه‌هایی مانند گستره، زمان، هزینه، و کیفیت هستند. برخی منابع متغیرهای دیگری مانند مجموع ریسک و منافع را نیز اضافه می‌کنند. همه این متغیرها را باید دایما ارزیابی کرد و توجیه‌پذیری پروژه معمولا ترکیبی از همه آن‌هاست.
هریک از متغیرهای پروژه‌تان تا چه اندازه حساسند؟ برای نمونه، اگر قرار است مجموعه‌ای بسازید که برای همایشی ملی به کار برود، هیچ‌گونه تاخیری پذیرفتنی نخواهد بود و نیاز به کنترل‌های دقیق‌تری برای زمان خواهید داشت. در چنین مواردی، کنترل‌های لازم را در متدولوژی خود تقویت کنید.
چگونه وضعیت پروژه را ارزیابی می‌کنید؟
در گذشته رایج بود که پیشرفت پروژه‌های نرم‌افزاری را بر پایه تعداد خط برنامه‌ای که نوشته شده است بسنجند. زمانی شرکتی برنامه‌نویس بسیار خبره‌ای را استخدام کرد و در پایان ماه از او خواستند که تعداد خط برنامه‌ای که نوشته است را اعلام کند. مقداری که گزارش کرده بود عددی منفی بود! او در مدت ماه مشغول بررسی کدهای پیشین و اصلاح آن‌ها بود و در بسیاری موارد کدهای تکراری یا اضافه را پاک کرده بود. کار این فرد کمک فراوانی به پروژه کرده بود، ولی با معیار ارزیابی موجود اینگونه برداشت نمی‌شد.
این شیوه ارزیابی پیشرفت، که به وضوح کارایی مناسبی ندارد، امروزه چندان رایج نیست. دلیل اصلی برای از بین رفتن این روش، رواج شیوه‌های چابک و مخالفت آن‌ها با این نوع ارزیابی است. شیوه‌های رایج ارزیابی در پروژه‌های چابک کارایی نسبتا مناسبی دارند، ولی متاسفانه آن‌ها نیز به شکل دیگری منحرف شده‌اند. برای نمونه، در بسیاری از این روش‌ها فهرستی از کارها برای دوره پیش رو انتخاب می‌شوند. در برخی پروژه‌ها شمار کارهای تکمیل شده در پایان دوره را با آنچه انتخاب شده بود مقایسه می‌کنند و این مسئله برایشان معیار ارزیابی مهمیست. این معیار درست نیست، زیرا برنامه‌نویسان را تشویق می‌کند که در آغاز دوره کارهای کمتری را انتخاب کنند و آن هم به نوبه خود منجر به کاهش خروجی می‌شود، زیرا «کار به اندازه زمانی که در اختیار دارید منبسط می‌شود» (اصل پارکینسون).
همیشه به یاد داشته باشید که شیوه ارزیابی عملکرد بر عملکرد اثر می‌گذارد، زیرا اعضای تیم پروژه می‌کوشند با تغییر روند کاری خود کاری کنند که در ارزیابی‌ها موفق‌تر جلوه کنند.
ارزیابی هدف واقعی پروژه و ارزش آفریده شده به دلیل انتزاعی بودنشان کاری ساده و عملی نیست. از این رو، به‌جای ارزیابی هدف یا اهداف اصلی، متغیرهای پروژه را ارزیابی می‌کنیم. این کار ایده‌آل نیست، ولی نزدیک‌ترین تقریب برای اهداف است. در مراحل بعد، سیستم مدیریت پرتفولیو می‌تواند بر پایه این داده‌ها ارزیابی‌های پیچیده‌تری روی توجیه‌پذیری و ارزش پروژه انجام دهد.
مشکل رایج در پروژه‌های متعین این است که خروجی ارزیابی‌ها مقادیری انتزاعی از متغیرهای پروژه، مانند پیشرفت واقعی و برنامه‌ریزی شده دوره‌ای و تجمعی هستند. این داده‌ها در فرآیند ارزیابی لازمند، ولی خروجی مناسبی نیستند. مسئول ارزیابی باید با کمک برنامه‌ها و این داده‌ها وضعیت متغیرهای پروژه را برای زمان پایان پیشبینی کند؛ برای نمونه، «اگر اینگونه پیش برویم، پروژه دو ماه دیرتر از زمان مقرر و با هزینه‌ای معادل ۲۵ هزار پیتزا بیشتر از انتظار نخستین پایان خواهد یافت.»
اگر در پروژه‌های متعین فعالیت می‌کنید، با شیوه تحلیل زمان کسب شده (earned schedule analysis) آشنا شوید. این روش بهترین گزینه برای پیشبینی زمان پایان پروژه است.
پس از ارزیابی وضعیت پروژه، باید نتیجه را به برخی از ذی‌نفعان گزارش کنید. اعضای تیم باید از وضعیت پروژه آگاه باشند تا بتوانند کار خود را بر آن پایه اصلاح کنند. برخی لایه‌های مدیریتی سازمان هم باید از وضعیت پروژه باخبر باشند. اگر کارفرمایی بیرون سازمان داشته باشید هم بی‌گمان از شما انتظار گزارش خواهد داشت.
در بیشتر مواقع نمی‌توان با فقط یک نوع گزارش با همه ذی‌نفعان ارتباط مناسب برقرار کرد. برخی نیاز به اطلاعات فنی و برخی مدیریتی دارند. برخی نیاز به اطلاعات تفصیلی دارند و برخی کلان. چند نوع گزارش که برای پاسخگویی به همه نیازها کافی باشد طراحی کنید و در فهرست ذی‌نفعان هم مشخص کنید که هر فرد قرار است چه نوع گزارشی دریافت کند. پس از فرستادن گزارش، با ذی‌نفعان گفتگو کرده، کارآمدی گزارش را ارزیابی کنید. باید دایما به دنبال یافتن راه‌هایی برای بهبود گزارش‌های خود باشید.
ذی‌نفعان به درجه‌های مختلفی گرفتار هستند و بسیاری از آن‌ها صبر و حوصله ندارند. از این رو، گزارش‌های خلاصه و سرراست کارآمدتر هستند. برخی از ذی‌نفعانتان پافشاری خواهند کرد که گزارش‌های تفصیلی برایشان بفرستید، ولی حتی در آن حالت هم گزارشی تک‌صفحه‌ای به آن پیوست کنید، زیرا هنگامی که گزارش تفصیلی درخواست می‌کنند بیشتر از این روست که مطمئن باشند زیرساخت و توانایی کافی را برای ارزیابی پروژه دارید، ولی طولانی بودن گزارش باعث می‌شود که در مطالعه آن سهل‌انگاری کنند. وجود گزارش تک‌صفحه‌ای در کنار گزارش تفصیلی این مشکل را حل خواهد کرد.
هیچ الزامی ندارد که همه گزارش‌هایتان کاغذی باشند. گاهی بهتر است که گزارش بر روی تخته‌های بزرگ در محل پروژه قرار داشته باشد. اگر ذی‌نفعان هم‌محل نیستند، به جای تخته فیزیکی می‌توان از داشبوردهای اینترنتی استفاده کرد. چنانچه از این شیوه ارتباطی استفاده می‌کنید، باید مطمئن باشید که ذی‌نفعان وجود داشبورد را فراموش نمی‌کنند و از پروژه باخبر می‌مانند؛ برای نمونه، می‌توانید پس از هر به‌روزرسانی ایمیلی فرستاده، وجود نسخه تازه را اعلام کنید.
داستانی از یک سازنده آسانسور وجود دارد: مشتریان از کندی آسانسورها ناراضی بودند. سازنده پروژه‌های مختلفی برای افزایش سرعت محصول اجرا کرده بود و مشتریان همچنان ناراضی بودند. روزی برآن بودند که پروژه دیگری برای افزایش سرعت آغاز کنند که یکی از اعضای تیم گفتگوی جالبی را آغاز کرد:
پس از مدتی بررسی، به‌جای تغییر دادن سرعت آسانسور، فقط آیینه‌ای در آسانسور نصب کردند. اینگونه حواس مسافران به سر و وضع خودشان می‌رفت و این مشغولیت باعث می‌شد که گذشت زمان را کمتر احساس کنند. نکته جالب این است که پس از نصب آیینه، بسیاری از افراد گمان کردند که سرعت آسانسور بیشتر شده است.
بیشتر افراد در پاسخ به نیازها یا مشکل‌ها بی‌درنگ نخستین راهکار «بدیهی» را انتخاب می‌کنند. اگر زمان بیشتری صرف درک مشکل و نیاز کنیم و راهکارهای گوناگون را بسنجیم، معمولا می‌توانیم گزینه‌های بهتری بیابیم. برای همین چنین روندی در همه متدولوژی‌ها وجود دارد:
الزامات ← تحویل‌شدنی‌ها ← فعالیت‌ها
گام نخست، شناسایی الزامات است؛ هم الزامات واضح و هم پنهان. بسیاری از الزامات از سوی کارفرما هستند، ولی معمولا آنچه به شما می‌گویند واقعا الزام پروژه نیست، بلکه راهکاری «بدیهی» است برای الزامی که در ذهن داشته‌اند. از این رو، باید با آن‌ها گفتگو کنید تا بتوانید الزامات واقعی را استخراج کنید. از سوی دیگر، معمولا بیش از یک نماینده از سوی کارفرما وجود دارد و الزاماتی که در اختیارتان می‌گذارند شاید با یکدیگر هماهنگ نباشند که در این حالت هم باید به شکل‌های گوناگون رفع اختلاف کنید و به مجموعه‌ای سازگار از الزامات برسید. بسته به نوع محصول پروژه و محدوده مسئولیت‌هایتان، شاید بهتر باشد به آنچه از نمایندگان کارفرما می‌شنوید نیز کاملا اعتماد نکنید و با شماری از کاربران نهایی که در آینده از محصول استفاده خواهند کرد هم گفتگو کنید.
افزون بر کارفرما، سازمان خودتان هم چه‌بسا الزاماتی برای همه پروژه‌ها داشته باشد که باید در نظرشان بگیرید. شاید آیین‌نامه‌های مختلفی هم برای نوع پروژه‌تان وجود داشته باشند که الزاماتی را حکم کنند.
همیشه باید کارتان را با درک الزامات آغاز کنید و پس از آن به سراغ تحویل‌شدنی‌ها و در پایان فعالیت‌ها بروید. پروژه‌های متعین و تطبیقی از این دیدگاه تفاوتی با هم ندارند: زمان اجرای این فرآیندها در آن‌ها یکسان نیست، ولی ترتیب فرآیندها یکسان است.
فرض کنید درگیر انجام پروژه‌ای نرم‌افزاری هستید و یکی از ذی‌نفعان به شما مراجعه می‌کند و می‌گوید که نیاز به قابلیت تازه‌ای دارند که با کمک آن نیروهای پشتیبانی سایت بتوانند بدون دانستن پسورد کاربران به‌جای آن‌ها لاگین کنند. چه خواهید کرد؟
آنچه به شما گفته‌اند درباره یک تحویل‌شدنی است، ولی می‌دانیم باید کارمان را با الزامات آغاز کنیم. پس نخستین کار این است که درباره این قابلیت با آن‌ها گفتگو کنید و درک کنید که نیاز واقعی‌شان چیست. پس از آن، به راهکارهای مختلف بیندیشید و با همکاری آن‌ها بهترین گزینه را انتخاب کنید.
روند رایج در پروژه‌های چابک این است که قابلیت‌ها در قالب user story ارائه شوند؛ برای نمونه: «به‌عنوان نیروی پشتیبانی سایت، می‌خواهم بدون در اختیار داشتن پسورد کاربران از طرف آن‌ها در سایت لاگین کنم تا وضعیت حساب و دسترسی‌هایشان را از زاویه دید خودشان ببینم و مشکل را به‌سرعت حل کنم، بدون این‌که ده‌ها پیام و تصویر از صفحه کاربر ردوبدل شود.»
این قالب بسیار مفید است، زیرا بخش پایانی آن هدف را توضیح می‌دهد و الزامی که در پس قابلیت بوده در هدف مستتر است. این قالب کمابیش مخاطب را تشویق می‌کند که به راهکارهای دیگر هم بیندیشید. افزون بر آن، به تدقیق قابلیت هم کمک می‌کند. برای نمونه، با خواندن متن بالا متوجه می‌شویم که نیازی نیست که نیروهای پشتیبانی بتوانند به‌جای مدیران سایت و سایر کاربران لاگین کنند و نیاز فقط برای مشتریان است.
آیا متدولوژیتان به اندازه کافی به الزامات پروژه اولویت می‌دهد؟ اگر این جنبه واضح یا قوی نیست، شاید بهتر باشد آن را بهبود دهید.
تحویل‌شدنی‌های بسیاری از پروژه‌ها به اندازه‌ای پرشمارند که اگر در فهرستی ساده و تک‌سطحی قرار داده شوند فهرست آنقدر بلند می‌شود که قابل استفاده نخواهد بود. راهکار معمول در چنین مواقعی، دسته‌بندی کردن آیتم‌های فهرست است و برای تحویل‌شدنی‌ها نیز می‌توان چنین کاری کرد. به‌جای یک سطح دسته‌بندی هم می‌توانید چندین سطح داشت که اصلاحا سلسله‌مراتبی نامیده می‌شود.
بسیاری از متدولوژی‌های مدیریت پروژه استفاده از دسته‌بندی‌های سلسله مراتبی را پیشنهاد می‌کنند. در چنین دسته‌بندی‌هایی محصول اصلی پروژه به چند تحویل‌شدنی کلان تقسیم می‌شود، هرکدام از آن‌ها به چند تحویل‌شدنی کوچک‌تر و روند به همین ترتیب ادامه پیدا می‌کند تا به جزئی‌ترین تحویل‌شدنی‌ها برسیم.
این دسته‌بندی‌های سلسله‌مراتبی نام‌های مختلفی دارند:
به‌کارگیری چنین ساختارهایی بسیار کارآمد است، ولی بازهم باید توجه داشته باشید که لیست‌های تک سطحی برای پروژه‌های بسیار کوچک کافی و مناسب‌تر هستند. از این رو، در متدولوژی micro.P3.express، که نسخه ویژه‌ای از P3.express برای پروژه‌های بسیار کوچک است، وجود نقشه تحویل‌شدنی‌ها الزامی نیست.
دیر یا زود، محصول نهایی پروژه، شامل همه تحویل‌شدنی‌هایش، به کارفرما تحویل می‌شود و در اختیار کاربران نهایی قرار می‌گیرد. با این‌همه، زمان، چگونگی، و بسامد تحویل همیشه یکسان نیست:
پروژه‌ای که نتواند نسخه‌های قابل استفاده محصول را بسازد نمی‌تواند تطبیقی باشد. فراموش هم نکنید که هر نسخه قابل استفاده مجموعه‌ای از تحویل‌شدنی‌هاست، ولی هر مجموعه‌ای از تحویل‌شدنی‌ها نسخه‌ای قابل استفاده نیست.
تحویل یک‌باره در پایان پروژه ریسک‌های فراوانی دارد، زیرا اگر عنصری از پروژه مناسب نباشد و در زمان تحویل کشف شود، اصلاحش می‌تواند بسیار پرهزینه باشد. پروژه‌های تطبیقی که تحویل تدریجی دارند چنین ریسکی ندارند، اما در پروژه‌های متعین باید مراقب آن بود.
با این‌که در بسیاری از پروژه‌های متعین نمی‌توان تحویل در میانه کار داشت، بازهم می‌توان روندی دوره‌ای برای بررسی وضعیت تازه محصول و دریافت تاییدی ضمنی از کارفرما داشت. این مسئله چنان مهم است که بسیاری از متدولوژی‌ها روندی برای این منظور دارند. اگر متدولوژیتان چنین جنبه‌ای را پوشش نداده باشد، بهتر است آن را بیفزایید، به‌ویژه اگر پیشبینی می‌کنید که میان کارفرما و پیمانکار اختلاف‌نظر به وجود خواهد آمد.
در هر زمان شماری تحویل‌شدنی نیمه‌کاره در پروژه وجود دارد. برخی پروژه‌ها حساسیتی به خرج نمی‌دهند و تحویل‌شدنی‌های پرشماری را به‌موازت هم پیش می‌برند که باعث افت بهره‌وری کلی پروژه می‌شود.
محدود کردن کار نیمه‌کاره یکی از اصل‌های زیربنایی در تولید Lean است، که تاثیر بزرگی هم در پروژه‌های چابک گذاشته است. با این‌همه، کاربرد آن محدود به پروژه‌های چابک نیست و در همه پروژه‌ها باید به آن توجه داشت.
یکی از مسایل اصلی درباره افزایش بیش از اندازه شمار کارهای موازی این است که وقتی چنین فرهنگی در پروژه وجود داشته باشد، هرگاه اعضای تیم در ساخت تحویل‌شدنی‌ای به دشواری بر بخورند به‌جای گره‌گشایی به سراغ انجام تحویل‌شدنی دیگری می‌روند که خروجی کارشان به ظاهر بالاتر باشد. هرچه بیشتر از زمان بروز دشواری بگذرد، حلش سخت‌تر می‌شود و از این رو چنین روندی مناسب نیست. همیشه به یاد داشته باشید که هدف زودتر آغاز کردن کارها نیست، بلکه زودتر به پایان رساندن آن‌هاست.
برخی از متدولوژی‌ها عناصری دارند که تیم پروژه را تشویق می‌کند که تحویل‌شدنی‌های نیمه‌کاره را به سرانجام برسانند و پس از آن دست به کار تحویل‌شدنی‌های تازه بشوند. چنین عنصری را می‌توان به روندی ضمنی برای دریافت تایید نیز متصل کرد که خود مانع بروز بسیاری از دشواری‌های زمان تحویل نهایی می‌شود و در بخش گذشته بررسی شد. اگر متدولوژیتان چنین جنبه‌ای را پوشش نداده باشد، بهتر است آن را اضافه کنید.
توجه داشته باشید که آنچه گفته شد به معنی حذف کار موازی نیست، بلکه به معنی بهینه‌سازی آن است. هر پروژه‌ای نیاز به حدی از کار موازی دارد و حد مناسب بستگی به شرایط و محصول پروژه، افراد مشغول به کار، و بسیاری عناصر دیگر دارد. با این‌همه، حد بهینه معمولا بسیار پایین‌تر از آن است که بسیاری می‌پندارند.
همانگونه که گفته شد، بهتر است روندی برای تیم پروژه وجود داشته باشد که به‌جای کار روی انبوهی از تحویل‌شدنی‌ها، روی شمار اندکی کار کرده، آن‌ها را به سرانجام برساند. بهتر است مدیر پروژه کارهای پایان یافته را بررسی و تایید نیز بکند.
تایید تحویل‌شدنی‌ها بر پایه گستره و کیفیت آن‌هاست. باید پیش از آغاز به کار روی تحویل‌شدنی‌ها از نیروهای فنی پروژه کمک بگیرید و گستره و کیفیت تحویل‌شدنی‌ها را بر پایه الزامات و نیازهای ذی‌نفعان تعیین کنید. پس از این‌که کار به پایان رسد، بر پایه همان تعریف نخستینی که به کمک اعضای تیم شده بود کارشان را بررسی خواهید کرد. این بررسی به مفهوم نظارتی از بالا به پایین و با هدف خرده‌گیری نیست، بلکه کمکی دوستانه است از سوی فردی که شاید حتی فنی هم نباشد تا با نگاهی تازه، کمی دورتر از کار به آن بنگرد و تفاوت احتمالی آن را با آنچه افراد فنی در نظر داشته‌اند بسنجد و کمبودهای احتمالی را مشخص کند.
جلوگیری از بروز دشواری‌های بنیادین در زمان تحویل نهایی، افزایش بهره‌وری کار با محدود کردن کارهای موازی، و بسیاری دیگر از عناصر مفید پروژه مستلزم تعیین گستره و کیفیت تحویل‌شدنی‌ها پیش از ساخت است. پرینس۲ برای این کار سندی به نام شرح محصول دارد («محصول» در اینجا به معنی تحویل‌شدنی است) و P3.express این مشخصات را به شکل یادداشت در نقشه تحویل‌شدنی‌ها لحاظ می‌کند. متدولوژی خود را بررسی کنید تا ببینید برای این کار چه عناصری در نظر گرفته است و اگر برای شرایط پروژه کافی نیست، آن را اضافه یا اصلاح کنید.
پروژه‌های چابک معمولا اقلام کاری را بر روی کارت‌های کوچک می‌نویسند و اطلاعات تکمیلی درباره گستره و کیفیت را در پشت کارت درج می‌کنند. تحویل‌شدنی‌های پروژه‌های نرم‌افزاری بسیار یکدست‌تر از بسیاری پروژه‌های دیگر هستند و از این رو کیفیت و سایر شرایط پذیرششان اشتراک‌های فراوانی دارند. بنابراین، بسیاری از پروژه‌های چابک به‌جای تکرار آن شرایط برای همه اقلام، اشتراک‌ها را جدا کرده، در سندی که می‌تواند definition of done نامیده شود ذخیره می‌کنند. این ترفند بسیار کارآمد است و شاید بتوانید آن را به نوعی در پروژه‌های غیرچابک نیز به کار ببرید؛ برای نمونه، شاید بتوانید بسیاری از تحویل‌شدنی‌ها را بر پایه همانندی‌های الگوی پذیرششان در چند گروه تقسیم کرده، برای هر گروه الگوی پذیرش مشترکی تدوین کنید.
عدم‌قطعیت مباحث فراوانی دارد، ولی مهم‌ترین جنبه آن در مدیریت پروژه، مدیریت ریسک است.
همانگونه که پیشتر به آن اشاره شد، برای مدیریت مناسب ریسک باید روندی کارا برای شناسایی، تحلیل، و برنامه‌ریزی واکنش به ریسک داشته باشیم و سپس واکنش‌ها را اجرا کرده، اثربخشی آن‌ها و سایر تغییرهای احتمالی در وضعیت ریسک را پایش کنیم.
سیستم مدیریت ریسک را با میزان پیچیدگی متفاوتی می‌توان پیاده‌سازی کرد. برای نمونه، در سیستم مینیمالیستی P3.express یک سند به نام فهرست پیگیری وجود دارد که برای ذخیره‌سازی اطلاعات ریسک‌ها، مسایل، درخواست‌های تغییر، برنامه‌های بهبود، و درس آموخته‌ها به کار می‌رود. این رویکرد که با رویکرد بسیاری از متدولوژی‌ها متفاوت است به دو دلیل انتخاب شده است:
چنین روشی برای بسیاری از پروژه‌ها مناسب‌تر از روش‌های پیچیده است، ولی، چه‌بسا در پروژه‌های بسیار بزرگ پاسخگو نباشد و لازم باشد درجه پیچیدگی سیستم را افزایش داده، برای هرکدام از انواع اقلام قابل‌پیگیری اسناد و فرآیندهای جداگانه‌ای بسازید.
پرینس۲ و بسیاری دیگر از متدولوژی‌ها سندی با نام فهرست ریسک (risk register) برای ذخیره‌سازی اطلاعات ریسک‌ها و برنامه‌های واکنشی‌شان دارند. این فهرست را می‌توانید به شکل جدولی در اکسل و نرم‌افزارهای مشابه بسازید.
هر ریسک می‌تواند بیش از یک واکنش برنامه‌ریزی‌شده داشته باشد و هر واکنش می‌تواند برای بیش از یک ریسک به کار رود. از این رو، اگر مایل باشید سیستم مدیریت ریسک پیشرفته‌تری داشته باشید می‌توانید اطلاعات ریسک را در یک جدول و واکنش‌ها را در جدول دیگری ذخیره کرده، ارتباطی چند-به-چند میان آن‌ها ایجاد کنید.
از سوی دیگر، هر ریسک نتیجه رابطه‌ای علی است و تحلیل این روابط در مدیریت ریسک اهمیت فراوانی دارد زیرا علتی یکه می‌تواند بیش از یک معلول (ریسک) داشته باشد و بنابراین با هدف قرار دادن چنان علتی می‌توان چندین ریسک را هم‌زمان پوشش داد. افزون بر این‌که یک علت می‌تواند چند معلول داشته باشد، هر پدیده‌ای نیز می‌تواند معلول چند علت باشد. بنابراین، در گام بعدی می‌توان علت‌ها را هم از جدول اطلاعات ریسک جدا کرده، ارتباطی چند به چند میان آن‌ها برقرار کرد. یک گام فراتر این است که شبکه علی را به‌جای دو جدول در قالب یک گراف بازسازی کنید تا به واقعیت نزدیک‌تر باشد.
در عمل نهایتی برای افزایش پیچیدگی سیستم مدیریت ریسک وجود ندارد و نمی‌توان حد مشخصی از پیچیدگی هم در نظر گرفت که برای همه پروژه‌ها مناسب باشد. سیستمی مانند P3.express حد پیچیدگی بسیار کمی را به پروژه‌های مخاطب خود پیشنهاد می‌کند، پرینس۲ حدی بالاتر، منابع تخصصی مدیریت ریسک هم معمولا بالاتر از همه. مطابق معمول، باید شرایط پروژه خود را بسنجید و تصمیم بگیرید که سیستم پیش‌فرض متدولوژیتان برای پروژه مناسب است یا باید آن را ساده‌تر یا پیچیده‌تر کرد. هرگاه در چنین تصمیم‌گیری‌ای دودل بودید، گزینه ساده‌تر را انتخاب کنید.
واکنش‌هایی که برای ریسک‌ها طراحی می‌کنید باید توجیه‌پذیر باشند. برای نمونه، به‌کارگیری هزینه‌ای معادل هزار پیتزا در ماه برای بیمه کردن پروژه‌ای که در بروز مشکل دچار آسیب معادل چند میلیون پیتزا می‌شود شاید توجیه‌پذیر باشد، ولی اگر حداکثر آسیب معادل چند هزار پیتزا باشد توجیه‌پذیر نخواهد بود.
بررسی شهودی و موردی واکنش‌ها برای بیشتر پروژه‌ها به‌اندازه و مناسب است، ولی در برخی پروژه‌های بزرگ و حساس باید از محاسبات پیشرفته‌تری استفاده کرد.
وقتی نیاز به موشکافی پیشرفته‌تر باشد، می‌توان داده‌های احتمالی را گردآوری کرده، با روشی مانند مونت‌کارلو بررسی کرد و با ترکیب آن‌ها در شکل‌های مختلف خروجی‌های احتمالی را محاسبه کرد. برای نمونه، پس از تحلیل وضعیت نخستین پروژه‌ای می‌بینید که به احتمال ۸۵٪ در حداکثر ۲۲ ماه به پایان می‌رسد. پس از این‌که واکنش‌های ریسک را به برنامه اضافه کنید، که معادل ۸۰ هزار پیتزا هزینه دارند، احتمال پایان پروژه در ۲۲ ماه به ۹۸٪ می‌رسد. در این مرحله می‌توانید توجیه‌پذیری واکنش‌ها را بر پایه اهداف و استراتژی‌ها بسنجید.
چنین شکلی از تحلیل کمی ریسک، کاری پیچیده و پرهزینه است و فقط باید در پروژه‌های بزرگ و حساس به کار برود.
هرآنچه در پروژه انجام می‌دهیم باید با سطوح بالاتر سازمان هماهنگ و همسو باشد. با این‌همه، درجه حساسیت کارهای مختلف یکسان نیست و مدیریت ریسک از مواردیست که نیاز به هماهنگی بیشتری دارد.
مهم‌ترین دلیل برای حساسیت بالای مدیریت ریسک این است که برخی از ریسک‌ها بر بیش از یک پروژه اثر می‌گذارند و وقتی اینگونه باشد بهتر است که واکنش به ریسک در سطحی بالاتر از پروژه‌ها و با رویکردی همه‌جانبه انجام شود.
لایه مدیریت پرتفولیوی سازمان باید فهرستی از ریسک‌هایی که میان پروژه‌ها مشترک هستند بسازد و پیگیری کند. این فهرست باید در اختیار مدیران پروژه‌ها نیز باشد تا در پروژه‌هایشان لحاظ کنند و اطلاعات تکمیلی احتمالی را به لایه مدیریت پرتفولیو بفرستند. از سوی دیگر، مدیران پروژه‌ها نیز باید فهرست ریسک‌های خود را در اختیار لایه مدیریت پرتفولیو بگذارند که چنانچه ریسک‌های مشترک تازه‌ای میان پروژه‌ها کشف شد مدیریتش به لایه بالاتر منتقل شود.
بسیاری از سازمان‌ها سیستم مدیریت پرتفولیوی ساخت‌یافته ندارند. اگر در چنین سازمانی کار کنید چالش‌هایتان به نبود روند مناسبی که در این بخش توضیح داده شد محدود نخواهد شد و شاید کار چندانی هم از دستتان ساخته نباشد. با این‌همه، برای کاستن دشواری‌ها می‌توانید جلسه‌های مشترک ماهانه‌ای با دیگر مدیران پروژه‌ها داشته باشید تا درباره ریسک‌های پروژه‌هایتان همفکری کنید. این کار جای خالی مدیریت پرتفولیوی ساخت‌یافته را پر نخواهد کرد، ولی باز هم کمک فراوانی به پروژه‌ها خواهد کرد. می‌توانید مشابه همین روند را برای به اشتراک‌گذاشتن درس آموخته‌ها میان پروژه‌ها نیز به کار ببرید.
به یاد داشته باشید که مدیریت پروژه به معنی درست انجام دادن کار و مدیریت پرتفولیو به معنی انجام دادن کار درست است.
امیدوارم از مطالعه این کتاب لذت برده باشید و برایتان مفید بوده باشد، به‌ویژه که محتوای کتاب متمرکز بر جنبه‌های مفهومی پم‌باک ۷ است و تناظر یک‌به‌یکی با محتوای منوآل ندارد. برای بسیاری از عناوین پم‌باک عنوانی در این کتاب وجود ندارد، ولی نگران نباشید، چون تمام جنبه‌های مهم و کلیدی به شکل‌های مختلف در کتاب پوشش داده شده‌اند.
بسیاری می‌کوشند سیستم مدیریت پروژه خود را بر پایه پم‌باک بسازند که گزینه کاملا اشتباهیست زیرا پم‌باک متدولوژی نیست. از این رو تمرکز این کتاب بر روشن کردن این تمایز و توضیح دادن رسالت واقعی پم‌باک بود.
از پم‌باک به دو شکل می‌توانید در پروژه‌های خود کمک بگیرید:
از این رو لازم بود که متدولوژی‌های مدیریت پروژه را هم اندکی بررسی کنیم که موضوع یکی از فصل‌های کتاب بود.
اگر علاقه‌مند به یادگیری بیشتر در این حوزه‌ها باشید می‌توانم موارد زیر را پیشنهاد کنم:
در پایان این‌که برای کسانی که در حوزه مدیریت پروژه فعالیت می‌کنند، یادگیری مدیریت پرتفولیو نیز سودمند خواهد بود.
پیروز باشید!