مدیرعامل یک هلدینگ می‌بیند که بیشتر پروژه‌ها در گزارش PMO وضعیت سبز دارند. نقاط تحویل ثبت شده، هزینه‌ها نزدیک بودجه‌اند و مدیران پروژه از درصد پیشرفت دفاع می‌کنند. اما هدف سالانه کاهش زمان خدمت به مشتریان کلیدی حرکت نکرده است. در جلسه بعد، PMO می‌گوید پروژه‌های تاییدشده را طبق برنامه تحویل می‌دهد. مدیر راهبرد می‌گوید شاید پروژه‌های درست انتخاب نشده‌اند. هر دو می‌توانند درست بگویند، زیرا کار آنها یکی نیست.
PMO یا دفتر مدیریت پروژه، نگهبان کیفیت تحویل پروژه است. SRO یا نقش اجرای راهبرد، نگهبان اتصال ابتکار به انتخاب و پیامد راهبردی است. سازمانی که این دو را یکی بگیرد، یا همه چیز را به زمان‌بندی پروژه فرو می‌کاهد یا از تیم پروژه انتظار دارد درباره مسئله‌های بازار و اولویت‌گذاری کلان به تنهایی تصمیم بگیرد. هم‌راستایی یعنی مرزها روشن باشند و اطلاعات درست در زمان درست از یک مرز به مرز دیگر برسد.
دو دفتر، دو سوال مدیریتی
| حوزه | سوال اصلی | شاهد قابل استفاده | تصمیم معمول |
|---|---|---|---|
| PMO | آیا پروژه مطابق محدوده، زمان، هزینه و کیفیت پیش می‌رود؟ | نقطه تحویل، مصرف بودجه، ریسک اجرایی، وابستگی فنی | بازبرنامه‌ریزی، رفع مانع، تغییر محدوده یا کنترل ریسک |
| SRO یا اجرای راهبرد | آیا ابتکار هنوز به هدف و فرض راهبردی وصل است؟ | پیامد، ارزش مشتری، ظرفیت، ریسک راهبردی، تغییر محیط | ادامه، توقف، بازطراحی یا جابه‌جایی اولویت |
| مدیر ارشد | میان ابتکارهای متعارض کدام انتخاب ارزش ظرفیت دارد؟ | سازگاری با انتخاب‌ها، منابع، ریسک و زمان تصمیم | تخصیص، توقف، تفویض یا بازنگری جهت |
پروژه سبز و راهبرد قرمز، الزاماً نشانه شکست PMO نیست. ممکن است پروژه همان چیزی را که تایید شده بود تحویل داده باشد، اما فرض اولیه درباره ارزش آن برای مشتری یا بازار ضعیف شده باشد. یا پروژه به خروجی رسیده ولی سازمان برای استفاده از خروجی، فرایند، مهارت یا ظرفیت لازم را آماده نکرده است. SRO باید این فاصله را قابل دیدن کند، نه اینکه پایان موفق یک پروژه را بی‌ارزش جلوه دهد.
از سوی دیگر، SRO نباید با دیدن یک شاخص قرمز، بدون فهم وضعیت پروژه درخواست توقف کند. شاید پیامد هنوز زمان تاخیر دارد، شاید داده ناقص است یا شاید مانع اجرایی قابل رفع است. گفت‌وگوی سالم بین این دو نقش، فرض را باز می‌کند: چه خروجی‌ای قرار بود چه پیامدی بسازد، چه شرطی باید برقرار می‌بود و چه شواهدی نشان می‌دهند اکنون باید اجرا را اصلاح کرد یا ابتکار را بازنگری کرد.
موفقیت پروژه را به پیامد ترجمه کنید
برای هر ابتکار مهم، یک زنجیره کوتاه بنویسید. «پروژه سامانه درخواست مشتری تحویل می‌شود» یک خروجی است. «درخواست‌های مهم در زمان توافق‌شده پاسخ می‌گیرند» پیامد نزدیک‌تری است. «مشتریان کلیدی تمدید می‌کنند» پیامد دیرتر است. PMO می‌تواند خروجی و سلامت اجرا را پایش کند. SRO باید بررسی کند آیا خروجی به پیامد نزدیک وصل شده و آیا شرایط لازم برای این اتصال برقرار است.
واژه‌نامه GAO برای سنجش عملکرد و ارزیابی میان رصد پیشرفت و ارزیابی اینکه چرا مداخله اثر داشته تمایز می‌گذارد. این تمایز برای PMO و SRO ارزش عملی دارد. درصد پیشرفت پروژه ممکن است بگوید کار در چه وضعی است، اما به تنهایی نمی‌گوید چرا مشتری رفتار خود را تغییر داده یا چرا هدف راهبردی حرکت نکرده است.
مدیران نباید برای پیوند میان پروژه و پیامد، یک رابطه قطعی بسازند. اگر پروژه تحویل شد اما پیامد نرسید، باید علت‌های ممکن را بررسی کنند: کیفیت تحویل، پذیرش کاربر، زمان، بخش مشتری، قیمت، رقابت یا یک فرض اشتباه. این روش تیم‌ها را از دو رفتار مخرب دور می‌کند: دفاع از پروژه به هر قیمت و مقصر دانستن تیم پروژه برای مسئله‌ای که خارج از اختیار آن است.
یک منشور مرزها را روشن می‌کند
در سازمان بزرگ، PMO و SRO ممکن است دو دفتر جدا باشند. در سازمان کوچک، شاید یک تیم هر دو نقش را اجرا کند. در هر دو حالت، منشور مشترک لازم است. منشور باید بگوید چه کسی پیشنهاد ابتکار را ثبت می‌کند، چه کسی توجیه راهبردی را بررسی می‌کند، چه کسی برنامه پروژه را تایید می‌کند، چه کسی درباره توقف یا بازطراحی تصمیم می‌گیرد و اختلاف چگونه به مدیر ارشد ارجاع می‌شود.
مرز خوب، دیوار نیست. PMO باید بتواند بگوید تغییر راهبردی چه اثری بر زمان، هزینه، وابستگی و ریسک پروژه دارد. SRO باید بتواند بگوید تاخیر یا تغییر محدوده چه اثری بر فرض و پیامد راهبردی دارد. هر دو دفتر به داده هم نیاز دارند، اما نگاه آنها به داده یکسان نیست. PMO داده را برای کنترل تحویل نیاز دارد. SRO داده را برای قضاوت درباره ارزش و اولویت نیاز دارد.
وقتی مرزها مبهم‌اند، مدیران میانی از جلسات متعدد خسته می‌شوند. یک بار از آنها گزارش پیشرفت می‌خواهند، بار دیگر گزارش راهبردی با تعریف متفاوت. منشور مشترک باید منبع واحد هر داده، تعریف آن، مصرف‌کننده و تناوب را روشن کند. این کار به معنی ساختن سامانه تازه نیست؛ ابتدا از توافق مدیریتی آغاز می‌شود.
سبد ابتکارات محل گفت‌وگوی مشترک است
PMO ممکن است سبد پروژه را بر پایه ظرفیت، وابستگی فنی و سلامت تحویل ببیند. SRO باید به همان سبد، ارزش راهبردی، تغییر محیط، پیامد مشتری و فرصت هزینه نگاه کند. هیچ‌یک به تنهایی کافی نیست. پروژه‌ای که ارزش راهبردی دارد اما ظرفیت ندارد، فقط آرزوست. پروژه‌ای که ظرفیت و برنامه دارد اما ارزش خود را از دست داده، بار سازمان است.
در مدیریت سبد پروژه‌ها و ابتکارات استراتژیک، هر ابتکار به هدف و نتیجه مورد انتظار وصل می‌شود و ارزش، منابع، ریسک و وابستگی در تصمیم ورود به سبد دیده می‌شوند. ادامه، توقف یا بازطراحی نیز در یک ریتم مشخص مرور می‌شود. این خدمت اجرای پروژه‌ها یا مدیریت منابع مشتری را تضمین نمی‌کند؛ هدف آن روشن‌کردن انتخاب و تعارض ظرفیت است.
برای هر ابتکار، تاریخ بازنگری و نقطه تصمیم تعیین کنید. اگر فرض مرتبط ضعیف شد، PMO باید اثر توقف یا تغییر بر پروژه‌های وابسته را توضیح دهد. SRO باید نشان دهد چرا فرض ضعیف شده و چه گزینه‌ای جایگزین است. مدیر ارشد سپس بین ادامه، کاهش دامنه، توقف یا تخصیص منابع تازه انتخاب می‌کند. این ترتیب، بحث را از «پروژه ما سبز است» به «این کار هنوز ارزش ظرفیت ما را دارد؟» منتقل می‌کند.
گزارش مشترک نباید دو جهان را یکی کند
چارچوب ارزیابی CDC بر پرسش روشن و شواهد معتبر تاکید دارد. گزارش مشترک می‌تواند مفید باشد، اگر در آن خروجی پروژه و پیامد راهبردی با هم قاطی نشوند. یک صفحه می‌تواند هدف راهبردی، فرض، ابتکار، وضعیت تحویل PMO، شاخص پیامد، ریسک باز و تصمیم بعدی را نشان دهد. مدیر با یک نگاه می‌فهمد کدام نوع مسئله در حال رخ دادن است: خطر زمان‌بندی، کمبود ظرفیت، ضعف پذیرش، فرض بازار یا ابهام داده.
در طراحی داشبورد پایش استراتژی، تصمیم پشتیبانی‌شونده، سنجه محدود، منبع داده، تناوب، زمینه انحراف و اقدام اصلاحی مرکز طراحی است. این توصیف به معنی اتصال خودکار ابزارهای پروژه، نمایش زنده داده یا پیش‌بینی نتیجه نیست. اگر سازمان روزی به کار فنی نیاز داشته باشد، باید دامنه و مسئولیت آن را جداگانه تعیین کند.
چارچوب Fogarty میان خروجی، پیامد و اثر فرق می‌گذارد. این فرق برای گزارش مشترک حیاتی است. راه‌اندازی یک سامانه یا اتمام یک ساختمان خروجی است. استفاده درست، کاهش خطا یا تغییر تجربه مشتری پیامد نزدیک‌تری است. اثر راهبردی ممکن است دیرتر دیده شود و به عوامل دیگری نیز وابسته باشد.
ریتم جلسه باید نوع تصمیم را دنبال کند
PMO به جلسه‌های نزدیک برای ریسک پروژه، وابستگی فنی و وضعیت تحویل نیاز دارد. SRO به بازنگری دوره‌ای برای فرض‌ها، پیامدها، سبد و انتخاب‌ها نیاز دارد. مدیران اجرایی به جلسه‌ای نیاز دارند که تعارض میان این دو سطح را حل کند. اگر یک جلسه بخواهد همه این کارها را انجام دهد، یا وقتش صرف جزئیات می‌شود یا تصمیم‌های کلان بدون شواهد می‌مانند.
در استقرار و پایش اجرای استراتژی، تناوب جلسه، سطح تصمیم، مالک نتیجه، مالک اقدام و منبع به‌روزرسانی شاخص‌ها عناصر رسمی خدمت‌اند. برای PMO و SRO، این به معنای تعیین مسیر ارجاع روشن است: چه چیزی در پروژه حل می‌شود، چه چیزی به سبد می‌رود و چه چیزی باید به انتخاب راهبردی بازگردد.
هر جلسه باید یک خروجی قابل پیگیری داشته باشد. برای مثال، «PMO تا هفته بعد اثر تغییر زمان‌بندی بر وابستگی‌ها را روشن می‌کند؛ SRO شواهد مشتری را جمع می‌کند؛ مدیر اجرایی در جلسه بعد درباره ادامه ابتکار تصمیم می‌گیرد.» این تقسیم کار هم پاسخ‌گویی می‌سازد و هم مانع از آن می‌شود که PMO یا SRO جای دیگری را پر کند.
مالک یکپارچه‌سازی همه کارها را انجام نمی‌دهد
چارچوب Baldrige در NIST عملکرد سازمانی را در یک نگاه وسیع می‌بیند. سازمان گاهی برای حل فاصله PMO و SRO یک نقش تازه ایجاد می‌کند و انتظار دارد آن نقش همه گزارش‌ها، پروژه‌ها و تصمیم‌ها را مدیریت کند. این کار فقط گلوگاه تازه می‌سازد. مالک یکپارچه‌سازی باید معماری گفت‌وگو را نگه دارد: تعریف‌های مشترک، زمان جلسه‌ها، مسیر ارجاع، قرارداد داده و فهرست تصمیم‌های باز. صاحب هر پروژه و هر پیامد همچنان باید در واحد مسئول خود باقی بماند.
این نقش می‌تواند در دفتر راهبرد، PMO یا زیر نظر مدیر اجرایی باشد. محل سازمانی مهم است، اما مهم‌تر از آن اختیار روشن برای مطرح‌کردن تعارض است. اگر یک ابتکار به هدف وصل نیست یا گزارش دو دفتر با هم ناسازگار است، مالک یکپارچه‌سازی باید بتواند مسئله را به سطح صاحب تصمیم ببرد. او نباید به جای مدیران انتخاب کند، اما نباید فقط صورت‌جلسه‌نویس هم باشد.
در آغاز، یک منشور کوتاه کافی است: چه تصمیم‌هایی مشترک‌اند، چه اطلاعاتی پیش از جلسه لازم‌اند، چه کسی مسئول کیفیت هر بخش داده است و چه نتیجه‌ای باعث ارجاع می‌شود. پس از دو یا سه چرخه، تیم می‌فهمد کدام مرزها عملی‌اند و کجا باید تغییر کنند. این یادگیری تدریجی، از طراحی یک ساختار سنگین بر پایه حدس جلوگیری می‌کند.
ریسک پروژه و ریسک راهبرد را در یک صف نگذارید
ISO 55000 ارزش، ریسک و هم‌راستایی را در چرخه عمر دارایی مطرح می‌کند. ریسک پروژه معمولاً به زمان، هزینه، تامین‌کننده، فناوری، کیفیت تحویل یا وابستگی فنی مربوط است. مالک آن اغلب مدیر پروژه یا مدیر برنامه است. ریسک راهبردی به یک سطح بالاتر اشاره دارد: آیا انتخاب بازار، ارزش پیشنهادی، ظرفیت سازمان یا فرض مهمی که ابتکار بر آن بنا شده هنوز قابل دفاع است؟ این دو نوع ریسک می‌توانند به هم وصل شوند، اما یکسان نیستند.
اگر تامین‌کننده یک جزء دیر برسد، PMO باید اثر بر برنامه و گزینه‌های اجرایی را نشان دهد. SRO باید بپرسد این تاخیر چه اثری بر پیامد راهبردی و اولویت سبد دارد. شاید با تغییر توالی پروژه، پیامد حفظ شود. شاید تاخیر نشان دهد ابتکار در زمان مناسب ارزش ندارد. شاید هیچ‌کدام درست نباشد و فقط یک مسئله تحویل باشد. تصمیم به داده و زمینه وابسته است، نه به عنوان دفتر گزارش‌دهنده.
برای هر ریسک باز، سازمان باید مالک، آستانه، داده مورد نیاز و مسیر ارجاع داشته باشد. ریسک نباید فقط در فهرست پروژه بماند اگر می‌تواند انتخاب راهبردی را تغییر دهد. در مقابل، هر ریسک کوچک پروژه نباید بی‌دلیل به جلسه هیأت‌مدیره برود. تفکیک سطح ریسک، زمان مدیران را حفظ می‌کند و به افراد نزدیک مسئله اجازه می‌دهد در محدوده اختیارشان عمل کنند.
نشانه هشدار زودهنگام نیز باید با احتیاط تفسیر شود. افزایش درخواست تغییر محدوده شاید از ضعف تحلیل آغازین باشد، یا شاید از تغییر واقعی نیاز مشتری خبر دهد. تیم باید فرض‌های جایگزین را ثبت کند و پیش از نتیجه‌گیری، کیفیت داده و گروه متاثر را ببیند. هدف هشدار، ایجاد گفت‌وگو برای انتخاب است، نه اعلام خودکار شکست یا موفقیت.
وقتی ریسک و تصمیم در یک صفحه دیده می‌شوند، مدیرعامل می‌تواند تعارض واقعی را تشخیص دهد: آیا سازمان باید برای حفظ زمان تحویل، ظرفیت بیشتری تخصیص دهد؟ آیا باید ابتکار کم‌ارزش‌تری را متوقف کند؟ آیا لازم است فرض بازار بازبینی شود؟ پاسخ این پرسش‌ها در گزارش درصد پیشرفت پنهان نیست. به همکاری PMO، نقش اجرای راهبرد و مدیران صاحب اختیار نیاز دارد.
پاداش و شاخص را با احتیاط همسو کنید
اگر مدیر پروژه فقط برای پایان به‌موقع پاداش بگیرد، ممکن است تغییر ضروری راهبردی را تهدید ببیند. اگر SRO فقط برای پیامد بلندمدت پاسخ‌گو باشد، ممکن است محدودیت واقعی تحویل را نادیده بگیرد. پاسخ، گره‌زدن مکانیکی همه پاداش‌ها به همه هدف‌ها نیست. پاسخ، طراحی چند سنجه روشن است که کیفیت تحویل، یادگیری و ارزش راهبردی را در سطح مناسب نشان دهند.
KR دوره‌ای می‌تواند برای آزمودن یک فرض باشد. KPI ممکن است سلامت تحویل یا خدمت را نشان دهد. هدف BSC یا نقشه راهبرد می‌تواند رابطه بلندمدت میان توانمندی، فرایند، مشتری و مالی را نگه دارد. طراحی نظام OKR، KPI و BSC این ابزارها را جایگزین هم نمی‌داند. سازمان باید پیش از سنجش افراد، روشن کند هر ابزار چه سوالی را پاسخ می‌دهد و چه رفتاری را ممکن است تحریک کند.
هنگامی که پاداش به شاخص متصل می‌شود، سنجه محافظ لازم است. اگر پروژه برای کاهش هزینه اجرا می‌شود، کیفیت تحویل یا تجربه مشتری می‌تواند سنجه محافظ باشد. اگر ابتکار برای سرعت عرضه اجرا می‌شود، ریسک کیفیت یا ظرفیت تیم باید دیده شود. سنجه محافظ مانع از آن می‌شود که یک دفتر برای سبز کردن عدد خود، هزینه را به دفتر دیگر منتقل کند.
اختلاف را به داده و انتخاب برگردانید
همسوسازی واقعی به معنی نبود اختلاف نیست. PMO ممکن است درباره تغییر محدوده هشدار دهد، در حالی که SRO بر اساس تغییر بازار خواهان اصلاح جهت باشد. اختلاف حرفه‌ای وقتی مفید است که هر طرف فرض، داده و اثر انتخاب پیشنهادی خود را روشن کند. مدیر ارشد نیاز ندارد هر اختلاف را با مصالحه حل کند؛ گاهی باید یک انتخاب واقعی میان زمان، هزینه، مشتری یا ریسک انجام دهد.
مگنتا بوک بر واردکردن ارزیابی در طراحی و بازنگری تاکید دارد. برای PMO و SRO، این یعنی ابتکار از روز اول باید بداند چه نتیجه‌ای را می‌آزماید و چه شواهدی در بازنگری، ادامه یا تغییر آن را توجیه می‌کند. بدون چنین قرارداد یادگیری، هر دفتر فقط به آمار خودش برمی‌گردد.
برای شروع، مدیرعامل می‌تواند یک ابتکار مهم را انتخاب کند و یک صفحه مشترک بسازد: هدف، فرض، خروجی پروژه، پیامد نزدیک، مالک PMO، مالک SRO، ریسک باز، تصمیم بعدی و تاریخ بازنگری. اگر بعد از دو چرخه، مدیران هنوز میان سبزی پروژه و قرمزی راهبرد سردرگم‌اند، مسئله ابزار نیست؛ رابطه میان خروجی و پیامد یا اختیار تصمیم هنوز روشن نشده است.