ترجمه: اشتباه های فاحش در مدیریت پروژه

اشتباه های فاحش در مدیریت پروژه
کار را در لحظه آخر خراب کردیم

مترجم: فرهاد امیری
بازي ششم در مسابقات بیسبال سال 1986 است؛ یک بازی حساس بین نیویورک متز و بوستون رد ساکس! رد ساکس بسیار موفق ظاهر شده و کافی بود یک گیم دیگر از این مسابقه را ببرد تا به عنوان قهرمانی دست یابد.

[Only Registered and Activated Users Can See Links. Click Here To Register...]

اما تا اواخر بازی چنین اتفاقی نیفتاده است. حالا گیم آخر است. هر دو تیم برابرند. موکی یک توپ کاملا عادی را برای بیل بروکنر می فرستد، اما در کمال شگفتی، توپ از لای پاهای بیل قل می خورد و همین باعث می شود تا متز بازی را ببرد و قهرمان شود. بیل بروکنر برای 22 سال در لیگ ماژور بیسبال آمریکا بازی کرد، 2715 ضربه زد و با چوب بیسبالش به یک سوم توپ های ارسالی ضربه زد و آمار بسیار قابل قبولی به جا گذاشت، اما آقای بیل بروکنر به خاطر کدام بازی مشهور شده است؟ بله، دقیقا به خاطر همین بازی 1986 که اشتباهی فاحش در آن انجام داد!

یکی از اشتباه هاي فاحش در پروژه را به سختی می توان بخشید: اینکه تمام طول پروژه را به خوبی پیش رفته ای، به آخر رسیده ای و چون کمی زودتر پیروزی پروژه را اعلام کرده ای، ناگهان چیزی آن اواخر همه چیز را خراب می کند. من به تجربه (و البته از خلال شکست های خودم) آموخته ام که در آخرین هفته های پروژه باید مدیریت اجرایی بسیار دقیقی داشته باشید، هر روز وضعیت پروژه را به اعضای تیم اطلاع دهید و برای هر مشکلی که ممکن است پیش بیاید، به سرعت راه حلی دست و پا کنید. اجازه ندهید مثل بیل بروکنر توپی از لای پاهایتان قل بخورد، بازی را ببازید و آن وقت هم به پروژه خود آسیب کلان وارد کنید و هم به شهرت تان در مقام مدیر پروژه.

چطور اتفاق می افتد
1_کسی تغییری در لحظه آخر در محصول ایجاد و این تغییر چیز دیگری را تخریب کرده است.
اگر یکی از طرفداران سریال طنز مونتي پایتون(1) باشید، احتمالا قسمتی را به یاد دارید که در آن مرد فربه و چاقی تا خرخره غذا خورد و سپس وقتی به او یک برگ نعنا بیشتر دادند، به معنای تحت الفظی کلمه و به خاطر حجم غذایی که بلعیده بود، منفجر شد - تنها یک برگ نعنای اضافی کافی بود تا این آدم تعادلش را از دست بدهد و به کلی تخریب شود! این داستان شباهت زیادی دارد با اتفاقی که ممکن است اواخر یک پروژه رخ دهد؛ يعني زمانی که تغییرات در لحظه آخر بر محصول اعمال می شوند. در یکی از آخرین پروژه هایم، نقش صاحب کسب و کار را برعهده داشتم و به تیم پروژه دستور اکید دادم که در آخرین هفته های پروژه تنها در صورتی محصول را تغییر دهند که تغییر مورد نظر اساسی و کلیدی باشد. اما یکی از مشتری ها، توسعه دهنده محصول را قانع کرد تا یک تغییر «آسان» در محصول ایجاد کند. توسعه دهنده این تغییر را ایجاد کرد و یکی از ویژگی های محصول را که پیشتر کار می کرد، از کار انداخت. تغییر «آسان» مورد نظر مشتری نه تنها در محصول نهایی پیاده سازی نشد، بلکه منابع بسیار ارزشمندی بر سر پیاده سازی ناموفق آن و نیز تشخیص و خنثی*کردن اثرات مخرب تغییر یادشده هدر رفت.

2- ارتباط بین اعضای تیم به موقع نیست
همان طور که پیش از این گفتم، به نظر من حفظ و اجرای ارتباطات بسیار دقیق و منظم بین اعضای تیم در آخرین هفته های پروژه اهمیت دارد. من یکی از طرفداران پروپاقرص جلسات روزانه ای هستم که هر صبح برگزار می شود و فعالیت های روز قبل را مورد بررسی و ارزیابی قرار می دهد و موضوعات مهم و برنامه های کاری روز جاری را عنوان می کند. همچنین مهم است اطمینان حاصل کنیم که همه قواعد پروژه در جلسات روزانه بیان می شوند و همه می توانند از نظرگاه خاص خود فعالیت ها را ارزیابی کنند و نیز نقش موثر خود بر روند پروژه را درک نمایند.

همچنین به باور من، نباید مدت این جلسات از حد مشخصی بیشتر شود و احتمالا سقف سی دقیقه سقف مناسبی است، چرا که اگر زمان بیش از حد زیاد باشد، انرژی اعضای تیم را پیش از شروع کار روزانه هدر می دهد يا شاید اساسا اعصاب آنها را خرد کند. همچنین، اگر به حد کافی کوتاه نباشد، احتمالا نمی تواند ماندگاری خوبی داشته باشد و پس از چند جلسه کنار گذاشته خواهد شد.

3- پروژه درست قبل از اتمام به بن بست می رسد.
وقتی به عنوان مشاور کار می کردم و مسائل مالی بر پروژه ای فشار می آورد، دائما به دنبال این بودم که کدام آدم ها را از پروژه کنار بگذارم تا پول کافی برای اتمام پروژه وجود داشته باشد. این کار به لحاظ مدیریت هزینه تنها زمانی مقبول و موفق است که آدم های مورد نظر - آدم هایی که کنار گذاشته می شوند - دیگر کاری برای انجام در این پروژه نداشته باشند، اما در مواردی که فعالیت های آنها به طور کامل انجام نشده باشد، بقیه تیم مجبورند مسوولیت آنها را نیز تقبل کنند و آن وقت است که شما به دست خودتان ریسکی را در برابر موفقیت پروژه تان آفریده اید. واقعیت این است که اگر کسی هنوز فعالیت خود را تمام نکرده باشد و شما وی را از پروژه کنار بگذارید، آن وقت انگار هیچ پولی صرفه جویی نکرده اید.

نکات کلیدی
از تغییرات در لحظه آخر اجتناب کنید، چون این تغییرات می توانند به ازکار افتادن یکی از ویژگی های محصول بینجامند.
جلسات بحث و بررسی مختصر را هر روز صبح برگزار کنید و در آنها وضعیت پروژه و کارهای مورد نیاز برای آن روز را مرور کنید و همچنین مشکل های پروژه را در این جلسات به طور کامل به بحث بگذارید.
زودتر از موعد پیروزی پروژه را اعلام نکنید؛ بازی های بیسبال زیادی در همان گیم آخر واگذار شده اند؛ تمرکزتان را حفظ کنید!
یادداشت:

(1) مونتی پایتون (Monty Python) یک گروه کمدیِ سوررئالیستی در بریتانیا بود. این گروه یکی از مشهورترین و محبوب ترین سریال های کمدی تاریخ انگلیس را با نام «سیرک پرنده مونتی پایتون» از 5 اکتبر 1969 آغاز کرد. 45 قسمت و 4 سری حاصل فعالیت های تلویزیونی این گروه بود و آنها را تقریبا در کل اروپا و حتی آمریکا به شهرت رساند.


علائم خطر
1- اعضای تیم در دیگر پروژه ها مسوولیت بر عهده گرفته اند.
وقتی یک پروژه نزدیک اتمام باشد، شاید اعضای تیم از سوی مدیران دیگر پروژه ها مسوول کاری شوند. شاید اگر مسوولیت تازه ای برای برخی از اعضای تیم درنظر گرفته شود، مشکلی پیش نیاید، اما باید در این مورد محتاط بود تا افراد یک پروژه زودتر از موعد کارشان را رها نکنند. همچنین باید با این افراد کماکان در ارتباط بود، تا در مواقع نیاز و برای تقبل وظیفه ای بحرانی آنها را دوباره به پروژه کشاند.

2- مشتریان در لحظات آخر خواستار تغییراتی غیرضروری در محصول هستند.
هربار شنیدید که «اما این کار خیلی ساده است، فقط چند دقیقه وقتتان را می گیرد» باید صدای زنگ خطر را در ذهنتان بشنوید. قبول، یک تغییر می تواند ظاهرا خیلی ساده باشد، اما باید در نظر بگیرید که هر تغییری باعث می شود اتفاقاتی برای دیگر ویژگی های محصول نیز بیفتد و همین امر باعث می شود کار به ظاهر ساده بسیار پیچیده شود.

3- ارتباطات تیم پروژه کاهش یافته است یا دیگر وجود ندارد.
وقتی تیم پروژه ارتباطات دائمی و مداوم خود را در حول و حوش زمان تکمیل پروژه حفظ نکند، ممکن است لغزش هایی رخ دهد یا تیم پروژه از برخی موضوعات اساسی و حیاتی پیش آمده خبردار نشوند. خود من ترجیح می دهم در بازه زمانی نزدیک به اتمام پروژه از آن طرف بام بیفتم و ارتباطات بیش از حد را در دستور کار خود قرار دهم تا مطمئن شوم همه اعضای تیم از همه مسائل محتمل
آگاه شوند.

راه حل: ورق را برگردانید

1- تمرکز خود را حفظ کنید
انسجام تیم پروژه را حفظ کنید و آنها را بر اتفاقات لحظه های متمرکز نگه دارید. اطمینان حاصل کنید که تیم پروژه نسبت به اینکه چه اتفاقاتی هر روز رخ می دهد، کاملا آگاه است و می داند چه کسی مسوولیت انجام کدام فعالیت های کلیدی، رفع کدام مشکلات مهم و تصمیم گیری در باب چه موضوعی را برعهده دارد. مواظب باشید اعضای تیم پیش از اتمام پروژه کاملا درگیر وظایف پروژه های دیگر نشوند.

2- تیم پروژه را به ارتباط با یکدیگر وادار کنید
ترجیح من این است که جلسات کوتاه تر و متناوب تری را در آغاز یا پایان یک روز کاری برگزار کنیم و در آنها وضعیت پروژه و وظایف هر فرد را بررسی کنیم. در برخی از پروژه ها یک «اتاق جنگ» درست می کردم تا در آنها بتوانیم وظایف، مشکلات و تصمیم گیری های کنونی در مورد پروژه را به دقت به بحث بگذاریم. گاه حتی اعضای تیم پروژه را داخل این اتاق جنگ نگه می داشتیم تا تصمیم گیری های بسیار مهم انجام شوند؛ این کار به سهولت مباحثات بین افراد می انجامید و تصمیم گیری ها با دقت بالاتری انجام می گرفت.

3- محصول را تثبیت کنید
هرچه به لحظه ارائه محصول نزدیک تر می شوید، باید در مورد اعمال تغییر در محصول هوشیاری و احتیاط بیشتری به خرج دهید؛ به خصوص تغییراتی که برای کارکرد محصول ضروری نیستند. هر بار که تغییری اعمال می کنید، باید در نظر بگیرید که ممکن است سهوا تغییری در خصیصه ای دیگر ایجاد کرده باشید. هیچ وقت خودتان را مجبور نکنید تمام دقایق پروژه خود را به پیاده سازی خصیصه ها و ویژگی های اضافی در محصول بگذرانید.