داستان شکست یک پروژۀ آی‌تی را بخوانید…
همۀ ما شاهد شکست پروژه‌های آی‌تی بوده‌ایم… سؤال این است که چرا؟ آیا همیشه مقصر مدیر پروژه است؟ داستانی را از یک مدیر پروژه بشنوید که از شکست پروژه‌اش می‌گوید…
«دو دهه است که هم به‌عنوان یک نویسندۀ فنی و هم طراح صنعتی در صنعت آی‌تی خدمت می‌کنم… پروژه‌هایم همیشه نیاز به راه‌اندازی نرم‌افزاری و سخت‌افزاری داشته‌اند. کمتر شده پروژه‌ای را ببینم که به‌موقع تکمیل شود. معمولاً دیر تحویل داده می‌شوند، و البته با مشکلات و خطاهای بسیار. از تحقیق Gartner می‌فهمیم که «شکست» یک برداشت ذهنی و شخصی نیست… نرخ شکست پروژه‌های آی‌تی 24 درصد است (هاندلر 2011).
ماجرای داستان
پروژه‌ای داشتم که موضوع آن ارائۀ یک راهکار نرم‌افزی-سخت‌افزاری برای یک شرکت خرده‌فروش بود. من مسئول نوشتن مستند محصول، توسعۀ مجموعه‌ای از ماژول‌های آموزش مجازی و ساخت و تدریس ILT بودم. در دوماه عرضۀ آزمایشی، تجهیزات به مشکل برخورد و پروژه پس فرستاده شد تا دوباره بر آن کار شود. دلیلش این بود که بسیاری از مشتریان مغازۀ شرکت خرده‌فروش این مفهوم جدید را نمی‌پذیرفتند و البته، سخت‌افزار و نرم‌افزار نیز درست کار نمی‌کرد.
برنامه‌ریزی پروژه
هم شرکت من و هم شرکت مشتری، مدیران پروژه‌ای داشتند که پروژه را با دقت بررسی کرده بودند. تمام مستندات، زمان‌بندی‌ها و قراردادهای مرسوم تهیه شده بود. مدیر پروژۀ شرکتِ مشتری و تحلیلگر تجاری آن یک سند پرجزئیات از نیازمندی‌ها تهیه کرده بود که نشان می‌داد دقیقاً محصول باید چه کارکردی داشته باشد. تغییراتی در محدوده صورت گرفت که چند بار با آن‌ها موافقت شد و با دقت در در‌خواست‌های کتبیِ تغییر ثبت شد. وقتی زمان راه‌اندازی رسید تمام سخت‌افزار و پرسنل به‌موقع رسیدند. من هم با مدیر اجرایی حسابداری برای تهیۀ شرح‌کار آموزش مجازی و ILT کار کرده بودم. این مستندات اقلام تحویلی، محدوده، ریسک‌ها، فرضیات، خط زمانی و هزینه‌ها را مشخص کرده بود. هرچند پروژه 8 ماه از زمان‌بندی عقب افتاده بود، اما مدیران پروژه کار را طبق مستندات به‌انجام رساندند. پس مشکل از کجا بود؟
تحلیل نیازها
این پروژه یک فرایند خودپردازی جدیدی را در یک مغازه تعریف می‌کرد. مغازه مزایای سیستم جدید را با نشان‌ها و بنرهای رنگی به اطلاع همه رسانده بود، اما هدف اصلی تجاری کاهش هزینه‌های کار بود. این شیوۀ پرداخت جدید برای ردۀ سنی جوان‌تر بسیار جالب بود. اما یک روز که از راه‌اندازی گذشت من و تعدادی از افراد تیم مشتری با تعجب شاهد بودیم که گروهی از افراد مسن‌تر به‌سمت در خروجی می‌رفتند. این مشتری‌ها واقعاً از سیستم جدید راضی نبودند و سیستم برای برخی از آن‌ها جداً ازلحاظ ذهنی و فیزیکی دشوار بود.
پروژه‌ها غالباً به دلیل «انتظارات غیرواقعی و نامنطبق» شکست می‌خورند. فاز اولیۀ پروژه باید شامل یک مورد تجاری باشد که تحلیل بازار در آن گنجانده شده است.
مشتری ما به‌وضوح نیازهای مشتریانش را به صرفه‌جویی در هزینه درنظر نگرفته بود. حداقل در انتخاب مغازۀ هدف خوب عمل نکرده بودند.
منابع
شاید بتوان شرکت مشتری‌مان را برای اینکه مشتری‌های مغازه سیستم جدید را نپذیرفتند سرزنش کرد، اما مقصر مشکلات سخت‌افزاری و نرم‌افزاری واقعاً شرکت ما بود. مورفی (1994) تأکید می‌کند که به مدیر ارشدی نیاز است که به پروژه منابع کافی اختصاص بدهد. موفقیت قطعاً برای شرکت ما یک بازار جدید ایجاد می‌کرد، اما گروه ما، آن‌قدر که باید، نیرو نداشت. وقتی پروژه آغاز شد نیمی از تیم کوچک ما استعفا دادند و ما برای آن‌ها جایگزین پیدا نکرده بودیم. بدتر از آن یک نقش QA را در فاز حیاتی آزمون ازدست داده بودیم.
رَوِشگان (متدولوژی)
از دیگر اشتباهات ما این بود که برای توسعه و تست محصول روشمان «آبشاری» بود؛ که در دنیای طراحی صنعتی به‌معنای الگوی عمومی طراحی آموزشی یا ADDIE است. وِست (2013) معتقد است که این مدل «خطرپذیر و شکست‌پذیر» است (بند سوم). برعکس روش‌های چابک، فرایند ما خطی و زمان‌بر بود و در فرایند QA و دوباره‌کاری و تأخیرهایی داشت. درنهایت محصولِ عرضه‌شده واقعاً معیوب بود.
نتیجۀ داستان
اگر مدیر ارشد نگرش اشتباهی داشته باشد و منابع کافی به پروژه تخصیص ندهد، علی‌رغم تمام تلاش‌های مدیر پروژه، پروژه به شکست می‌انجامد.
