لو عندك فريق بيشتغل على أكتر من مشروع في نفس الوقت، أنت عارف الأعراض: حد نسي مهمة، مشروع اتأخر ومحدش عرف ليه، عميل بيسأل عن حالة شغله ومحدش عنده إجابة واضحة، ومشروع اتقفل وأنت مش متأكد كسبت منه ولا خسرت.
الحل المعتاد: اشتراك في نظام إدارة مشاريع. والنتيجة المعتادة: الفريق يستخدمه شهر، وبعدين يرجع لجروب الواتساب.
الدليل ده عن ليه بيحصل ده — وإزاي تختار نظام فريقك هيستخدمه فعلاً.
ابدأ من المشكلة مش من النظام
«عايزين ننظّم شغلنا» مش مشكلة — دي أمنية. المشكلة الحقيقية بتبان في سؤال: إيه اللي بيوجعك فعلاً؟
أعراض مختلفة تحتاج حلول مختلفة
- «بنفقد المواعيد» → محتاج جدول زمني وتبعيات وتنبيهات.
- «مش عارفين مين فاضي» → محتاج إدارة موارد وتحميل الفريق.
- «مش عارفين المشروع كسب ولا خسر» → محتاج تتبّع وقت وتكاليف.
- «العميل بيسأل ومحدش عارف» → محتاج حالة مشروع واضحة وربما بوابة عميل.
- «الشغل بيضيع بين الأقسام» → محتاج سير عمل بمراحل وتسليم واضح.
دورة حياة المشروع عندك
قبل ما تقيّم أي نظام، ارسم الرحلة الفعلية:
- الطلب بيجي إزاي؟ (عميل، مبيعات، إدارة)
- مين بيقدّر الوقت والتكلفة؟ وعلى أي أساس؟
- مين بيوافق على البدء؟
- الشغل بيتقسّم إزاي؟ ومين بيوزّع؟
- التقدّم بيتقاس إزاي؟ (نسبة، مراحل، مهام مكتملة)
- المراجعة والاعتماد بيحصلوا إمتى؟
- التسليم والفاتورة بيتربطوا إزاي؟
- مين بيراجع الربحية بعد القفل؟
كل خطوة فيها قرار أو تسليم هي نقطة النظام لازم يغطّيها. والخطوات اللي مالهاش صاحب واضح هي مصدر مشاكلك الأساسي — والنظام مش هيحلها لوحده.
المنهجية المناسبة لشغلك
قوائم مهام بسيطة
مناسبة للفرق الصغيرة والشغل اللي مافيهوش تبعيات معقدة. أبسط وأسرع تبنّي. لو ده وضعك، متعقّدش الأمور بنظام ثقيل.
كانبان (لوحات المراحل)
الشغل بيتحرك بين أعمدة: جديد ← قيد التنفيذ ← مراجعة ← مكتمل. ممتاز للفرق اللي شغلها تدفّق مستمر: التصميم، الدعم، المحتوى، التطوير.
أهم إعداد فيها: حد أقصى للمهام في عمود «قيد التنفيذ». من غيره كل حاجة بتبقى «قيد التنفيذ» ومفيش حاجة بتخلص.
الجدول الزمني والتبعيات
مناسب للمشاريع اللي فيها ترتيب إجباري: مقاولات، تركيبات، فعاليات، تصنيع. المهمة B مش هتبدأ قبل A تخلص، وتأخير A بيزحزح كل اللي بعده.
تنبيه: الجداول الزمنية بتحتاج صيانة. لو مش هتحدّثها أسبوعياً على الأقل، هتبقى صورة قديمة بتضلّل أكتر ما تفيد.
الهجين
أغلب الشركات بتحتاج مزيج: جدول زمني على مستوى المشروع، وكانبان على مستوى الفريق اليومي. النظام الكويس بيدعم العرضين لنفس البيانات.
الوحدات الأساسية
1. المشاريع والمهام
الأساس: مهمة ليها مسؤول وموعد وحالة وأولوية، مرتبطة بمشروع. والمهام الفرعية للتقسيم. والأهم: سجل تغييرات يوريك مين غيّر إيه وإمتى.
2. الموارد
مين متاح ومشغول بكام. من غير الوحدة دي، بتوزّع شغل على أساس الإحساس وبتكتشف التحميل الزايد بعد فوات الأوان. لازم تشوف: نسبة تحميل كل فرد الأسبوع الجاي، والإجازات والالتزامات.
3. الوقت والتكاليف
ساعات مسجّلة على المهام، وتكلفة الساعة لكل دور، ومصروفات مباشرة. ده اللي بيدّيك ربحية المشروع الحقيقية — الرقم اللي أغلب الشركات بتفتكره وبتحسبه غلط.
4. الموافقات وسير العمل
لو عندك مراحل بتحتاج اعتماد (تصميم، ميزانية، تسليم)، لازم تكون في النظام مش في الإيميل. الموافقة في إيميل معناها مفيش أثر ولا تنبيه ولا تتبّع.
5. الملفات والتسليمات
النسخة النهائية فين؟ سؤال بيضيّع وقت هائل. الملفات مرتبطة بالمهمة، مع نسخ ومراجعات واضحة.
6. التواصل داخل السياق
التعليق على المهمة نفسها بدل جروب عام. أهم فايدة: القرار بيفضل مربوط بمكانه — بعد 6 شهور تعرف ليه اتاخد.
7. التقارير
حالة كل مشروع، المتأخر، تحميل الفريق، الوقت المستهلك مقابل المقدّر، والربحية.
8. بوابة العميل (اختيارية)
العميل يشوف حالة مشروعه ويعتمد التسليمات. بتقلّل مكالمات المتابعة بشكل كبير — بس بتحتاج انضباط في التحديث، لأن بيانات قديمة قدام العميل أسوأ من مفيش بوابة.
ليه الأنظمة بتفشل
ده أهم قسم — لأن اختيار النظام الصح مش كفاية.
1. التحديث أغلى من الفايدة
لو تحديث حالة مهمة بياخد 6 نقرات وتحميل صفحة، الموظف هيكتب في الواتساب. النظام الناجح هو اللي التحديث فيه أسرع من البديل. جرّب بنفسك: قيس كام ثانية تاخد لتحديث مهمة.
2. الإدارة بتستخدم نظام تاني
لو المدير بيطلب تقرير على إيميل بدل ما يفتح النظام، الفريق هيفهم إن النظام مش المصدر الحقيقي. الالتزام بيبدأ من فوق.
3. التطبيق دفعة واحدة
تفعيل كل الوحدات على كل الفرق في نفس اليوم = فوضى وارتداد. ابدأ بفريق واحد ووحدة واحدة.
4. تفاصيل زيادة
لو النظام بيطلب 12 حقل لإنشاء مهمة، محدش هينشئ مهام. ابدأ بالحد الأدنى وزوّد لما تحتاج.
5. مفيش صاحب للنظام
لازم شخص مسؤول: يضبط الإعدادات، يدرّب الجدد، يجاوب الأسئلة، ويراجع الاستخدام. من غيره النظام بيتدهور خلال شهور.
6. فرض تتبّع الوقت بدون سبب
لو مش هتستخدم البيانات في تسعير أو ربحية، ده عبء إداري بيولّد مقاومة. اطلبه لما يكون له غرض واضح ومشروح.
جاهز مقابل مخصص
الجاهز — إمتى يكفي
- سير عملك قياسي إلى حد كبير.
- الفريق أقل من 30–40 شخص.
- مش محتاج تكاملات عميقة بأنظمة داخلية.
- عايز تشتغل خلال أسابيع.
الجاهز بيديك وظائف مجرّبة وتحديثات مستمرة وتكلفة بداية منخفضة.
المخصص — إمتى يستحق
- سير عمل غير قياسي — تسعير بمعادلة خاصة، موافقات متعددة المستويات، مراحل مرتبطة بلوائح تنظيمية.
- تكامل عميق — ربط بنظام محاسبي أو ERP أو أجهزة ميدانية.
- عدد مستخدمين كبير — الاشتراك بيتحوّل لبند تكلفة كبير مع النمو.
- البيانات حسّاسة — مطلوب تحكم كامل في مكان التخزين.
- العملية نفسها ميزتك — الجاهز هيجبرك تتخلى عنها.
الوسط العملي
جاهز للنمطي (مهام، ملفات، تواصل) + وحدة مخصصة للجزء المميّز، مربوطين بـAPI. تدفع مرة واحدة في المكان اللي بيفرق بس. الإطار الكامل في دليل ERP جاهز مقابل مخصص.
التكلفة على 3 سنين
الجاهز
الاشتراك الشهري للمستخدم × عدد المستخدمين المتوقع بعد سنتين × 36 شهر + رسوم الإعداد + التخصيص + التدريب + رسوم التكاملات.
المخصص
تكلفة البناء + الاستضافة × 36 + عقد الدعم × 36 + التعديلات المتوقعة.
البنود المنسية
- وقت الفريق أثناء التعلّم — تكلفة حقيقية.
- انخفاض الإنتاجية أول شهر — متوقع، خطّط له.
- نقل البيانات — أقل من العيادات لكن موجود.
- الترقيات الإجبارية — بعض الأنظمة بتنقلك لباقة أغلى عند حد معيّن من المشاريع أو التخزين.
القطاعات ومتطلباتها
المكاتب الهندسية والاستشارية
محتاجة تتبّع وقت دقيق (المحاسبة غالباً بالساعة)، ومراحل تسليم بمراجعات، وأرشفة مخططات بنسخ. والربحية لكل مشروع هي المقياس.
المقاولات
جدول زمني بتبعيات، ربط بالمخزون والمواد، مستخلصات مرحلية، ومتابعة مقاولين من الباطن. والتحديث من الموقع بالموبايل شرط مش رفاهية.
وكالات التسويق والتصميم
كانبان بمراجعات العميل، تتبّع ساعات لتقييم ربحية العميل، ومكتبة أصول. وبوابة العميل بتقلّل الذهاب والإياب.
شركات البرمجيات
مهام مرتبطة بإصدارات، تتبّع أخطاء، ومراجعة كود. غالباً بتستخدم أدوات متخصصة مش نظام إدارة مشاريع عام.
الفعاليات
جدول زمني مضغوط بمواعيد صارمة، قوائم مهام لكل مورّد، وقوائم فحص لحظية يوم التنفيذ.
القياس — إيه اللي تتابعه
- نسبة المشاريع المسلّمة في موعدها — المقياس النهائي.
- الوقت المقدّر مقابل الفعلي — بيحسّن تقديراتك الجاية.
- ربحية المشروع — الإيراد ناقص التكلفة الحقيقية بالساعات.
- تحميل الفريق — مين فوق طاقته ومين تحتها.
- المهام المتأخرة — واتجاهها بمرور الوقت.
- نسبة التبنّي — كام % من الفريق بيحدّث أسبوعياً. لو أقل من 80%، عندك مشكلة تبنّي مش مشكلة نظام.
أسئلة قبل ما تدفع
- أقدر أجرّب بمشروع حقيقي كامل قبل الالتزام؟
- تحديث حالة مهمة بياخد كام نقرة؟ (جرّبها بنفسك)
- السعر بيتغيّر إزاي مع زيادة المستخدمين أو المشاريع؟
- أقدر أصدّر كل بياناتي في أي وقت وبأي صيغة؟
- فيه API للربط بأنظمتي؟
- التطبيق على الموبايل بيعمل إيه فعلاً — عرض بس ولا تحديث كامل؟
- الصلاحيات دقيقة لدرجة إن العميل يشوف مشروعه بس؟
- إيه المشمول في الدعم وبأي لغة؟
- ممكن أكلّم شركة في مجالي شغالة عليه؟
التقدير — الجذر الحقيقي للتأخير
أغلب المشاريع مابتتأخرش لأن الفريق بطيء — بتتأخر لأن التقدير كان متفائل من الأساس. والنظام مش هيصلّح ده، بس بيدّيك البيانات اللي تصلّحه بيها.
ليه التقديرات بتطلع غلط
- تقدير المهمة لوحدها بدون وقت المراجعة والتعديل والانتظار على العميل.
- افتراض تفرّغ كامل — الموظف مش بيشتغل 8 ساعات على مهمة واحدة. الواقعي 5–6 ساعات إنتاجية.
- تجاهل التبديل بين المهام — اللي شغال على 4 مشاريع بيفقد وقت في كل تنقّل.
- الضغط للتقدير المتفائل — لما المدير يقول «ده ماياخدش أسبوع»، الفريق بيوافق ويتأخر.
إزاي تحسّن
الطريقة الوحيدة اللي بتشتغل: قارن المقدّر بالفعلي بعد كل مشروع. لو اكتشفت إن تقديراتك بتقل 40% باستمرار، ده مش فشل — ده معامل تصحيح. اضربه في تقديراتك الجاية.
والنظام هنا بيدّيك القيمة الحقيقية: من غير تسجيل وقت فعلي، مفيش طريقة تعرف معاملك.
التقدير بالنطاق
بدل «5 أيام»، قول «4–7 أيام». النطاق بيوصّل عدم اليقين بصدق، وبيخلي المحادثة مع العميل عن المخاطر مش عن الوعود.
تضخّم النطاق
«إضافة صغيرة» × 20 = مشروع تاني بميزانية المشروع الأول. ده أكتر سبب لخسارة المشاريع المسعّرة بسعر ثابت.
إزاي تتعامل معاه
- نطاق مكتوب ومعتمد من البداية — ومتبدأش شغل من غيره.
- سجل تغييرات — كل طلب إضافي يتسجّل كطلب تغيير بتقدير وقت وتكلفة.
- مالكش حق ترفض، بس ليك حق تسعّر — «تمام نعملها، دي هتضيف يومين و1,500 ريال، توافق؟»
- راجع الطلبات المتراكمة — لو 10 «إضافات صغيرة» عدّت مجاناً، وريها للعميل مجمّعة عشان يفهم القيمة.
الفرق الموزّعة والعمل عن بُعد
لو فريقك موزّع أو بيشتغل عن بُعد، النظام بيتحوّل من أداة تنظيم لمصدر الحقيقة الوحيد.
اللي بيفرق
- التواصل غير المتزامن — التعليق على المهمة أهم من الاجتماع، لأنه بيفضل مكتوب ومربوط بسياقه.
- وضوح الحالة — الحالة لازم تكون واضحة من غير ما حد يسأل. «قيد التنفيذ» مش كافية، «مستني مراجعة العميل» أوضح.
- المناطق الزمنية — لو الفريق في بلاد مختلفة، النظام لازم يعرض المواعيد بتوقيت كل مستخدم.
- التوثيق — القرارات تتكتب مش تتقال في مكالمة.
الاجتماعات
لو الاجتماع اليومي بيتحوّل لقراءة تحديثات، ده معناه إن النظام مش بيتحدّث. الاجتماع الصح بيناقش العوائق بس — والتحديثات تكون مقروءة قبله.
المخاطر — القسم اللي الكل بيتخطاه
سجل مخاطر بسيط بيوفّر أزمات كتيرة. مش محتاج تعقيد — جدول فيه:
- الخطر — «المورّد ممكن يتأخر في التسليم».
- الاحتمال — عالي/متوسط/منخفض.
- الأثر — لو حصل، هيأخّرنا كام؟
- الاستجابة — نعمل إيه؟ مورّد بديل؟ طلب مبكر؟
- المسؤول — مين بيراقبه.
المخاطر الشائعة في المشاريع الخدمية
- تأخر العميل في المراجعة أو تسليم المحتوى — الأشيع على الإطلاق.
- غياب أو مغادرة شخص أساسي.
- تغيير متطلبات بعد بدء التنفيذ.
- اعتماد على طرف ثالث (مورّد، جهة حكومية، مزوّد خدمة).
التواصل مع العميل
تقرير الحالة الدوري
رسالة أسبوعية قصيرة: خلص إيه، شغالين على إيه، مستنيين منك إيه، وفيه مخاطر إيه. دي بتمنع 90% من مكالمات «فين المشروع؟».
بوابة العميل
لو النظام بيوفّرها، العميل يشوف الحالة والتسليمات ويعتمدها بنفسه. بس بشرط: لو البيانات مش محدّثة، البوابة بتضر أكتر ما تنفع.
حدود واضحة
حدّد قنوات التواصل الرسمية. لو العميل بيبعت طلبات على واتساب شخصي لموظف، هتضيع ومش هتتسجّل. وجّه كل الطلبات لقناة واحدة موثّقة.
خطة تطبيق تنجح
الأسبوع 1 — التجهيز
اختار فريق واحد ومشروع واحد. اضبط الحد الأدنى: مشروع، مهام، مسؤول، موعد، حالة. متفعّلش تتبّع وقت ولا موافقات ولا تقارير دلوقتي.
الأسبوع 2–3 — التشغيل المحدود
الفريق يشتغل على النظام بالتوازي مع طريقته القديمة. راقب: بيحدّثوا؟ بيشتكوا من إيه؟ التحديث بياخد قد إيه؟
الأسبوع 4 — القرار
لو التبنّي كويس، أوقف الطريقة القديمة لهذا الفريق. لو ضعيف، اعرف السبب قبل ما توسّع — التوسّع بمشكلة تبنّي بيضاعفها.
الشهر 2 — التوسّع
فريق تاني، ووحدة واحدة جديدة (الملفات أو الموافقات). واحدة في المرة.
الشهر 3 — القياس
فعّل التقارير وتتبّع الوقت لو محتاجه. دلوقتي بس، بعد ما الأساسيات بقت عادة.
الخلاصة
نظام إدارة المشاريع الناجح مش الأغنى بالمميزات — هو اللي فريقك بيحدّثه من غير ما حد يفكّره. ابدأ من المشكلة اللي بتوجعك، اختار أبسط حاجة تحلها، طبّق على فريق واحد، وزوّد بالتدريج.
ولو سير عملك فيه تميّز حقيقي، النظام الجاهز هيجبرك تتخلى عنه — وساعتها المخصص بيستحق.
احنا في يوني بنبني أنظمة إدارة مخصصة، وبنقول للعميل بصراحة لما الجاهز يكون أوفر له. لو عايز رأي محايد في حالتك، كلّمنا.
ما هو برنامج إدارة المشاريع؟
Project management software هو نظام بيحوّل الشغل من رسايل ومكالمات وملفات متفرقة لصورة واحدة: مين بيعمل إيه، وإمتى المفروض يخلص، وإيه اللي متوقف على إيه.
الفرق بينه وبين قايمة مهام عادية إنه بيمسك الاعتماديات. المهمة اللي مش هتبدأ غير لما التانية تخلص، والتأخير اللي بيدفع تواريخ عشر مهام بعديها. القايمة العادية بتوريك المهام، والنظام بيوريك أثر التأخير.
إدارة المهام مقابل إدارة المشاريع
Task management و project management مش نفس الحاجة، والخلط بينهم بيخلي الشركة تشتري أداة أبسط من احتياجها أو أعقد.
إدارة المهام
مهام مستقلة ليها مسؤول وميعاد وحالة. مناسبة للشغل المتكرر والفرق الصغيرة: طلبات التصميم، وتذاكر الدعم، والمتابعات اليومية. لوحة بأعمدة بتكفي هنا.
إدارة المشاريع
مشروع له بداية ونهاية وميزانية ونطاق، وجواه مهام مترابطة. محتاج جدول زمني، واعتماديات، وموارد، ومسار حرج. أي حاجة فيها تاريخ تسليم نهائي وعقوبة تأخير بتقع هنا.
القاعدة العملية: لو الشغل بيتكرر كل أسبوع بنفس الشكل، إنت محتاج إدارة مهام. لو كل شغلة ليها بداية ونهاية وميزانية، إنت محتاج إدارة مشاريع.
مخطط جانت والمسار الحرج
Gantt chart هو الرسم الأفقي اللي بيوري المهام على محور زمني، وكل مهمة عمود بيمتد من تاريخ البداية للنهاية، والأسهم بين المهام بتوضّح الاعتماديات.
فايدته الحقيقية
مش إنه شكل حلو للعرض على الإدارة. فايدته إنه بيوريك المسار الحرج: سلسلة المهام اللي أي تأخير فيها بيأخّر المشروع كله. المهام اللي برّه المسار ده عندها فسحة، وممكن تتأخر من غير ضرر.
وده بيغيّر طريقة إدارتك: بدل ما تضغط على كل الفريق بالتساوي، بتركّز على المسار الحرج. أغلب المديرين بيضغطوا على المهمة اللي بتبان متأخرة في اللوحة، وهي غالباً مش على المسار الحرج أصلاً.
حاجة تتجنبها
مخطط جانت من مئات المهام بيتعمل مرة في بداية المشروع ومحدش بيحدّثه. المخطط اللي مش بيتحدّث أسبوعياً بيتحوّل لصورة تاريخية بتخدع الكل.
تقدير الوقت والموارد
أكتر سبب لتأخير المشاريع مش الكسل، ده التقدير المتفائل.
قواعد عملية في التقدير
- قدّر بالمجهود مش بالمدة. «المهمة دي عشر ساعات شغل» غير «هتاخد يومين» — الشخص مش بيشتغل 8 ساعات صافية في اليوم.
- خد بالك من التوزيع. الشخص المقسوم على تلات مشاريع بيخسر وقت في التنقل بينهم.
- سجّل التقدير والفعلي. بعد عشر مهام هتعرف نسبة الانحراف عندك، واستخدمها كمعامل في التقديرات الجاية.
- الأجازات والعطلات جزء من الجدول مش مفاجأة.
تحميل الموارد
النظام لازم يوريك كل شخص محمّل بكام ساعة في الأسبوع الجاي عبر كل المشاريع. من غير الصورة دي، بتوزّع مهام على ناس مشغولة أصلاً وبتستغرب إن كل حاجة بتتأخر.
تتبع الوقت
موضوع حساس، ونجاحه بيعتمد على الغرض منه.
لو بتتبّع الوقت عشان تحاسب الموظفين، الفريق هيسجّل أرقام مجمّلة والبيانات هتبقى بلا قيمة. لو بتتبّعه عشان تعرف تكلفة المشروع وتحسّن التقدير، الفريق بيتعاون.
وأهم استخدام له إنك تعرف الربحية الحقيقية: المشروع اللي بعته بمية ألف وأخد ضعف الساعات المقدّرة ممكن يكون خسران وإنت فاكره ناجح.
المنهجيات: إيه اللي يناسبك
الشلال
مراحل متتابعة: تحليل، فتصميم، فتنفيذ، فتسليم. بيناسب المشاريع اللي نطاقها واضح ومش هيتغير — الإنشاءات والتوريدات.
الأجايل
دورات قصيرة بتسليم في نهاية كل واحدة. بيناسب اللي نطاقه بيتطور بالتعلّم — البرمجيات والمنتجات.
كانبان
تدفق مستمر بلوحة أعمدة وحد أقصى للمهام في كل عمود. بيناسب الشغل المتكرر — الدعم والصيانة وطلبات التصميم.
المختلط
وده اللي بيحصل فعلاً في أغلب الشركات: جدول زمني عام بالشلال للعميل، وشغل داخلي بالأجايل أو كانبان.
مقارنة الأدوات الشائعة
لو بتبحث عن project management tools هتقابل الأسماء دي.
- Trello — لوحات بسيطة، أسهل بداية، بتقف عند المشاريع المعقّدة والاعتماديات.
- Asana و Monday — أقوى في المهام والأتمتة والتقارير، والتكلفة بترتفع مع عدد المستخدمين.
- Jira — قوي جداً لفرق البرمجيات، ومرهق لغير التقنيين.
- MS Project — الأعمق في الجداول والموارد والمسار الحرج، منحنى تعلّم عالي.
- OpenProject و Redmine — مفتوحة المصدر، مجانية الترخيص، بتحتاج استضافة وإدارة.
- وحدة المشاريع في نظام ERP — منطقية لو محتاج تربط المشروع بالتكاليف والفوترة.
والسؤال اللي بيحسم: هل محتاج تربط المشروع بالفلوس؟ لو أيوه، الأدوات العامة هتسيبك تسجّل التكاليف على إكسل، والحل بيبقى وحدة مشاريع جوه نظام إداري أو نظام مخصص.
إدارة مشاريع المقاولات والمكاتب الهندسية
القطاع ده احتياجاته مختلفة تماماً عن أدوات إدارة المشاريع العامة.
- حصر الكميات وربطه ببنود العقد.
- المستخلصات — جاري وختامي — ونسب الإنجاز.
- الدفعة المقدمة واستقطاعها التدريجي.
- ضمان حسن التنفيذ المحتجز وتواريخ رده.
- الأوامر التغييرية وأثرها على القيمة والمدة.
- موازنة لكل مشروع ومقارنة المخطط بالفعلي بند بند.
أي أداة عامة مش هتعمل الحاجات دي. القطاع ده بيحتاج نظام متخصص أو وحدة مشاريع جوه نظام محاسبي بيفهم المستخلصات.
الأرقام اللي المفروض النظام يديها
- نسبة الإنجاز محسوبة من المهام المنجزة مش من تقدير شخصي.
- الانحراف الزمني — كام يوم متأخر عن الخطة.
- الانحراف في التكلفة — المصروف الفعلي مقابل المخطط.
- تحميل كل شخص عبر كل المشاريع.
- المهام المتأخرة على المسار الحرج تحديداً.
- ربحية المشروع بعد الساعات الفعلية.
ليه بتتأخر المشاريع
نطاق بيكبر في صمت
طلبات صغيرة بتتقبل واحدة ورا التانية من غير ما حد يحسب أثرها التراكمي. الحل: أي طلب يتكتب ويتقدّر أثره على المدة والتكلفة قبل الموافقة.
مهام من غير مسؤول محدد
المهمة المسؤول عنها «الفريق» مالهاش مسؤول. لازم اسم شخص واحد.
الاعتماديات مش مرسومة
الفريق بيكتشف إن مهمة مش هتبدأ غير لما حاجة تانية تخلص، بعد ما الميعاد يعدّي.
الحالة بتتحدّث في الاجتماع بس
لو النظام مابيتحدّثش يومياً، الاجتماع الأسبوعي بيتحوّل لجلسة تجميع معلومات بدل جلسة قرارات.
مافيش خط أساس محفوظ
لو الخطة الأصلية اتغيّرت من غير ما تتحفظ نسخة منها، مش هتعرف تقيس الانحراف أصلاً — كل مرة الجدول بيتعدّل والمشروع بيبان في الميعاد.
