نجات پروژه در حال شکست (قسمت اول)

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

 

شناخت یک پروژه ی مشکل دار :

معمولی ترین نشانه ی یک پروژه ی مشکل دار اختلاف نظر در مورد اولویت انجام کارها بین سرمایه گذاران می باشد اما با هم بحث و گفتگویی در این مورد نمیکنند که منجر به حل مسئله شود . ممکن است شما برای پروژه سرمایه گذار نداشته باشید و این سرمایه اولیه را خودتان یا از مشتری دریافت کرده باشید . در هر صورت اختلاف نظر بین کارفرما و پیمانکار مدنظر است .

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

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

G & A (Firestone) H-19 helicopter

پیدا کردن مشکل اصلی پروژه  :

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

1)      آیا اسپانسر یا سرمایه گذار قدرت تغییر در سازمان را دارد و این اختیار را دارد .

2)      آیا اسپانسر می تواند در مورد اولویت انجام کارها تصمیم بگیرد . (اسپانسر می بایست قدرت جلو بردن پروزه را داشته باشد . )

3)      آیا اسپانسر اطلاعات فنی درستی از پروژه را دارد (اگر ندارد نمیتواند بفهمد پروزه پیشرفت کرده است .)

4)      آیا اسپانسر وقت لازم برای توجه به پروژه را دارد . (اسپانسر مناسب اما بدون وقت مانند این است که اصلا اسپانسری وجود ندارد)

5)      آیا مشتری می تواند راه حل مشکل را به شما بگوید

6)      آیا محصول همچنان به درد مشتری می خورد . (ممکنه نیاز مشتری از بین نرفته باشد اما اولویت ها برای او تغییر کرده باشد)

7)      آیا مشتری درگیر پروسه پروژه هست ؟

8)      آیا تمامی منایع توسط مشتری به پروژه اختصاص داده شده است ؟ این منایع می تواند پول ، توجه و اهمیت باشد .

9)      آیا مشتری اطلاعات کاملی از مشکل خود و راه حل شما دارد ؟ مشتریانی که تجربه یا دانش کافی ندارند ریسک زیادی برای همکاری با آنها وجود دارد .

باید ابتدا مشکل اصلی پروژه را با سوالات بالا بدانیم سپس آن را حل کنیم .

 

نجات پروژه:

پس از پیدا کردن مشکل اصلی شما در صدد تغییر خواهید بود . این تغییرات شامل موارد زیر است  :

1)      برنامه ارتباطی شما با سرمایه گذاران و مشتریان

2)      منابع پروژه (شامل منابع پولی ، انسانی ، تجهیزات و … )

3)      زمان تحویل پروژه

 

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

بعد از بدست آوردن اعتماد سرمایه گذاران و روحیه بخشی به تیم می بایست دو کار بسیار مهم انجام دهید

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

2)      مدیریت ریسک پروژه شما مشکل دارد ! اگر مشکل نداشت به مشکل نمی خوردید ، یا مدیریت ریسک پروژه کامل نبوده و تمامی ریسک های موجود را پوشش نداده ، یا اصلا برای این پروژه  مدیریت ریسک در نظر نگرفتید . پس همین امروز آن را درست کنید  تا دیگر با مسائل پیش بینی نشده برخورد نکنید . لیست تمامی خطرات بوجود آمده و آنهایی که پیش بینی می کنید را لیست کنید با نوشتن اثری که این خطر دارد و راه حلی که برای حل یا کم کردن اثرش به ذهنتان می رسد .

پس از انجام موارد بالا شرایط فراهم می شود که عملیات نجات را شروع کنید . یکی از کارهایی که می بایست انجام دهید تنظیم مجدد برنامه است که شامل موارد زیر است :

1)      WBD یا کارها و تسک هایی که بدرستی خرد شده باشند و تقسیم کارها به خوبی انجام شده باشد .

2)      چک کردن تخمین زمانی کارها ، اینکه برای هر کاری چقدر زمان لازم است .

3)      درست سنجی هزینه ها که دقیق مدیریت شده باشند .

4)      در نظر گرفتن و انجام کارهایی که می تواند موفقیت های کوچک ایجاد کند.

5)      دادن اعتماد به نفس به اعضای تیم و سرمایه گذاران با عمل

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

6)      خلاص شدن از چیزها و کارهای بی مصرف و بیخودی در برنامه

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

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

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

وقتی یک تغییر را در یک تیم ، شرکت یا سازمان انجام می دهیم ، شایعه پراکنی زیاد می شود ، افراد روی چیزهایی که تغییر می کند شک می کنند و ناخودآگاه جلوی تغییرات می ایستند ، باید سعی شود همه ی تغییرات با هم انجام نشود و کم کم انجام شود تا این فشار این مقاومت طی زمان پخش شود ، همچنین تعداد جلسات توجیهی با مدت زمان  کم نیز می بایست افزایش یابد .

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

درنوشته ی بعدی به سلامت نگه داشتن پروژه ی نجات یافته خواهم پرداخت .

 


پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *