همهٔ پروژه‌ها با این جمله شروع می‌شوند که «ان‌شاءالله مشکلی پیش نمی‌آید». اما وقتی تأمین‌کننده غایب می‌شود، وقتی نرم‌افزار کلیدی از دسترس خارج می‌شود یا وقتی فرد کلیدی تیم استعفا می‌دهد، تیمی که برنامهٔ جایگزین ندارد، در همان لحظه شروع به تصمیم‌گیری می‌کند — و تصمیم‌گیری در بحران، گران‌ترین نوع تصمیم‌گیری است. Contingency Plan دقیقاً برای همین لحظه‌ها ساخته می‌شود.
در این مقاله می‌بینید Contingency Plan چیست، چه تفاوتی با فallback Plan و برنامهٔ تداوم کسب‌وکار دارد، چطور آن را برای ریسک‌های مهم پروژه بسازید، چه زمانی فعال شود، چه محتوایی باید داشته باشد و کجا بیش از حد هزینه‌بر می‌شود. هدف این است که بعد از خواندن، بتوانید برای بحرانی‌ترین ریسک‌های پروژه، یک برنامهٔ جایگزین قابل‌اجرا بنویسید.
Contingency Plan چیست؟ (پاسخ سریع)
Contingency Plan یا برنامهٔ جایگزین، مجموعه‌ای از اقدامات از پیش تعیین‌شده است که اگر یک ریسک شناسایی‌شده به واقعیت تبدیل شود، تیم آن‌ها را اجرا می‌کند تا کمترین آسیب را ببیند. معادل فارسی رایج آن «برنامهٔ اضطراری» یا «Plan B» است. برخلاف واکنش شتاب‌زده در لحظهٔ بحران، این برنامه پیش از وقوع نوشته، تأیید و تدارک دیده می‌شود.
چرا برنامهٔ جایگزین از واکنش در لحظه بهتر است؟
وقتی بحران رخ می‌دهد، سه چیز هم‌زمان از شما گرفته می‌شود: زمان، اطلاعات کامل و آرامش برای قضاوت. تصمیمی که در این شرایط گرفته شود، معمولاً گران‌تر و کمتر بهینه است. برنامهٔ جایگزین این فشار را از روی تیم برمی‌دارد.
| ویژگی | واکنش در لحظهٔ بحران | Contingency Plan |
|---|---|---|
| زمان تصمیم‌گیری | فوری و تحت فشار | از قبل و در آرامش |
| کیفیت تصمیم | وابسته به حال تیم | بازبینی‌شده و تأییدشده |
| تأمین منابع | دیرهنگام و گران‌تر | تدارک‌دیده |
| هماهنگی | پراکنده و شفاهی | مکتوب و مسئول‌دار |
| اثر بر پروژه | معمولاً بزرگ‌تر | کنترل‌شده |
نکتهٔ کلیدی: ارزش برنامهٔ جایگزین در «سرعت واکنش» است؛ چون تصمیم را از لحظهٔ بحران به لحظهٔ آرام منتقل می‌کند.
همین امروز به دوایتیفای بپیوندید
پروژه‌ها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفت‌ها و گزارش‌های تیم در یک محیط یکپارچه. ساخته‌شده برای شرکت‌ها، استارتاپ‌ها و تیم‌های دورکار — با راه‌اندازی چنددقیقه‌ای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
Contingency Plan چه تفاوتی با Fallback Plan و برنامهٔ تداوم کسب‌وکار دارد؟
این سه اصطلاح زیاد با هم قاطی می‌شوند، در حالی که نقش‌های متفاوتی دارند:
- Contingency Plan (برنامهٔ جایگزین): برای ریسک‌های شناسایی‌شدهٔ محتمل؛ اگر ریسک رخ دهد، این اقدامات اجرا می‌شود. نمونه: تأمین‌کنندهٔ دوم برای مواد اولیه.
- Fallback Plan (برنامهٔ پشتیبان): برای وقتی که پاسخ اصلی به ریسک شکست خورده باشد؛ یعنی Plan C. نمونه: اگر تأمین‌کنندهٔ دوم هم جواب نداد، تولید داخلی موقت.
- Business Continuity Plan (برنامهٔ تداوم کسب‌وکار): در سطح سازمان و برای رویدادهای بزرگ مثل قطعی گستردهٔ سیستم یا بحران؛ هدف، زنده نگه‌داشتن عملیات کلیدی است.
- Contingency Reserve (ذخیرهٔ احتمال): بودجه یا زمان از پیش کنارگذاشته‌شده برای اجرای برنامهٔ جایگزین. (تفاوت آن با Management Reserve در مقالهٔ جداگانه بررسی شده است.)
به‌عبارت ساده: Contingency Plan می‌گوید «اگر این شد، این کار را می‌کنیم»، Fallback Plan می‌گوید «اگر آن هم نشد، این کار را می‌کنیم» و برنامهٔ تداوم می‌گوید «چطور کل کسب‌وکار را سرپا نگه داریم».
برای کدام ریسک‌ها باید برنامهٔ جایگزین ساخت؟
ساختن برنامهٔ جایگزین برای هر ریسک، اتلاف منابع است. اولویت را بر پایهٔ دو معیار «شدت اثر» و «قابلیت پیش‌بینی/احتمال» بگذارید:
| نوع ریسک | احتمال | شدت | نیاز به Contingency Plan |
|---|---|---|---|
| قطعی سیستم حیاتی | کم | بسیار زیاد | بله، الزامی |
| خروج فرد کلیدی | متوسط | زیاد | بله |
| تأخیر تأمین‌کنندهٔ انحصاری | بالا | زیاد | بله |
| تغییر جزئی درخواست‌ها | بالا | کم | نه؛ کنترل تغییر کافی است |
| رویداد طبیعی نادر | بسیار کم | بسیار زیاد | فقط در سطح برنامهٔ تداوم کسب‌وکار |
قاعدهٔ ساده: برای ریسک‌هایی برنامهٔ جایگزین بسازید که «اگر رخ دهند، پروژه فلج می‌شود» و «می‌توان پیش از وقوع برایشان تدارک دید».
یک Contingency Plan خوب چه اجزایی دارد؟
برنامهٔ جایگزین باید آن‌قدر روشن باشد که در لحظهٔ بحران، نیازی به تصمیم‌گیری تازه نباشد. اجزای ضروری:
- ریسک هدف: دقیقاً برای کدام ریسک نوشته شده است.
- شرط فعال‌سازی (Trigger): چه علامتی مشخص می‌کند باید این برنامه اجرا شود.
- اقدامات گام‌به‌گام: چه کسی دقیقاً چه کاری انجام می‌دهد.
- مالک و جانشین: مسئول اجرا و نفر جایگزین او.
- منابع موردنیاز: بودجه، نیرو، ابزار و مجوزها.
- بازهٔ زمانی: هر اقدام در چه فاصله‌ای باید انجام شود.
- معیار خروج: از کجا بفهمیم وضعیت به حالت عادی برگشته است.
- نقطهٔ بازبینی: چه زمانی برنامه بازبینی و به‌روز می‌شود.
نکتهٔ کلیدی: اگر برنامه شرط فعال‌سازی و مالک ندارد، در عمل فقط یک توصیهٔ کلی است، نه یک برنامه.
چگونه یک Contingency Plan بسازیم؟ گام‌به‌گام
- ریسک‌های بحرانی را انتخاب کنید: از فهرست ریسک‌ها، آن‌هایی که شدت بالا دارند.
- سناریوی تحقق را روایت کنید: اگر این ریسک رخ دهد، دقیقاً چه اتفاقی می‌افتد و چه چیزی از کار می‌افتد.
- پاسخ اصلی را انتخاب کنید: اول سعی کنید احتمال یا اثر ریسک را کاهش دهید (کاهش ریسک).
- برنامهٔ جایگزین را طراحی کنید: اگر با وجود کاهش، ریسک رخ داد، چه می‌کنیم.
- شرط فعال‌سازی را تعیین کنید: علامت روشن و قابل‌مشاهده.
- مالک و منابع را تخصیص دهید: مسئول اجرا و بودجهٔ لازم.
- تمرین و شبیه‌سازی کنید: یک بار برنامه را روی کاغذ یا در جلسه اجرا کنید.
- ثبت، پایش و به‌روزرسانی: برنامه را در ابزار مدیریت پروژه نگه دارید و در نقاط عطف بازبینی کنید.
شرط فعال‌سازی (Trigger) چطور نوشته می‌شود؟
شرط فعال‌سازی باید قابل‌مشاهده و بدون ابهام باشد. «احساس خطر» شرط نیست. نمونه‌های درست: «اگر تأمین‌کننده تا تاریخ ۱۵ ماه دو تأیید نهایی را نفرستد»، «اگر نرخ خطای سیستم در دو روز پیاپی بالای ۳ درصد بماند»، «اگر فرد کلیدی بیش از پنج روز کاری غایب باشد».
مثال‌های عددی از Contingency Plan
- پروژهٔ پیاده‌سازی نرم‌افزار با سرور حیاتی: ریسک قطعی سرور شناسایی شد. برنامهٔ جایگزین: نسخهٔ پشتیبان روی سرور دوم با فعال‌سازی کمتر از ۴ ساعت. تمرین این برنامه نشان داد این زمان ۳ ساعت و ۲۰ دقیقه است. وقتی قطعی واقعی رخ داد، سرویس در بازهٔ توافق‌شده برگشت و جریمهٔ خدمت فعال نشد.
- پروژهٔ تولید با تأمین‌کنندهٔ انحصاری: ریسک تأخیر تأمین‌کننده با احتمال متوسط و شدت زیاد. برنامه: موجودی اطمینان ۳ هفته‌ای و تأمین‌کنندهٔ جایگزین تأییدشده. هزینهٔ نگهداری موجودی حدود ۴ درصد بودجهٔ پروژه بود، اما در برابر توقف ۳ هفته‌ای خط تولید، توجیه‌پذیر شد.
- پروژهٔ مشاورهٔ مالی با فرد کلیدی: ریسک خروج مشاور اصلی. برنامه: مستندسازی روش‌ها، آموزش جانشین و تعریف دسترسی دوم. با غیبت ناگهانی مشاور، پروژه فقط ۵ روز کند شد، در حالی که بدون برنامه، احتمال توقف کامل چند هفته‌ای وجود داشت.
- پروژهٔ رویداد با مکان اجاره‌ای: شرط فعال‌سازی: «اگر تا ۱۰ روز قبل، مجوز نهایی مکان صادر نشود». برنامهٔ جایگزین: یک مکان دوم از قبل بازدیدشده. با عدم صدور مجوز، رویداد بدون تأخیر در مکان جایگزین برگزار شد.
Contingency Plan برای سه دستهٔ ریسک پرتکرار
بیشتر برنامه‌های جایگزین پروژه در سه دسته خلاصه می‌شوند: تأمین و وابستگی بیرونی، فناوری و داده، و نیروی انسانی. برای هر دسته، شکل برنامه متفاوت است:
| دستهٔ ریسک | نمونهٔ ریسک | شکل برنامهٔ جایگزین | شرط فعال‌سازی نمونه |
|---|---|---|---|
| تأمین و بیرون | تأخیر تأمین‌کنندهٔ انحصاری | منبع دوم + موجودی اطمینان | عبور از تاریخ تعهد |
| فناوری و داده | قطعی سیستم حیاتی | سرور پشتیبان + روش کار دستی موقت | قطعی بیش از ۱ ساعت |
| نیروی انسانی | خروج فرد کلیدی | جانشین آموزش‌دیده + مستندسازی | غیبت بیش از ۵ روز |
| مالی | قطع بودجهٔ یک بخش | کاهش محدوده + اولویت‌بندی مجدد | ابلاغ کاهش بیش از ۲۰٪ |
این دسته‌بندی به شما کمک می‌کند هنگام ساخت برنامه، از قالب‌های تکراری استفاده کنید و سرعت طراحی بالا برود.
تمرین و شبیه‌سازی Contingency Plan چگونه انجام می‌شود؟
برنامهٔ جایگزین تا وقتی اجرا نشده، فقط یک فرضیه است. تمرین آن لازم نیست همیشه واقعی و پرهزینه باشد؛ می‌تواند یک «شبیه‌سازی روی میز» باشد. گام‌های ساده:
- سناریو را اعلام کنید: بگویید «فرض کنید همین حالا این ریسک رخ داده است».
- بدون راهنمایی اجرا کنید: اجازه دهید تیم بر پایهٔ سند، گام‌ها را طی کند.
- زمان و گلوگاه را ثبت کنید: هر مرحله چقدر طول کشید و کجا تیم معطل ماند.
- نقاط کور را پیدا کنید: کدام اطلاعات یا دسترسی در سند نبود.
- برنامه را اصلاح کنید: سند را با یافته‌های تمرین به‌روز و دوباره تأیید کنید.
یک تمرین ساده ۴۵ دقیقه‌ای می‌تواند پیش از بحران، ضعف‌های برنامه را نشان دهد. تجربه نشان می‌دهد بزرگ‌ترین نقص این تمرین‌ها کشف «مالک غیرقابل‌دسترس» و «نبود دسترسی کلید» است — مواردی که روی کاغذ دیده نمی‌شوند.
چک‌لیست آمادگی برنامهٔ جایگزین
پیش از اینکه یک برنامهٔ جایگزین را نهایی اعلام کنید، این چک‌لیست را مرور کنید. هر «بله» یعنی برنامه در بحران واقعاً قابل‌استفاده است:
- آیا شرط فعال‌سازی عددی و بدون ابهام نوشته شده است؟
- آیا مسئول اجرا و جانشین او مشخص شده‌اند؟
- آیا منابع (بودجه، نیرو، دسترسی) از قبل تدارک دیده شده‌اند؟
- آیا بازهٔ زمانی هر اقدام نوشته شده است؟
- آیا معیار خروج و بازگشت به حالت عادی تعریف شده است؟
- آیا برنامه یک بار تمرین یا حداقل مرور شده است؟
- آیا در همان ابزاری ثبت است که تیم روزمره از آن استفاده می‌کند؟
- آیا تاریخ بازبینی بعدی تعیین شده است؟
اگر به هر یک از این موارد پاسخ «خیر» است، برنامهٔ جایگزین شما در بحران معطل می‌ماند. بیشتر شکست‌های برنامه‌های اضطراری، نه به‌خاطر ایدهٔ بد، بلکه به‌خاطر نبود یکی از همین هشت مورد رخ می‌دهد.
۶۰ دقیقهٔ اول بحران: کاری که برنامهٔ جایگزین باید ممکن کند
بحران با یک ویژگی شناخته می‌شود: فشار برای تصمیم فوری. یک برنامهٔ جایگزین خوب، ۶۰ دقیقهٔ اول را به مسیر از پیش تعیین‌شده تبدیل می‌کند. در این بازه، تیم باید دقیقاً بداند چه کاری انجام دهد:
- تأیید فعال‌سازی (۵ دقیقه): مالک ریسک تأیید می‌کند که شرط فعال‌سازی محقق شده است.
- اطلاع‌رسانی (۵ دقیقه): ذی‌نفعان کلیدی و اعضای تیم از فعال‌شدن برنامه باخبر می‌شوند.
- اجرای اقدامات مرحلهٔ اول (۳۰ دقیقه): گام‌هایی که باید فوراً انجام شوند؛ مثل فعال‌سازی سرور پشتیبان یا توقف یک انتشار.
- ارزیابی وضعیت (۱۵ دقیقه): آیا اقدامات اثر گذاشتند؟ چه اطلاعات جدیدی هست؟
- تصمیم برای ادامه (۵ دقیقه): ادامهٔ برنامه، تغییر مسیر یا ارجاع به سطح بالاتر.
این ساختار، از اتلاف زمان در مکالمه‌های پراکنده جلوگیری می‌کند. حتی اگر اعداد دقیق نباشند، همین چارچوب، تیم را از سردرگمی نجات می‌دهد و اجازه نمی‌دهد بحران به هرج‌ومرج تبدیل شود. نکتهٔ کلیدی این است که برنامه باید «اولین ۶۰ دقیقه» را روشن کرده باشد؛ جزئیات بعدی می‌توانند در جریان بحران تنظیم شوند.
مزایا، معایب و Trade-off
| مزایا | معایب و محدودیت‌ها |
|---|---|
| کاهش زمان واکنش در بحران | هزینهٔ تدارک منابع و موجودی اطمینان |
| تصمیم‌های باکیفیت‌تر در لحظهٔ بحران | نگهداری برنامه‌های متعدد، بار مدیریتی دارد |
| حفاظت از ددلاین و قرارداد | خطر احساس امنیت کاذب و کم‌توجهی به پیشگیری |
| شفافیت مسئولیت در بحران | برنامهٔ به‌روز‌نشده در لحظهٔ نیاز بی‌فایده است |
| افزایش اعتماد ذی‌نفعان | طراحی برنامهٔ خوب، زمان و مهارت می‌خواهد |
Trade-off اصلی: Contingency Plan همیشه هزینه دارد — یا به‌صورت منابع کنارگذاشته‌شده، یا به‌صورت زمان طراحی و تمرین. بنابراین فقط برای ریسک‌هایی که اثرشان از هزینهٔ برنامه بیشتر است، توجیه دارد. برای ریسک‌های کوچک، کنترل و پایش کافی است.
اشتباهات رایج
- برنامهٔ بدون شرط فعال‌سازی: «اگر مشکلی پیش آمد» شرط نیست؛ علامت روشن لازم است.
- نوشتن برای همهٔ ریسک‌ها: برنامه‌های زیاد و کم‌کیفیت، مدیریت را فلج می‌کند.
- نبود مالک و جانشین: اگر مسئول اجرا در دسترس نباشد، برنامه معطل می‌ماند.
- نادیده‌گرفتن تدارک منابع: برنامهٔ جایگزین بدون بودجه و نیرو، فقط روی کاغذ است.
- یک‌بار‌وهمیشه: ریسک‌ها و شرایط عوض می‌شوند؛ برنامهٔ قدیمی گاهی خطرناک‌تر از نبود برنامه است.
- اشتباه‌گرفتن با برنامهٔ تداوم کسب‌وکار: Contingency Plan پروژه‌محور است، نه سازمانی.
- نبود تمرین: برنامه‌ای که یک بار آزمایش نشده، در بحران با غافلگیری روبه‌رو می‌شود.
نکات کاربردی
- نکته مهم: اول ریسک را کاهش دهید، بعد برنامهٔ جایگزین بنویسید؛ برنامهٔ جایگزین جای پیشگیری را نمی‌گیرد.
- ترفند کاربردی: شرط فعال‌سازی را عددی بنویسید (درصد، روز، تعداد) تا بحث سلیقه‌ای نشود.
- اشتباه رایج: بازهٔ زمانی اقدامات را ننوشتن؛ در بحران، «چه زمانی» به‌اندازهٔ «چه کاری» مهم است.
- قبل از شروع این را بدانید: بودجهٔ اجرای برنامهٔ جایگزین باید از ذخیرهٔ احتمال تأمین شود، نه از بودجهٔ عمومی که برای کار عادی کنار گذاشته شده است.
- معیار سنجش: برنامهٔ خوب، در یک شبیه‌سازی بدون تصمیم‌گیری تازه قابل اجراست.
چه کسی مسئول نگهداری Contingency Plan است؟
مالک ریسک، نه فقط مدیر پروژه. برای هر برنامهٔ جایگزین یک مالک تعیین کنید که موظف است شرایط را پایش کند و در صورت رسیدن به شرط فعال‌سازی، اجرا را آغاز کند. این مالک باید اختیار کافی برای شروع اقدامات را داشته باشد؛ در غیر این صورت، در لحظهٔ بحران منتظر تأیید می‌ماند و زمان طلایی از دست می‌رود.
دوایتفای و Contingency Plan
برنامهٔ جایگزین فقط وقتی در بحران به کار می‌آید که در همان ابزاری نگه داشته شود که کار پروژه در آن جریان دارد. دوایتفای یک پلتفرم جامع مدیریت پروژه، مدیریت تیم و رسیدن به اهداف است و امکان می‌دهد برای هر ریسک بحرانی یک برنامهٔ جایگزین با تسک، زیرتسک، چک‌لیست، مسئول و ددلاین بسازید؛ بخش ریسک‌ها و محدودیت‌ها، Milestone، تقویم، گانت‌چارت و گزارش‌های عملکرد به شما نشان می‌دهد چه زمانی یک شرط فعال‌سازی محقق شده است. اتوماسیون‌ها می‌توانند هشدارها را به مسئول برسانند و چت تیمی، هماهنگی اقدامات بحرانی را سریع‌تر کند. Doitify Copilot و AI Coach نیز می‌توانند در طراحی سناریو و تبدیل آن به برنامهٔ اجرایی کمک کنند. دوایتفای محصول ماست و طبعاً امکاناتش را از نزدیک می‌شناسیم؛ اما برای تیم‌های کوچک، حتی یک سند کوتاه با شرط فعال‌سازی و مسئول هم می‌تواند جان پروژه را نجات دهد.
چطور بفهمیم برنامهٔ جایگزین کافی است؟
یک آزمون ساده وجود دارد: سند برنامه را به فردی بدهید که در پروژه حاضر نبوده و بپرسید «اگر همین حالا این ریسک رخ دهد، چه می‌کنی؟». اگر او بتواند فقط با خواندن سند، گام‌های اول را درست توضیح دهد، برنامه روشن است. اگر نتواند، یعنی برنامه به دانش ذهنی تیم وابسته است و در غیبت اعضای کلیدی کار نمی‌کند.
این آزمون «تازه‌وارد» همچنین مشخص می‌کند کدام دسترسی‌ها فرض گرفته شده‌اند. بسیاری از برنامه‌های جایگزین روی کاغذ کامل‌اند، اما در عمل چون نرم‌افزار یا حساب کاربری لازم در دسترس فرد مجری نیست، شکست می‌خورند. ثبت «پیش‌نیازهای دسترسی» به همان اندازهٔ ثبت اقدامات مهم است و باید در همان سند بیاید.
سوالات متداول
جمع‌بندی
Contingency Plan یعنی تصمیم‌گیری در آرامش، نه در بحران. برای ریسک‌های بحرانی پروژه یک برنامهٔ جایگزین بنویسید که شرط فعال‌سازی روشن، اقدامات گام‌به‌گام، مالک، منابع و بازهٔ زمانی داشته باشد؛ بودجهٔ آن را از ذخیرهٔ احتمال تأمین کنید و پیش از وقوع، یک بار تمرینش کنید. مهم‌ترین درس این است که برنامهٔ جایگزین جای پیشگیری را نمی‌گیرد و برای هر ریسک جزئی هم ساخته نمی‌شود؛ فقط برای آن ریسک‌هایی که «اگر رخ دهند پروژه فلج می‌شود و می‌توان از قبل برایشان تدارک دید». اگر این مرزها را رعایت کنید، برنامهٔ جایگزین به یک بیمه‌نامهٔ واقعی برای پروژه تبدیل می‌شود.
اگر موضوع Contingency Plan برایتان مفید بود، پیشنهاد می‌کنیم برنامه ریزی ماهانه؛ آموزش کامل + جدول، نمونه، روش ۳-۴-۱ و ابزارهای کاربردی و روش CPM چیست؟ آموزش محاسبه مسیر بحرانی پروژه را هم بخوانید.
همین امروز به دوایتیفای بپیوندید
پروژه‌ها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفت‌ها و گزارش‌های تیم در یک محیط یکپارچه. ساخته‌شده برای شرکت‌ها، استارتاپ‌ها و تیم‌های دورکار — با راه‌اندازی چنددقیقه‌ای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
