واکنش‌هایی که برای ریسک‌ها طراحی می‌کنید باید توجیه‌پذیر باشند. برای نمونه، به‌کارگیری هزینه‌ای معادل هزار پیتزا در ماه برای بیمه کردن پروژه‌ای که در بروز مشکل دچار آسیب معادل چند میلیون پیتزا می‌شود شاید توجیه‌پذیر باشد، ولی اگر حداکثر آسیب معادل چند هزار پیتزا باشد توجیه‌پذیر نخواهد بود.
بررسی شهودی و موردی واکنش‌ها برای بیشتر پروژه‌ها به‌اندازه و مناسب است، ولی در برخی پروژه‌های بزرگ و حساس باید از محاسبات پیشرفته‌تری استفاده کرد.
وقتی نیاز به موشکافی پیشرفته‌تر باشد، می‌توان داده‌های احتمالی را گردآوری کرده، با روشی مانند مونت‌کارلو بررسی کرد و با ترکیب آن‌ها در شکل‌های مختلف خروجی‌های احتمالی را محاسبه کرد. برای نمونه، پس از تحلیل وضعیت نخستین پروژه‌ای می‌بینید که به احتمال ۸۵٪ در حداکثر ۲۲ ماه به پایان می‌رسد. پس از این‌که واکنش‌های ریسک را به برنامه اضافه کنید، که معادل ۸۰ هزار پیتزا هزینه دارند، احتمال پایان پروژه در ۲۲ ماه به ۹۸٪ می‌رسد. در این مرحله می‌توانید توجیه‌پذیری واکنش‌ها را بر پایه اهداف و استراتژی‌ها بسنجید.
چنین شکلی از تحلیل کمی ریسک، کاری پیچیده و پرهزینه است و فقط باید در پروژه‌های بزرگ و حساس به کار برود.
مسئله پیش از دوره رایگانی که درباره مدیریت ریسک منتشر کرده‌ام آماده است. در زمان نوشتن این کتاب حدودا سه هزار نفر این دوره را گذرانده‌اند و از میان این افراد ۷۸٪ بازی نخست را انتخاب کرده‌اند. آیا به نظر شما این بازی بهترین گزینه است؟
برای پاسخ دادن به پرسش باید امید ریاضی (expected value) بازی‌ها را محاسبه کنیم:
1. 50% × 10¤ = 5¤ 2. 50% × 30¤ + 50% × -10¤ = 10¤
مانند $ و ¥ و €، نشان ¤ هم برای مقادیر مالیست، ولی برخلاف آن‌ها اشاره به ارز خاصی نمی‌کند و در نمونه ما معادل قیمت پیتزا به کار می‌رود.
امید ریاضی بازی دوم دو برابر بازی نخست است، به این معنی که اگر این دو بازی را هزاران بار انجام دهیم، درآمد بازی دوم به احتمال زیاد دو برابر بازی نخست خواهد بود. بنابر این اگر قرار باشد بازی را هزاران بار انجام دهیم، بی‌گمان بازی دوم بهتر خواهد بود.
تا اینجای استدلال ساده است، ولی درباره این مسئله که قرار است بازی را فقط یک‌بار انجام دهیم چگونه می‌توان استدلال کرد؟
این بازی را یک‌بار انجام خواهیم داد، ولی در کار و زندگی شخصی هزاران هزار بازی اینچنینی می‌کنیم. اگر استراتژی همیشگی‌مان این باشد که گزینه‌های با امید ریاضی بالاتر را انتخاب کنیم، درمجموع برنده خواهیم بود. از این رو، بهتر است که در این بازی هم گزینه دوم را انتخاب کنیم.
آنچه در بالا گفته شد روندی کلیست، ولی برای آن تبصره‌های …
شاید تعجب کنید که هنگامی که پم‌باک با هر دو روش ساخت محصول تطبیقی و متعین سازگار است، باز هم اصلی درباره تطبیق‌پذیری دارد. دلیلش این است که تطبیق‌پذیری به دو مقوله قابل حمل است:
تطبیق‌پذیری برای محصولی که در پروژه ساخته می‌شود
تطبیق‌پذیری برای سیستم مدیریت پروژه
برخی محصول‌ها را بهتر است تطبیقی ساخت و برخی را باید متعین ساخت، ولی سیستم مدیریت پروژه همیشه باید تطبیقی باشد زیرا با رفتارها و برداشت‌های پیچیده انسانی سر و کار دارد. موضوع واقعی این اصل سیستم مدیریت پروژه است.
این اصل به این معنیست که به‌جای ساخت یک سیستم تفصیلی برای مدیریت پروژه، بهتر است سیستمی ساده و حداقلی بسازید و کار را با آن آغاز کنید. پس از آن به‌تدریج جزئیات بیشتر را برای تطبیق دادن آن با محیطش بیفزایید.
هر پروژه محصول تازه‌ای می‌سازد یا محصولی که وجود دارد را دگرگون می‌کند. هر پروژه تغییری ساخت‌یافته است. با این حال، هنگامی که درباره تغییر سخن می‌گوییم، بیشتر منظورمان نتیجه تغییر است. برای نمونه، اگر سیستمی برای مدیریت اسناد در سازمانتان راه‌اندازی کنید، خروجی یا محصول پروژه سیستم مدیریت اسناد خواهد بود که تغییری در وضعیت شرکت به شمار می‌رود (زمانی این سیستم وجود نداشت و تغییر این است که اکنون وجود دارد). نتیجه این تغییر، اگر همه‌چیز به‌خوبی پیش برود، دسترسی آسان‌تر و سریع‌تر به اسناد، کاهش اشتباه‌ها و مانند آن خواهد بود.
آنچه انتظار داریم نتیجه مطلوب است و نه تنها تغییر. با این‌همه، این دو مفهوم همیشه با هم اشتباه گرفته می‌شوند که خود منشا چالش‌های فراوانیست.
وقتی افراد قدرت تصمیم‌گیری داشته باشند بیشتر مشارکت و همکاری می‌کنند. از این رو، نیاز است که سیستم تفویض اختیار مناسبی در پروژه داشت. متدولوژی پرینس۲ ساختار جالب و مناسبی برای این منظور دارد: چندین سطح تصمیم‌گیری در پروژه وجود دارد و هر سطح اختیار تصمیم‌گیری ویژه خود را دارد. برای این منظور حدی از اثر تصمیم بر زمان، هزینه، کیفیت، ریسک و منافع برای هر سطح در نظر گرفته می‌شود. اگر اثر از حد تعیین شده پایین‌تر باشد، افراد سطح بالاتر نباید در تصمیم‌گیری دخالت کنند، و اگر اثر بزرگتر باشد، باید تصمیم را به سطح بالاتر فرستاد.
در یکی از پروژه‌ها پیچیدگی‌های ویژه‌ای در سازه بتنی وجود داشت. برای به پایان رساندن بهنگام پروژه نیاز بود که بتن‌ریزی‌ها بسیار بهینه انجام شوند. یک‌بار که برای بازدید به پروژه رفته بودم دیدم که همه قالب‌های بتن بسته شده، آماده بتن‌ریزی‌اند. در آن پروژه انتظار داشتیم که بتن‌ریزی بی‌درنگ انجام شود تا قالب‌ها در زودترین زمان ممکن آزاد شده، در ناحیه بعدی به‌کار گرفته شوند. با این حال، اثری از بتن‌ریزی نبود. وقتی پرسیدم، به من گفتند که قالب‌ها سه روز پیش بسته شده‌اند، ولی نمی‌توانند بتن‌ریزی کنند چون نیاز به مصالح تکمیلی ساده‌ای دارند که فعلا در کارگاه موجود نیست.
مدیر پروژه، که در کارگاه مستقر بود، اختیار خرید مصالح نداشت و باید درخواست را به دفتر مرکزی می‌فرستاد و در …
بسیاری فقط بر فعالیت‌ها تمرکز دارند، ولی بهتر است تمرکز بر محصول و تحویل‌شدنی‌های پروژه باشد. این اصل از این روست که راه‌های فراوانی برای ساخت هر تحویل‌شدنی وجود دارد و بهتر است گزینه‌های خود را بی‌درنگ محدود نکنیم. هنگامی که تمرکز بر محصول و تحویل‌شدنی‌ها باشد، دید بهتری بر راهکارها خواهیم داشت و می‌توانیم بهترین را انتخاب کنیم، ولی اگر تمرکزمان بر فعالیت‌ها باشد در عمل تسلیم گزینه پیش‌فرضی که در فعالیت‌ها پنهان است خواهیم شد.
یکی از مسایل مهم در اجرای پروژه، توازن میان اجرا و برنامه‌ریزیست. پروژه‌های مختلف به یکی از شکل‌های زیر اجرا می‌شوند:
برخی از پروژه‌ها بدون برنامه یا بدون توجه به برنامه اجرا می‌شوند. در این حالت نیروهای اجرایی پروژه بر پایه تجربه و برنامه‌های ضمنی‌ای که در ذهن دارند اقدام بعدی را انتخاب می‌کنند. اگر برنامه‌ای وجود داشته باشد، شاید مسئولی برای برنامه‌ریزی هم باشد که دایما آن را بر پایه واقعیت‌های پروژه به‌روزرسانی کند تا بتواند از آن برای ارزیابی پروژه استفاده کند، ولی کماکان استفاده از برنامه محدود به ارزیابی‌ست و نه سودهی به پروژه.
برخی پروژه‌ها پافشاری زیاد از حدی بر مطابقت اجرا و برنامه‌ریزی دارند و کوچک‌ترین تفاوتی را نمی‌پذیرند، که خود منبع دشواری‌های فراوانیست، زیرا برنامه‌ها هیچ‌وقت ایده‌آل نیستند.
برخی پروژه‌ها توازن مناسبی میان برنامه‌ریزی و اجرا برقرار می‌کنند. اجرا بر پایه برنامه‌ها انجام می‌شود، و در عین حال انعطاف‌پذیری کافی برای جذب عدم‌قطعیت‌ها دارد. از سوی دیگر، برنامه‌ها نیز بر پایه واقعیت‌های اجرایی دایما به‌روزرسانی می‌شوند. برای نمونه، در P3.express جلسه‌ای هفتگی وجود دارد که در آن اعضای کلیدی پروژه کارهای هفته پیش رو را همراه هم مرور می‌کنند تا چالش‌ها و ناسازگاری‌های احتمالی کشف و اصلاح شوند.
هرگاه برنامه را بر پایه واقعیت‌ها بازبینی می‌کنید، تغییر شکل …
همه راهنماها و متدولوژی‌های مدیریت پروژه بر اهمیت درک چرایی پروژه‌ها پافشاری می‌کنند، ولی آن را به شکل یکسانی در سیستم خود بازتاب نمی‌دهند. راه متداول این است که بر توجیه‌پذیری پروژه تمرکز کنیم که یکی از اصل‌های پرینس۲ هم هست. توجیه‌پذیری پروژه معمولا در سندی با نام انگیزه تجاری (business case) ثبت می‌شود. این سند باید دایما بر پایه تازه‌ترین پیش‌بینی‌های زمان و هزینه و دیگر متغیرهای پروژه بازبینی و سپس برای مدیران ارشد فرستاده شود تا درباره توجیه‌پذیری پروژه تصمیم بگیرند.
فقط پروژه‌هایی که توجیه‌پذیر باشند را باید آغاز کرد. با این‌همه، توجیه‌پذیر بودن در آغاز پروژه کافی نیست، زیرا گاهی با شناخت بهتر پروژه می‌توان برداشت واقع‌بینانه‌تری از بازگشت سرمایه آن به دست آورد و گاهی هم به دلیل تغییر شرایط بیرونی پروژه توجیه‌پذیری‌اش تغییر می‌کند. از این رو، باید دایما توجیه‌پذیری پروژه را بازنگری کرده، بسته به نیاز پروژه را متوقف کرد.
بسیاری از پروژه‌های در حال انجامی که توجیه‌پذیری خود را از دست می‌دهند به دو دلیل متوقف نمی‌شوند:
سیستم مدیریت پروژه مناسبی ندارند که متوجه تغییر توجیه‌پذیری بشود. از این‌رو، می‌گوییم که متوقف کردن پروژه‌های نیمه‌کاره نشانه‌ای از مدیریت پروژه و مدیریت پرتفولیوی قویست.
گاهی سازمان‌ها متوجه از بین رفتن توجیه‌پذیری می‌شوند، ولی به دلیل هزینه و کوششی که تا آن زمان صرف پروژه شده است ترجیح می‌دهند کار را ادامه دهند که در عمل باعث تباهی کوشش و پول بیشتر می‌شود. این ضعف ناشی از فریبی ذهنی به نام sunk cost effect است.
باید توجیه‌پذیری هر پروژه‌ای را دوره‌ای کنترل کرد. این کار هم به یافتن پروژه‌هایی که توجیه‌پذیریشان را از دست داده‌اند کمک می‌کند و هم به همگان دایما هدف پروژه و لزوم هم‌راستا شدن با آن را یادآوری می‌کند.
به فعالیت‌هایی که وضعیت تیم را بهبود می‌دهند «تیم‌سازی» (team building) گفته می‌شود. برخی سازمان‌ها فعالیت‌هایی ویژه این کار ترتیب می‌دهند. این فعالیت‌ها معمولا با کمک مربی‌هایی انجام می‌شود که در تیم‌سازی خبره هستند. برای نمونه، همه افراد تیم به یک بازی دست جمعی یا برنامه‌ای آموزشی مانند آشپزی دعوت می‌شوند و تیم‌سازی در خلال این کار انجام شود.
بهتر است به‌جای فعالیت‌های مختص تیم‌سازی تا حد امکان آن را با فعالیت‌های معمول پروژه ترکیب کنید تا کارآمدتر شود. هرگاه درگیر ترتیب دادن فعالیتی هستید، از خود بپرسید که چگونه می‌توانید از آن فعالیت برای تیم‌سازی نیز کمک بگیرید.
برای نمونه، فرض کنید درگیر برنامه‌ریزی عنصری در پروژه هستید. می‌توانید برای این کار با پنج عضو تیم جداگانه ملاقات کنید، اطلاعات لازم را گردآوری کرده، برنامه را بر آن پایه آماده کنید. گزینه دیگر این است که کارگاهی تسهیل‌شده ترتیب دهید و آن پنج نفر را دعوت کنید تا با هم همفکری کرده، برنامه را آماده کنند. گزینه دوم، هنگامی‌که به خوبی انجام شود، فرصت خوبی برای تقویت کار گروهی، بهبود روابط میان افراد، و حرکت به سوی شکل‌دهی تیمی توانمند است.
امتیاز اصلی ترکیب تیم‌سازی با فعالیت‌های معمول این است که آهسته و پیوسته انجام می‌شود.
برخی مدیر پروژه را بالاترین نقش پروژه می‌دانند، ولی بیشتر متدولوژی‌ها نقش دیگری بالاتر از مدیر پروژه دارند؛ مدیری ارشد که می‌تواند
با قدرت سازمانی‌ای که دارد بودجه و سایر منابع برای پروژه فراهم کند، و
بر پایه دانشی که از استراتژی‌های بلندمدت سازمان دارد و دید کلانی که در سطح سازمان پیدا کرده است تصمیم‌گیری‌های کلان پروژه را بر دوش بگیرد.
این دو کار از بیشتر مدیر پروژه‌ها ساخته نیست، زیرا از یک سو معمولا قدرت سازمانی چندانی ندارند (مدیر ارشد نیستند) و از ریزه‌کاری‌های استراتژیک و برنامه‌های بلندمدت سازمان که گاهی فقط در اختیار مدیران ارشد و سهام‌داران است بی‌اطلاعند و از سوی دیگر بیشتر افراد نمی‌توانند در موضوعی یکه هم مسئولیت‌های انتزاعی و هم روزمره را بر دوش داشته باشند و در انجام یکی از این دو مورد (معمولا کارهای انتزاعی‌تر) سهل‌انگاری می‌کنند.
نقشی که در راس پروژه قرار می‌گیرد، در بسیاری از منابع، ازجمله P3.express، حامی پروژه (sponsor)، در پرینس۲ مدیر ارشد (executive) و در DSDM حامی کسب و کار (business sponsor) نامیده می‌شود.
برخی حیوانات می‌توانند به‌تنهایی زندگی کنند، ولی برخی دیگر، مانند انسان‌ها، نمی‌توانند به‌تنهایی از پس نیازهای زندگی برآیند و نیاز دارند که در گروهی از موجودات همانند خود باشند. انسان‌های نخستینی که گرایش کمتری به تعلق در گروه‌ها داشتند شانس بقای کمتری داشتند و آن‌هایی که به زندگی خود ادامه دادند و تولیدمثل بیشتری کردند این گرایش را به نسل‌های بعدی خود منتقل کردند. این انتخاب طبیعی باعث شده است که گونه انسانی حسی قوی برای تعلق به گروه‌های مختلف داشته باشد و ترد شدن را به‌مثابه مرگ بپندارد.
این مورد، مانند هر گرایش طبیعی دیگری، از محدوده خود فراتر می‌رود و باعث می‌شود انسان‌ها ارزش‌های فراوانی را قربانی عضویت در گروه‌ها کنند. در بسیاری از این موارد، آنچه فرد از تعلق شدید به گروه به دست می‌آورد بسیار کمتر از آن است که قربانی می‌کند.
این گرایش درونی در حوزه مدیریت پروژه باعث می‌شود که افراد خود را وابسته به گروهی بدانند که از روشی ویژه‌ای برای اجرای پروژه استفاده می‌کند و به‌تدریج آن را تبدیل به تعصب و دشمن‌تراشی کنند. مدیر پروژه‌ای که خود را وارد چنین بازی‌های ایدئولوژیکی‌ای نکند و اندیشه‌اش را به روی همه منابع و ایده‌ها باز بگذارد، از آن‌ها بیاموزد و در هر شرایطی بسته به نیاز از آموخته‌های خود بهره گیرد، به‌مراتب موفق‌تر خواهد بود.
در این بخش می‌تونین نسخه کاملی از تمام مطالب سایت رو دانلود کنین. البته در نظر داشته باشین که مطالب سایت سالی یک بار بررسی می‌شن و مواردی که صرفا ارزش مقطعی داشته باشن (مثلا آگهی‌های استخدام) حذف می‌شن. بعد از هر بار رسیدگی حدودا ۲۵٪ مطالب سایت باقی می‌مونن و در این بخش همون موارد قابل دانلود هستن.
هر وقت مطلب جدیدی به سایت اضافه می‌شه، فایل قابل دانلود این صفحه هم به طور خودکار به‌روزرسانی می‌شه؛ در نتیجه، همیشه می‌تونین با مراجعه به این صفحه کامل‌ترین نسخه قابل دانلود سایت رو دریافت کنین.
اگر انتظارمان از مدیر پروژه پشتیبانی و تسهیل‌گری غیرفنی باشد، قاعدتا بسیاری از این افراد اطلاعات فنی کافی برای برنامه‌ریزی و کنترل پروژه یا تصمیم‌گیری‌های کلان فنی نخواهند داشت. از این رو، به‌جای این‌که شخصا چنین کارهایی را انجام دهند، باید از اعضای تیم پروژه کمک بگیرند. باید با مهارتی که در برنامه‌ریزی، تسهیل‌گری و سایر موارد مدیریتی دارند به این افراد کمک کنند تا خودشان پروژه را به شکل مناسب بسازند. منظور از مدیریت پروژه واقعی این است.
آیا به نظرتان مدیر پروژه باید اطلاعات فنی داشته باشد؟
سه پاسخ برای این پرسش ممکن است:
بله، مدیر پروژه باید اطلاعات فنی داشته باشد.
الزامی نیست که مدیر پروژه اطلاعات فنی داشته باشد، ولی اگر داشته باشد شاید بهتر باشد.
خیر، بهتر است که مدیر پروژه اطلاعات فنی نداشته باشد.
نخستین پاسخ رویکردی سنتیست که چه‌بسا در بسیاری از سازمان‌ها دیده باشید. این رویکرد محدود به ایران هم نیست و در همه کشورها وجود دارد.
رویکرد دوم کمابیش نوین و بااین‌همه کمی محافظه‌کارانه است. این رویکرد با آنچه تاکنون گفته شد هماهنگ است و می‌توان گفت که PMI هم چنین دیدگاهی دارد.
سومین پاسخ رویکردی کاملا پیشروست که درکش برای بسیاری از افراد چالش‌برانگیز است. گروهی، ازجمله من، از آن طرفداری می‌کنند.
فرض کنید مدیر پروژه‌ای هستید که در جنبه‌های فنی‌اش نیز تخصص دارید. اگر ببینید که کاری …
بسته به شرایط، شاید کارهای دیگری هم برای بهبود وضعیت تیم نیاز باشد. برای نمونه، وقتی تیم زیاد از حد کوچک نباشد بهتر است که انتظارهایی که از هرکس می‌رود و انتظارهایی که آن فرد از دیگران می‌تواند داشته باشد مشخص و شفاف باشد. به عبارت دیگر، باید نقش‌ها و مسئولیت‌ها را به‌خوبی تعریف کنید. این نکته یکی از اصل‌های متدولوژی مدیریت پروژه پرینس۲ (PRINCE2) نیز هست.
افزون بر نقش و مسئولیت‌ها، شاید نیاز باشد که فرآیندهای کارهای رایج پروژه را نیز تدوین کنید. برای نمونه: «هر سندی که طراحی می‌شود باید برای بررسی نخستین به …… فرستاده شود، این بررسی باید در …… روز کامل شده و پس از آن…»
نکته دیگری که شاید نیاز باشد تدوین قواعد رفتاری (ground rules) است . برای نمونه، «با صدای بلند پشت تلفن صحبت نکنید.»
شاید به این بیندیشید که تدوین و ابلاغ چنین قواعدی تحکمی و برخلاف آنچه در اصل پیش بررسی کردیم است. وضعیت اینگونه خواهد بود اگر این موارد را به تنهایی یا همراه با عده‌ای انگشت‌شمار آماده کرده، به همگی حکم کنید. راه مناسب این است که با تسهیل‌گری مناسب از خود اعضای تیم درخواست کنید که چنین مواردی را برای خودشان تدوین کنند. اینگونه، هم قواعد واقع‌بینانه‌تر و کاراتر خواهند بود و هم امکان موفقیت بیشتری خواهند داشت چون به افراد تحمیل نشده‌اند. برای نمونه، آیین‌نامه اخلاق …
چگونه و تا چه اندازه می‌تواند بر پروژه اثر بگذارد؟
جبه‌گیری‌اش در برابر پروژه مثبت است یا منفی؟
چه انتظاری از پروژه دارد؟ چه مسایلی برایش خوش‌آیند و چه مسایلی آزاردهنده است؟
و …
وقتی در جستجوی پاسخ به چنین پرسش‌هایی هستید، به‌تدریج برنامه‌ای هم برای مشارکت‌دادن و جلب حمایت آن‌ها تدوین کنید. وقتی چنین کاری می‌کنید مراقب توجیه‌پذیری برنامه نیز باشید: آیا منافعی که از مشارکت و حمایت ذی‌نفع دریافت می‌کنید بیش از توانی که صرف می‌کنید هست؟ آیا بازگشت سرمایه در این فرآیند بیشتر از هزینه فرصت (opportunity cost) شما هست یا خیر؟ به عبارت دیگر، آیا کار دیگری با بازگشت بالاتر هست که بتوان به‌جای آن انجام داد؟
استثنایی که در تحلیل توجیه‌پذیری مشارکت ذی‌نفعان وجود دارد، مسایل اخلاقیست. فرض کنید قرار است ساختمان کوچکی در همسایگی پیرزنی بسازید. پیرزن نمی‌داند که چنانچه سر و صدا و مزاحمت کار بیش از اندازه یا بی‌موقع باشد می‌تواند از شما شکایت کند و شاید توان و حوصله این کار را نداشته باشد. آیا این مسئله به این معنیست که نیازی به محدود کردن آلودگی صوتی کارگاه ندارید؟ نه؛ باید جنبه اخلاقی مسئله را هم در نظر بگیرید.
اطلاعاتی که درباره تحلیل و برنامه‌ریزی ذی‌نفعان گردآوری کرده‌اید را برای ارجاع‌های بعدی مستند کنید. برخی متدولوژی‌ها سندی برای این کار …