كيف تمنع زحف نطاق المشروع؟ أدوات عملية لإدارة النطاق وضبط التغيير

ما الفرق بين زحف النطاق والتغيير المعتمد؟

زحف نطاق المشروع هو إضافة مزايا أو وظائف أو متطلبات أو أعمال لم تُعتمد، أي عمل يتجاوز النطاق المتفق عليه. فالمشكلة ليست في التغيير نفسه، والتوسع الذي يمر بالموافقة المعتمدة ليس زحفًا. ^[1]

ومن صوره التذهيب (Gold Plating)، حين يضيف المطورون أو الخبراء الفنيون مزايا يرونها مفيدة. وحتى لو أضافت قيمة، فقرار إضافة الوظائف ليس من صلاحيتهم. ^[1] وفي المقابل يحذر المصدر نفسه من “قتل النطاق”، أي إجراء جامد يرفض التغييرات المشروعة. ^[1]

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

لماذا يزحف النطاق؟

ترصد ورقة منشورة في مكتبة PMI خمسة أسباب متكررة، ولكل منها علاج عملي: ^[1]

وطول المشروع لا يسبب الزحف مباشرة، لكنه يوسع الفرصة له خاصة إذا اجتمعت معه الأسباب الأربعة الأخرى. ^[1] لذلك يُنصح بتقسيم المشروعات الطويلة إلى مراحل أو مشروعات فرعية تُغلق كل منها بدروسها المستفادة. ^[1]

الأداة الأولى: بيان نطاق يحدد ما هو خارج المشروع

يبدأ ضبط النطاق من الراعي بميثاق يحدد مزايا المنتج، ثم يكتب مدير المشروع بيان نطاق يذكر صراحة المزايا الداخلة في النطاق والخارجة منه. ^[1] ويضع مخطط محتوى امتحان PMP لعام 2026 هذه المهمة في ثلاث خطوات: تعريف النطاق، والحصول على موافقة أصحاب المصلحة عليه، وتجزئته. ^[3]

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

ولتوضيح الحدود قبل التفاصيل، يفيد مخطط السياق الذي يرسم الحل في المركز وحوله الجهات والأنظمة وتدفقات البيانات المتصلة به. فتحديد ما يقع خارج الحل يكشف حدوده، ويكشف أيضًا واجهات الربط وأصحاب مصلحة ربما لم يُحسب لهم حساب. ^[5]

إدارة المتطلبات وتتبعها

بيان النطاق وحده لا يكفي إذا جُمعت المتطلبات بطرق مختلفة من كل إدارة. والعلاج خطة لإدارة المتطلبات، وتتبع كل متطلب رجوعًا إلى هدف العمل الذي يخدمه وصولًا إلى التصميم والاختبار والتنفيذ، وموافقة أصحاب المصلحة على المتطلبات قبل البناء. ^[1] ويفيد جمع المتطلبات على طبقات متتالية، من العام إلى التفصيلي، بدل محاولة جمعها كلها دفعة واحدة. ^[1]

الأداة الثانية: هيكل تجزئة العمل وخط أساس النطاق

هيكل تجزئة العمل (WBS) تفكيك هرمي موجه بالمخرجات للنطاق الكامل إلى مكونات أصغر يمكن إسنادها وتقديرها ومتابعتها. ^[2] وتنص قاعدة 100% على أن الهيكل يشمل كل العمل داخل النطاق، وأن مكونات كل عنصر تساويه تمامًا، فلا عمل ناقص ولا عمل زائد. ^[2]

ويرافق الهيكل قاموس يعرّف كل عنصر: نطاقه ومعالمه ومسؤوله وموارده ومعايير قبوله. ^[2] ومجموع بيان النطاق المعتمد والهيكل وقاموسه هو خط أساس النطاق، وهو المرجع الذي تُقاس عليه طلبات التغيير. ^[2]

ومعايير القبول في القاموس هي خط الدفاع العملي: حين يقول المستخدم “توقعت أن يفعل النظام كذا”، تعود إلى المعيار المكتوب بدل الجدل حول النوايا.

الأداة الثالثة: إجراء ضبط تغيير مكتوب

الطلبات الصغيرة التي تُقبل دون تقييم أثر، والتحسينات التي يضيفها المهندسون دون موافقة، هي الطريق المعتاد للزحف. ^[4] لذلك يُتفق كتابيًا مع العميل قبل بدء العمل على طريقة اقتراح أي عمل خارج النطاق وتقييمه واعتماده وتنفيذه. ^[4]

ويضع مخطط محتوى PMP لهذه المهمة أربع ممارسات: تنفيذ إجراء ضبط التغيير، وإبلاغ حالة التغييرات المقترحة، وتنفيذ التغييرات المعتمدة، وتحديث وثائق المشروع لتعكسها. ^[3] وتضيف ورقة Abramovici ممارسات ميدانية مفيدة: ^[4]

• مراجعة المواصفات وبيان العمل بندًا بندًا مع العميل قبل التوقيع لإزالة المناطق الرمادية.
• تسجيل تكلفة العمل المشكوك في دخوله النطاق في حساب مستقل مع مبرر مكتوب.
• جمع أفكار التحسين من الفريق في قائمة لمرحلة لاحقة بدل تنفيذها الآن.
• التزام قاعدة “لا إضافات مجانية” بعد الاتفاق الأولي.

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

مثال افتراضي

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

نموذج طلب تغيير من صفحة واحدة

لا يحتاج طلب التغيير إلى نموذج طويل، لكنه يحتاج إلى حقول تمنع القرار قبل فهم الأثر:

وحقل البدائل هو الأهم عمليًا، لأنه يحول الطلب من إضافة صافية إلى مفاضلة واضحة يراها صاحب القرار. ^[4]

كيف يتعامل الفريق التكيفي مع التغيير؟

تتوقع المناهج التكيفية التغيير، لكنها لا تتركه بلا ضابط. ففي Scrum يمكن توضيح النطاق وإعادة التفاوض عليه مع مالك المنتج كلما زادت المعرفة، لكن لا يُجرى أي تغيير يهدد هدف السبرنت، ولا تنخفض الجودة. ^[6] ومالك المنتج مسؤول عن إدارة قائمة المنتج وترتيبها، ولا يملك إلغاء السبرنت غيره. ^[6]

وقائمة المنتج المرتبة أداة فعالة ضد الزحف حتى في المشروعات الهجينة: كل طلب جديد يُقدَّر ويوضع في موقعه من الأولويات، فيرى صاحبه ما الذي سيتأخر إذا تقدم طلبه. ^[5] وبهذا يتحول النقاش من “نعم أو لا” إلى “ماذا نؤجل مقابله؟”.

قائمة تحقق أسبوعية لمدير المشروع

• هل وصل طلب جديد خارج سجل التغيير؟ سجّله اليوم.
• هل يعمل أحد في الفريق على شيء لا يقابله عنصر في هيكل تجزئة العمل أو قائمة المنتج؟
• هل حُدّث خط الأساس بعد آخر تغيير معتمد؟
• هل يعرف أصحاب المصلحة حالة طلباتهم؟
• هل الراعي حاضر في القرارات أم يتركها للفريق؟ ^[1]

الخلاصة

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