نادرًا ما تنهار المشاريع العملاقة Mega Projects والمشاريع فائقة الضخامة Giga Projects بسبب خطأ كارثي واحد ارتكبه مهندس واحد.

في معظم الحالات، يبدأ الفشل بصورة أكثر هدوءًا.

قرار تصميمي لا يصل إلى فريق المشتريات.
مقاول يفترض أن بندًا معينًا يقع ضمن نطاق مقاول آخر.
خطر يتم تسجيله دون تعيين مسؤول واضح عنه.
تعليمات شفهية تتحول إلى أعمال تنفيذية قبل اعتمادها تعاقديًا وتجاريًا.
صاحب مصلحة كان يُنظر إليه على أنه محدود التأثير، ثم يصبح فجأة قادرًا على تعطيل المشروع بالكامل.

كل مشكلة من هذه المشكلات قد تبدو منفردة قابلة للإدارة.

لكن عندما تتجمع، فقد ينتج عنها أشهر من التأخير، وتكاليف إضافية بملايين الدولارات، ومطالبات تعاقدية Claims، ونزاعات Disputes، وإعادة أعمال Rework، وتدهور في العلاقات بين أطراف المشروع.

وبعد سنوات طويلة من العمل في المشاريع الكبرى، تبقى هناك حقيقة أساسية:

أخطر مناطق المشروع المعقد ليست دائمًا داخل حزم العمل نفسها، بل في المناطق الفاصلة بينها.

مشكلة الواجهات  Interface Management

لنأخذ مثالًا بسيطًا.

المقاول الإنشائي مسؤول عن توفير الفتحات اللازمة للخدمات الميكانيكية.

مقاول الأعمال الكهروميكانيكية MEP يحدد أبعاد المعدات.

الاستشاري المصمم يعتمد مسارات الخدمات.

وفريق المشتريات يختار المعدة النهائية.

قد ينفذ كل طرف نطاق عمله بصورة صحيحة تمامًا.

ولكن ماذا يحدث إذا تغيرت الأبعاد النهائية للمعدة، ولم تصل هذه المعلومة إلى المقاول الإنشائي قبل صب الخرسانة؟

من الناحية التعاقدية، قد يدعي كل طرف أنه نفذ مسؤولياته.

لكن من الناحية التنفيذية، ما زال المشروع أمام مشكلة حقيقية.

وهذا هو فشل إدارة الواجهات  Interface Failure.

في المشاريع الصغيرة، قد يتمكن بعض الأفراد ذوي الخبرة من إدارة هذه الواجهات بصورة غير رسمية.

أما في المشاريع العملاقة، فقد يصبح هذا الأسلوب شديد الخطورة.

مئات الشركات، وآلاف المخرجات Deliverables، وحزم تصميم متعددة، وعقود مختلفة، وجهات حكومية، وموردون، ومشغلون، واستشاريون، ومقاولون؛ كلها تخلق آلاف النقاط التي تنتقل عبرها المعلومات أو المسؤوليات أو الأعمال المادية من جهة إلى أخرى.

هذه الحدود لا يمكن تركها للاجتهاد الشخصي.

يجب إدارتها بصورة منهجية ومقصودة.

وضوح نطاق العمل وحده لا يكفي

تبذل فرق المشاريع جهدًا كبيرًا في تعريف نطاق العمل Scope.

وهذا ضروري، لكنه غير كافٍ.

قد يوضح نطاق العمل بصورة ممتازة ما يجب على المقاول "أ" تنفيذه، وما يجب على المقاول "ب" تنفيذه، لكنه يفشل في توضيح ما يجب أن يحدث بين المقاول أ والمقاول ب.

لكل واجهة رئيسية في المشروع، يجب أن يستطيع الفريق الإجابة بوضوح عن خمسة أسئلة:

ما الذي يجب تسليمه أو تبادله تحديدًا؟

من المسؤول عن تقديمه؟

من يستلمه ومن يعتمد عليه؟

متى يجب توفيره؟

وماذا يحدث إذا تغير هذا المتطلب؟

إذا لم يستطع الفريق الإجابة عن هذه الأسئلة بصورة واضحة، فإن المشروع يحمل مخاطر واجهات Interface Risks، سواء ظهرت هذه المخاطر في سجل المخاطر أم لم تظهر.

أغلى جملة يمكن أن تسمعها في مشروع إنشائي

هناك جملة يجب أن تثير قلق أي مدير مشروع فور سماعها:

"كنت أعتقد أنهم هم المسؤولون عنها."

غالبًا لا تُقال هذه الجملة إلا بعد وقوع المشكلة.

المصمم اعتقد أن المقاول يقوم بالتنسيق.

المقاول الرئيسي اعتقد أن المقاول المتخصص قد أدرج البند ضمن نطاقه.

المورد اعتقد أن المالك سيقوم بتوفير نقطة الربط.

والمالك اعتقد أن البند داخل السعر الإجمالي Lump Sum للمقاول.

هنا تبدأ حالة عدم الوضوح الفني بالتحول سريعًا إلى خلاف تجاري وتعاقدي.

مشكلة بدأت كواجهة غير مُدارة قد تتحول إلى:

• خلاف على نطاق العمل.
• أمر تغييري Change Order.
• مطالبة تعاقدية Claim.
• أو تأخير في البرنامج الزمني.

الحل ليس في عقد اجتماعات أكثر.

الحل هو:

تحديد واضح للمسؤوليات، مدعوم باتفاقيات موثقة ومتابعة منضبطة.

يجب إدارة التغيير قبل أن يصل إلى الموقع

التغيير في حد ذاته ليس أمرًا سلبيًا بالضرورة.

بعض التغييرات قد تحسن السلامة، أو القابلية للتنفيذ Constructability، أو أداء المنشأة، أو القيمة على مدى دورة حياتها.

المشكلة الحقيقية هي التغيير غير المنضبط.

قد يسمع فريق المشروع عبارة:

"إنه مجرد تعديل بسيط."

لكن تعديلًا صغيرًا في تخصص واحد قد يسبب تأثيرات كبيرة على تخصصات أخرى.

تغيير موقع معدة واحدة قد يؤثر على:

الأساسات، والأحمال الكهربائية، وأنظمة مكافحة الحريق، ومسارات الوصول، وأعمال الاختبار والتشغيل Commissioning، ومساحات الصيانة، والمشتريات، والبرنامج الزمني.

لهذا السبب، فرق المشاريع الناضجة لا تقيّم التغيير بالسؤال فقط:

"كم ستبلغ تكلفة هذا البند؟"

بل تسأل السؤال الأهم:

"ما الذي سيتأثر بهذا التغيير؟"

كلما تم طرح هذا السؤال مبكرًا، زادت قدرة الفريق على التعامل مع التغيير دون اضطرابات كبيرة.

ومع تقدم أعمال التنفيذ، تقل الخيارات المتاحة، بينما ترتفع تكلفة التغيير بصورة كبيرة.

سجل المخاطر لا يدير المخاطر

تمتلك مشاريع كثيرة سجلات مخاطر Risk Registers تبدو ممتازة من الناحية الشكلية.

وقد يحتوي بعضها على مئات المخاطر.

لكن هذا لا يعني بالضرورة أن المخاطر تتم إدارتها.

يصبح سجل المخاطر ذا قيمة حقيقية فقط عندما يقود إلى قرارات وإجراءات فعلية.

الخطر المُدار بصورة صحيحة يجب أن يتضمن:

• سببًا واضحًا ومحددًا للخطر.
• الحدث المحتمل.
• أثرًا يمكن قياسه.
• تقييم الاحتمالية والتأثير.
• مسؤولًا واضحًا عن الخطر Risk Owner.
• استجابة متفقًا عليها.
• مؤشرًا أو إشارة تحذيرية Trigger.
• تاريخًا للمراجعة.
• ودليلًا على أن إجراءات الاستجابة يتم تنفيذها فعلًا.

عبارة:

"سنستمر في مراقبة الخطر."

ليست استراتيجية.

كما أن مناقشة نفس الخطر شهريًا بينما تستمر احتمالية حدوثه في الارتفاع ليست إدارة مخاطر.

الهدف من إدارة المخاطر ليس توثيق ما قد يحدث بصورة خاطئة.

الهدف هو تغيير ما يفعله فريق المشروع قبل أن يحدث الخطأ.

العقود لا تستطيع أن تحل محل التعاون

العقود عنصر أساسي في إدارة المشاريع.

فهي تحدد الالتزامات، وتوزع المخاطر، وتوضح الآليات التجارية، وتحدد الإجراءات التي يجب اتباعها عند حدوث خلاف.

لكن لا يوجد عقد قادر بمفرده على إدارة مشروع إنشائي معقد بنجاح.

العقد يحدد ما يلتزم الأطراف بتنفيذه.

أما نظام إدارة المشروع، فيجب أن يحدد كيف ستتم آلاف التفاعلات اليومية بين تلك الأطراف.

ولهذا، تجمع المشاريع القوية بين الانضباط التعاقدي والتعاون التشغيلي.

ويشمل ذلك:

• صلاحيات واضحة لاتخاذ القرار.
• قنوات اتصال محددة.
• سجلات للواجهات Interface Registers.
• أنظمة منضبطة لإدارة الوثائق.
• مهلًا زمنية لاتخاذ القرارات.
• آليات واضحة للتصعيد Escalation.
• إجراءات لإدارة وضبط التغييرات.
• وتنسيقًا دوريًا ومنظمًا بين مختلف الجهات.

الهدف ليس منع جميع الخلافات.

فهذا غير واقعي.

الهدف هو منع الخلاف من التحول إلى تعطيل للمشروع.

أصحاب المصلحة قادرون على تغيير مسار المشروع دون تعديل رسم واحد

يميل العاملون في قطاع الإنشاءات بصورة طبيعية إلى التركيز على الرسومات، والجداول الزمنية، والكميات، والعقود.

لكن بعضًا من أكبر مخاطر المشروع لا يوجد داخل أي من هذه المستندات.

الجهات الحكومية، والمجتمعات المحلية، والمنظمات البيئية، وشركات الخدمات، والمشغلون، والمستثمرون، وغيرهم من أصحاب المصلحة Stakeholders قد يؤثرون بصورة جوهرية في المشروع.

كما أن مستوى تأثيرهم قد يتغير مع الزمن.

قد يكون أحد أصحاب المصلحة محدود التأثير خلال مرحلة التصميم، ثم يصبح شديد التأثير خلال مرحلة إصدار التصاريح أو التنفيذ.

لهذا، لا يجوز إجراء تحليل أصحاب المصلحة مرة واحدة ثم اعتباره منتهيًا.

يجب على فريق المشروع إعادة تقييم الأسئلة التالية بصورة مستمرة:

من يمتلك القوة أو السلطة؟

من لديه اهتمام مرتفع بالمشروع؟

من يستطيع التأثير على القرار؟

من يستطيع تعطيل المشروع أو تأخيره؟

دعم من سيصبح حاسمًا خلال المرحلة القادمة؟

تجاهل هذه الأسئلة حتى تظهر المعارضة أو المشكلة عادة ما يكون أكثر تكلفة بكثير من إدارة العلاقة مع أصحاب المصلحة بصورة مبكرة.

أفضل فرق المشاريع تكشف المشكلات مبكرًا

ثقافات المشاريع الضعيفة تُخفي المشكلات.

أما ثقافات المشاريع القوية فتجعل المشكلات مرئية.

وهذا الفرق جوهري.

عندما يخشى الأفراد من اللوم، فإنهم يؤخرون نقل الأخبار السيئة.

وعندما تتأخر المعلومة السيئة، تقل خيارات الإدارة في التعامل معها.

أما المؤسسة الناضجة، فتبني بيئة يستطيع فيها المهندس أن يقول:

"لدينا مشكلة."

فتكون استجابة الإدارة:

"ممتاز أننا عرفنا بها مبكرًا بما يكفي لنتعامل معها."

يمكن أن تساعد غرف الإدارة المرئية Big Room / Obeya، واجتماعات التنسيق المنظمة، ومنصات تبادل المعلومات، ومسارات التصعيد الواضحة في تحقيق ذلك.

لكن التكنولوجيا ليست الحل الحقيقي.

الحل الحقيقي هو:

ثقافة تتحرك فيها المعلومة أسرع من المشكلة.

المهارة الحقيقية وراء نجاح المشاريع العملاقة

المشاريع العملاقة تحتاج بلا شك إلى معرفة فنية وهندسية استثنائية.

لكن التميز الفني وحده لا يضمن نجاح المشروع.

غالبًا ما يصبح الأشخاص الأكثر قيمة داخل المشاريع هم القادرون على ربط التخصصات ببعضها.

يربطون:

الهندسة بالعقود.

ونطاق العمل بالبرنامج الزمني.

والمخاطر باتخاذ القرار.

وأصحاب المصلحة بالاستراتيجية.

والتصميم بالتنفيذ.

والتنفيذ بالتشغيل.

والمقاول بمقاول آخر.

هؤلاء يفهمون أن مسؤوليتهم لا تنتهي عند حدود حزمة العمل الخاصة بهم.

لأن المشاريع الكبرى ليست مجرد مجموعة من حزم الأعمال.

إنها أنظمة مترابطة.

والأنظمة غالبًا لا تفشل داخل مكوناتها.

بل تفشل عند نقاط الاتصال بينها.

فكرة أخيرة

عندما تقوم بمراجعة مشروعك القادم، لا تسأل فقط:

"هل تتم إدارة كل حزمة عمل بصورة جيدة؟"

بل اسأل أيضًا:

"من يدير كل ما يحدث بين حزم العمل؟"

قد يكشف هذا السؤال عن الحالة الحقيقية للمشروع أكثر مما يمكن أن تكشفه مئة صفحة إضافية من تقارير التقدم.