الكوتش في دور مدير المشروع

إدارة المشروع تُفهم أحياناً بوصفها فناً للخطط والجداول ومصفوفات المخاطر. وهذه أدوات ضرورية، لكنها لا تفسر وحدها لماذا يتعطل مشروع واضح النطاق وممول جيداً. ينجز البشر معظم المشاريع، ويفسرون الأولويات بطرق مختلفة، ويترددون في رفع المخاطر، ويتفاوضون على الموارد، ويعملون تحت ضغط الوقت والتوقعات. لذلك فإن مدير المشروع الفعال لا يكتفي بمتابعة المهام؛ إنه يصمم شروطاً يتعاون فيها الناس بوضوح ومسؤولية. وهنا تتقاطع إدارة المشاريع (Project Management) مع الكوتشينغ (Coaching).

لا يعني ذلك أن يتحول مدير المشروع إلى معالج أو أن يتخلى عن دوره القيادي لصالح الأسئلة المفتوحة (Open-Ended Questions). للمشروع موعد، وميزانية، وقرارات يجب اتخاذها، وأصحاب مصلحة ينتظرون نتائج. لكن مدير المشروع الذي يوظف عقلية الكوتش يعرف أن الإجابة السريعة قد تمنح تقدماً ظاهرياً، بينما بناء قدرة الفريق (Team) على التفكير واتخاذ القرار يمنح تقدماً قابلاً للاستمرار. إنه يوازن بين التوجيه حين تستدعيه المخاطر أو الخبرة، وبين الاستكشاف حين يكون الحل موزعاً بين أعضاء الفريق لا في رأس شخص واحد.

تتناول هذه المقالة كيف يمكن لمدير المشروع أن يدمج أدوات الكوتشينغ في دورة العمل اليومية: من تحويل التكليف إلى ملكية، إلى استعمال الأسئلة القوية (Powerful Questions) في الاجتماعات، ثم التفويض والقيادة التمكينية، وأخيراً التعامل مع التعثر والتعلم. المقصود ليس إضافة طقوس كثيرة إلى جدول مزدحم، بل رفع جودة الحوارات التي تجري أصلاً.

من خطة المشروع إلى ملكية مشتركة للنتيجة

تبدأ القيادة (Leadership) التمكينية قبل توزيع أول مهمة. فعندما يقدم مدير المشروع خطة مكتملة للفريق ويطلب التنفيذ، قد يحصل على امتثال سريع، لكنه يخسر معرفة العاملين بتفاصيل التنفيذ والمخاطر. أما حين يعرض الهدف (Goal) والقيود غير القابلة للتفاوض، ثم يدعو الفريق إلى المشاركة في بناء المسار، فإنه يثري الخطة ويعزز الشعور بالملكية. لا تعني المشاركة أن كل قرار يُتخذ بالإجماع؛ بل تعني أن يعرف الناس ما الذي تقرر، ولماذا، وأين يملكون التأثير الحقيقي.

يمكن عقد جلسة انطلاق قصيرة حول أربعة محاور: ما النتيجة التي نريدها للمستخدم أو للجهة المستفيدة؟ ما القيود الزمنية والمالية والتنظيمية؟ ما الافتراضات التي نبني عليها الخطة؟ وما المخاطر التي قد تدفعنا، إن تحققت، إلى إعادة التفكير؟ بدلاً من أن يكتفي أعضاء الفريق بالاستماع إلى عرض الشرائح، يكتب كل منهم ما يراه، ثم يناقش الفريق الفروق. هذه العملية تكشف مبكراً أن كلمة مثل «إطلاق» قد تعني لفريق التقنية نسخة تعمل، بينما تعني لفريق العمليات جاهزية دعم العملاء، وتعني للتسويق حملة مكتملة.

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

الملكية المشتركة تحتاج إلى أدوار صريحة. حدّد من يقرر، ومن ينفذ، ومن يُستشار، ومن ينبغي إعلامه. لكن لا تجعل مخطط الأدوار وثيقة جامدة. راجعه عند انتقال المشروع بين المراحل؛ فالشخص الذي يقود الاستكشاف ليس بالضرورة الأنسب لقيادة الإطلاق. وعند تكليف مسؤول بمهمة، لا تكتفِ بعبارة «أنت مسؤول». اسأله: «كيف ستعرف أن العمل أصبح جاهزاً؟ ما أول نقطة قد تتعثر؟ ومن تحتاج أن تتفق معه قبل أن تبدأ؟». هكذا تتحول المسؤولية من عنوان إلى تصور عملي.

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

السؤال القوي ليس سؤالاً ذكياً لذاته، ولا اختباراً خفياً لمعرفة من في الغرفة. هو سؤال يفتح زاوية لم تكن مرئية، ويقود إلى قرار أو تجربة أو وضوح. في المشروع، يفقد السؤال أثره إذا كان عاماً جداً أو متأخراً جداً. سؤال «كيف نشعر؟» قد يصلح لبداية جلسة تأملية، لكنه لا يساعد فريقاً يواجه تأخيراً حرجاً. أما سؤال «ما القرار الذي نؤجله منذ أسبوعين، وما البيانات الأدنى التي نحتاجها لاتخاذه اليوم؟» فيجمع الانتباه حول فعل محدد.

قبل اجتماع الحالة الأسبوعي، يستطيع مدير المشروع أن يرسل ثلاث نقاط: ما الذي تغير؟ أين نحتاج قراراً أو دعماً؟ وما الخطر الذي نفضّل مناقشته الآن بدل أن يفاجئنا لاحقاً؟ وفي الاجتماع، لا يقرأ الجميع تقريرهم بالتتابع؛ بل يركزون على الاستثناءات والاعتمادات والقرارات. من الأسئلة المفيدة: «ما الذي نفترضه ولم نختبره بعد؟»، «إذا تعطل هذا المسار، ما البديل الواقعي؟»، «ما الذي نحتاجه من هذا الفريق تحديداً؟»، و«ما الالتزام الذي يستطيع كل طرف تسميته قبل نهاية الاجتماع؟». هذه الأسئلة تقلل الغموض وتمنع تحويل الاجتماع إلى مسرح عرض إنجازات.

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

تحتاج الأسئلة إلى إنصات حقيقي. لا تسأل كي تفرض الحل الذي تريده في النهاية. امنح الصمت ثواني، واطلب أمثلة ودليلاً، ثم لخّص ما سمعت: «أفهم أن الخطر ليس في بناء الميزة، بل في اعتمادنا على موافقة خارجية لم نثبت وقتها». التلخيص يختبر الفهم ويمنح الفريق لغة مشتركة. وعندما تملك رأياً خبيراً، صرّح بالانتقال: «سأقترح الآن خياراً بحكم خبرتي؛ أريد أن نختبره في ضوء ما ذكرتم». الشفافية تحافظ على الثقة أكثر من التنكر في هيئة سؤال.

التفويض بوصفه بناء قدرة لا نقل عبء

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

ابدأ بتحديد مستوى التفويض. هل المطلوب جمع الخيارات فقط؟ أم تقديم توصية؟ أم اتخاذ قرار ضمن ميزانية محددة؟ أم التنفيذ ثم الإبلاغ؟ لا تفترض أن الطرفين يفهمان الكلمة نفسها. مثال ذلك أن يفوض مدير المشروع محلل البيانات في «معالجة مشكلة لوحة المتابعة». قد يتوقع المحلل حرية تغيير التصميم، بينما يتوقع المدير مجرد تصحيح الأرقام. صياغة أوضح تكون: «أريد منك تشخيص مصدر الخطأ، واقتراح خيارين قبل الثلاثاء. تستطيع التنسيق مع فريق البيانات، وأي تغيير يؤثر في تعريف المؤشر نراجعه معاً».

بعد الوضوح، تأتي أسئلة بناء القدرة: «ما طريقتك الأولى في التعامل مع هذه المهمة؟»، «ما المهارة التي تريد أن تخرج بها من هذا العمل؟»، «ما الدعم الذي تحتاجه مني حتى لا أتحول إلى عنق زجاجة؟». ليست هذه الأسئلة مجاملة؛ فهي تكشف إن كان التفويض مجرد إلقاء في المجهول أم فرصة تعلم مقصودة. وقد يجيب الشخص بأنه يحتاج إلى حضور اجتماع واحد مع صاحب مصلحة صعب، أو إلى مراجعة أول مسودة فقط. عندها يستطيع المدير تقديم دعم محدود ومنظم بدلاً من التدخل الدائم.

تخيل عضو فريق مبتدئاً يقود لأول مرة تنسيقاً بين قسمين متعارضين. لا يصح أن يسلمه المدير المفاوضة الحساسة ثم يختفي. يمكنهما محاكاة الاجتماع مسبقاً: ما النتيجة المطلوبة؟ ما اعتراض كل طرف المحتمل؟ ما السؤال الذي يعيد النقاش إلى الهدف؟ بعد الاجتماع، لا يبدأ المدير بذكر ما كان ينبغي فعله، بل يسأل: «ما الذي لاحظته في ردودهم؟ أين فقدت مسار الحوار؟ وماذا ستفعل بطريقة أخرى؟». ثم يقدّم تغذيته الراجعة المحددة. بهذه الطريقة يصبح التفويض مساراً لتكوين قادة جدد، لا مجرد توزيع للأعمال.

احذر أيضاً من استخدام التمكين (Empowerment) لتبرير نقص الموارد. لا يستطيع الفريق أن يكون «مالكاً للحل» إذا كانت الأولويات تتغير كل يوم أو إذا كان الوصول إلى أصحاب القرار محجوباً. جزء من دور مدير المشروع هو إزالة العوائق، وحماية الوقت، وتصعيد ما يتجاوز سلطة الفريق. التمكين الحقيقي يجمع المسؤولية مع الشروط التي تجعل ممارسة المسؤولية ممكنة.

القيادة التمكينية عند التعثر: تحويل الخطأ إلى تعلم مسؤول

كل مشروع يواجه لحظات لا تسير فيها الخطة: اعتماد يتأخر، مورد ينسحب، اختبار يكشف عيباً، أو تغيير مفاجئ في اتجاه العمل. في هذه اللحظات تظهر الثقافة الفعلية للفريق. إذا كان المدير يبحث فوراً عن المذنب، سيتعلم الناس إخفاء الإشارات المبكرة. وإذا تعامل مع كل تعثر بعبارة «لا بأس»، قد يفقد الفريق حس المسؤولية. القيادة التمكينية تمسك بالطرفين: فضول في فهم ما حدث، ومساءلة واضحة عمّا سيختلف لاحقاً.

عند ظهور مشكلة، افصل بين الوقائع والتفسيرات. ما الذي كان متوقعاً؟ ما الذي حدث فعلاً؟ متى عرفنا بالفجوة؟ وما القرار أو الإشارة التي تجاهلناها؟ هذه الأسئلة تحول الانفعال إلى مادة للتعلم. ثم انتقل إلى المستقبل: ما الإجراء الذي يخفف الضرر الآن؟ ما الافتراض الذي ينبغي اختباره في الدورة القادمة؟ من يملك المتابعة، ومتى نراجع؟ لا يحتاج هذا التحليل إلى اجتماع طويل دائماً؛ يمكن أن ينجز في خمس عشرة دقيقة إذا كان مركزاً وصريحاً.

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

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

خاتمة عملية: طقوس صغيرة تجعل المشروع مدرسة للقيادة

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

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

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