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

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

« إن كيفية عزفك للنوطة الموسيقية هي بنفس أهمية النوطة نفسها »
Henry Kaiser

 وعندما يتم دفع الفريق بشدة، فإن الاستشفاء والعودة إلى نفس مستوى الأداء المتوقع في تقديرات عمل الفريق سيحتاج إلى أيام أو أسابيع، والأسوأ، أنه كلما تكرر دفع الفريق بهذه الطريقة، فإن استجابته سوف تتناقص -إن الأعياء بسبب الضغط المتواصل هي النقطة التي لا يعود فيها الحل ممكنا ضمن مجال زمني محتمل.
 سوف تدفع ثمن دفعك الفريق لتحقيق الموعد الأول في احتمالية تحقيق الموعد التالي فالدفع الشديد للوصول إلى المرحلة الأساسية 1 سيجبر المرحلة الأساسية 2 أن تبدأ بمشكلة. من الأفضل التفكير بإنتاجية الفريق، على مستوى المشروع كمورد متوازن للربح والخسارة: فإذا تطلب تحقيق موعد ما جهودا غير عادية، يجب أن تعلم أنك تسرق تلك الجهود من المراحل الأولى للمرحلة التالية. (من جهة أخرى، إذا كانت مهام الفريق مخصصة، فإنه من الممكن تخفيض هذا بإزاحة المسئوليات. حيث إن الزمن العصيب لتحقيق النجاح في العمل عند المصممين، والمخططين، ومدراء المشروع، ومسئولي الاختبار والمبرمجين يصادف في فترات مختلفة بالنسبة لهم أثناء المشروع. وإذا تم توزيع العمل بالشكل المناسب، فلن يحصل أن يمر ذلك الوقت على أعضاء الفريق بالتساوي، حيث إن الأدوار المختلفة تحمل المزيد من العبء في أوقات مختلفة).
لكن الأسوأ، أن هناك نسبة متزايدة يجب أن تدفع: حيث إن نسبة الاستشفاء من تلك الفترة العصيبة ليست 1:1، حيث إن زمن الاستشفاء أطول من الزمن اللازم لتقديم الجهد المكثف (مثلاً، قد يستغرق استعجالك للحاق بالقطار 20 ثانية، لكنك تحتاج إلى دقيقة أو أكثر لتستعيد أنفاسك مرة أخرى). وأحياناً، يكون الثمن التضحية بالحياة الشخصية أو العائلية للأشخاص، وهذا ليس في مصلحة الأفراد أو الفريق أو المنظمة على المدى الطويل (انظر الشكل 15-1).
إن هذا يعني أن الإدارة الجيدة يجب أن تتجنب تلك الضغوطات الكبيرة. من المستحيل تجنب بعض العقبات في مشروع ضخم، ولكن من مصلحة مدراء المشروع السيطرة عليها بحذر، والعمل بجد لمنعها أو تقليلها، واستيعاب تكاليفها الحقيقية عندما تظهر. (يعني هذا، لا تلُم الفريق بعد أسبوعين من دخول المرحلة الأساسية لكونهم بطيئين ومزاجيين). وكلما طالت فترة المشروع يفقد الفريق المزيد من الطاقة بسبب تلك الضغوطات، وتصبح النهاية الحقيقية لمشروع متعدد المراحل الأساسية أكثر صعوبة.

إن مواعيد التسليم الكبيرة هي 
مجرد مجموعة من المواعيد الصغيرة

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

• اكتمال التصميم/ اكتمال المواصفات: الفريق جاهز لكتابة الشيفرة الإنتاجية، حيث إن جميع المواصفات والنماذج الأولية، أو توضيحات التصميم اللازمة لابتداء التنفيذ قد اكتملت. (لاحظ أن هذا لا يتطلب انتهاء جميع المواصفات، وإنما فقط تلك اللازمة لبداية التنفيذ، وقد تكون 20% أو 90% من المواصفات). وقد يستمر العمل التصميمي (راجع المقطع [مجرى التشفير] في الفصل 14)، كما أن التكرارات والمراجعات قد تحدث، إلا أن أساسها أو نسبة مئوية مقبولة منها تكون قد اكتملت.
• اكتمال السمات: الفريق جاهز للتركيز على التنقيح وضمان الجودة. إن هذا يعني أن جميع الوظائف المقدمة من قبل بنود العمل الفردية قد اكتملت، والسمات والتصميم اللازم لتحقيق المتطلبات قد نفذ. قد تكون هناك مشكلات أو فجوات في الجودة، ولكن باعتبار أن القيادة قد تتبعها (فالأخطاء موجودة فعلياً)، فإن العمل البنائي الأساسي يمكن اعتباره مكتملا. وأي اختبارات أو قياسات للجودة معرفة كجزء من المواصفات يجب أن يتم قياسها. وفي ذلك الوقت، يجب تتبع كل الأمور المتبقية كأخطاء، وتصبح قاعدة بيانات الأخطاء هي الطريقة الأساسية (إن لم تكن الوحيدة) لمتابعة التقدم المتبقي.
• اكتمال الاختبار أو نقاط العلام: نقطة العلام قد انتهت. ووصلت الجودة والتنقيحات إلى المستويات المناسبة. هنا تبدأ المرحلة الأساسية التالية و/أو يمضي المشروع. يدعي  هذا أحيانًا باكتمال نقطة العلام، لأنها المرحلة الأخيرة في نقطة العلام. فإذا كانت هذه النقطة هي الأخيرة، يكون المشروع قد اكتمل.

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

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

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

• اكتمال قوائم المواصفات/ التصميم/ بنود العمل: إن هذا مفيد فقط لاكتمال التصميم. ومهما كانت الأدوات أو العمليات المستخدمة لتنفيذ العمل التصميمي، فإنها يجب أن تكون ذات معيار خروج لإنهاء التصميم. وربما يكون هذا المعيار هو مراجعة 90% من جميع المواصفات أو أنه نموذج أولي ذو مجموعة محددة من الوظائف العملية.
• اكتمال بنود العمل الفعلية: التي يجب أن تكون قائمة بنود العمل المعرفة في بداية نقطة العلام أو بداية مرحلة من المشروع. وعندما تنتهي بنود العمل وفقا للمواصفات فإن المرحلة/ نقطة العلام تكتمل.
• قياس الأخطاء عند حدود معينة: كما سنناقش لاحقاً، فإن هناك العديد من الطرق المختلفة لتتبع وقياس الأخطاء/ العيوب. بشكل عام، فإن معيار الخروج الذي يتعلق بالأخطاء يحدد القدر المسموح من الأخطاء الفعالة وذات نمط معين.
• تمرير حالات اختبارية محددة: قد يكون هناك مجموعة من الشروط الاختبارية التي تستخدم لتحديد متى تنتهي نقطة العلام. فإذا استخدمت الحالات الاختبارية كمعيار، فإنها ستوجه إلى القرارات التي تحدد الأخطاء/ العيوب التي يجب إصلاحها قبل انتهاء المرحلة. قد يكون كافيا استخدام معيار خروج مبني على قيمة حدية معرفة في الحالات الاختبارية، مثل « يجب أن تمر بـ 80% من الحالات الاختبارية للأولوية 1 بنجاح ».
• القياسات المتعلقة بالأداء أو الوثوقية: إذا كان الفريق يقيس أداء عناصر معينة (ولنقل مثلاً قاعدة بيانات أو محرك بحث)، فقد يكون هناك معيار خروج يعتمد على الأرقام. فإذا كان المعيار هو تحسن في السرعة بنسبة 10% عن الإصدار السابق، إذن لن تنتهي نقطة العلام حتى تتحقق تلك الزيادة بنسبة 10%.
• الزمن أو المال: إن الزمن هو أبسط معيار خروج في العالم. فعندما تنتهي مرحلة زمنية معينة، تنتهي معها نقطة العلام. وتنتهي الحكاية. وتستخدم الأشهر مع نقاط العلام، لأنه لا يوجد مجال للشك تجاه متى تبدأ، أو تنتهي أو كم تستغرق من الوقت (يستخدم الأشخاص الأسابيع والأشهر لمتابعة ما تبقى من حياتهم، فلم لا تبني جدولة المشاريع عليها أيضًا؟). ويتم إلغاء السمات المكتملة جرئيا أو المكتملة إلى نصف المستوى المحدد وإعادة اعتمادها في نقطة العلام التالية (إذا وجدت). يمكن أن يكون المال أيضًا معيارا للخروج: فعندما تصرف الميزانية، وتنفد الطاقة، تتوقف.

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

• إكمال بنود العمل من 1- 10 تبعاً لمواصفاتها.
• تحقيق 80% من أهداف قابلية الاستخدام الخاصة بما يتعلق بالأولوية 1.
• اجتياز جميع اختبارات الأولوية 1 المؤتمتة واليدوية.
• ترتيب أولويات جميع الأخطاء النشطة.
• تصحيح جميع أخطاء الأولوية 1 و2.
• الحصول على موافقة رسمية من فريق الأعمال والتسويق.

لم يشبه تحقيق المواعيد هبوط الطائرات
مع وجود نقاط علام وسلمية، يعني أن الهدف ليس هو مجرد تحقيق موعد تسليم معين، وإنما لتحضير الفريق نقطة العلام (أو الإصدار) التالية. إن تحقيق موعد ما هو أكثر من مجرد موضوع زمني، حيث إن مقدار المخاطرة باستقرار الشيفرة ونقطة العلام التالية (إن وجدت) يتعلق بمدى السلاسة التي وصلت بها إلى تحقيق هذا الموعد.
فكر بهبوط الطائرة، فالهبوط الجيد يضع الطائرة في وضعية تسهل عليها الإقلاع مرة أخرى. على سبيل المثال، إذا بقيت الأجنحة مرتبطة، فإن مقود الهبوط يعمل جيداً، وطاقم العمل ما زال على قيد الحياة. إن كل ما يحتاجه ذلك هو المزيد من الوقود، خطة للرحلة، وفطيرة للقبطان. ويجب التفكير بإنهاء نقاط العلام بنفس الطريقة. وكلما اتخذت زاوية حادة أكثر في إنهاء المرحلة، كانت احتمالات أن تنتهي نقاط العلام بحالة غير جيدة للمشروع، أكبر.
زاوية الهبوط
إن معظم جدولة المشاريع الهندسية يمكن تحويلها إلى مخطط بسيط. إن هذا المخطط يفترض أن نسبة التقدم ثابتة، وسوف يكتمل المشروع تماماً وفق الجدولة بالمتابعة بنفس النسبة الثابتة. إن هذا بالطبع، أمر خيالي. ولن يرتبط هذا المخطط بالواقع لأن تقدم وفعالية الفريق لا يمكن أن تكون ثابتة (لأسباب عديدة مشروحة سابقًا في هذا الكتاب). 
إن المشاريع تنتهي فعلياً بالحالة الموصوفة، حيث يدرك الفريق في مرحلة معينة أثناء التقدم باتجاه التاريخ المستهدف، أن العمل لا يمضي بالسرعة المتوقعة. وقد يكون هذا بسبب دخول عمل جديد (راجع المقطع [إدارة التغييرات (السيطرة على التغيير)] في الفصل 14)، أو لأن الفريق لم يحقق تقديراته. وبغض النظر عن كيفية حدوث ذلك، فإن الفريق يواجه الآن خياراً: كيف نقصر المسافة باتجاه تاريخ النهاية؟ وتوجد خيارات ثلاثة فقط:
1- أزلق الجدولة: أخر تاريخ النهاية لتعكس الإدراك الجديد لسرعة الهبوط.
2- غيّر الزاوية: أقنع نفسك نوعاً ما أنه بإمكانك جعل الفريق أن ينجز المزيد من العمل بسرعة أكبر لتعويض الفجوة الزمنية (مثلاً، التجهيز للهبوط القاسي). يمكنك أن تجرب هذا، ولكن يجب أن تدفع الثمن. وسيكون هناك مخاطرة أكبر بوجود أخطاء، وسيتباطأ عمل الفريق ويصل متعبا إلى بداية دورة العمل التالية.
3- حقق التاريخ بما يتوفر لديك: عرف السمات أو بنود العمل التي تبقى لها أعظم مقدار من العمل أو المخاطر. فإما أن تلغي هذه السمات، أو أن تؤجلها إلى نقطة العلام التالية (إن وجدت)، أو خفض الجودة وانقلها كما هي.
الخيال يحقق الواقع
إن الطريقة التي تشكل بها هذا الخيار يجب أن تعتمد كلياً على معيار الخروج. وهذه تماماً هي الحالة التي تستفيد أكثر ما يمكن من وجود تفكير واضح بما تعنيه نهاية نقطة العلام. وبدلا من اختراع معيار جديد الآن، تحت ظروف الضغط النفسي للهبوط الصعب، فإن كل ما تحتاجه هو أن تنظر إلى الخلف وتضبط المعيار الذي وضعته منذ عدة أسابيع مضت. إن اتخاذ القرارات في الحالات الصعبة لنهاية اللعبة يصبح أسهل إذا وجد معيار مرجعي متآلف معه الفريق مسبقاً.
لم يكن ألا ينجح تغيير الزاوية
باستخدام التشبيه بالطائرة ثانية، فإن تغيير الزاوية لتتلاءم مع المساحة المتبقية يجعل الطريقة غير مستقرة. إن المشاريع، مثلها مثل الطائرات، لا يمكن السيطرة عليها جيداً عندما تكون سرعتها في الهبوط عالية. حيث إن هناك العديد من الأشياء التي يجب إنجازها في نفس الوقت حتى تستقر تلك السرعة. فإذا كنت في طائرة تقترب من ممر الهبوط وأدركت أن طريقتك لم تنجح، فإنك تغير الاتجاه وتستخدم طريقة أخرى (إن تحريك ممر الهبوط، غير ممكن، كما في حالة جدولة المشاريع). وإذا كان الطقس شيئاً، فإن الطائرات التجارية تعيد إقلاع طريقتها. بينما، من النادر أن تتوفر تلك الإمكانية للمشاريع. فهي مثل الطائرات التي يوشك وقودها على النفاد، حيث إن هناك موارد كافية فقط لطريقة واحدة. وبحركة واحدة فقط، يستطيع الطيارون المنطقيون أن يشكلوا طرقا شديدة الحذر ومخططة جيداً. ويجب أن تتبع مدراء المشاريع المنطقيون. وإذا كان التاريخ المحدد لك أو مجموعة السمات غير قابلة للتعديل (مثل ممر الهبوط)، يجب عليك أن تبدأ التخطيط للهبوط المبكر.
لِمَ تسوء الأمور
هناك مبدأ نفسي أساسي خلف كيفية تشكيل أغلب الأشخاص لأولوياتهم في عملهم، كل الأشياء متساوية، وسيميل الأشخاص إلى تجنب تنفيذ الأشياء التي لا يرغبون القيام بها. إن هذا يعني أنه مع تقدم الجدولة، فإن بنود العمل المتبقية أو إصلاح الأخطاء ستكون مهام مزعجة وغير مرغوب بها في تلك المرحلة من نقطة الغلام. وإن كان العمل المتبقي يبدو ظريفا، أو قدمت المكافآت للفرق عن عدد الأخطاء التي يصححونها كل يوم أو كل أسبوع، سيبقى هناك ضغط نفسي في اختيار الأخطاء ذات المستوى المناسب من الصعوبة لتحقيق المعادلة.
في نهاية نقاط العلام، يميل الأشخاص لأن يكونوا متعبين، ومنزعجين ويعانون من الضغط النفسي -وهي الحالات التي تقود إلى أداء أضعف. كما أن الأخطاء الصعبة التي تقع بين المراحل تميل لأن تدور حول فريق التطوير في المراحل المتقدمة من الجدولة (وهي الحالة المعروفة سابقًا بالأخطاء التي تحمل المخاطرة بالعواقب غير لجيدة عند التعامل معها). حيث ينظر المبرمج إلى أحد تلك الأخطاء ويدرك أنه صعب، وبسبب شعوره بالضغط النفسي تجاه عمله الآخر، فإنه يوكل التعامل مع الخطأ إلى شخص آخر قد يستطيع تحمل مسئوليته، كما كتب  ».. إن المشكلات لا تُحل، إنها تنتشر فقط ». حتى أفضل المبرمجين يعانون من هذه الإغراءات الطبيعية من حين إلى آخر.
إن الميول الأساسية نحو تأجيل العمل الصعب تنطبق أيضًا على اكتشاف الأخطاء -رغم أن سببها ليس نفسياً. إن العيوب التي يستغرق اكتشافها زمنا أطول، أو تظهر في مرحلة متأخرة في الجدولة، تميل بشكل طبيعي لأن تكون الأكثر تعقيدا. إن هذا ليس بالأمر المهم بالنسبة إلى الأخطاء المعقدة ولكن ذات الأولوية المنخفضة، أما تلك ذات الأولوية المرتفعة فإن هذا التوجه يعتبر مشكلة جدية. حيث إن هذه الأخطاء لن تستغرق زمنا أطول من العادي فقط لاكتشافها، وإنما ستحتاج إلى زمن أطول من المعتاد لإصلاحها. إن المسارين ذوي الخطوط المستقيمة الظاهرة كلاهما خاطئ: إن اقتراب المشروع من تاريخ ما هو تقريباً منحني، ويبدو أقرب إلى ما يعرضه، قد يعمل الفريق بنفس الجد الذي عمل به سابقًا، ولكن النتائج -حسب اعتبارات التقدم باتجاه الأهداف- سوف تتناقص. وتزداد صحة هذا كلما كنت أقرب من تاريخ المحدد.
 الدليل العام لتصحيح زوايا الاقتراب
إن زاوية الاقتراب لنقاط العلام أو اكتمال المشروع ليست بالأسطورة، حيث توجد اعتبارات تساهم في تحديد دقة الزاوية المتوقعة، تماماً مثل أي مهمة أخرى تتعلق بالجدولة. إليك العوامل الأساسية التي يجب أخذها بالاعتبار:

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

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

• الأولوية: اجعل هذا الأمر أبسط ما يمكن، الأولوية 1= يجب الإصلاح. الأولوية 2= سيتم الإصلاح فور توفر الإمكانية. الأولوية 3= مرغوب ولكن غير محتمل. الأولوية 4= غير محتمل.
• الشدة: ما مدى جدية تأثير الخطأ؟ الشدة 1= ضياع البيانات، توقف مفاجئ للنظام، أو أمر يتعلق بالسرية. الشدة 3= وظيفة أساسية لا تعمل كما هو متوقع (محددة). الشدة 3= وظيفة صغيرة لا تعمل كما هو متوقع (محددة). إن الشدة تختلف عن الأولوية. على سبيل المثال، قد يكون هناك خطأ متعلق بتوقف المستعرض فجأة، وهو خطأ ذو أهمية كبيرة (الشدة 1)، ولكن بما أنه يحصل فقط عندما تكتب «PAPAYAI» سبع مرات، وبأحرف كبيرة، في حقل البريد الإلكتروني في صفحة تسجيل ضمن موقع وب، فإنه ذو أولوية منخفضة (الشدة 1، الأولوية 4). 
• موكل إلى: يجب أن توكل جميع الأخطاء إلى شخص واحد. يمكن تفويض الأخطاء الجديدة إلى أسماء بديلة، ولكن جزءا من هدف عملية ترتيب أولويات الأخطاء (التي ستناقش قريباً) هو توكل الأخطاء إلى شخص ما بأسرع ما يمكن. ولكي تسمح بإدخال الأخطاء من النسخ ألفاً وبيتا. شكل قيمة تدعي [نشطة] أو [وقت الاحتفال] يمكن أن توكل الأخطاء إليها. والأخطاء الموكلة إلى هذه القيمة يمكن أن ترتب بالأولويات وتعطي إلى أشخاص حقيقيين لاحقاً. 
• إعادة الإنتاج (المعروفة سابقًا بـ repro): هي تسلسل الإجراءات التي تسمح لشخص آخر أن يعيد إنتاج الأخطاء. وربما يكون هذا هو الحقل الأكثر أهمية لنوعية الأخطاء. حيث إن حالات إعادة الإنتاج السيئة تضيع وقت الفريق، وتجبر المبرمجين على بذل طاقة أكبر من اللازمة لمجرد اكتشاف ما الخطأ. فالأخطاء الجيدة تكون ذات خطوات إعادة إنتاج قصيرة وبسيطة.
• المساحة: في المشاريع الكبيرة، يجب أن تصنف الأخطاء تبعاً لمكان حدوثها في المشروع (المساحة). حيث يسمح هذا بتتبع الأخطاء تبعاً للعنصر، وليس تبعاً للمطور فقط. 
• مفتوحة من قبل. اسم الشخص الذي فتح الخطأ، مع معلومات تواصل. 
• الحالة: يمكن أن يكون الخطأ ضمن أربع حالات فقط: نشط، مصحح، محلول، مغلق. النشط تعني أنه لم يتم تصحيحه بعد وما زال قيد الاعتبار. المصحح تعني أن المبرمج يعتقد أنه قد تم تصحيحه. يصبح الخطأ محلولا فقط عندما يوافق الشخص الذي فتحه على أنه قد صحح أو يوافق على تأجيله. والمغلق يشير إلى أن الخطأ قد زال وأن فريق الاختبار قد أكد على انتهائه. 
• محلول كـ: إن الخطأ المحلول يعني أنه لم يعد نشطا. ويمكن أن يحل الخطأ بطرق مختلفة عديدة: التصحيح، التأجيل إلى النسخة أو بند إنهاء المرحلة التالية، مضاعفته لخطأ موجود، أو أنه لن يصحح.
• النوع: هناك نوعان هامان من الأخطاء: العيوب وَ الارتكاسات فالعيب هو عبارة عن خطأ طبيعي بسيط وقديم، أما الارتكاس فهو الخطأ الذي تم إصلاحه ذات مرة، ولكنه ظهر الآن ثانية كأثر جانبي سلبي لبعض التغييرات الأخرى. 
• ترتيب الأولوية: يدل هذا الحقل فيما إذا قد تم ترتيب الخطأ بحسب أولويته، وماذا كانت النتيجة. أحيانًا، تكون الأخطاء التي يجب إصلاحها هي فقط تلك التي تم ترتيبها والإشارة عليها بالموافقة وبالتالي في هذا الحقل عادة ثلاث حالات: حاصل على الموافق أو مرفوض أو ق يد البحث.
• العنوان: يجب أن تحوي كل الأخطاء عنوانا مؤلفا من سطر واحد يصف الخطأ بحيث يمكن لشخص آخر أن يحصل على فكرة أساسية عن المشكلة.

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

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

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

• نشط: العدد الكلي للأخطاء النشطة التي لم يتم حلها أو إصلاحها.
• قادم: العدد الكلي للأخطاء المفتوحة في يوم محدد (قبل الترتيب تبعاً للأولويات).
• مصحح: العدد الكلي للأخطاء المصححة في يوم محدد.

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

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

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

• الواردة للموافقة: كم عدد الأخطاء الجديدة المفتوحة التي تحتاج فعلياً أن تصحح، وليست مضاعفة لأخطاء أخرى أو بنودا من الأولوية 3 أو 4؟ (تدعي عملية التحديد تلك بـ triage، وسوف نتحدث عنها أكثر في المقطع التالي). إن معرفة نسبة الأخطاء الواردة إلى الأخطاء المرتبة تساعد في إعطاء تقديرات تقريبية مقابل الأخطاء غير المرتبة. وبشكل عام يجب أن تتناقص نوعية الأخطاء مع مرور الوقت. بعد مرحلة ما، سوف تتباطأ وتنتهي نسبة الأخطاء الجيدة والغنية وذات الأولوية 1 وَ 2. حيث إن نسبة الأخطاء الواردة الأولية لن تخبرك متى يحدث هذا. 
• زمن الأخطاء النشطة: هو الزمن المتوسط لمدى كون الأخطاء نشطة. ويشير هذا القياس إلى مدى تجاوب الفريق وكيفية معالجته لحمل العمل الحالي. إن زمن الاستجابة يجب أن يتزايد كلما اقتربت التواريخ المحددة، لأنه يفترض أن الفريق يعالج أخطاء أقل ويجب أن يكون أكثر رغبة في ترتيب ومعالجة الأمور الواردة. فإذا كان زمن الاستجابة بطيئاً، فإن هذا يني أن الناس مشغولين.
• عدد الأخطاء عند كل مطور: من أجل موازنة حمل العمل، فإن فريق التطوير بحاجة إلى تتبع عدد الأخطاء النشطة التي يبحث عنها أو يعمل عليها كل مطور حالياً. كما يجب ملاحظة النسبة المئوية للأخطاء النشطة الموكلة حالياً إلى مسئولي الاختبار والمطورين، أو مدراء المشاريع. إن الأخطاء الموكلة إلى مدراء المشاريع أو مسئولي الاختبار لا تكون موجودة حالياً في المجرى ليتم إصلاحها، كما أنه يجب ترتيبها وفقا للأولويات وإعادة تخصيصها دوريا. 
• نسبة التغذية الراجعة الخاطئة: يدعو Weinberg نسبة الارتكاسات التي سببها إصلاح خطأ ما بنسبة التغذية الراجعة الخاطئة .(FFR) Fault Feedback Ratio فإذا سبب تصحيح كل خطأ بتشكيل خطأين إضافيين. تكون FFR=20. إن 1=FFR إلى 3 هي نسبة أساسية مقبولة؛ وأي نسبة أعلى تعني الحاجة إلى تحسين الجودة (أو/ و أن السرعة بحاجة إلى تباطؤ).

إن معظم قواعد بيانات الأخطاء تسمح للأخطاء الجديدة أن ترتبط بالأخطاء الموجودة، مما يسمح بتتبع FFR. من جهة أخرى، لم أر هذا الأمر مؤتمتاً -وإنما يعطي الحكم شخصيا من قبل أولئك الذين ينفذون ترتيب الأخطاء تبعاً لأولوياتها على مستوى (لاحظ أنه يمكن أن يسبب تصحيح خطأ واحد أحيانًا ظهور سابقة مخفية. وهذا يجب ألا يدخل ضمن FFR).
عناصر التحكم
إن التحكم بالمشاريع أصعب بكثير من تتبعها، حيث إن تحصيل المعلومات الجيدة وتقييمها هو أمر استنتاجي أما اكتشاف كيفية الاستجابة للتوجهات والتأثير عليها فيتطلب حسا فطريا. إن للمشاريع زخمها الخاص، خاصة في مرحلة نهاية اللعبة، ولا يمكن توجيهها كثيرًا كما يتم التأثير عليها. وعندما يتم تركيز النشاطات على العمل مع الأخطاء، فإن هناك الكثير من القرارات الفردية التي تتخذ عبر الفريق، والتي تتطلب تواصلا مستمراً ومنبهات تذكيرية لكي يستمر الأشخاص في اتخاذ تلك القرارات بنفس السمات والافتراضات، والأهداف. 
إن الطريقة الأكثر أهمية للتفكير بمختلف عناصر التحكم هو بتواتر تطبيقها. ففي حال بعض النشاطات عالية المستوى، مثل المراجعات الإدارية، من الضروري تنفيذ الإجراء مرة واحدة فقط شهريا. أما في لنشاطات أخرى، مثل عملية ترتيب الأخطاء بالأولويات، فإنه يمكن أن يكون نشاطا يومياً أو ساعيا. وتبعا لدرجة التحكم التي تحتاجها، أو مستوى التأثير الذي ترغب بالحصول عليه، فإن الفترات الزمنية للتحكم يجب أن تكون أهم اعتباراتك.
اجتماع المراجعة
هو أساسا آلية تحكم بمرحلة منتصف اللعبة، فالمراجعة تحصل عندما يجب على قادة الفريق عرض حالة المشروع، بالمقارنة مع الأهداف للإدارة العليا، أو العملاء، والفريق كاملاً. كما يجب أن يخدم اجتماع المراجعة كإجراء إجباري لاكتشاف ما الذي يمضي جيداً (نسبة إلى الأهداف) وما الذي لا يمضي جيداً، وما الذي يتم تجاه ذلك. إن صيغة المراجعة يمكن أن تكون فعلياً بهذه البساطة. فإذا تمت الإجابة على هذه الأسئلة بصدق، يمكن أن يستغرق النقاش ساعة أو أكثر. إن أفضل المراجعات التي شاركت بها توجهت مباشرة إلى جوهر الأمور. حيث توفر النضج الكافي إذ كانت الأخطاء غير المقصودة عفوية (غير مخفية)، وطلبات المساعدة مرحباً بها (لا يستهزأ بها) كما أن الاهتمام قد بذل جيداً للأشياء الأكثر أهمية (لا للأشياء التي تجعل الأشخاص يبدون بحالة جيدة أو يشعرون بالسعادة). 
إن نقاش المراجعة يجب أن يجبر الفريق على تقييم الأهداف، والخطوط الزمنية والتقنيات، والأدوار بواقعية. ويجب ألا يستثنى أي شيء في المراجعة. وأي أمر يؤثر على المشروع يجب أن يكون مفتوحا للمناقشة. لهذا السبب، يعتبر اجتماع المراجعة عنصرا من عناصر التحكم، وليس مجرد آلية متابعة، لأنه يقدم منتدى حواريا للقادة والمدراء المخضرمين لمناقشة التعديلات التي يجب أن تجري بما يتعلق بأي ناحية من نواحي المشروع.
إن جودة المراجعة تعتمد إلى درجة كبيرة على صاحب السلطة في المشروع. حيث تتضمن أفضل المراجعات نقاشات صادقة تجاه ما يحدث، مع التركيز على استيعاب الأمور وتطوير الحلول، بدلاً من توجيه وتجنب اللوم. لهذا السبب، يجب أن تكون اجتماعات المراجعة مؤلفة من عدد صغير من الأشخاص. وبعدها تقدم خلاصة عن النقاش، إضافة إلى الشرائح والمواد المستخدمة في العرض التقديمي إلى كل أعضاء الفريق ضمن منتدى خاص بهم. (يجب أن يرتاح القادة لمسئولياتهم عن فرقهم، خاصة في التواصل مع الإدارة العليا).
يجب أن يتوفر لدى الفريق مراجعات مجدولة خلال فواصل زمنية دورية في فترة كل نقطة علام. ويجب أن تنشر مواعيدها، ثم يتبعها اجتماع للفريق. إن المشاريع التي تمتد على مدى عدة أشهر يجب أن تتضمن مراجعات شهرية. وكلما ازداد عدد هذه المراجعات، ازدادت إمكانية كونها غير رسمية وأكثر فائدة.
مراجعات الزبائن/ العملاء
إذا كنت تعمل مع فريق متعاقد، أو لديك عملاء داخليون، فإن اجتماعات المراجعة يمكن أن تعمل كطريقة وحيدة للحصول على التغذية الراجعة المباشرة من زبائنك. وتبقى معظم النصائح السابقة مطبقة. وكفكرة أخرى إضافية، فإنك يجب ألا تعتمد أبداً على تلك الاجتماعات كمصدر وحيد للتغذية الراجعة من الزبائن. فالفواصل الزمنية بين الاجتماعات ستكون دائماً طويلة جدًّا، كما أن رسمية الاجتماعات ستصعب التعمق بالأمور أو مناقشة الأمور المعقدة.
إن إحدى النواحي الهامة لـ XP هي أنها تشجع أحد مندوبي الزبائن على المشاركة مباشرة في تطوير البرمجية. إنه من المنطقي جدًّا أن تطلب من الزبون تخصيص شخص واحد على الأقل للقيام بهذا الدور. يجب أن يستخدم هذا الشخص النسخ التجريبية اليومية ويطور ا لعلاقات مع المبرمجين وقادتهم. وهذا يجعل حصولك وفريقك على التغذية الراجعة تجاه الأمور يومياً أو أسبوعياً، بدلاً من أسبوعياً أو شهريا، أمراً ممكنا. إن تعريف هذه العلاقة يمكن أن يكون صعباً نسبياً في المرة الأولى (راجع المقطع [تحديد الأدوار] في الفصل التاسع)، إلا أنه سيكون مثمرا دائماً في اتخاذ قرارات أكثر ذكاء بالنسبة للمشروع، ويجعل الزائن أكثر سعادة.
ترتيب الأخطاء وفق الأولويات
إن أي عملية تأخذ فيها قائمة من الأمور وتعيد وضعها مرتبة بالأولويات هي عملية Triage.إن ما يجعل Triage الحقيقي مختلفاً عن الأنواع الأخرى للأولويات هو أنك تتعامل مع تدفق ثابت من الأمور الجديدة التي تحتاج إلى استيعاب، ومن ثم إعادة ترتيبها وفقا للأولويات مقابل كل الاهتمامات الأخرى. تحصل عملية Triage في مرحلة منتصف اللعبة، في كل مرة يعين فيها تاريخ فاصل يجب تحقيقه أو يوجد قياس للنوعية في معيار الخروج. من جهة أخرى، فإن Triage يصبح مهمة أساسية للفريق في مرحلة نهاية اللعبة، ويستغرق غالباً نسبة عالية من العمل اليومي للمدراء والآخرين.
إن الهدف من Triage هو إداري المجرى الهندسي (المشروح في الفصل الرابع) بطريقة ترفع من قيمة العمل المنجز من أجل معيار الخروج للمرحلة النهائية. إن تنفيذ هذا بنجاح يتطلب أشياء ثلاثة:

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

إن ما يجعل عملية Triage صعبة هي أنه للقيام بأي من الأمور الثلاثة بشكل جيد، فإنك بحاجة إلى المزيد من المعرفة أكثر من أي شخص آخر. وكلما كان المشروع أكبر، كان الاحتمال أقل أن يستطيع شخص واحد أن ينفذ Triage بفعالية لوحده. لذلك، لدى معظم الفرق في معظم المشاريع، تكون عملية Triage نشاطا جماعيا. في المراحل الأولى، قد يُقبل أن يقوم الأفراد بعملية Triage تجاه أخطائهم الخاصة، ولكن لاحقاً، سوف ينتقل التركيز إلى مجموعات صغيرة وفرق جزئية. لهذا السبب يجب أن تكون الأخطاء منظمة في مساحات محددة من المشاريع (راجع المقطع [إدارة الأخطاء/ العيوب]). حيث إن هذا يسهل على المجموعات الصغيرة من الأشخاص المسئولة عن تلك المنطقة، الاجتماع وإجراء عملية Triage بشكل مستقل عن باقي أعضاء الفريق.
لاحقاً، مع اقتراب نهاية اللعبة، عندما يتم فص كل قرار خاص بالأخطاء جيداً، يجب أن يتوفر Triage واحد للمشروع كاملاً، ويجب أن يدار من قبل مجموعة أساسية من قادة الفريق. أما الآن، فالمهم تعريف النوعين الأساسيين للـ Triage : اليومي وغير المباشر.
Triage اليومي/ الأسبوعي
إن Triage اليومي هو العملية المعتادة للتعامل مع الأخطاء الواردة والنشطة. وقد يتطلب هذا تبعاً للخط الزمني أن ينجز مرة واحدة أسبوعياً، أو يومياً أو ساعيا. وكلما تقدمت في مرحلة نهاية اللعبة، وجب تنفيذ Triage بتواتر أكبر.
إن الهدف من Triage اليومي بسيط، وهو الحفاظ على منطقية الأمور. حيث يعتبر الفريق البرمجي المسار الرج لنهاية المشروع، و Triage هو الطريقة الوحيدة للتأكد من أن المجرى الخاص بهم يستخدم بفعالية. وكل خطأ يرد يجب أن يصحح ويقارن مع مجموعة من الأخطاء الموجودة، ويفضل أن يحصل هذا قبل أن يستقر في عمل المبرمج.
أحيانًا، يكون وجود شخص واحد يدير Triage اليومي لكل منطقة أفضل (حسب مصطلحات فعالية الفريق). وبافتراض أن المبرمجين ومسئولي الاختبار متفقون على المعيار، فإن شخصاً واحداً بإمكانه أن يكون مسئولا عن تصيح الأخطاء الجديدة، والتأشير على الأخطاء المضاعفة، وتعديل الأولويات للأخطاء الواردة. إن مدراء المشاريع هم أشخاص مناسبون للقيام بهذا، بافتراض أنهم تقنيون بما يكفي لاستيعاب الأمور واتخاذ قرارات أساسية تجاه الأخطاء، وإلا، فإن Triage يجب أن ينجز ضمن اجتماع صغير، مع وجود ممثلين من فرق التطوير، والاختبار ومدير المشروع. وإذا دعت الحاجة لوجود خبراء آخرين -مثل مسئولي التسويق أو التصميم أو قابلية الاستخدام -يمكن استدعاؤهم عند الضرورة. يجب أن تكون الاجتماعات قصيرة. وأي أمر لا يمكن حله في دقائق، يجب أن يوكل إلى أحد المبرمجين لإجراء البحث.
عندما تنفذ عملية Triage على الأخطاء. يجب أن يملأ قل  المتعلق بها مما يعطي المشروع نظرة إضافية عن معطيات الأخطاء، ويمكن عندئذ أن تفصل كمية الأخطاء التي أجرى لها  Triage (المعروفة بالأخطاء الجيدة) عن الكمية الكلية للأخطاء النشطة (الأخطاء ذات النوعية المجهولة).
Triage الموجّه
إن Triage الموجه هو عبارة عن جهد مركز لتحقيق هدف معين. ويتم هذا بالإضافة إلى Triage اليومي، وهو أد عناصر التحكم، على مستوى المشروع، للمساعدة في دفع الأمور إلى الأمام وتحسين قيمة مخططات الأخطاء وتحليلات التوجهات. إليك بعض الأسباب العامة لوجود Triage الموجه:

• عندما تكون نسبة الأخطاء المرتبة إلى الأخطاء النشطة منخفضة: إذا كان هناك 500 خطأ نشط و200 منها فقط قد أجرى لها عملية  Triage ، فليس هناك أي طريقة لمعرفة أهمية الأخطاء الـ 300 المتبقية. فقد تكون جميعها معيقات للنظام ذات أولوية 1، أو قد تكون أخطاء مضاعفة، لا يمكنك أن تعرف. إن  الموجه هدفه أن يلغي جميع تلك الأخطاء التي لم يجري لها Triage في زمن معين (غداً مساءً ). فإذا كانت هذه مشكلة مستمرة عند الفريق، يجب أن يكون هناك هدف تجاه تحقيق حالة عدم وجود أخطاء نشطة لم يُجر لها Triage أقدم من فترة زمنية معينة (24 ساعة).
• عندما يتغير معيار الخروج: إذا قرر قادة الفريق أو الإدارة أنه يجب تعديل معيار الخروج، ربما بإلغاء أو إضافة شرط ما، فإن عملية Triage هي الطريقة الوحيدة لجعل المشروع يتلاءم مع هذه التغييرات. حيث إنه من الشائع استخدام معيار خروج جديد كطريقة لتغيير زاوية الانحدار لاغيا تصنيفات محددة للأخطاء من الاعتبار لتحسين أمن الزاوية (لكنه يخفض جودة العملية).
• الحسابات غير المغلقة عالية: عندما يتم إصلاح خطأ ما، فإن حقل الحالة يجب أن يأخذ القيمة (محلول) ويوكل ثانية إلى الشخص الذي فتحه للتأكد من أنه قد تم إصلاحه حقاً. إن نسبة من تلك الأخطاء ربما قد لا تكون أصلت بشكل صحيح. فإذا بقيت هذه الأخطاء غير مغلقة، فإن هذا يعني أن هناك كمية من الأخطاء يجب إصلاحها، ولكن لم ترد في حسابات الأخطاء النشطة. قد توجد أماكن أخرى للأخطاء يمكن أن تكون مخفية، وذلك تبعاً لنظامك الخاص لتتبع الأخطاء. وعليك أن تدفع الفريق بشكل دوري لكي يفصل هذا الأمر.
• فريق الحرب

مع اقتراب اكتمال المشروع، يجب أن يصبح توزع السلطة مركزيا، على عكس مرحلتي البرمجة وتصميم المزايا، حيث يمكن أن توزع السلطة منطقيا بين أعضاء الفريق، فالعمل باتجاه النهاية لا يحتمل أي وجود للخطأ. حيث تصب جميع القرارات متزايدة الأهمية، مع تزايد المخاطر، مما يعني أنه يطلب المزيد من السيطرة والتحكم. إن المصطلح الذي تطلقه  Microsoftعلى هذا التحكم المركزي هو فريق الحرب (وأعتقد، أنه مستعار من المصطلح العسكري غرفة الحرب، حيث يجتمع القادة لاتخاذ القرارات بالأمور الهامة). حيث تتحول مجموعة صغيرة من قادة الفريق إلى فرع تنفيذي مسيطر ولديه السلطات مع اقتراب موعد التسليم. بالنسبة للفرق الصغيرة، قد يلزم إزاحة رسمية في السلطات، بينما بالنسبة للفرق المتوسطة والكبيرة، تكون هذه الإزاحة ضرورية فهي ترفع معيار اتخاذ القرارات وتزود إجراء قسريا للفريق وهو أن اللعبة تنتهي.
إن الاجتماع الفعلي لفريق الحرب بسيط، وكل ما تحتاجه عبارة عن غرفة مؤتمرات، وعضو مخضرم من كل مجموعة (البرمجة، والاختبار، ومدير المشروع أو أي قادة نظراء له، وأحياناً المدير الأعلى للمجموعة)، وجهاز حاسب مرتبط بشاشة عرض كبير ليتمكن جميع الموجودين من رؤية الخطأ أو الأمر الذي تتم مناقشته. ولكي يجتاز أمر ما فريق الحرب يجب أن يتفق الأعضاء المخضرمين جميعاً (بعض الفرق تعمل على أساس ثلثي الأغلبية أو تعطي أعضاء فريق الرب حق الفيتو). تقرر برامج عمل فريق الرب كل صباح. ويمكن وضع أي موضوع فيها. ومثلها مثل المحكمة القضائية، إذ يمكن لهم قبول أي شيء أو رفضه، يحدد الأسبقية لبقية الفريق. يجب أن تكون مفتوحة للفريق، وتعطي الأولوية للأشخاص الذين يمثلون DCRs محددة (راجع الفصل السابق) أو الأخطاء المعروضة للمراجعة.
إن فريق الحرب يجب أن يضع معيارا مرتفعا، فأي شخص يبرز للفريق غير جاهز، أو لا يعرف الإجابات عن أسئلة أساسية (أي معايير الخروج يوافق هذا الأمر؟ ما الارتكاسات التي قد يسببها؟ هل يوافق كل من المبرمج ومسئول الاختبار أن هذا يجب أن يصحح؟) يجب أن يطلب منه المغادرة والعودة عندما يكون جاهزا. يجب أن يتمس كل مدير مشروع ومبرمج لدرجة كبيرة للحصول قبل أن تطلب موافقة فريق الحرب. إن هذا الضغط يخلق دافعاً عند الفريق كاملاً للتفكير بجدية بالأمور بأنفسهم قبل أن يقرروا عرضها على فريق الحرب (لكن احذر: فاجتماعات فريق الرب قد تكون ذات كلفة عالية، وهناك الكثير من الفرص لضياع الوقت بالأنانية، ويعود الأمر لمدير المجموعة أن يمنع هذا الأمر باكرا).
ومن حق الفريق الحصول على تحذيرات عن متى وكيف سيتدخل فريق الحرب. تعرض بعض المراحل الأساسية في الشكل 15-9، للأشياء التي تحتاج موافقة فريق الحرب. والهدف هو الحصول على تمركز تدريجي للسلطة بالنسبة للتواريخ العامة لتوقيت حصول هذه الانتقالات. إن موافقة DCRs هي غالباً أول استخدام لفريق الحرب، لأن هذا يمكن أن يحصل في المراحل الأولية أو خلال منتصف اللعبة. لاحقاً، عندما تشتد الحاجة إلى تتبع تعداد الأخطاء فإن الموافقة على وضع الأخطاء في المجرى البرمجي تتحول إلى فريق الحرب (والأخطاء الحاصلة على الموافقة مسبقاً يجب أن تكون موروثة). أخيراً، وفي الأسابيع أو الأيام المتممة، يراجع فريق الحرب كل الأخطاء الواردة، وتتمركز السيطرة على المشروع بفعالية.
يمكن أن تبدأ اجتماعات فريق الحرب أسبوعياً، إلا أنها يجب أن تتحول فوراً إلى اجتماعات يومية ساعية أو نصف ساعية. ويعود الأمر إلى فريق الحرب لكي يؤكد على ابتداء وانتهاء هذه الاجتماعات في الوقت المحدد (يجب أن يقوم شخص ما بتوضيح بنود برنامج العمل قبل أن يبدأ الاجتماع). فإذا كان الهدف هو اتخاذ قرارات جيدة بشأن معايير الخروج والأهداف، من الممكن مراجعة العديد من DCRs وإجراء Triage للعديد من الأخطاء في 60 أو 30 دقيقة. والسر هو تجنب الإدارة الضعيفة لمرحلة نهاية اللعبة.
لا يحتاج فريق الحرب أن يعرف نشاطات كل خطأ أو موضوع. وإنما يحتاج فقط أن يتأكد من أن القرارات المتخذة هي في صالح المشروع بأفضل ما يمكن، وأن الأسئلة المناسبة قد طرحت وأجيبت بشكل جيد، وأنه قد تم وضع المعيار الصحي ليستخدم في الوقت المتبقي. تفشل فرق الحرب في التبريرات عندما يفشل القادة في الثقة بفرقهم. وإذا كان الأمر شائنا جدًّا، فإنه يجب أن يخرج من النقاش لتتم مناقشته مع أحد أعضاء فريق الحرب، ومن ثم يعود في اليوم التالي مع طريقة أفضل للعرض.
ما بين أهداف المشروع، ومعايير الخروج والقرارات الخاصة بتحديد أسبقية الأخطاء واتصالات الفريق، توجد الكثير من الفرص لتوكيل الفريق باتخاذ القرارات.
أحيانًا، يمكن أتمته عملية الموافقة من فريق الحرب، وذلك بوجود نماذج ويب تسمح لأعضاء فريق الحرب بالمصادقة على العناصر عن بعد وخلال أوقاتهم الحرة الخاصة. كن ذكيا وجد الطرق لتجنب جعل فريق الحرب مشكلة اختناق غير ضرورية أو غير مقصودة.
بشكل عام، كلما قل عدد البنود التي يحتاج فريق الحرب إلى إدارتها، فإن هذا يعني أن عمل الإدارة العليا كان أفضل بالنسبة للتخطيط والتنفيذ وقيادة الفريق عبر المشروع، أما إذا كانت اجتماعات الفريق عادة قاسية وتشبه سباق ماراتون ذا ثلاث ساعات، فهذا يعني أن القيادة قد فشلت باتجاه ما أو بعدة اتجاهات، وأن هناك دروسا يجب تعلمها من أجل المشروع التالي.
نهاية نهاية اللعبة
إن الفترة الأخيرة لأي مشروع هندسي هي عملية صعبة ومخدرة للدماغ. وقد أشار Jim McCarthy في « ديناميكيات التطوير البرمجي (Microsoft Press, 1995 إليها أنها مثل العمل مع Jell-O. ففي كل مرة تصلح فيها خطأ ما، فإنك تلمس المكعب الكبير من Jell-O مرة أخرى، وسوف يستغرق منه بعض الوقت للتوقف عن الاهتزاز والاستقرار. وكلما وضعت لمسات أكثر، كان هناك المزيد من الارتدادات في اهتزازاته وكان التداخل بين التموجات الناتجة عن هذه التغيرات، أكثر تعقيدا. إن موقع الويب أو المنتج البرمجي هو بشكل أساسي عبارة عن مجموعة كبيرة من الأجزاء المتحركة المتصلة داخليا، وفي كل مرة تغير فيها واحدة، فإنك تفرض جميع أنواع الأمواج الجديدة المحتملة من التصرفات، خلالها. ولكن البرمجية على عكس Jell-O حيث إنه ليس من السهل أن تعرف متى توقف الاهتزاز، فالشيفرة ليست شفافة. حيث لا تكفي اختبارات الجودة اليدوية الحذرة على النسخ اليومية لكي تفهم أثر ذلك التغير البسيط.
إن هذا يعني أن النهاية الحقيقية للمشروع هي تقريباً لعبة انتظار، حيث تمضي الساعات وراء الساعات في مراجعة تقارير الأخطاء الجديدة أو المواضيع وتأملها جيداً لمعرفة إذا كانت تحقق المعيار لاهتزاز Jell-O مرة أخرى. في حال الفرق الكبيرة، يتحمل فريق الحرب هذا العبء. على الرغم من أنه يجب على باقي الفريق أن يستطيع بفعالية عن الأمور الجديدة واستخدام النسخ اليومية الأخيرة، إلا أنه يمكن لأي شخص أن يشارك في لعبة الانتظار بطريقة ما. 
ولكن عندما يوجد خطأ ما يستحق اهتزاز Jell-O ، فإن كل شيء سيعود إلى حركته الكاملة مرة أخرى. حيث يمضي فريق الحرب في عملية قيادة الفريق (أو، على وجه التحديد، المبرمجين). لفهم الأمر بشكل جيد بما يكفي لإجراء تغيير جذري. ومن ثم يجب إعادة تشغيل مجموعات الاختبارات والشروط مرة أخرى للتأكد من أن الأمور عادت تماماً إلى ما كانت عليه، ما عدا بالنسبة لذلك الشيء الصغير جدًّا الذي احتاج إلى تغيير، وهي عملية مسببة بشدة للضغط النفسي، ولا تشبه منتصف اللعبة، اللعبة كاملة، ومتعة إيجاد الأخطاء في بدايات نهاية اللعبة. فالضغط النفسي في الأيام الأخيرة لا يمكن إزالته بتكديس أمور العمل، حيث إن كل شيء صغير، وليس لدي هذا الضغط أي مكان ليذهب إليه. 
توجد قياسات مختلفة ولحظات مهمة في هذه العملية، لكنها لا تؤدي الكثير لتغير طبيعة العمل، وإنما هي ببساطة عبارة عن مراحل انتهائية وسطية على مدى الاتجاه نحو تحرير النسخة. وإذا لم تفد بشيء آخر، فإن هذه العلامات تقسم هذه الوتيرة من الضغط النفسي الناتجة عن العمل المتأخر في مرحلة نهاية اللعبة.

• تأرجح تعداد الأخطاء حول الصفر: عندما يصل تعداد الأخطاء النشطة والمصادق عليها (من قبل فريق الحرب) إلى الصفر. يقال إن الفريق قد وصل إلى تأرجح تعداد الأخطاء حول الصفر ZBB) Zero Bug Bounce). تسمى هذه الحالة بالتأرجح، لأنه فور وصول الخطأ التالي، لن يبقى هذا التعداد مساويا للصفر. وهناك بعض النظريات المفضلة عن المسافة بين ZBB والنسخة الفعلية، ولكن أياً منها ليست قوية بما يكفي لسردها هنا.
• أخطاء محلولة صفرية: إن الأخطاء ا لمحلولة قد تكون عبارة عن أمور مخفية لا يعرف عنها الفريق. وإلى أن يتم إغلاقها (والتأكد منها)، لا يمكن التأكد أنه قد تم تصحيح الخطأ فعلياً بالطريقة المفروضة. إن الوصول إلى حالة محلولة تساوي صفر ونشطة تساوي صفر تعني أن المشروع فعلياً في حالة اكتمال ممكنة.

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

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

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