IT परियोजनाओं के बारे में लगातार बनी रहने वाली शिकायत यह नहीं है कि वे पूरी तरह विफल हो जाती हैं, हालाँकि कुछ होती हैं। शिकायत यह है कि वे पूर्वानुमेय होने में विफल रहती हैं। एक कार्यक्रम जो छह महीने देर से और बजट से चालीस प्रतिशत अधिक पर समाप्त होता है, वह हानिकारक है, लेकिन एक ऐसा पोर्टफोलियो जिसमें कोई भी परियोजना समय पर समाप्त हो सकती है या एक वर्ष खिसक सकती है, और पहले से यह विश्वसनीय रूप से बताने का कोई तरीका नहीं है कि कौन-सी, वह एक अलग ढंग से घातक होता है। यह व्यावसायिक स्तर पर योजना बनाना असंभव बना देता है। यह अधिकारियों को हर अनुमान को बढ़ा-चढ़ाकर बताना और हर प्रतिबद्धता को कम आँकना सिखाता है, जो बदले में वितरण टीमों को यह सिखाता है कि अनुमान महज़ नाटक हैं। पूरी व्यवस्था एक कम-विश्वास वाले संतुलन में बहकर पहुँच जाती है जहाँ कोई भी योजना पर विश्वास नहीं करता और हर कोई स्वयं की रक्षा करता है।

यह अब एक दशक पहले की तुलना में एक विशेष कारण से अधिक महत्वपूर्ण है। IT परिवर्तन अब कोई अलग-थलग घटना नहीं है जिसे कोई व्यवसाय कभी-कभार अवशोषित कर ले। यह निरंतर है, और यह राजस्व, विनियमन और ग्राहक अनुभव के साथ इस तरह उलझा हुआ है कि इसमें बहुत कम गुंजाइश बचती है। जब कोई मुख्य बैंकिंग माइग्रेशन खिसकता है, या कोई ERP समेकन ठप पड़ जाता है, तो उसके परिणाम किसी IT बजट पंक्ति तक सीमित नहीं रहते। वे व्यावसायिक प्रतिबद्धताओं, अनुपालन समय-सीमाओं और उस नेतृत्व की विश्वसनीयता तक फैल जाते हैं जिसने इस कार्य को प्रायोजित किया था। अप्रत्याशितता की लागत वहाँ भी बढ़ी है जहाँ व्यक्तिगत विफलता की लागत नहीं बढ़ी।

असहज सच यह है कि बहुत सारी अप्रत्याशितता तो शुरुआत में ही, कोड की एक पंक्ति लिखे जाने या कोई सर्वर प्रावधानित किए जाने से पहले ही, गढ़ ली जाती है। यह अनुमान लगाने को मोल-भाव समझने से, कभी वास्तव में न समझे गए दायरे के प्रति प्रतिबद्ध होने से, और एक ऐसा वितरण दृष्टिकोण अपनाने से गढ़ी जाती है जो कार्य के वास्तविक स्वरूप के बजाय सांस्कृतिक सहूलियत के लिए चुना गया हो। पूर्वानुमेयता काफ़ी हद तक उन निर्णयों से तय होती है जो तब लिए जाते हैं जब परियोजना को आकार देना अभी सस्ता होता है। अनुशासन को वहीं से शुरू होना चाहिए।

किसी भी IT परियोजना में बुनियादी निर्णय यह नहीं है कि कौन-सा फ़्रेमवर्क अपनाया जाए। यह इस बात का निदान है कि अनिश्चितता कहाँ बसती है। मोटे तौर पर, वितरण में अनिश्चितता दो रूपों में आती है, और वे विपरीत प्रतिक्रियाओं की माँग करती हैं। पहली है क्रियान्वयन की अनिश्चितता: हम ठीक-ठीक जानते हैं कि हमें क्या बनाना है, लेकिन उसे बनाना विशाल, जटिल या जोखिमपूर्ण है। दूसरी है आवश्यकता की अनिश्चितता: हम इसे कुशलता से बना सकते हैं बशर्ते हमें पता हो कि यह क्या है, लेकिन सही उत्तर केवल वास्तविक उपयोग से मिलने वाली प्रतिक्रिया के ज़रिए ही स्पष्ट होगा। इन दोनों को आपस में गड्डमड्ड करना ही पद्धति-संबंधी अधिकांश विफलता का मूल है।

जहाँ प्रमुख अनिश्चितता क्रियान्वयन की है और आवश्यकता वास्तव में स्थिर है, वहाँ योजना-आधारित वितरण कोई ऐसी पुरानी चीज़ नहीं है जिसके लिए क्षमा माँगी जाए। यह सही उपकरण है। एक डेटा सेंटर माइग्रेशन, एक निश्चित कानूनी विनिर्देश वाला नियामक रिपोर्टिंग परिवर्तन, या एक भली-भाँति समझे गए पैकेज का नई जगहों पर रोलआउट, इन सभी का दायरा ज्ञेय होता है और इन्हें विस्तृत अग्रिम अनुक्रमण, निर्भरता मानचित्रण और क्रांतिक-पथ प्रबंधन से बहुत लाभ होता है। ऐसे कार्य को खोज की यात्रा बताने का दिखावा उस एकमात्र लाभ को बर्बाद कर देता है जो वह देता है, अर्थात् उसकी ठीक से योजना बनाने की क्षमता।

जहाँ प्रमुख अनिश्चितता आवश्यकता की है, वहाँ योजना-आधारित दृष्टिकोण सक्रिय रूप से हानिकारक बन जाता है, क्योंकि यह उन निर्णयों के प्रति समय-पूर्व प्रतिबद्धता के लिए बाध्य करता है जिन्हें खुला रहना चाहिए। यहाँ अनुकूली वितरण अपना स्थान अर्जित करता है: छोटे चक्र, कार्यशील वृद्धियाँ और वास्तविक उपयोगकर्ताओं के साथ बार-बार संपर्क अज्ञात को ज्ञात में सबसे तेज़ टिकाऊ दर पर बदल देते हैं। पुनरावृत्ति का उद्देश्य अपने आप में गति नहीं है। यह आवश्यकता जोखिम का व्यवस्थित उन्मूलन है। जो टीम पुनरावृत्ति तो करती है पर अपनी वृद्धियों का सामना कभी वास्तविक उपयोगकर्ता प्रतिक्रिया से नहीं कराती, उसने तंत्र के बिना केवल औपचारिकता अपना ली है, और उसे कुछ हासिल नहीं होता।

ईमानदार स्थिति, और वही जिसके पक्ष में यह लेख तर्क देता है, यह है कि अधिकांश महत्वपूर्ण कार्यक्रमों में उनके घटकों में अलग-अलग अनुपातों में दोनों प्रकार की अनिश्चितता होती है। परिपक्व निर्णय यह नहीं है कि पूरी चीज़ को एजाइल या वॉटरफॉल घोषित कर दिया जाए, बल्कि यह है कि उसका विघटन किया जाए, जहाँ दायरा स्थिर है वहाँ योजना-आधारित कठोरता लागू की जाए और जहाँ नहीं है वहाँ अनुकूली खोज, और उनके बीच की सीमा-रेखा को सोच-समझकर प्रबंधित किया जाए। वही सीमा-रेखा वह जगह है जहाँ असली कौशल बसता है।

हाल के वर्षों में कई घटनाक्रमों ने IT परियोजना प्रबंधन को नए सिरे से आकार दिया है, और सारभूत को फ़ैशनपरस्त से अलग करना उचित है। सबसे सारभूत है IT परिदृश्य के उन हिस्सों में परियोजना-सोच से उत्पाद-सोच की ओर बदलाव, जो दीर्घजीवी होते हैं। एक भुगतान प्लेटफ़ॉर्म या एक ग्राहक पोर्टल कोई ऐसी परियोजना नहीं है जो समाप्त हो जाती है; यह एक ऐसा उत्पाद है जो बना रहता है, जिसे निरंतर वित्तपोषित किया जाता है और जिसका स्वामित्व एक स्थिर टीम के पास होता है। उस श्रेणी के कार्य के लिए, अपनी निश्चित समाप्ति तिथि और पूर्णता पर टीम के बिखराव के साथ परियोजना की संरचना एक सक्रिय दायित्व बन गई है, क्योंकि यह हस्तांतरण के लिए अनुकूलन करती है, न कि उस निरंतर स्वामित्व के लिए जो सॉफ़्टवेयर को स्वस्थ रखता है।

साथ ही, और उत्पाद आंदोलन के साथ कुछ तनाव में, बड़े पैमाने पर निर्भरताओं के प्रबंधन के अनुशासन को औपचारिक रूप दिया गया है। जैसे-जैसे संगठन एक साझा वास्तुकला के विरुद्ध दर्जनों टीमें चलाते हैं, वितरण पर बाध्यकारी अड़चन शायद ही कभी किसी एक टीम की उत्पादकता होती है। यह उनके बीच की समन्वय लागत होती है: साझा सेवाएँ, एकीकरणों का अनुक्रमण, वे प्लेटफ़ॉर्म क्षमताएँ जिन पर कई धाराएँ निर्भर करती हैं। बड़े पैमाने के वितरण फ़्रेमवर्क, अपने उपयोगी मूल में, इन अंतर-टीम निर्भरताओं को दृश्यमान बनाने और उन्हें सभी के अवरुद्ध होने का कारण बनने से पहले ही अनुसूचित करने का एक प्रयास हैं।

तीसरा बदलाव है निरंतर वितरण का परिपक्व होना और उत्पादन तक के रास्ते का स्वचालन। जब किसी परिवर्तन को तैनात करना एक दुर्लभ, हस्तचालित, उच्च-जोखिम वाली घटना होती है, तो अर्थशास्त्र बड़े बैचों और लंबे रिलीज़ चक्रों की ओर धकेलता है, जो बदले में भारी अग्रिम योजना की ओर धकेलता है। जब तैनाती स्वचालित, परीक्षित और नियमित होती है, तो छोटी वृद्धियों को रिलीज़ करना सस्ता हो जाता है, और वितरण की पूरी लय उस बार-बार मिलने वाली प्रतिक्रिया की ओर स्थानांतरित हो सकती है जिस पर अनुकूली कार्य निर्भर करता है। जो कुछ पद्धति के नाम मढ़ा जाता है, वह वास्तव में इसी इंजीनियरिंग क्षमता का परिणाम होता है। कोई टीम मूल्य की ओर सार्थक रूप से पुनरावृत्ति नहीं कर सकती यदि वह वर्ष में केवल दो बार ही रिलीज़ कर पाती है, भले ही दीवार पर कोई भी फ़्रेमवर्क लिखा हो।

पूर्वानुमेय वितरण उतना ही इस बात का गुण है कि कार्य को कैसे संरचित किया गया है, जितना कि इस बात का कि उसे कैसे प्रबंधित किया जाता है। सबसे शक्तिशाली एकल उत्तोलक है ऐसी वृद्धियों में विघटन जिनमें से प्रत्येक कुछ प्रदर्शन योग्य, और आदर्श रूप से कुछ उपयोग योग्य, प्रदान करे। यह कोई परियोजना-प्रशासन की शिष्टता नहीं है। एक ऐसी वृद्धि जो कार्यशील सॉफ़्टवेयर उत्पन्न करती है, एकीकरण और परीक्षण के सवालों को जल्दी और बार-बार हल करने के लिए बाध्य करती है, बजाय इसके कि उन्हें किसी अंतिम चरण तक टाल दिया जाए जहाँ वे सब एक साथ फट पड़ें। बिग-बैंग एकीकरण की चिरपरिचित विफलता, जहाँ अलग-अलग बनाए गए घटकों को महीनों बाद अंत में जोड़ा जाता है और पता चलता है कि वे आपस में नहीं बैठते, प्रबंधन की विफलता होने से पहले वृद्धि-डिज़ाइन की विफलता है।

निर्भरता वास्तुकला दूसरा सिद्धांत है। टीमों, प्रणालियों या विक्रेताओं के बीच हर निर्भरता एक अनुसूचन अड़चन और एक जोखिम है। अच्छा वितरण डिज़ाइन इन्हें सोच-समझकर न्यूनतम करने और अनुक्रमित करने का काम करता है: यह पहचानते हुए कि कौन-से घटक क्रांतिक पथ पर हैं, कौन-सी साझा क्षमताएँ आश्रित कार्य शुरू होने से पहले मौजूद होनी चाहिए, और कौन-सी बाहरी प्रतिबद्धताएँ, जैसे कोई विक्रेता वितरण या कोई नियामक स्वीकृति, टीम के नियंत्रण से बाहर बैठती हैं और इसलिए सबसे पहले ध्यान और सबसे रूढ़िवादी बफ़रिंग की आवश्यकता रखती हैं। जो निर्भरताएँ देर से पता चलती हैं, वे सबसे महँगी किस्म की होती हैं, क्योंकि जब तक वे सामने आती हैं तब तक उन्हें सुलझाने के विकल्प संकुचित हो चुके होते हैं।

तीसरा सिद्धांत है जहाँ आवश्यकता अनिश्चित है वहाँ प्रतिवर्तीयता के लिए और जहाँ वह तय है वहाँ मज़बूती के लिए डिज़ाइन करना। जिन निर्णयों को पलटना सस्ता है, उन्हें तेज़ी से लिया जा सकता है और प्रतिक्रिया के आलोक में संशोधित किया जा सकता है; जिन निर्णयों को पलटना महँगा है, जैसे प्रणाली के केंद्र में स्थित एक डेटा मॉडल या ऐसे प्लेटफ़ॉर्म का चुनाव जिस पर बाकी सब कुछ निर्भर करेगा, वे लॉक होने से पहले असंगत रूप से अधिक जाँच के हकदार हैं। एक भली-भाँति चलाई गई परियोजना अपना सावधान विश्लेषण वहाँ खर्च करती है जहाँ पलटना महँगा है और वहाँ तेज़ी से आगे बढ़ती है जहाँ नहीं है, बजाय इसके कि हर पसंद पर एक जैसी औपचारिकता लागू की जाए। इन दोनों को गड्डमड्ड करना, तुच्छ पर सिर खपाना जबकि अपरिवर्तनीय को जल्दबाज़ी में निपटाना, मुसीबत का एक आम और चुपचाप उभरने वाला कारण है।

लचीलेपन के भेस में दायरे का विस्तार। अनुकूली वितरण का बार-बार दुरुपयोग दायरे को कभी न बाँधने की छूट के रूप में किया जाता है। सच्ची पुनरावृत्ति समाधान को एक स्थिर लक्ष्य की ओर परिष्कृत करती है; अनुशासनहीन बदलाव हर कुछ हफ़्तों में एक लक्ष्य के स्थान पर दूसरा रख देता है और उसे उत्तरदायित्व कहता है। भेद इस बात में है कि क्या बदलाव अभिसरण कर रहे हैं। एक ऐसी परियोजना जहाँ हर चक्र परिणाम को एक सुसंगत उद्देश्य के करीब लाता है, वह सीख रही है। एक ऐसी परियोजना जहाँ हर चक्र एक नया उद्देश्य जोड़ता है, वह दायरे का प्रबंधन नहीं कर रही, वह उसे त्याग रही है, और वह समाप्त नहीं होगी।

तरबूज़ स्थिति रिपोर्ट। बाहर से हरी, अंदर से लाल। यह परियोजनाओं को कार्यशील सॉफ़्टवेयर और साकार मूल्य के बजाय पार किए गए मील के पत्थरों पर आँकने का स्वाभाविक उत्पाद है। जब मापक पूर्ण किए गए कार्यों का प्रतिशत होता है, तो एक टीम महीनों तक नब्बे प्रतिशत रिपोर्ट कर सकती है जबकि वह कठिन, एकीकृत करने वाला, मूल्य-वहन करने वाला दस प्रतिशत अछूता पड़ा रहता है। उपाय बेहतर रिपोर्टिंग अनुशासन नहीं है। उपाय यह बदलना है कि क्या मापा जाता है, ताकि प्रगति का अर्थ किसी योजना के विरुद्ध गतिविधि नहीं, बल्कि प्रदर्शन योग्य, परीक्षित, उपयोग योग्य वृद्धियाँ हों।

निर्भरता का इनकार। टीमें अपने कार्य की योजना सावधानी से बनाती हैं और अपनी सीमा के बाहर की हर चीज़ को किसी और की समस्या मानती हैं जो समय पर स्वयं सुलझ जाएगी। शायद ही कभी सुलझती है। जिन निर्भरताओं का स्वामित्व किसी परियोजना के पास नहीं है, वे ठीक वही हैं जिनके खिसकने की सबसे अधिक संभावना है, और जब वे खिसकती हैं तब उन्हें तेज़ करने में टीम सबसे कम सक्षम होती है। बाहरी निर्भरताओं को स्पष्ट करना, उन्हें स्वामी सौंपना और उन्हें यथार्थवादी ढंग से बफ़र करना एक अनाकर्षक काम है जो अपनी तिथियों पर टिकने वाले कार्यक्रमों को उनसे अलग करता है जो नहीं टिकते।

हितधारक अस्पष्टता। कई परियोजनाएँ महीनों तक इस स्पष्ट उत्तर के बिना चलती हैं कि वास्तव में निर्णय कौन लेता है। जब प्रायोजक, उपयोगकर्ता और वित्तपोषक सूक्ष्म रूप से भिन्न चीज़ें चाहते हैं और कोई एक जवाबदेह स्वामी उनमें मेल नहीं बिठाता, तो परियोजना इस टकराव को मंथन के रूप में सोख लेती है, तय हो चुके निर्णयों पर फिर से बहस करती है और किसी को खुश नहीं करती। इस बारे में स्पष्टता कि परिणाम का स्वामी कौन है, किससे परामर्श अनिवार्य है और किसे केवल सूचित करना है, नौकरशाही नहीं है। यह वह तंत्र है जिसके द्वारा कोई परियोजना वास्तव में निर्णय ले सकती है और उन्हें बरकरार रख सकती है।

अनुमान को प्रतिबद्धता समझना। अनुमान एक अनिश्चित भविष्य के बारे में एक प्रायिकतापरक कथन है। जिस क्षण इसे एक वादा समझ लिया जाता है, यह ईमानदार होना बंद कर देता है, क्योंकि वादा करने के लिए सबसे सुरक्षित अनुमान बढ़ा-चढ़ाकर बताया गया अनुमान होता है, और यह बढ़ावा उस जानकारी को नष्ट कर देता है जिसे अनुमान का वहन करना था। स्वस्थ वितरण अनुमान और प्रतिबद्धता को अलग रखता है: अनुमान योजना को खुले तौर पर सूचित करते हैं, और प्रतिबद्धताएँ सोच-समझकर की जाती हैं, जिसमें अनिश्चितता को स्वीकार किया जाता है, न कि मोल-भाव में मिटा दिया जाता है।

IT परियोजना प्रबंधन के प्रति Nashua का दृष्टिकोण पद्धति के बजाय निदान से शुरू होता है। किसी भी वितरण मॉडल की सिफ़ारिश करने से पहले, हम यह स्थापित करने के लिए काम करते हैं कि किसी दिए गए कार्यक्रम में अनिश्चितता वास्तव में कहाँ बसती है, घटक-दर-घटक, क्योंकि वह आकलन आगे की हर चीज़ तय करता है। यह जानबूझकर की गई गैर-फ़ैशनपरस्त कार्य है। यह पूरे परिदृश्य के लिए एक ही पद्धति घोषित करने की प्रवृत्ति का विरोध करता है और इसके बजाय यह स्वीकार करता है कि किसी कार्यक्रम को अपने स्थिर, निर्भरता-भारी मूल के लिए योजना-आधारित कठोरता और उन हिस्सों के लिए अनुकूली खोज की आवश्यकता हो सकती है जहाँ आवश्यकताएँ अभी भी सीखी जा रही हैं। हम उन तरीकों के बीच की सीमा-रेखा को एक बाद की सोच के बजाय एक प्रथम-श्रेणी की चिंता के रूप में प्रबंधित करते हैं।

क्रियान्वयन में, हम कुछ गिने-चुने अलंघनीय अनुशासनों पर टिके रहते हैं। वृद्धियों को इस तरह डिज़ाइन किया जाता है कि वे जल्दी और बार-बार कार्यशील, परीक्षित सॉफ़्टवेयर उत्पन्न करें, ताकि एकीकरण जोखिम को टालने के बजाय निरंतर सामना किया जाए। निर्भरताओं को, विशेषकर उन्हें जो टीम के नियंत्रण से बाहर हैं, शुरू से ही स्पष्ट किया जाता है, उनका स्वामित्व सौंपा जाता है और उन्हें बफ़र किया जाता है। दायरे को एक सुसंगत उद्देश्य के विरुद्ध प्रबंधित किया जाता है, जहाँ बदलाव का स्वागत किया जाता है यदि वह उस उद्देश्य पर अभिसरण करता है और चुनौती दी जाती है जहाँ वह उसे महज़ बड़ा करता है। और हम अनुमान को प्रतिबद्धता से अलग रखकर उसे ईमानदार बनाए रखते हैं, ताकि योजनाएँ रक्षात्मक बढ़ावे के बजाय वास्तविक जानकारी वहन करें। सबसे बढ़कर, हम प्रगति को प्रदर्शन योग्य कार्यशील सॉफ़्टवेयर और साकार मूल्य के प्रमाण से आँकते हैं, पार किए गए मील के पत्थरों की गिनती से नहीं, क्योंकि दूसरे में जालसाज़ी आसान है और पहले में नहीं।

हम किसी परियोजना की मानवीय वास्तुकला को भी गंभीरता से लेते हैं: यह स्थापित करना कि परिणाम का स्वामी कौन है, निर्णय कौन लेता है, और उन निर्णयों को कैसे बरकरार रखा जाता है। जो कुछ वितरण विफलता जैसा दिखता है, वह वास्तव में अनसुलझी हितधारक अस्पष्टता होती है जो मंथन के रूप में व्यक्त होती है, और हम जवाबदेही के स्पष्टीकरण को न्यूनतम किए जाने वाले शासन के बोझ के बजाय प्रथम कोटि के वितरण कार्य के रूप में मानते हैं।

Nashua जो फ़र्क लाती है वह कोई मालिकाना पद्धति नहीं है जो अनिश्चितता को गायब कर देने का वादा करती हो। ऐसी कोई पद्धति मौजूद नहीं है, और जो फ़र्में इसके विपरीत दावा करती हैं वे वितरण नहीं, बल्कि तसल्ली बेच रही होती हैं। फ़र्क है निरंतरता से लागू किया गया निर्णय: ईमानदारी से निदान करने की इच्छा, योजना-आधारित और अनुकूली वितरण को फ़ैशन के बजाय उनके गुणों पर चुनने की, निर्भरताओं और जवाबदेही को उनके बहाने बनने से पहले दृश्यमान करने की, और पूरे समय इस बात पर अड़े रहने की कि कोई परियोजना उतनी ही मूल्यवान है जितना वह उपयोगकर्ताओं के हाथों में डालती है और मूल्य में साकार करती है, न कि जितना वह किसी योजना के विरुद्ध रिपोर्ट करती है। वह निर्णय पर्याप्त कार्यक्रम वितरित करने का उत्पाद है, इतने कि यह जाना जा सके कि वे वास्तव में कहाँ गड़बड़ाते हैं।

एक व्यावहारिक निष्कर्ष भी है जो यह बदल देता है कि कार्य को क्या मान लेने की अनुमति है। जब किसी अनुबंध को ऐसी क्षमता की आवश्यकता होती है जो अभी तक मौजूद नहीं है, तो उसे किसी खरीद चक्र या किसी विक्रेता के रोडमैप की प्रतीक्षा नहीं करनी पड़ती। enterprise platform को इस तरह बनाया गया है कि यह लगभग किसी भी फ़ीचर को तेज़ गति से समायोजित कर ले, agentic engineering के ज़रिए: जो चाहिए उसे सरल भाषा में वर्णित किया जाता है और जल्दी उत्पन्न किया जाता है, लेकिन हमेशा दृढ़ वास्तुकला सिद्धांतों के भीतर और कठोर गुणवत्ता आश्वासन के अंतर्गत, ताकि गति कभी सुसंगति, सुरक्षा या नियंत्रण की कीमत पर न आए। प्रभाव केवल सुविधाजनक होने के बजाय रणनीतिक है। यह बनाओ-या-खरीदो की सीमा-रेखा को खिसका देता है, विकल्पशीलता को सस्ता रखता है, और वास्तुकला को रणनीति के पीछे चलने देता है, बजाय इसके कि रणनीति उस चीज़ के आगे झुके जो संयोगवश किसी शेल्फ़ पर पड़ी हो।

जो चीज़ इन सबको बाँधती है वह है वितरण को नाटक बन जाने न देने का इनकार। ऐसी परियोजना चलाना सीधा-सादा है जो भली-भाँति प्रबंधित दिखती है, आत्मविश्वासी रिपोर्टिंग उत्पन्न करती है और हर शासन जाँच-बिंदु को संतुष्ट करती है, जबकि चुपचाप मूल्य की कोई चीज़ उत्पन्न करने में विफल रहती है। ऐसी परियोजना चलाना कहीं अधिक कठिन, और कहीं अधिक दुर्लभ है जो अपनी अनिश्चितता के बारे में ईमानदार बनी रहती है, अपने जोखिमों का जल्दी सामना करती है, अपने दायरे को अभिसरित रखती है और स्वयं को कार्यशील परिणामों के विरुद्ध मापती है। वही कठिन रास्ता है जिसके प्रति Nashua प्रतिबद्ध है, क्योंकि यही एकमात्र रास्ता है जो IT परिवर्तन को महज़ भली-भाँति प्रलेखित के बजाय वास्तव में पूर्वानुमेय बनाता है। जिन संगठनों के साथ हम काम करते हैं, वे इस वादे पर नहीं, कि कुछ भी गलत नहीं होगा, बल्कि इस विश्वास पर भरोसा करने लगते हैं कि जब कुछ गलत होगा, तो उसे जल्दी देखा जाएगा, साफ़-साफ़ नाम दिया जाएगा और तब निपटाया जाएगा जब उसे ठीक करना अभी सस्ता है।