اشتباه‌های فاحش در پروژه
ما به مساله واقعی نپرداختیم!
مترجم: فرهاد امیری
هسته اصلی هر پروژه عقلانی را «نیاز به حل یک مساله» تشکیل می‌دهد؛ یعنی مساله‌ای که کسی بدان پی‌می‌برد و به دنبال حل آن است. مسائل می‌توانند همچون موانعی بر سر راه تحقق چیزی ظاهر شوند («نمی‌توانیم با سیستم‌های موجود، ۱۰۰۰۰ واحد کالا را به‌صورت هفتگی جابه‌جا کنیم») یا فرصتی برای انجام بهتر کاری باشند («باید هزینه رسیدگی به سفارش‌های خرید را تا ۲۰ درصد کاهش دهیم»).
نویسنده: لُنی پاسلی
مترجم: فرهاد امیری
هسته اصلی هر پروژه عقلانی را «نیاز به حل یک مساله» تشکیل می‌دهد؛ یعنی مساله‌ای که کسی بدان پی‌می‌برد و به دنبال حل آن است. مسائل می‌توانند همچون موانعی بر سر راه تحقق چیزی ظاهر شوند («نمی‌توانیم با سیستم‌های موجود، ۱۰۰۰۰ واحد کالا را به‌صورت هفتگی جابه‌جا کنیم») یا فرصتی برای انجام بهتر کاری باشند («باید هزینه رسیدگی به سفارش‌های خرید را تا ۲۰ درصد کاهش دهیم»). در هر صورت، تمایل به انجام‌دادن چیزی در آینده وجود دارد که امروز قابل دستیابی نیست.
مسلما برخی از مفرح‌ترین پروژه‌هایی که تاکنون روی آنها کار کرده‌ام، پروژه‌هایی از این دست بوده‌اند: «آهای، باید این کار یا آن کار را بکنیم». اما مشخص‌ترین اهداف متعلق به پروژه‌هایی بوده‌اند که مانعی بسیار واقعی و قابل فهم بر سر تحقق موفقیت‌آمیز آنها وجود داشته است. مثالی برجسته از این مورد ــ که به معنای واقعی کلمه هر کسب‌وکاری را روی زمین تحت تاثیر قرار داد ــ هراس سایبری از سر رسیدن سال ۲۰۰۰ بود. یکی از وظایف من حصول اطمینان از این امر بود که فروشندگان اصلی ما به خوبی آماده فرارسیدن سال ۲۰۰۰ شده باشند و بر اثر عدم قابلیت اجرای کامپیوتری، هیچ اختلالی در کسب‌وکار شرکت ما پیش نیاید. همه می‌دانستند مساله اصلی چیست: سیستم‌های کامپیوتری از سال دو رقمی استفاده می‌کردند و ۱۹ را در دو سال اول فرض می‌گرفتند، به همین خاطر در ۱ ژانویه ۲۰۰۰، سال میلادی را ۱۹۰۰ فرض می‌گرفتند و بسته به سیستم کامپیوتری، ممکن بود در عملکرد همه‌چیز از شبکه برق گرفته تا سیستم‌های کنترل عبور و مرور هوایی تا تجهیزات خردتر اختلال ایجاد شود. همه شما باقی داستان را می‌دانید: ۱/۱/۲۰۰۰ سر رسید و با کمترین میزان ممکن مشکلات سپری شد؛ نه به این دلیل که هراس کامپیوتری ما بی‌مورد بود، بلکه بدین خاطر که میلیاردها دلار در سرتاسر جهان هزینه شد تا مشکلی جدی پیش نیاید. سرانجام و پیامد مخرب بسیار واقعی و قابل فهمی طرف بودیم، اگر هیچ تمهیدی‌اندیشیده نمی‌شد.
چه‌طور اتفاق می‌افتد
۱ - ماموریت پروژه به خوبی بیان نشده است.
بسیاری از پروژه‌هایی که با آنها مواجه شده‌ام، ماموریت خود را به شکلی مبهم یا غیرواقع‌بینانه بیان کرده بودند یا اصلا بیان نکرده بودند. گفتن این حرف که «باید هزینه‌ها را کاهش دهیم» ستودنی و مطلوب است، اما چیزی نیست که تیم پروژه بتواند آن را انجام دهد؛ آن هم به این دلیل ساده که خود پروژه و زمان به پایان رساندن آن معلوم نیست. بهترین دستورالعمل‌ها و بیان ماموریت‌هایی که تا به حال دیده‌ام، اجزای زیر را داشته‌اند:
چه باید کرد؟
تا چه زمانی باید این کار را کرد؟
چه ابزار سنجشی برای ارزیابی موفقیت پروژه مورد استفاده قرار خواهد گرفت؟
یکی از پروژه‌هایی که روی آن کار کردم، بر فروشندگانی تمرکز داشت که صورتحسابها را مستقیما از طریق اینترنت به سیستم پذیرش صورتحساب شرکت وارد می‌کردند و از روش قدیمی ارائه صورتحساب از طریق سندهای چاپی استفاده نمی‌کردند. دستورالعمل یا بیانِ ماموریت برای این پروژه چنین بود:
«ما باید هزینه رسیدگی به صورتحسابها را تا ۱ مارس به نصف برسانیم و در عین حال اطمینان حاصل کنیم که به فروشندگان طبق قرارداد و در زمان مقرر ۱۰۰ درصد هزینه‌ها پرداخت شوند.»
این پروژه یک موضوع واضح (کاهش هزینه رسیدگی به صورتحسابها) داشت، یک زمانبندی مشخص (۱ مارس) داشت و یک ابزار سنجش واضح (۵۰ درصد هزینه رسیدگی به صورتحسابها و ۱۰۰ درصد پرداخت به‌موقع طبق قرارداد). ما در این پروژه می‌توانستیم به طور دقیق بر آنچه باید انجام می‌دادیم تمرکز کنیم و مطمئن باشیم همه بخش‌های اجرایی پروژه در هماهنگی کامل با یکدیگرند، زیرا یک دستورالعمل یا بیان ماموریت به شدت دقیق داشتیم.
۲- فهمی مغایر و ناهماهنگ از چیستی مساله وجود دارد.
در پروژه‌هایی که با گروه‌های ذی‌نفع متعددی طرف هستید، بسیار محتمل است که هر گروه ذی‌نفع برای پروژه دستورالعمل خاص خود را داشته باشد. گاه آنچه برای شما مساله است، برای دیگران ابدا مساله به نظر نمی‌رسد، اما حیاتی است که همان ابتدای پروژه دیدگاهی بسیار منسجم راجع به این که «پروژه قصد انجام چه چیزی را دارد» داشته باشید و این دیدگاه را از خلال یک دستورالعمل یا بیان ماموریت واضح بیان کنید و اطمینان حاصل کنید که دیگر اجزای پروژه ماموریت را به خوبی فهمیده‌اند و برای حل مساله دست به کار شده‌اند.
گاه ممکن است با «عوامل مقاوم»ای طرف شوید که نمی‌خواهند پروژه را به اتمام برسانند، زیرا اتمام پروژه به معنای تغییری عمیق در شغل یا سازمان متبوع ایشان یا حتی حذف کامل آنها است. ضروری است که همان ابتدا در تعریف بیان ماموریت به این موارد اشاره کنید و دغدغه‌های عوامل مقاوم را مشخص کنید. تکنیکی که خود من به‌طور موفقیت‌آمیزی از آن بهره بردم، چنین بود: من همه گروه‌های سهامدار و ذی‌نفع را داخل یک اتاق جمع کردم و به هر یک فرصت دادم تا دستورالعمل پروژه را به شیوه خودشان شکل دهند. پی بردم که حتی اگر کسی تنها یک کلمه را تغییر دهد یا بیافزاید، احساس می‌کند که در راهبری پروژه نقش داشته است. در برخی پروژه‌ها می‌توانستیم با عوامل مقاوم کنار بیاییم؛ در برخی دیگر، عوامل مقاوم هرگز تن به قواعد بازی نمی‌دادند. در این موارد، عوامل مقاوم از پروژه‌ها کنار گذاشته می‌شدند. حذف یک عامل مقاوم ابدا فرآیند آسان و مطلوبی نیست، اما همیشه باید کاری کرد که پروژه رو به جلو حرکت کند.
۳- بله، این هم یک مساله است، اما هنوز مسایل بسیار مهم‌تری وجود دارند.
خوب، ممکن است ببینید چیزی آن‌اندازه که باید، خوب کار نمی‌کند یا دریابید که یک محصول یا خدمت می‌تواند به سازمان شما سود برساند. شاید اجراکردن راه‌حل بتواند منافعی را برای سازمان شما به همراه آورد؛ پس مساله بر سر اولویت‌ها و تمرکز مدیریتی است.
در یکی از سازمان‌هایی که مشغول به کار بودم، سندی سالانه از پروژه‌ها را تهیه می‌کردم که در آن پروژه، مساله پروژه، منابع مورد نیاز، منافع مدنظر، اولویت پروژه بر اساس اولویت‌ها و تمرکز مدیریتی و مدت زمان لازم برای تحقق پروژه ذکر می‌شد. پس از آنکه تعریف هر پروژه‌ای کامل می‌شد، پروژه‌ها را در یک صفحه‌گسترده (spreadsheet) می‌ریختیم، آنها را بر حسب اولویت مرتب می‌کردیم و «حد آخرِ» دقیق جلسه‌های برگزار شده را بر اساس زمان مصرف منابع قرار می‌دادیم. برای مثال، اگر به نقطه‌ای رسیدیم که پس از پنج پروژه دیگر پولی برای کار روی بقیه پروژه‌ها باقی نمانده بود، آن وقت «حد آخر» را پس از پروژه پنجم می‌گذاشتیم. البته همه این کارها ابدا فرآیندی صرفا محاسباتی نبود. این فرآیند نیازمند مباحثات بسیار درباره اولویت‌های مربوطه است و در حالی که یک سازمان شاید پروژه‌ای را برای کسب‌وکار خویش بسیار حیاتی ارزیابی کند، اما در نگاهی کلی‌تر پروژه‌هایی بودند که از اهمیت بیشتری برخوردار باشند. پس همه با پیامد یک پروژه هیجان‌زده نمی‌شدند، بلکه فهرستی از پروژه‌های اولویت‌بندی‌شده وجود داشت که همه می‌دانستند و می‌فهمیدند. با این حال، وضع امور و همراه با آن اولویت پروژه‌ها تغییر می‌کنند. بنابراین، مرور دوره‌ای فهرست پروژه‌ها مهم است (ما این کار را هر سه‌ماه یک بار انجام می‌دادیم) تا اطمینان حاصل کنید که در حال کارکردن روی مساله درست با ترتیب اولویتی درست هستید.
علامت‌های خطر
۱- در یافتن حامی مالی برای پروژه خود دچار مشکل هستید.
شما پروژه‌ای را در دست گرفته اید که فکر می‌کنید مهم است، اما برای قانع‌کردن حامیان بالقوه مالی و قبولاندن اهمیت این پروژه به آنها زمان دشواری را پشت سر
می‌گذرانید. شاید مساله پروژه حقیقتا واقعی باشد، اما از اولویت کافی برای تضمین عمل فوری برخوردار نباشد. پس شاید بار دیگر در بیان ماموریت پروژه ضعیف عمل کرده‌اید، به‌طوری که این ماموریت برای دست‌زدن به عمل به حد کافی قانع‌کننده نیست.
۲- تیم پروژه گیج شده‌اند و نمی‌دانند مساله این پروژه دقیقا به چه چیزی اشاره دارد.
چندین پروژه را تا به حال دیده‌ام که هر یک از اعضای تیم آن با دیدگاه‌های متفاوتی نسبت به مساله‌ای که باید حل شود، به سراغ پروژه رفته‌اند. اگر هرکدام از اعضای تیم پروژه شما نتوانند فهم سازگار و مشترکی از بیان ماموریت و دستورالعمل پروژه داشته باشند، قطعا ضمن اجرای پروژه با مشکل سردرگمی مواجه خواهید شد.
۳- متمرکز کردن تیم پروژه بر روی حل مساله دشوار است.
در مورد برخی پروژه‌ها، با موقعیت‌هایی مواجه شده‌ام که اعضای تیم پروژه از حل مساله اصلی منحرف و به حل «مساله‌ای فرعی» مشغول شده‌اند که شاید ربطی به پروژه نداشته باشد. گهگاه، این موضوع نوظهور واجد اعتبار است و می‌تواند به شما در بیان بهتر ماموریت پروژه و راه‌حل منتج‌شده از آن کمک کند، اما گاه این کار صرفا «دنبال نخود سیاه رفتن» است که تمرکز شما را به هم می‌ریزد و در مسیر انجام هدف پروژه سردرگم‌تان می‌کند.
ورق را برگردانید
۱ - بیان ماموریت پروژه خود را همیشه جلوی چشم بگذارید
پروژه‌هایی با بیان ماموریت‌های فوق‌العاده دیده‌ام که برای فروختن پروژه تهیه دیده شده‌اند، اما بعد از آن دیگر داخل کشو قرار می‌گیرند و هرگز چشم کسی دوباره به آن نمی‌افتد، اما حتما بیان ماموریت را در سرتاسر طول پروژه از نو مرور کنید و انتقال دهید تا مطمئن شوید که کار درست را انجام می‌دهید و همه نیز می‌دانند چه کاری درست است و نیز مطمئن شوید که در حال حرکت به سوی حل مساله هستید.
۲- با تغییرکردن مساله، ماموریت پروژه را تغییر دهید
مسائل تغییرناپذیر نیستند؛ پیچیدگی و اهمیت آنها قابلیت تغییر دارد. اگر چیزی در مساله پروژه تغییر کند، اطمینان حاصل کنید که ماموریت شما نیز بر حسب آن تغییر کرده باشد. این امر همچنین می‌تواند به معنای تغییر میزان اهمیت پروژه شما باشد، زیرا اهمیت مساله نسبت به قبل کمتر یا بیشتر شده است و به همین میزان نیز اهمیت پروژه شما تغییر کرده است.
۳- پروژه را به تعویق بیندازید
اگر نتوانستید پشتیبانی برای پروژه پیدا کنید پس آن را به تعویق بیندازید یا بپذیرید که پروژه مدنظر شما در زمان کنونی توجه کافی حامیان مالی را به خود جلب نمی‌کند. انجام یکی از این دو کار بهتر است تا اینکه پروژه خود را بدون حمایت مالی آغاز کنید. چنین کاری صرفا تلف‌کردن وقت تا زمان مرگ بی‌حاصل پروژه‌تان خواهد بود.
خلاصه نکات
اطمینان حاصل کنید که بیان ماموریت و دستورالعملی صریح و واضح در دست دارید.
اطمینان حاصل کنید که ذی‌نفع‌ها و سهامداران، بیان ماموریت و دستورالعمل پروژه را به‌درستی می‌فهمند و فرصت بررسی و تغییر در آن را داشته‌اند.
اطمینان حاصل کنید که بیان ماموریت پروژه با کانون توجه و اولویت‌های حامی مالی بالقوه هم‌راستا است و نسبت به دیگر پروژه‌ها در اولویت قرار دارد.
بیان ماموریت و دستورالعمل پروژه را دائما در معرض دید تیم پروژه قرار دهید.
ارسال نظر