چرا این تصمیم سخت بود؟
پیش از ورود به مراحل LIAM، باید دید چه نیروهایی تصمیم را در دو جهت متفاوت می‌کشیدند.
درآمد بزرگ، نقدینگی نامطمئن
عدد قرارداد جذاب بود، اما زمان پرداخت می‌توانست فشار نقدی جدی ایجاد کند.
اعتبار بیشتر، ظرفیت محدود
نمونه‌کار سازمانی ارزشمند بود، اما تیم هم‌زمان دو پروژه فعال داشت.
فرصت فوری، قرارداد مبهم
مشتری پاسخ سریع می‌خواست، در حالی که دامنه و مسئولیت تغییرات هنوز روشن نبود.
صورت مسئله و گزینه‌ها
پروژه قبل از جذاب‌بودن باید قابل‌پذیرش باشد
چه شرط‌هایی اگر پاس نشوند، ادامه بررسی پروژه بی‌معنی است؟
تصمیم واقعاً درباره چه بود؟
مسئله فقط اضافه‌شدن یک قرارداد بزرگ نبود؛ باید روشن می‌شد آیا پروژه بدون به‌خطر انداختن نقدینگی، کیفیت تحویل و اعتبار آژانس قابل پذیرش است.
داخل و خارج این تصمیم
- داخل: پذیرش، رد یا پذیرش مشروط همین پروژه.
- داخل: شروط مالی، دامنه کار و ظرفیت لازم برای اجرای آن.
- خارج: بازطراحی کامل مدل کسب‌وکار آژانس.
- خارج: استخدام بلندمدت برای پروژه‌های احتمالی آینده.
شرط‌های حداقلی پیش از بررسی جذابیت پروژه
| شرط لازم | مرز قابل قبول | اثر نقض شرط |
|---|---|---|
| پیش‌پرداخت | حداقل ۲۵٪ پیش از شروع | رد یا مذاکره مجدد |
| زمان پرداخت | حداکثر ۴۵ روز | پذیرش مشروط |
| کنترل تغییرات | هر تغییر دامنه باید قیمت و زمان جدا داشته باشد | رد |
| ظرفیت تیم | بیش از ۹۰٪ ظرفیت پایدار اشغال نشود | کاهش دامنه یا تقویت تیم |
| حاشیه سود | کمتر از ۳۰٪ نباشد | رد |
اگر پروژه پذیرفته شود
- درآمد و اعتبار بالقوه افزایش می‌یابد.
- فشار نقدینگی، تمرکز و تحویل هم‌زمان بالا می‌رود.
- یک مشتری بزرگ می‌تواند سهم زیادی از ظرفیت را قفل کند.
اگر پروژه پذیرفته نشود
- ریسک فشار عملیاتی و بدحسابی حذف می‌شود.
- فرصت درآمد و نمونه‌کار مهم از دست می‌رود.
- تیم برای مشتریان فعلی و فرصت‌های کوچک‌تر آزاد می‌ماند.
این مرحله چه چیزی را تغییر داد؟
بحث روی رقم قرارداد و اعتبار مشتری می‌چرخید.
مرزهای مالی، قراردادی و ظرفیت به شرط‌های قابل مشاهده تبدیل شد.
پذیرش فوری از روی میز خارج شد و مذاکره مشروط به گزینه واقعی تبدیل شد.
جذابیت پروژه دیگر نمی‌توانست نقض حداقل‌های حیاتی را پنهان کند.
شواهد و عدم قطعیت
وعده‌های پروژه از شواهد قابل اتکا جدا شد
برای پذیرفتن پروژه چه چیزهایی باید واقعاً درست باشد؟
آنچه می‌دانستیم
- ارزش اسمی قرارداد ۱.۸ میلیارد تومان بود.
- تحویل در سه فاز و طی چهار ماه درخواست شده بود.
- دو پروژه جاری تا شش هفته آینده ادامه داشتند.
- هزینه مستقیم اجرای پروژه قابل برآورد بود.
آنچه فقط فرض می‌کردیم
- پروژه احتمالاً به قراردادهای بعدی منجر می‌شود.
- مشتری در زمان مقرر پرداخت خواهد کرد.
- تیم با کمی اضافه‌کاری فشار را تحمل می‌کند.
- دامنه کار پس از شروع ثابت می‌ماند.
نادانسته‌های تصمیم‌ساز
- سابقه واقعی پرداخت مشتری چگونه است؟
- چه کسی تغییر دامنه را تأیید می‌کند؟
- اگر فاز اول عقب افتاد، مسئولیت و جریمه چگونه تقسیم می‌شود؟
- حداقل نیروی لازم برای حفظ کیفیت مشتریان فعلی چقدر است؟
بررسی‌هایی که قبل از پاسخ نهایی انجام شد
| سؤال حیاتی | روش بررسی | یافته | اثر بر تصمیم |
|---|---|---|---|
| پرداخت مشتری چقدر قابل اتکاست؟ | استعلام از دو تأمین‌کننده قبلی | تأخیرهای ۲۰ تا ۴۰ روزه سابقه داشت | پیش‌پرداخت و سقف مطالبات ضروری شد |
| دامنه کار چقدر پایدار است؟ | مرور RFP و جلسه فنی | سه بخش مبهم و مستعد افزایش دامنه بود | پیوست کنترل تغییرات لازم شد |
| تیم ظرفیت دارد؟ | برآورد بار هفتگی هر نقش | با دامنه کامل، ظرفیت به ۱۰۸٪ می‌رسید | پذیرش کامل کنار رفت |
| ارزش راهبردی واقعی چیست؟ | بررسی دسترسی به صنعت و نمونه‌کار | ارزش برند بالا اما قرارداد بعدی تضمین‌شده نبود | مزیت حفظ شد اما وزن آن کاهش یافت |
رقم بزرگ قرارداد نباید جای کیفیت جریان نقدی و ظرفیت واقعی را بگیرد. پروژه سودآور روی کاغذ، با تأخیر پرداخت و اضافه‌کاری مزمن می‌تواند به تصمیم زیان‌بار تبدیل شود.
این مرحله چه چیزی را تغییر داد؟
اعتبار برند مشتری و رقم قرارداد به‌عنوان تضمین موفقیت دیده می‌شد.
سابقه پرداخت، ابهام دامنه، بار تیم و ارزش راهبردی جداگانه اعتبارسنجی شد.
پذیرش کامل تضعیف و نیاز به شروط قراردادی تقویت شد.
تصمیم از خوش‌بینی درباره مشتری به واقعیت جریان نقدی و اجرا متصل شد.
تحلیل و هم‌راستاسازی
پاسخ از «بله یا نه» به «بله، فقط با این شروط» رسید
آیا نسخه اصلاح‌شده پروژه حداقل‌ها را پاس می‌کند و ارزش پذیرش دارد؟
گیت نهایی انجام دادن یا ندادن
| معیار | وضعیت پیشنهاد اولیه | نسخه مذاکره‌شده | حکم |
|---|---|---|---|
| پیش‌پرداخت | ۱۰٪ | ۳۰٪ | پاس شد |
| پرداخت | ۶۰ روز | ۳۰ روز برای هر فاز | پاس شد |
| کنترل تغییرات | مبهم | پیوست رسمی تغییر دامنه | پاس شد |
| ظرفیت تیم | ۱۰۸٪ | ۸۶٪ با کاهش دامنه فاز اول | پاس شد |
| حاشیه سود | ۲۷٪ | ۳۴٪ | پاس شد |
| ریسک تمرکز مشتری | بالا | بالا اما محدود به چهار ماه | پایش شود |
چرا پذیرش فوری کنار گذاشته شد؟
نسخه اولیه سه شرط حداقلی را نقض می‌کرد: پیش‌پرداخت ناکافی، ظرفیت بیش از حد و کنترل ضعیف تغییرات.
چرا رد کامل کنار گذاشته شد؟
بخش بزرگی از ریسک‌ها با مذاکره قابل کاهش بود و ارزش مالی و اعتباری پروژه پس از اصلاح شروط همچنان معنی‌دار ماند.
پذیرش مشروط پروژه
پروژه پذیرفته می‌شود، اما نه با شرایط اولیه. فعال‌شدن تصمیم منوط به ثبت شروط مالی، کاهش دامنه فاز نخست و تأیید ظرفیت اجرایی است.
این مرحله چه چیزی را تغییر داد؟
دو پاسخ افراطی وجود داشت: پذیرش کامل یا از دست‌دادن فرصت.
نسخه اولیه و مذاکره‌شده در برابر شرط‌های حداقلی سنجیده شدند.
تصمیم نهایی به پذیرش مشروط و قابل لغو تبدیل شد.
تعهد فقط زمانی فعال شد که ریسک‌های تصمیم‌ساز مهار شده بودند.
حرکت، پایش و اصلاح
پذیرش به یک سیستم کنترل‌شده برای اجرا تبدیل شد
چطور پروژه شروع شود بدون اینکه شرط‌های تصمیم در فشار اجرا فراموش شوند؟
فعال‌سازی تصمیم؛ قبل از شروع پروژه
قرارداد نهایی
- پیش‌پرداخت وصول شود.
- پیوست تغییر دامنه امضا شود.
- تقویم پرداخت هر فاز ثبت شود.
ظرفیت اجرا
- مالک هر خروجی مشخص شود.
- بار هفتگی تیم ثبت شود.
- کارهای قابل تعویق مشتریان فعلی تعیین شود.
اقدام ۴۸ ساعت اول
- جلسه شروع با تصمیم‌گیر اصلی مشتری.
- تأیید دامنه فاز اول.
- ثبت خط مبنای زمان، هزینه و ظرفیت.
قواعد اگر/آنگاه برای کنترل پروژه
| اگر این نشانه دیده شد | اقدام از پیش تعیین‌شده | هدف |
|---|---|---|
| پرداخت بیش از ۱۵ روز عقب افتاد | شروع فاز بعد متوقف و موضوع به مدیر مالی مشتری ارجاع شود | جلوگیری از رشد مطالبات |
| ظرفیت تیم دو هفته پیاپی از ۹۰٪ عبور کرد | دامنه فاز بعد کاهش یا نیروی موقت اضافه شود | حفظ کیفیت و انرژی تیم |
| تغییر دامنه بدون بودجه جدید درخواست شد | درخواست ثبت و تا تأیید رسمی اجرا نشود | حفاظت از سود پروژه |
| حاشیه سود پیش‌بینی‌شده زیر ۲۸٪ رفت | پروژه وارد بازبینی مالی و مذاکره مجدد شود | جلوگیری از زیان پنهان |
اگر شروط قرارداد کامل نشود، آژانس پروژه را رد می‌کند و ظرفیت آزادشده را میان حفظ مشتریان فعلی و جذب دو پروژه کوچک‌تر تقسیم خواهد کرد.
این مرحله چه چیزی را تغییر داد؟
تصمیم خوب روی کاغذ وجود داشت، اما امکان فرسایش شروط در اجرا بالا بود.
اقدام‌های آغازین، سنجه‌ها، هشدارها و مسیر جایگزین ثبت شد.
هر ریسک مهم به یک مالک و قاعده اگر/آنگاه متصل شد.
تیم می‌دانست چه زمانی ادامه دهد، مذاکره کند یا فاز بعد را متوقف سازد.
از این تصمیم چه می‌آموزیم؟
این نکات نتیجه خاص پرونده را نسخه عمومی نمی‌کنند؛ فقط سؤال‌ها و محافظ‌هایی را نشان می‌دهند که در تصمیم‌های مشابه ارزش بررسی دارند.
رقم قرارداد با کیفیت پول یکی نیست
زمان وصول، پیش‌پرداخت و ریسک مطالبات بخشی از ارزش واقعی پروژه‌اند.
حداقل‌ها قبل از مزایا بررسی می‌شوند
گزینه‌ای که شرط حیاتی را نقض می‌کند نباید فقط به‌دلیل جذابیت وارد امتیازدهی شود.
«پذیرش مشروط» یک گزینه مستقل است
مذاکره می‌تواند تصمیم دوگانه قبول یا رد را به گزینه‌ای بهتر تبدیل کند.
ظرفیت باید با عدد دیده شود
عبارت «تیم از پسش برمی‌آید» بدون محاسبه بار واقعی، شاهد محسوب نمی‌شود.
Tripwire تصمیم را در اجرا زنده نگه می‌دارد
پیش از فشار پروژه باید معلوم باشد چه نشانه‌ای باعث توقف یا مذاکره مجدد می‌شود.