مسئله
پروژه چند واحد و چند تیم داشت و تیم فنی و حمایت مدیران هم کافی بود، اما پیشرفت نمی‌کرد. تصمیم‌ها دیر گرفته می‌شدند، مالک مشخصی نداشتند و موانع وقتی دیده می‌شدند که بحران شده بودند. بررسی نشان داد کمبود تخصص در کار نیست. نتیجه نهایی برای ذی‌نفعان یکسان تعریف نشده بود، مسئولیت اجرا با تأیید قاطی شده بود و موانع مسیری برای ارجاع به مدیریت نداشتند.
راهکار
قبل از هر نرم‌افزار یا فرم جدید، روی پنج سؤال توافق شد: نتیجه نهایی چیست، مالک هر تصمیم کیست، خروجی هر مرحله چیست، وابستگی‌ها کدام‌اند و چه موضوعی باید فوراً به مدیریت برسد. بعد پروژه به بسته‌های کاری تقسیم شد و برای هر اقدام مسئول، موعد، خروجی و وابستگی تعیین شد. جلسات و گزارش‌ها هم روی تصمیم لازم و مانع موجود متمرکز شدند. برای مقابله با مقاومت، تعداد فرم‌ها و گزارش‌ها محدود ماند.
نتیجه
مدیران و تیم اجرایی تصویر مشترکی از وضعیت پروژه پیدا کردند. مسئولیت اقدامات روشن شد، موضوعات معطل سریع‌تر به تصمیم‌گیر می‌رسید و جلسات به جای مرور گذشته صرف رفع موانع آینده شد. مدیریت پروژه از گزارش‌گیری به هماهنگ‌کردن تصمیم‌ها، منابع و مسئولیت‌ها تغییر کرد.
همه‌چیز بود، جز پیشرفت
در سال‌های فعالیت من در پروژه‌های صنعتی و فناورانه، بارها با موقعیتی مشابه روبه‌رو شده‌ام. سازمان مسئله مشخصی دارد، تیم‌های فنی و شرکت‌های دانش‌بنیان توان لازم را دارند و مدیران نیز از اجرای پروژه حمایت می‌کنند؛ با این حال، پروژه متناسب با انتظار پیش نمی‌رود.
فعالیت‌های زیادی انجام می‌شود، جلسات متعددی برگزار می‌شود و هر واحد گزارش خود را ارائه می‌کند، اما تصمیم‌ها با تأخیر گرفته می‌شوند، مسئولیت‌ها میان افراد جابه‌جا می‌شوند و موانع اصلی پروژه زمانی دیده می‌شوند که به بحران تبدیل شده‌اند.
تجربه من نشان داد که در بسیاری از این پروژه‌ها، مشکل اصلی کمبود تخصص فنی نیست. مسئله، فاصله‌ای است که میان تصمیم مدیریتی و اجرای واقعی آن وجود دارد.
مسئله‌ای که مطرح بود
در یکی از تجربه‌های مبنای این روایت، پروژه‌ای با مشارکت چند واحد سازمانی و چند تیم تخصصی در جریان بود. هر بخش، تعریف متفاوتی از موفقیت پروژه داشت.
مدیریت ارشد انتظار نتیجه داشت، تیم فنی بر کیفیت و امکان‌پذیری راهکار تمرکز می‌کرد، واحد مالی درباره هزینه‌ها و تعهدات نگران بود و بخش اجرایی منتظر تصمیم‌هایی بود که مسئول یا موعد مشخصی نداشتند.
صورت‌جلسه‌ها نوشته می‌شدند، اما تصمیم‌ها الزاماً به اقدام تبدیل نمی‌شدند. گزارش پیشرفت نیز بیشتر شرح فعالیت‌های گذشته بود و به مدیران نشان نمی‌داد کدام مانع، تصمیم یا وابستگی می‌تواند آینده پروژه را تحت‌تأثیر قرار دهد. در ظاهر، پروژه فعال بود؛ اما میان فعالیت‌کردن و پیشرفت واقعی فاصله وجود داشت.
ریشه‌ی کار کجا بود؟
برداشت اولیه این بود که پروژه به نیروی بیشتر، جلسات بیشتر یا نرم‌افزار کنترل پروژه نیاز دارد. بررسی من نشان داد که اضافه‌کردن ابزار، بدون اصلاح منطق تصمیم‌گیری و اجرا، فقط حجم گزارش‌ها را بیشتر می‌کند.
ریشه مسئله در چند نقطه بود:
○ نتیجه نهایی برای تمام ذی‌نفعان به یک شکل تعریف نشده بود
○ مالک هر تصمیم مشخص نبود
○ مسئولیت اجرا با مسئولیت تأیید اشتباه گرفته می‌شد
○ وابستگی میان فعالیت‌ها دیر شناسایی می‌شد
○ موانع پروژه مسیر روشنی برای ارجاع به مدیران نداشتند
○ درصد پیشرفت بدون توجه به تصمیم‌های معطل‌مانده گزارش می‌شد
○ مسئله اصلی نبود برنامه نبود؛ پروژه فاقد یک نظام اجرایی مشترک بود.
نقش من
نقش من صرفاً تهیه برنامه زمان‌بندی یا پیگیری صورت‌جلسه‌ها نبود. باید میان زبان مدیریت، صنعت و فناوری ارتباط برقرار می‌کردم و مسئله‌ای را که هر واحد از زاویه خود می‌دید، به یک تصویر مشترک تبدیل می‌کردم.
تحصیلات مهندسی مکانیک، تجربه راهبری شرکت‌های فناور و تحصیل در دوره MBA با تخصص مدیریت پروژه، به من کمک کرد تا پروژه را هم از منظر فنی و هم از منظر مدیریتی بررسی کنم. مهم‌ترین مسئولیت من این بود که تصمیم‌های کلی و گاهی مبهم مدیریتی را به اقدام‌های روشن، زمان‌دار و قابل‌پیگیری تبدیل کنم.
از کجا شروع کردیم؟
تصمیم گرفتم به‌جای شروع با یک نرم‌افزار یا مجموعه‌ای از فرم‌های جدید، ابتدا درباره پنج پرسش توافق ایجاد کنیم:
○ نتیجه نهایی پروژه دقیقاً چیست؟
○ چه کسی مالک هر تصمیم است؟
○ خروجی قابل‌تحویل هر مرحله چیست؟
○ هر فعالیت به کدام تصمیم یا اقدام دیگر وابسته است؟
○ چه موضوعی باید فوراً به سطح مدیریت ارجاع داده شود؟
بر اساس پاسخ این پرسش‌ها، پروژه به بسته‌های کاری مشخص تقسیم شد. برای هر اقدام، مسئول اجرا، موعد، خروجی مورد انتظار و وابستگی آن به سایر فعالیت‌ها تعیین شد.
جلسات نیز بازطراحی شدند. به‌جای اینکه هر واحد گزارشی طولانی از اقدامات گذشته ارائه کند، گفت‌وگوها بر تصمیم مورد نیاز، مانع موجود و مسئول اقدام بعدی متمرکز شدند. از آن پس، گزارش پروژه قرار نبود فقط وضعیت را توصیف کند؛ باید مدیر را به یک تصمیم مشخص می‌رساند.
وقتی مسئولیت‌ها روشن می‌شود، مقاومت هم شروع می‌شود
مقاومت اولیه قابل پیش‌بینی بود. شفاف‌شدن مسئولیت‌ها برای همه خوشایند نیست، به‌خصوص در سازمان‌هایی که بخش زیادی از امور با پیگیری شفاهی و روابط فردی پیش می‌رود.
برخی افراد تصور می‌کردند این ساختار یک لایه کنترل اداری جدید به پروژه اضافه می‌کند. برای کاهش مقاومت، تعداد فرم‌ها و گزارش‌ها را محدود کردیم و ارزش هر ابزار را در حل یک مسئله واقعی نشان دادیم.
چالش دیگر، تفاوت زبان ذی‌نفعان بود. تیم فنی درباره کیفیت و امکان‌پذیری صحبت می‌کرد، مدیریت ارشد نتیجه و ریسک را می‌دید و واحدهای مالی و اجرایی محدودیت‌های خود را داشتند. بخش مهمی از کار من، ترجمه این دیدگاه‌ها به یک برنامه اجرایی مشترک بود.
نتیجه
پس از اجرای این رویکرد، مدیران و تیم اجرایی به تصویر مشترک‌تری از وضعیت پروژه رسیدند. مسئولیت اقدامات روشن‌تر شد، موضوعات معطل‌مانده سریع‌تر به فرد تصمیم‌گیر ارجاع داده شدند و جلسات از مرور اتفاقات گذشته به حل موانع آینده تغییر کردند.
تغییر مهم‌تر، تغییر نگاه تیم به مدیریت پروژه بود. مدیریت پروژه از یک واحد گزارش‌گیری یا مسئول به‌روزرسانی برنامه زمان‌بندی، به سازوکاری برای هماهنگ‌کردن تصمیم‌ها، منابع و مسئولیت‌ها تبدیل شد.
راهکار فنی لازم است، اما کافی نیست
در پروژه‌های پیچیده، داشتن راهکار فنی شرط لازم است، اما کافی نیست. پروژه زمانی از بن‌بست خارج می‌شود که تصمیم‌ها مالک مشخص داشته باشند، مسئولیت‌ها به خروجی قابل‌سنجش متصل شوند و موانع پیش از تبدیل‌شدن به بحران دیده شوند.
این تجربه به من نشان داد که مدیریت پروژه، مدیریت جدول‌ها و گزارش‌ها نیست. مدیر پروژه باید میان مسئله، تصمیم، مسئولیت و اقدام ارتباط ایجاد کند و اجازه ندهد پروژه در فاصله میان واحدها و ذی‌نفعان متوقف شود.
لبّ کلام
«پروژه زمانی پیش می‌رود که هر تصمیم، صاحب مشخص و هر مسئولیت، خروجی قابل‌سنجش داشته باشد.»