اشتباه‌های فاحش در مدیریت پروژه
اشتباه‌ طراحی کرده‌ایم



اغلب پروژه‌ها را ــ چه در حال ساختن یک سیستم باشید، چه یک اتومبیل و چه یک آسمانخراش ـ با طراحی نتیجه نهایی آنها آغاز می‌کنید تا شکل تقریبی آن را تهیه کنید. شما در این طراحی دو چیز را مدنظر قرار می‌دهید:

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

چطور اتفاق می‌افتد
1- محدوده‌ پروژه به‌درستی مشخص نمی‌شود.
چهار کلمه‌ کوچک وجود دارند که وقتی مشتری نهایی (وقتی کلمه‌ «مشتری» را به کار می‌برم، منظورم طرف ذی‌نفع اصلی پروژه است) آنها را می‌شنود، به‌شدت خشمگین می‌شود: «خارج از محدوده است». بنا به تجربه‌ شخصی من، بحث پس از گفتن و شنیدن این جمله فورا بدل به بحثی نومیدکننده و مخرب می‌شود. همچنین تضمین می‌کنم روی هر پروژه‌ای که کار کنید، گاه لازم است از این چهار کلمه استفاده نمایید تا پروژه را در مسیر درست نگاه دارید و منحرف نشوید.
مهم است که در مشخص‌کردن محدوده‌ پروژه، بیان محدوده‌ پروژه را همان ابتدا در فرآیند طراحی تعریف کنید. برخی از بهترین بیان محدوده‌هایی که تا به حال دیده‌ام، از ابعاد زیر به محدوده‌ پروژه نگریسته اند:
 محدوده‌ کارکردی پروژه؛ به بیان دیگر، «چه فرآیندهای کسب‌و‌کاری را باید در طراحی گنجاند؟»
 محدوده‌ جغرافیایی پروژه؛ برای مثال، «طراحی مورد نظر در یک ناحیه، منطقه، کشور یا در سطحی جهانی به کار بسته می‌شود؟»
 محدوده‌ سازمانی پروژه؛ به بیان دیگر، «آیا طراحی پروژه دپارتمان خاص، بخش خاص یا کل شرکت را تحت تاثیر قرار می‌دهد؟»
 استثناهای خاص محدوده؛ برای مثال، «چه مواردی به‌طور خاص از محدوده حذف خواهند شد که اگر خارج نشوند، داخل محدوده فرض می‌شوند؟»
بهتر است با طرح چند پرسش بنیادی، معقول‌بودن و موجه‌بودن بیان محدوده را حین تعریف آن بیازمایید:
 چند تصمیم‌گیرنده باید تصمیمات پروژه را ارزیابی کنند؟
 آیا می‌توانم محدوده‌ پروژه را به شکل موجهی به چند مرحله تقسیم کنم یا همه‌ آن باید فورا انجام شود؟
 آیا می‌توانم ابتدا بر سازمان‌دادن‌های کمتری (حتی یک سازمان‌دهی) تمرکز کنم و پس از انجام سازماندهی اول، به دیگر سازماندهی‌ها بپردازم؟
پروژه‌های رویایی من یک تصمیم‌گیرنده‌ واحد درباره‌ پروژه دارند، می‌توانند به مراحلی منطقی تقسیم شوند، و اجازه می‌دهند که در مرحله‌ اول بر گروهی کوچک تمرکز کنم و سپس در مراحل بعدی روی دیگر سازمان‌ها و جغرافیاها تمرکزکنم. وقتی بتوانید این متغیرها و محدوده‌ پروژه را به درستی کنترل کنید، همه‌چیز عالی خواهد شد. گاه به‌عنوان مدیر پروژه می‌توانید همه‌چیز را به روشنی تبیین کنید، اما در دیگر اوقات با مشکلی مواجه می‌شوید که چنین انعطاف‌پذیری‌ای ندارد. در یکی از پروژه‌هایی که مدیریتش را بر عهده داشتم، وظیفه‌ ما اجرای فرآیند و سیستم نوینی بود که برای پشتیبانی یک فرآیند برنامه‌ریزی کسب‌و‌کار سالانه ضروری بود. پس باید مقتضیات و نیازمندی‌های تغییرناپذیر در آن برآورده می‌شدند: سیستم باید کارکردی جهانی می‌داشت، هر سازمانی را که نیازمند به این شیوه‌ از برنامه‌ریزی است، پشتیبانی می‌کرد، ضرورت‌های خاص هر مشتری را برآورده می‌کرد، شامل تصمیم‌گیرندگان کلیدی متعدد می‌شد و تا تاریخ معینی به اتمام می‌رسید و در غیر این‌صورت کل فرآیند برنامه‌ریزی شرکت ضربه می‌خورد. وقتی نیازمندی‌های این مشتری را برایم توضیح دادند، به یاد مجموعه‌ تلویزیونی قدیمی «ماموریت غیرممکن» افتادم؛ مجموعه‌ای که هر قسمت آن با پخش شرح وظیفه‌ای از یک نوار استودیویی آغاز می‌شد: «تو باید این ماموریت را بپذیری»؛ و نوار پنج ثانیه بعد به طور خودکار نابود می‌شد. به‌این ترتیب، از همه آن چیزهایی که می‌خواستم زمان تعریف محدوده پروژه در اختیار داشته باشم، دقیقا هیچ یک در دسترس من نبود. با این حال، انجام این کار بسیار حیاتی بود و حامی مالی پروژه نیز اشتیاق زیادی از خود نشان داد. بنابراین پروژه را با استفاده از مدیریتی محتاطانه و محدوده‌ای اندک اجرا کردیم و دست‌آخر موفقیت عظیمی نصیب‌مان شد.
مهم است ضمن تعریف‌کردن بیان محدوده مطمئن باشید که مشتریان نهایی، حامی مالی و اجرایی و تیم پروژه، فهم کاملی در مورد حد و مرزهای پروژه داشته باشند. و دقیقا همین‌جا است که بین یک مدیر پروژه‌ ناشی و یک مدیر پروژه‌ بزرگ و برجسته تمایز قایل می‌شوم:
یک مدیر پروژه ناشی حد و مرزها را به‌طور ثابت ترسیم می‌کند. او به دو صورت عمل می‌کند: یا وقتی طراحی کامل می‌شود، دیگر تحت هیچ شرایطی در مورد این حد و مرزها به خود تردیدی راه نمی‌دهد، یا تغییرات محدوده را بدون فهم تاثیرات پروژه می‌پذیرد و حد و مرزها را کاملا نادیده می‌گذارد. یک مدیر پروژه بزرگ خطوط را به‌شکلی موقتی رسم می‌کند و به‌طور سنجیده تصمیم می‌گیرد؛ چه زمانی این خطوط باید از نو ترسیم شوند. به عبارت دیگر، مدیر بزرگ در عین فهمیدن تاثیرات وارد بر پروژه، می‌تواند حد و مرزهای آن را برای برآورده‌کردن نیازهای کسب‌وکار تغییر دهد.
وقتی در حال تکمیل طراحی خود هستید، باید به‌‌خوبی بدانید که حد و مرزها را کجا ترسیم کرده‌اید؛ اما علاوه بر آن، باید از جایی که یک مرز به‌شکلی نادرست تعیین شده است، کاملا آگاه باشید. پس از آنکه طراحی تثبیت شد و در حالت کنترل تغییرات قرار گرفتید، دیگر می‌توانید حد و مرزها را محکم‌تر رسم کنید؛ با این وجود، هنوز باید هوشیار باشید چه زمانی در حال اشتباه‌کردن بابت همین حد و مرزهای ترسیم‌شده هستید. از آن مهم‌تر، ضروری است از دادوستدهایی که باید انجام شوند (بودجه‌های اضافه، زمان اضافه یا منابع اضافه) آگاه باشید و پیشنهاد و راه‌حل بی‌عیب و نقصی مطرح کنید. در یکی از پروژه‌هایی که مدیریتش را برعهده داشتم، تنها یک هفته باقی مانده بود تا محصول را به مشتریان تحویل دهیم و درست همان زمان مدیر محصولات پروژه دریافت یکی از ویژگی‌های کلیدی و کاربردی محصول مورد نظر از قلم افتاده است. او اضافه کرد اگر این ویژگی در محصول تعبیه نشود، تجربه کلی مشتری از محصول ارائه‌شده را به‌شکل فاحشی تنزل خواهد داد. مدیر توسعه ما اصرار داشت که نباید این ویژگی را در محصول تعبیه کنیم، زیرا ریسک بسیاری در بردارد و می‌تواند بر دیگر ویژگی‌های محصول تاثیر منفی بگذارد. در هر حال، ما از چشم‌انداز ریسک، هزینه، زمان و تجربه مشتری به مساله نگاه کردیم و نهایتا تصمیم گرفتیم تغییر مورد نظر را اعمال کنیم؛ اما این کار را با فرآیندی به‌شدت تحت نظارت و مدیریت دقیق به انجام رساندیم تا مطمئن باشیم این تغییر اعمال‌شده هیچ تاثیر منفی‌ای بر دیگر ویژگی‌های محصول نمی‌گذارد. ما توانستیم به طور موفقیت‌آمیزی تغییر را اعمال کنیم، بی‌آنکه به کلیت محصول ضربه‌ای وارد شود و با عکس‌العمل‌های منفی مشتریانمان مواجه نشدیم.
2- مشتری به حد کافی در فرآیند طراحی درگیر نمی‌شود
موفقیت همه پروژه‌ها همیشه با حضور مشتریان قابل اتکا، دارای تفکر انتقادی و عقلانی همراه بوده است. بهترین مشتریان عضو تیم پروژه که تا کنون دیده‌ام، خصایص زیر را داشته‌اند:
 آنها حوزه کاری خویش را به خوبی نمایندگی کرده‌اند و مسوولیت واردکردن متخصصان دیگر حوزه‌ها را هنگام نیاز برعهده گرفته‌اند.
 قادر بوده‌اند برای بهترشدن کار به هنگام نیاز، دادوستدهای مناسب و معقولی انجام دهند.
 پذیرای راه‌های جدید برای انجام‌دادن کارها بوده‌اند و فعالانه در جهت بهترکردن فرآیند کسب‌و‌کار خویش تلاش کرده‌اند.
 کاملا مورد قبول سازمان متبوع خود بوده‌اند.
 کاملا تمایل داشته‌اند تا «عضوی از تیم» باشند و شانه به شانه تیم‌های توسعه پیش رفته‌اند تا مطمئن باشند در فاصله میان طراحی و به‌کاربستن محصول چیزی از دست نرود.
برای اینکه مشتری بتواند خصیصه‌های بالا را در خود بروز دهد، اعضای تیم پروژه باید وی را «خودی» بدانند و مشتاقانه و فعالانه به سخنان او هنگام تبیین و تعریف انتظاراتش گوش فرا دهند. البته منظورم ابدا این نیست که مشتری باید از بالای کوه با لوح‌های ده‌گانه نیازها و انتظاراتش پایین بیاید و دیگر اعضای تیم پروژه تنها به علم لایتناهی او گوش بسپارند و دم نزنند! بسیار مفید است که اعضای تیم پرسش‌های انتقادی خویش را از مشتری و نیز از یکدیگر بپرسند تا با تن نسپردن به کار ماشینی، به بهترشدن آن کمک کنند. برخی از بهترین ایده‌هایی که در طراحی‌های کسب و کار دیده‌ام، وقتی به وجود آمده‌اند که فرد کنارگذاشته‌شده از فرآیند بتواند پرسش‌های بچه‌گانه «چرا؟ چرا؟» بپرسد. این اتفاق تنها وقتی به صورت موثر اتفاق می‌افتد که مشتری را همان اوایل وارد بازی کنید.
3- تیم پروژه برای آغاز «کار واقعی»، برای مثال اجرای طراحی، تحت فشار هستند.
در پروژه‌های زیادی شاهد چنین اتفاقی بوده‌ام و هر بار نیز یکی از این دو دلیل مسبب آن بوده‌اند: انتظارات سهامداران و ذی‌نفعان پروژه‌؛ یا اینکه تیم پروژه زمان مناسب را برای پایان طراحی و آغاز اجرای آن نمی‌داند. وقتی انتظارات سهامداران مطرح باشد، مشتریان، مدیر پروژه یا حامی اجرایی احساس می‌کند که «خیلی ساده باید شروع به اجرای طراحی» کرد. تیم پروژه در تلاش برای راضی‌کردن سهامداران می‌پذیرند که سراغ پیاده‌سازی طراحی بروند. از سوی دیگر، ممکن است مرحله طراحی تیم پروژه، برای تکمیل طراحی با بالاترین دقت ممکن، بیش از حد به درازا بکشد. اگرچه این کار مستندسازی طراحی را کامل و بی‌عیب و نقص می‌سازد، اما جلوی شتاب و پیشرفت پروژه را می‌گیرد، زیرا تیم و مدیریت پروژه فرآیند حل مساله کسب‌وکار خویش را به حد کافی سریع نمی‌یابند. بهترین راه حل این مشکل به نظر من، چابک‌بودن در فرآیند طراحی، سنجیدن مراحل تکمیل آن و نشان‌دادن پیشرفت طراحی با ساختن مدل‌های اولیه است.
4- چیزی در تفسیر رابطه میان نیازمندی‌ها و طراحی از دست می‌رود
در پروژه‌های بسیاری، نوعی «سند نیازمندی‌های مشتری» تکمیل می‌شود که نیازمندی‌های مشتری را (که باید توسط پروژه رفع شوند) با شرح جزئیات مستند می‌کند. سپس از مشتری درخواست می‌شود که این سند را تایید و امضا کند. آنگاه، این نیازمندی‌ها در توسعه طراحی یک محصول به کار می‌روند و این طراحی نهایتا به راه‌حلی اجرایی برگردان می‌شود. اما خود من به‌عنوان یک کارفرما، همیشه تایید نیازمندی‌های موردنظرم را کار دشواری می‌دانستم و مجبور بودم به آنها بر حسب جهان «فعلی» خودم و نه نوعی جهان «بهتر» در ذهنم بیندیشم.
طی سال‌ها تجربه، بدل به یکی از طرفداران پروپا قرص طراحی و ارائه دائمی مدل‌های اولیه به مشتری در ضمن پروژه شدم. این کار تیم پروژه را بر سر فرآیندهای کسب و کار مورد اشاره یا مسائل موردنظر به توافق می‌رساند. وقتی مدل اولیه کامل‌تر می‌شود، مشتری آن را به همتایان خویش (یعنی مشتریان دیگر) و نیز دیگر سهامداران نشان می‌دهد تا آنها را از فرآیند کار آگاه سازد و نظرات ایشان را برای بهترشدن فرآیند جویا شود.
5- یک فرآیند بد باعث می‌شود اشتباه در کار سریع‌تر رخ دهد
اگر پروژه شما نیازمند فرآیندهای طراحی دوباره باشد، بهتر است نگاهی دقیق و ریزبینانه به فرآیندها بیندازید و مطمئن باشید فعالیت‌های بی‌ارزش با تکمیل طراحی از دور خارج می‌شوند. از تکنیک‌های بسیاری می‌توانید برای کشف ناکارآمدی‌ها استفاده کنید. اما فارغ از تکنیکی که مورد استفاده قرار می‌دهید، هدف شما سادگی و وضوح است. اگر پروژه را با یک مجموعه برنامه کاربردی از پیش مشخص آغاز می‌کنید، ترتیب کاری برنامه کاربردی جدید را در نظر بگیرید و آنگاه سعی کنید فرآیندهایتان را با این ترتیب کاری وفق دهید. در برخی موارد، باید بر اساس ضرورت‌های خاص پروژه در دست اجرای خود، تغییراتی را در برنامه کاربردی ایجاد کنید. سعی کنید ذهن خود را پذیرا و گشوده نگاه دارید و هر جا می‌توانید، فرآیندهای خود را با برنامه کاربردی‌تان تطبیق دهید.
6- فرآیند تغییر طراحی ضعیف یا ناموجود است
در انجام پروژه‌ها نسبت به این یک نکته مطمئن باشید: نخستین تقاضای تغییر، درست چند روز بعد از اتمام فرآیند طراحی، روی میز کارتان خواهد بود. حتی با بهترین طراحی‌ها نیز نیازمندی‌های کسب‌وکار تغییر می‌کنند، چیزهایی از قلم می‌افتند یا مواردی که ابتدا از «محدوده خارج محسوب شده‌اند»، به «واجبات» بدل می‌گردند.
اگر «علامت‌های خطر» را در فرآیند پروژه مشاهده کردید، برای حل مشکل به بخش «ورق را برگردانید» مراجعه کنید.

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


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