برنامه‌ریزی باید گستره، زمان، هزینه، کیفیت، منابع، ریسک و سایر حوزه‌ها را پوشش دهد. با این‌همه، زمان‌بندی یکی از عناصر مهم و مرکزی در برنامه‌ریزیست و معمولا موردی که چالش‌های ویژه خود را دارد و از این‌رو بیشتر از دیگر حوزه‌ها به آن پرداخته شده است.
زمان‌بندی به معنی تخصیص زمان آغاز و پایان یا ترتیب اجرا به فعالیت‌های پروژه است.
دو نوع زمان‌بندی می‌توان داشت:
وابستگی محور
اولویت محور
فعالیت‌های بسیاری از پروژه‌ها وابستگی‌هایی ذاتی و گریزناپذیر به همدیگر دارند. برای نمونه، تا وقتی دیواری ساخته نشده باشد نمی‌توانید آن را رنگ کنید. چنین پروژه‌هایی را باید به شیوه وابستگی محور برنامه‌ریزی کرد. برای این کار شبکه‌ای از روابط میان فعالیت‌ها ساخته می‌شود و اطلاعاتی دیگر مانند مدت‌زمان آن‌ها نیز درج می‌شود. پس از آن با روش مسیر بحرانی (critical path method) و همانند آن تاریخ‌های آغاز و پایان به دست می‌آیند. نرم‌افزارهایی مانند پریماورا و مایکروسافت پراجکت نمونه‌هایی از ابزارهای رایج در این نوع برنامه‌ریزی‌اند.
فعالیت‌های برخی پروژه‌ها را می‌توان به شکلی ساخت که به هم وابسته نباشند. در این حالت می‌توانید آن‌ها را با روشی اولویت محور زمان‌بندی کنید. در این روش، اولویت هر فعالیت بر پایه مجموعه‌ای از پارامترها مانند ارزش و ریسک تعیین می‌شود و سپس فهرست فعالیت‌ها بر آن پایه مرتب می‌شود. …
اگر ذی‌نفعان پرشمار باشند، بد نیست آن‌ها را بر پایه توجیه‌پذیری برنامه‌ای که برای مشارکت‌دادنشان دارید، حدود اثرگذاری، و موارد مشابه آن اولویت‌بندی کنید تا اگر زمانی در میان اجرای پروژه توان کافی برای اجرای همه برنامه‌ها نبود، دست‌کم روی مهم‌ترین موارد تمرکز کنید.
به یاد داشته باشید که توجیه‌پذیری‌ها دایما تغییر می‌کنند و از این رو باید اولویت‌بندی‌ها را نیز اصلاح کنید.
فرض کنید منبع‌هایی که دارید تنها برای انجام یکی از دو پروژه زیر بسنده می‌کند:
پروژه ۱ – با به پایان رساندن پروژه معادل یک میلیون پیتزا پول به دست خواهید آورد.
پروژه ۲ – پس از به پایان رساندن پروژه، به مدت بیست سال، هر سال معادل سیصد هزار پیتزا به دست خواهید آورد.
کدام پروژه را انتخاب می‌کنید؟
اگر پیش از این تنها روی پروژه‌های بلندمدت سرمایه‌گذاری کرده باشید نیاز به درآمد کوتاه‌مدت خواهید داشت و از این رو شاید گزینه نخست بهتر باشد. اگر شرکت دچار چالش مالی و در شرف ورشکستگی باشد، بی‌گمان گزینه نخست بهتر خواهد بود. اگر چالشی در درآمدهای کوتاه‌مدت وجود نداشته باشد، شاید گزینه دوم را ترجیح دهید.
این نمونه دیگری از مواردیست که ارزیابی ارزش پروژه بستگی به وضعیت کلان سازمان پیدا می‌کند و بنابراین نیاز است که ارزیابی در آن سطح انجام شود.
کسانی که در چنین تصمیم‌گیری‌هایی مشارکت می‌کنند هم باید با دقت انتخاب شوند. مشکلی رایج در برخی سازمان‌های بزرگ این است که فردی مشهور را به طور کوتاه‌مدت به‌عنوان مدیرعامل انتخاب می‌کنند. او که می‌داند بیش از چند سال مدیرعامل نخواهد بود، تنها هدفش ایجاد سابقه بهتر برای خودش خواهد بود و درنتیجه به جای این‌که ترکیبی از بهترین پروژه‌ها را انتخاب کند، فقط روی پروژه‌هایی با بازگشت کوتاه‌مدت تمرکز می‌کند. برخی از آن‌ها حتی آینده بلندمدت سازمان را …
بیشتر افراد در پاسخ به نیازها یا مشکل‌ها بی‌درنگ نخستین راهکار «بدیهی» را انتخاب می‌کنند. اگر زمان بیشتری صرف درک مشکل و نیاز کنیم و راهکارهای گوناگون را بسنجیم، معمولا می‌توانیم گزینه‌های بهتری بیابیم. برای همین چنین روندی در همه متدولوژی‌ها وجود دارد:
الزامات ← تحویل‌شدنی‌ها ← فعالیت‌ها
گام نخست، شناسایی الزامات است؛ هم الزامات واضح و هم پنهان. بسیاری از الزامات از سوی کارفرما هستند، ولی معمولا آنچه به شما می‌گویند واقعا الزام پروژه نیست، بلکه راهکاری «بدیهی» است برای الزامی که در ذهن داشته‌اند. از این رو، باید با آن‌ها گفتگو کنید تا بتوانید الزامات واقعی را استخراج کنید. از سوی دیگر، معمولا بیش از یک نماینده از سوی کارفرما وجود دارد و الزاماتی که در اختیارتان می‌گذارند شاید با یکدیگر هماهنگ نباشند که در این حالت هم باید به شکل‌های گوناگون رفع اختلاف کنید و به مجموعه‌ای سازگار از الزامات برسید. بسته به نوع محصول پروژه و محدوده مسئولیت‌هایتان، شاید بهتر باشد به آنچه از نمایندگان کارفرما می‌شنوید نیز کاملا اعتماد نکنید و با شماری از کاربران نهایی که در آینده از محصول استفاده خواهند کرد هم گفتگو کنید.
افزون بر کارفرما، سازمان خودتان هم چه‌بسا الزاماتی برای همه پروژه‌ها داشته باشد که باید در نظرشان بگیرید. شاید آیین‌نامه‌های مختلفی هم برای نوع پروژه‌تان وجود داشته باشند که الزاماتی …
همه پروژه‌ها نیاز به برنامه‌ریزی دارند. برخی گمان می‌کنند پروژه‌های چابک نیاز به برنامه‌ریزی ندارند، ولی این‌چنین نیست؛ فقط برنامه‌ریزی آن‌ها با پروژه‌های متعین متفاوت است:
پروژه‌های متعین برنامه‌های تفصیلی یا کلان نخستین دارند. اگر برنامه نخستین تفصیلی نباشد، معمولا دوره‌ای (برای نمونه، ماهانه) تفصیلی می‌شود.
پروژه‌های تطبیقی با برنامه‌ای کلان آغاز می‌شوند. شاید برنامه هر دوره کمی تفصیلی‌تر شود، ولی فقط پیش از اجرای هر جز است که برنامه‌اش کامل تفصیلی خواهد شد.
همه کارهایمان باید هدفمند باشند. برنامه‌ریزی با دو هدف کلی انجام می‌شود:
هدایت پروژه
ارزیابی وضعیت پروژه
چگونگی هدایت پروژه به شیوه ساخت محصول بستگی دارد و ارزیابی وضعیت پروژه به متدولوژی مدیریت پروژه. برنامه‌ریزی مفهومی مستقل نیست و نمی‌توان درباره کیفیت برنامه مستقل از شیوه ساخت محصول و متدولوژی مدیریت پروژه قضاوت کرد. شاید برنامه‌ای برای یک بستر مناسب و برای بستری دیگر نامناسب باشد.
مستقل از این‌که از چه روشی برای ساخت محصول استفاده می‌کنید، برنامه‌ریزی باید مستمر باشد. برخی گمان می‌کنند که می‌توان در آغاز پروژه برنامه‌ای آماده کرد، نسخه‌ای از آن را چاپ و بر دیوار نصب کرد و تا پایان پروژه دست از کار برنامه‌ریزی کشید. برنامه‌ای که دایما بازبینی نشود به‌سرعت کاربرد خود را از دست می‌دهد، زیرا با این‌که اجرا بر پایه برنامه قرار است انجام شود، عدم‌قطعیت‌های اجرایی همیشه تفاوت‌هایی به وجود می‌آورند. این تفاوت‌ها را باید در برنامه بازتاب داده، آن را بازبینی کرد.
در نظر داشته باشید که افراد و سازمان‌های مختلف برچسب‌هایی مانند «مدیر پروژه» و «حامی پروژه» را به شکل‌های گوناگونی به کار می‌برند. گاهی فردی که مدیر پروژه نامیده می‌شود درواقع نقش حامی پروژه را دارد و کارهای مدیریت پروژه را فردی انجام می‌دهد که برچسب رهبر تیم، رئیس کارگاه و همانند آن را دارد.
فریب برچسب‌ها را نخورید و اگر گمان می‌کنید برچسب‌های پیش‌فرضی که در متدولوژیتان وجود دارند با آنچه در محیط اطرافتان استفاده می‌شوند سازگار نیستند، برچسب‌های دیگری انتخاب کنید که سوتفاهم ایجاد نکنند. اگر وجود مدیر پروژه در متدولوژیتان اجباریست، به این معنی نیست که وجود برچسبی با آن نام الزامیست، بلکه به این معنیست که وجود نقشی با مسئولیت‌های تعریف شده الزامیست.
مدیریت پروژه جنبه‌های فراوانی دارد که دست به دست هم کار می‌کنند. اگر فقط یکی از این جنبه‌ها نادیده گرفته شود، جنبه‌های دیگر نیز کارایی خود را از دست می‌دهند. از این رو، باید مدیریت پروژه‌تان همه‌جانبه باشد و نه محدود به یک یا چند جنبه به ظاهر مهم‌تر مانند زمان‌بندی.
در فصل آینده، حوزه‌های عملکردی (performance domains) پم‌باک را بررسی می‌کنیم که نوعی دسته‌بندی از انواع جنبه‌هاییست که باید در مدیریت پروژه لحاظ شود:
ذی‌نفعان
تیم
چرخه حیات و شیوه ساخت محصول
برنامه‌ریزی
اجرا
ارزیابی
تحویل
عدم‌قطعیت
زاویه دیدهای گوناگونی برای دسته‌بندی حوزه‌ها وجود دارد و بهتر است مسئله را از چند زاویه ببینید تا نقاط کور برایتان مشخص شوند. برای نمونه، ایزو ۲۱۵۰۰ و نسخه‌های پیشین پم‌باک چنین دسته‌بندی‌ای دارند:
یکپارچگی
گستره
زمان
هزینه
کیفیت
منابع
ارتباطات
ریسک
تدارکات
ذی‌نفعان
پرینس۲ چنین دسته‌بندی‌ای دارد:
توجیه‌پذیری
سازمان‌دهی
کیفیت
برنامه
ریسک
تغییر
پیشرفت
راهنمای APMbok مسایل را این‌گونه تقسیم‌بندی می‌کند:
مسایل انسانی
مسایل مربوط به تولید و تحویل
یکپارچگی
گستره
زمان
هزینه
ریسک
کیفیت
منابع
ارتباط با سایر لایه‌ها
حسابداری
ایمنی و سلامت
منابع انسانی
قانون
امنیت
پایداری
آیا به همه این جوانب در پروژه‌های خود توجه می‌کنید؟
واکنش‌هایی که برای ریسک‌ها طراحی می‌کنید باید توجیه‌پذیر باشند. برای نمونه، به‌کارگیری هزینه‌ای معادل هزار پیتزا در ماه برای بیمه کردن پروژه‌ای که در بروز مشکل دچار آسیب معادل چند میلیون پیتزا می‌شود شاید توجیه‌پذیر باشد، ولی اگر حداکثر آسیب معادل چند هزار پیتزا باشد توجیه‌پذیر نخواهد بود.
بررسی شهودی و موردی واکنش‌ها برای بیشتر پروژه‌ها به‌اندازه و مناسب است، ولی در برخی پروژه‌های بزرگ و حساس باید از محاسبات پیشرفته‌تری استفاده کرد.
وقتی نیاز به موشکافی پیشرفته‌تر باشد، می‌توان داده‌های احتمالی را گردآوری کرده، با روشی مانند مونت‌کارلو بررسی کرد و با ترکیب آن‌ها در شکل‌های مختلف خروجی‌های احتمالی را محاسبه کرد. برای نمونه، پس از تحلیل وضعیت نخستین پروژه‌ای می‌بینید که به احتمال ۸۵٪ در حداکثر ۲۲ ماه به پایان می‌رسد. پس از این‌که واکنش‌های ریسک را به برنامه اضافه کنید، که معادل ۸۰ هزار پیتزا هزینه دارند، احتمال پایان پروژه در ۲۲ ماه به ۹۸٪ می‌رسد. در این مرحله می‌توانید توجیه‌پذیری واکنش‌ها را بر پایه اهداف و استراتژی‌ها بسنجید.
چنین شکلی از تحلیل کمی ریسک، کاری پیچیده و پرهزینه است و فقط باید در پروژه‌های بزرگ و حساس به کار برود.
مسئله پیش از دوره رایگانی که درباره مدیریت ریسک منتشر کرده‌ام آماده است. در زمان نوشتن این کتاب حدودا سه هزار نفر این دوره را گذرانده‌اند و از میان این افراد ۷۸٪ بازی نخست را انتخاب کرده‌اند. آیا به نظر شما این بازی بهترین گزینه است؟
برای پاسخ دادن به پرسش باید امید ریاضی (expected value) بازی‌ها را محاسبه کنیم:
1. 50% × 10¤ = 5¤ 2. 50% × 30¤ + 50% × -10¤ = 10¤
مانند $ و ¥ و €، نشان ¤ هم برای مقادیر مالیست، ولی برخلاف آن‌ها اشاره به ارز خاصی نمی‌کند و در نمونه ما معادل قیمت پیتزا به کار می‌رود.
امید ریاضی بازی دوم دو برابر بازی نخست است، به این معنی که اگر این دو بازی را هزاران بار انجام دهیم، درآمد بازی دوم به احتمال زیاد دو برابر بازی نخست خواهد بود. بنابر این اگر قرار باشد بازی را هزاران بار انجام دهیم، بی‌گمان بازی دوم بهتر خواهد بود.
تا اینجای استدلال ساده است، ولی درباره این مسئله که قرار است بازی را فقط یک‌بار انجام دهیم چگونه می‌توان استدلال کرد؟
این بازی را یک‌بار انجام خواهیم داد، ولی در کار و زندگی شخصی هزاران هزار بازی اینچنینی می‌کنیم. اگر استراتژی همیشگی‌مان این باشد که گزینه‌های با امید ریاضی بالاتر را انتخاب کنیم، درمجموع برنده خواهیم بود. از این رو، بهتر است که در این بازی هم گزینه دوم را انتخاب کنیم.
آنچه در بالا گفته شد روندی کلیست، ولی برای آن تبصره‌های …
شاید تعجب کنید که هنگامی که پم‌باک با هر دو روش ساخت محصول تطبیقی و متعین سازگار است، باز هم اصلی درباره تطبیق‌پذیری دارد. دلیلش این است که تطبیق‌پذیری به دو مقوله قابل حمل است:
تطبیق‌پذیری برای محصولی که در پروژه ساخته می‌شود
تطبیق‌پذیری برای سیستم مدیریت پروژه
برخی محصول‌ها را بهتر است تطبیقی ساخت و برخی را باید متعین ساخت، ولی سیستم مدیریت پروژه همیشه باید تطبیقی باشد زیرا با رفتارها و برداشت‌های پیچیده انسانی سر و کار دارد. موضوع واقعی این اصل سیستم مدیریت پروژه است.
این اصل به این معنیست که به‌جای ساخت یک سیستم تفصیلی برای مدیریت پروژه، بهتر است سیستمی ساده و حداقلی بسازید و کار را با آن آغاز کنید. پس از آن به‌تدریج جزئیات بیشتر را برای تطبیق دادن آن با محیطش بیفزایید.
هر پروژه محصول تازه‌ای می‌سازد یا محصولی که وجود دارد را دگرگون می‌کند. هر پروژه تغییری ساخت‌یافته است. با این حال، هنگامی که درباره تغییر سخن می‌گوییم، بیشتر منظورمان نتیجه تغییر است. برای نمونه، اگر سیستمی برای مدیریت اسناد در سازمانتان راه‌اندازی کنید، خروجی یا محصول پروژه سیستم مدیریت اسناد خواهد بود که تغییری در وضعیت شرکت به شمار می‌رود (زمانی این سیستم وجود نداشت و تغییر این است که اکنون وجود دارد). نتیجه این تغییر، اگر همه‌چیز به‌خوبی پیش برود، دسترسی آسان‌تر و سریع‌تر به اسناد، کاهش اشتباه‌ها و مانند آن خواهد بود.
آنچه انتظار داریم نتیجه مطلوب است و نه تنها تغییر. با این‌همه، این دو مفهوم همیشه با هم اشتباه گرفته می‌شوند که خود منشا چالش‌های فراوانیست.
وقتی افراد قدرت تصمیم‌گیری داشته باشند بیشتر مشارکت و همکاری می‌کنند. از این رو، نیاز است که سیستم تفویض اختیار مناسبی در پروژه داشت. متدولوژی پرینس۲ ساختار جالب و مناسبی برای این منظور دارد: چندین سطح تصمیم‌گیری در پروژه وجود دارد و هر سطح اختیار تصمیم‌گیری ویژه خود را دارد. برای این منظور حدی از اثر تصمیم بر زمان، هزینه، کیفیت، ریسک و منافع برای هر سطح در نظر گرفته می‌شود. اگر اثر از حد تعیین شده پایین‌تر باشد، افراد سطح بالاتر نباید در تصمیم‌گیری دخالت کنند، و اگر اثر بزرگتر باشد، باید تصمیم را به سطح بالاتر فرستاد.
در یکی از پروژه‌ها پیچیدگی‌های ویژه‌ای در سازه بتنی وجود داشت. برای به پایان رساندن بهنگام پروژه نیاز بود که بتن‌ریزی‌ها بسیار بهینه انجام شوند. یک‌بار که برای بازدید به پروژه رفته بودم دیدم که همه قالب‌های بتن بسته شده، آماده بتن‌ریزی‌اند. در آن پروژه انتظار داشتیم که بتن‌ریزی بی‌درنگ انجام شود تا قالب‌ها در زودترین زمان ممکن آزاد شده، در ناحیه بعدی به‌کار گرفته شوند. با این حال، اثری از بتن‌ریزی نبود. وقتی پرسیدم، به من گفتند که قالب‌ها سه روز پیش بسته شده‌اند، ولی نمی‌توانند بتن‌ریزی کنند چون نیاز به مصالح تکمیلی ساده‌ای دارند که فعلا در کارگاه موجود نیست.
مدیر پروژه، که در کارگاه مستقر بود، اختیار خرید مصالح نداشت و باید درخواست را به دفتر مرکزی می‌فرستاد و در …
بسیاری فقط بر فعالیت‌ها تمرکز دارند، ولی بهتر است تمرکز بر محصول و تحویل‌شدنی‌های پروژه باشد. این اصل از این روست که راه‌های فراوانی برای ساخت هر تحویل‌شدنی وجود دارد و بهتر است گزینه‌های خود را بی‌درنگ محدود نکنیم. هنگامی که تمرکز بر محصول و تحویل‌شدنی‌ها باشد، دید بهتری بر راهکارها خواهیم داشت و می‌توانیم بهترین را انتخاب کنیم، ولی اگر تمرکزمان بر فعالیت‌ها باشد در عمل تسلیم گزینه پیش‌فرضی که در فعالیت‌ها پنهان است خواهیم شد.
یکی از مسایل مهم در اجرای پروژه، توازن میان اجرا و برنامه‌ریزیست. پروژه‌های مختلف به یکی از شکل‌های زیر اجرا می‌شوند:
برخی از پروژه‌ها بدون برنامه یا بدون توجه به برنامه اجرا می‌شوند. در این حالت نیروهای اجرایی پروژه بر پایه تجربه و برنامه‌های ضمنی‌ای که در ذهن دارند اقدام بعدی را انتخاب می‌کنند. اگر برنامه‌ای وجود داشته باشد، شاید مسئولی برای برنامه‌ریزی هم باشد که دایما آن را بر پایه واقعیت‌های پروژه به‌روزرسانی کند تا بتواند از آن برای ارزیابی پروژه استفاده کند، ولی کماکان استفاده از برنامه محدود به ارزیابی‌ست و نه سودهی به پروژه.
برخی پروژه‌ها پافشاری زیاد از حدی بر مطابقت اجرا و برنامه‌ریزی دارند و کوچک‌ترین تفاوتی را نمی‌پذیرند، که خود منبع دشواری‌های فراوانیست، زیرا برنامه‌ها هیچ‌وقت ایده‌آل نیستند.
برخی پروژه‌ها توازن مناسبی میان برنامه‌ریزی و اجرا برقرار می‌کنند. اجرا بر پایه برنامه‌ها انجام می‌شود، و در عین حال انعطاف‌پذیری کافی برای جذب عدم‌قطعیت‌ها دارد. از سوی دیگر، برنامه‌ها نیز بر پایه واقعیت‌های اجرایی دایما به‌روزرسانی می‌شوند. برای نمونه، در P3.express جلسه‌ای هفتگی وجود دارد که در آن اعضای کلیدی پروژه کارهای هفته پیش رو را همراه هم مرور می‌کنند تا چالش‌ها و ناسازگاری‌های احتمالی کشف و اصلاح شوند.
هرگاه برنامه را بر پایه واقعیت‌ها بازبینی می‌کنید، تغییر شکل …