8.2 دروس من المشاريع الفاشلة
مهما خُطّط للمشروع بعناية، فإن الفشل يبقى ممكنًا. لكن الفشل ليس مجرد نتيجة نهائية — إنه يحمل دروسًا تستحق الحفاظ عليها للمرة القادمة.
يستعرض هذا القسم الأسباب الشائعة وإشارات الإنذار التي تظهر في المشاريع الفاشلة، من زوايا متعددة، حتى تتمكن من رصدها مبكرًا ومنع انتشارها.
1. كانت الأهداف غامضة أو تحوّلت في منتصف الطريق
- كان لدى أصحاب المصلحة المختلفين توقعات متعارضة لم تُسوَّ قط
- لم تُكتب الأهداف التجارية بوضوح، فأوّل كل طرف وجهتها بطريقته
- تغيّرت أولويات الشركة أثناء المشروع، وانحرف الغرض الأصلي
دون اتجاه ثابت، حتى المشروع الذي يُسلَّم في موعده قد يبقى في الذاكرة كخيبة أمل.
2. ضعف التواصل بشأن المخاطر والمشكلات
- أصبح متتبّع المشكلات شكليًا — يُملأ لكن لا يُتفاعل معه
- لم تصل أصوات الميدان إلى صانعي القرار
- كانت خطط تخفيف المخاطر والاحتياط مفقودة أو ضعيفة
ثقافة الصمت — أو تأجيل المحادثات الصعبة — تجعل التصرف بشأن المخاطر المبكرة شبه مستحيل.
3. إغفال العامل البشري
- عُيّن مدير المشروع أو القادة الرئيسيون متأخرين، أو لم يُعيّنوا أصلًا
- تحوّلت المراجعات والاعتمادات إلى ختم مطّاطي
- ترك تغيّر الأعضاء عمليات تسليم ناقصة
استقرار الناس ووضوح الملكية يهمّان بقدر أهمية الجدول الزمني. أفقد أحدهما، يبدأ الباقي بالاهتزاز.
4. لم تكن إدارة المشروع تؤدّي دورها
- كان الوضع مفهومًا، لكن تأخّرت القرارات أو تُجنّبت
- لم تُتّبع القواعد المتفق عليها — المراجعات، تحديثات التقدم
- قُدّمت التقارير، لكنها لم تؤدِّ إلى عمل
"كنا نعرف، لكن لم نتصرّف" واحد من أكثر الأنماط شيوعًا في المشاريع الفاشلة.
دراسة حالة: تجديد موقع تجارة إلكترونية (شركة تجزئة)
نظرة عامة: تجديد كامل لموقع B2C للتجارة الإلكترونية على مدى 8 أشهر، أُلغي في النهاية قُبيل الإطلاق.
- كانت مؤشرات الأداء غير واضحة وظلّت المتطلبات تتغيّر منذ البداية
- كان التنسيق مع فريق المستخدمين ضعيفًا، فظل تأكيد المواصفات يتأخّر
- استقال أعضاء فريق رئيسيون، فانكسرت الاستمرارية والتسليم
- تراكمت مشكلات الجودة قُبيل الإصدار وأُلغي المشروع
جمعت هذه الحالة بين أهداف غامضة، وفجوات قيادية، وتواصل ضعيف — كلٌّ منها يمكن النجاة منه وحده، لكنها مجتمعة دفعت المشروع إلى ما بعد نقطة التعافي.
الخلاصة: الفشل نمط من إشارات تجاهَلَها الجميع
فشل المشروع لا تسبّبه خطيئة واحدة. إنه نتيجة إشارات متراكمة، وقرارات مؤجَّلة، ومحادثات لم تحدث قط.
لذلك، فإن ملاحظة الانزعاج مبكرًا — وامتلاك الشجاعة والنظام للتوقف والحديث والإصلاح — هو الوقاية الحقيقية.
هكذا يبدو هذا في AB
لكل نمط فشل أعلاه نظير في AB Project Management: نطاق غامض → وصف المشروع بالإضافة إلى صفحة "خارج النطاق" في Wiki تمنح النطاق منزلًا واحدًا لا ينحرف؛ مخاطر مخفية → مهام من نوع Risk مع وتيرة متابعة تُبقي المخاطر حيّة بدلًا من دفنها في جدول؛ تصعيدات متأخرة → تبويب سجل التغييرات يُظهر تحوّلات الحالة وتعيين الأشخاص تلقائيًا، فلا يكون التصعيد تقريرًا منفصلًا؛ صوامع المعرفة → صفحات Wiki والتعليقات والمرفقات تبقى مع المشروع بدلًا من تشتّتها عبر الأقراص وعلب البريد؛ ملكية غير واضحة → حقل المسؤول يفرض اسمًا على كل مهمة. AB لا يمنع الإخفاقات — لكنه يجعلها مرئية مبكرًا، حين تكون كلفتها لا تزال زهيدة.
→ التالي، انتقل إلى 9.0 الأسئلة الشائعة (FAQ) للعمل على التحديات الشائعة والمخاوف العملية من العمل الواقعي للمشروع.