प्रोडक्शन में रुकावट अक्सर उन प्रोजेक्ट फैसलों की वजह से आती है जो सिस्टम पर असली लोड पड़ने से पहले तो सही लगते थे। लॉन्च के बाद SLO पूरे न होने का पता चलता है क्योंकि इंटीग्रेशन देर से हुआ, डिपेंडेंसी को सिर्फ़ अंदाज़ा मान लिया गया, और एंड-टू-एंड परफॉर्मेंस की ज़िम्मेदारी किसी ने नहीं ली।
जब ज़िम्मेदारी साफ नहीं होती, तो काम पूरा करने का रिस्क बढ़ जाता है। एक टीम सर्विस का v1 रिलीज़ करती है, दूसरी oncall संभालती है, और तीसरी अपस्ट्रीम स्कीमा को कंट्रोल करती है; इसलिए एक छोटा सा बदलाव रिव्यू से बचकर निकल जाता है और उससे बार-बार कोशिश (retries), क्यू (queue) का बढ़ना और लगातार लेटेंसी (cascading latency) जैसी दिक्कतें शुरू हो जाती हैं। प्रोजेक्ट ने फीचर्स तो डिलीवर कर दिए, लेकिन डिलीवरी सिस्टम फेलियर की सीमा (failure boundary) को कंट्रोल नहीं कर पाया।
डिलीवरी प्लान तब सबसे अच्छा काम करता है जब वह एक छोटे आर्किटेक्चर डायग्राम जैसा दिखे। यह प्रोडक्ट के लक्ष्य को टेक्निकल स्कोप से जोड़ता है, ज़िम्मेदारी तय करता है, और बाहरी डिपेंडेंसी को साफ-साफ दिखाता है ताकि इंटीग्रेशन इतनी जल्दी हो जाए कि ज़रूरत पड़ने पर रास्ता बदला जा सके।
डायग्राम का इस्तेमाल करके यह पता लगाएं कि फैसले कहाँ लेने हैं और सबूत कहाँ देने हैं। वह सबूत आमतौर पर एक चेकपॉइंट होता है, जैसे लोड टेस्ट का नतीजा, कॉन्ट्रैक्ट टेस्ट पास होना, या डिपेंडेंसी की तैयारी का साइन-ऑफ, जिसके बिना आगे का प्रोसेस (प्रमोशन) रुक जाता है।
डायग्राम को देखें और समझें कि लक्ष्य, स्कोप, टीम की ज़िम्मेदारी, डिपेंडेंसी और चेकपॉइंट आपस में कैसे जुड़े हैं।
यह डायग्राम डिलीवरी सिस्टम को दिखाता है और बताता है कि कौन सा कंपोनेंट अगले कंपोनेंट के लिए आउटपुट बनाता है। जब किसी डिपेंडेंसी नोड का कोई मालिक नहीं होता या इंटीग्रेशन से पहले कोई चेकपॉइंट नहीं होता, तो रिस्क एक जानी-पहचानी स्थिति से हटकर रोलआउट के दौरान देर से पता चलने वाली समस्या बन जाता है।
जब आप लेवर का नाम जानते हैं और सिस्टम पर उनके असर का अंदाज़ा लगा सकते हैं, तो ट्रेड-ऑफ़ (समझौतों) को मैनेज करना आसान हो जाता है। स्कोप काम की मात्रा को बदलता है, समय यह तय करता है कि आप कितनी अनिश्चितता को खत्म कर सकते हैं, क्वालिटी डिफेक्ट एस्केप रेट (खामियों के बच निकलने की दर) को बदलती है, रिस्क यह तय करता है कि आप कितनी अस्थिरता स्वीकार करते हैं, और टेक्निकल डेट यह तय करता है कि आप भविष्य के कितने काम को पहले ही पूरा कर लेते हैं या टाल देते हैं।
एक उपयोगी नियम यह है कि लेवर में किया गया हर बदलाव इन नतीजों में से कम से कम एक में दिखना चाहिए:
टेबल में लेवर में बदलाव और उनके संभावित नतीजों की तुलना करें।