रिक्वायरमेंट गैदरिंग टेम्पलेट: प्रोजेक्ट में काम आने वाले मेरे 7 हैक

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

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

यह पैटर्न असामान्य नहीं है। रिक्वायरमेंट मैनेजमेंट पर PMI की 2014 की रिपोर्ट Pulse of the Profession में पाया गया कि असफल प्रोजेक्ट में से 47% अपने लक्ष्य इसलिए चूके कि रिक्वायरमेंट मैनेजमेंट कमज़ोर था। मैंने इसे दर्जनों बार होते देखा है।

एक बड़े सिस्टम रोलआउट पर मैं ख़ुद लगभग उसी स्थिति में पहुँच गया था। स्टेकहोल्डर चारों तरफ़ बिखरे थे। डेवलपर अंदाज़े लगा रहे थे। हमने रुककर एक ढंग का रिक्वायरमेंट टेम्पलेट बनाया, और बिज़नेस को जो चाहिए था वह समय पर और बजट के भीतर डिलीवर किया।

एक दोस्त की कंपनी ने एक कस्टम CRM पर $350K ख़र्च किए जिसे कोई इस्तेमाल नहीं करता। सेल्स को एक चीज़ चाहिए थी, मार्केटिंग को दूसरी, और डेवलपरों ने वह बनाया जो उन्हें लगा कि सबको चाहिए।

मेरे एक हेल्थकेयर क्लाइंट ने EMR इम्प्लीमेंटेशन पर 18 महीने गँवा दिए, जिसे डॉक्टरों ने इस्तेमाल करने से मना कर दिया। किसी ने उनसे नहीं पूछा था कि उनके रोज़ के काम में उन्हें क्या चाहिए। प्रोजेक्ट रद्द करके दोबारा शुरू करना पड़ा।

देर से पता चलना महँगा पड़ता है। NASA के error cost escalation अध्ययन में पाया गया कि जो रिक्वायरमेंट की गलती इंटीग्रेशन और टेस्ट में पकड़ी गई, उसे ठीक करने में रिक्वायरमेंट के दौरान पकड़ी गई गलती की तुलना में 21 से 78 गुना ज़्यादा लागत लगी। ऑपरेशन में पकड़ी जाने पर यह गुणक 29 से लेकर 1,500 से भी ऊपर तक गया। एंटरप्राइज़ प्रोग्राम में यही फ़र्क एक वर्कशॉप और लाखों की लागत वाले चेंज रिक्वेस्ट का है।

1. रिक्वायरमेंटठीक करने की बुनियादी लागततब पकड़ी गई जब रिक्वायरमेंट अभी लिखे जा रहे थे
2. इंटीग्रेशन और टेस्ट21 से 78 गुना लागततब पकड़ी गई जब सिस्टम बन चुका था और टेस्ट में था
3. ऑपरेशन29 से 1,500 से भी ज़्यादा गुना लागतसिस्टम के लाइव होने के बाद पकड़ी गई

स्रोत: NASA का error cost escalation अध्ययन

मुश्किल तरीके से यह सीखने के बाद, ये वे पाँच सेक्शन हैं जिन्हें कोई भी रिक्वायरमेंट टेम्पलेट नहीं छोड़ सकता।

1. हस्ताक्षर ब्लॉक के साथ एग्ज़ीक्यूटिव समरी

व्यस्त एग्ज़ीक्यूटिव 30 पन्नों का रिक्वायरमेंट डॉक्यूमेंट नहीं पढ़ेंगे। एक बार एक स्पॉन्सर ने यह समझे बिना प्रोजेक्ट मंज़ूर कर दिया कि वह किस पर साइन कर रहा है, और नतीजा देखकर आपा खो बैठा। इसे एक पन्ने पर रखें: बिज़नेस पर असर, टाइमलाइन, रिसोर्स, अपेक्षित लाभ और उसी पन्ने पर हस्ताक्षर ब्लॉक, ताकि मंज़ूरी देने वाले यह न कह सकें कि उनसे अहम ब्योरे छूट गए।

2. भूमिका और प्रभाव की मैपिंग

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

3. बिज़नेस उद्देश्य, तकनीकी रिक्वायरमेंट नहीं

हम कौन सी समस्या सुलझा रहे हैं, और सफलता कैसे मापेंगे? एक मैन्युफ़ैक्चरिंग क्लाइंट ने इन्वेंट्री सॉफ़्टवेयर ठीक वैसे ही लागू किया जैसा तय था, और उसने वेयरहाउस के संचालन को 20% धीमा कर दिया। टेम्पलेट को स्टेकहोल्डर से मौजूदा बेसलाइन के साथ बिज़नेस की सफलता परिभाषित करवानी चाहिए, फ़ीचर की सूची नहीं।

4. फ़ंक्शनल रिक्वायरमेंट जो डेवलपर इस्तेमाल कर सकें

जार्गन छोड़िए। हर रिक्वायरमेंट को ठोस और टेस्ट करने योग्य बनाइए। “सिस्टम को ग्राहक अनुभव बेहतर करना चाहिए” बेकार है। “यूज़र को 3 मिनट से कम में रिटर्न प्रोसेस करके रिफ़ंड जारी कर पाना चाहिए” एक रिक्वायरमेंट है। अगर आप जाँच नहीं सकते कि वह पूरा हुआ, तो उसे दोबारा लिखिए।

5. नॉन-फ़ंक्शनल रिक्वायरमेंट

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

यह पूरा आउटलाइन है। ऊपर के पाँच सेक्शन इसके भीतर हैं, उन लॉग के साथ जो साइन-ऑफ़ के बाद इसे ज़िंदा रखते हैं।

सेक्शन	इसमें क्या जाता है	ओनर	साइन-ऑफ़ कौन करता है
1. एग्ज़ीक्यूटिव समरी	समस्या, बिज़नेस पर असर, टाइमलाइन, रिसोर्स, अपेक्षित लाभ। हस्ताक्षर ब्लॉक के साथ एक पन्ना	स्पॉन्सर, ड्राफ़्ट BA लीड का	स्पॉन्सर और फ़ाइनेंस
2. स्कोप और डिप्लॉयमेंट बेसलाइन	स्कोप के भीतर और बाहर, बाध्यताएँ। SAP के लिए: public edition, private edition या on-premise	प्रोग्राम डायरेक्टर	स्टीयरिंग कमेटी
3. भूमिका और प्रभाव का मैप	विभाग, प्रतिनिधि, प्रभाव का स्तर, सलाह लेनी है या सिर्फ़ सूचित करना	BA लीड	स्पॉन्सर
4. बिज़नेस उद्देश्य	हर उद्देश्य KPI, उसकी मौजूदा बेसलाइन और लक्ष्य के साथ	प्रोसेस ओनर	स्पॉन्सर
5. फ़ंक्शनल रिक्वायरमेंट	ID (जैसे REQ-FUN-023), विवरण, उत्पत्ति, प्राथमिकता, स्वीकृति के मानदंड, fit-to-standard का फ़ैसला	फ़ंक्शनल लीड	प्रोसेस ओनर
6. नॉन-फ़ंक्शनल रिक्वायरमेंट	परफ़ॉर्मेंस, सिक्योरिटी, कंप्लायंस, उपलब्धता। SAP के लिए, हर गैप का एक्सटेंशन तरीका	सॉल्यूशन आर्किटेक्ट	IT, सिक्योरिटी और कंप्लायंस
7. पार्किंग लॉट	टाले गए अनुरोध, किसने माँगे, अगले रिव्यू की तारीख़	BA लीड	प्रमोट होने तक कोई नहीं
8. रद्द किए गए का लॉग	क्या रद्द हुआ, क्यों, कब और किसने किया	BA लीड	स्पॉन्सर
9. चेंज लॉग	साइन-ऑफ़ के बाद का हर बदलाव, उसके समय और लागत के असर के साथ	PMO	चेंज बोर्ड

1. स्टेकहोल्डर इंटरव्यू में Five Whys इस्तेमाल करें

पूछिए “आपको क्या चाहिए?” तो आपको विश-लिस्ट मिलेगी। इसकी जगह तकलीफ़ के बारे में पूछिए: “आपको किस बात पर कंप्यूटर खिड़की से बाहर फेंकने का मन करता है?” फिर पूछिए क्यों, और फिर क्यों, पाँच बार। असली रिक्वायरमेंट अक्सर पहली माँग से अलग निकलता है।

एक स्टेकहोल्डर जटिल रिपोर्टिंग क्षमताओं पर अड़ा था। जब हमने उसके असली यूज़ केस पर बात की, तो उसे बस तीन सीधे डैशबोर्ड चाहिए थे।

2. रिक्वायरमेंट का पार्किंग लॉट बनाएँ

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

3. बार-बार मन बदलने वाले स्टेकहोल्डर के लिए तीन का नियम

वे बिना किसी नतीजे के दो बार दिशा बदल सकते हैं। तीसरे बदलाव पर, वे अपने बॉस को ईमेल करके बदलाव और उसके असर की सफ़ाई देते हैं। वह ईमेल कोई नहीं भेजना चाहता। बदलाव रुक जाते हैं।

4. प्राथमिकता तय करवाने के लिए फ़ंडिंग आवंटन तकनीक इस्तेमाल करें

हर स्टेकहोल्डर को सभी रिक्वायरमेंट पर ख़र्च करने के लिए 100 वर्चुअल डॉलर दें। सब कुछ उनके पास नहीं हो सकता, इसलिए वे पैसा वहाँ लगाते हैं जहाँ मायने रखता है। मैंने यह एक फ़ाइनेंशियल सर्विसेज़ क्लाइंट के साथ किया, जिसके पास 200 से ज़्यादा “क्रिटिकल” रिक्वायरमेंट थे। एक घंटे के भीतर हमारे पास असली टॉप 20 थे।

5. हर रिक्वायरमेंट को नंबर दें

REQ-FUN-023 जैसा एक सुसंगत फ़ॉर्मैट इस्तेमाल करें। इससे “हम किस रिक्वायरमेंट की बात कर रहे हैं?” वाली उलझन ख़त्म हो जाती है, जो मीटिंग का समय खाती है। उत्पत्ति दर्ज करें, किसने माँगा और क्यों, ताकि जब आइटम काटने हों तो पता हो कि किसे फ़ोन करना है।

6. रिक्वायरमेंट स्टेकहोल्डर की भाषा में दोहराकर सुनाएँ

डॉक्यूमेंट करने के बाद रिक्वायरमेंट को स्टेकहोल्डर के अपने शब्दों में उन्हें वापस पढ़कर सुनाएँ। जो भी जटिल हो, उसके लिए डेवलपमेंट शुरू होने से पहले एक तेज़ प्रोटोटाइप या वायरफ़्रेम बनाएँ। ग़लतफ़हमियाँ तब सामने आ जाती हैं जब उन्हें ठीक करना सस्ता होता है।

7. जो रद्द हुआ, उसे दर्ज करें

कोई न कोई पाँचवें महीने में रद्द हुआ रिक्वायरमेंट वापस ले आएगा। “हमने अप्रैल में इस पर चर्चा की थी, और हमने इसके ख़िलाफ़ इसलिए फ़ैसला किया” वह बातचीत जल्दी ख़त्म कर देता है। लॉग न हो, तो आप वही बहस दोबारा करते हैं।

सातों हैक किसी भी प्रोजेक्ट पर काम करते हैं। SAP प्रोग्राम को टेम्पलेट में तीन अतिरिक्त चीज़ें चाहिए।

डिप्लॉयमेंट मॉडल बेसलाइन में जाता है

फ़ंक्शनल रिक्वायरमेंट जुटाने से पहले डिप्लॉयमेंट मॉडल दर्ज करें: S/4HANA Cloud Public Edition (GROW with SAP के ज़रिए, या RISE), Private Edition (आम तौर पर RISE के ज़रिए) या on-premise। यही तय करता है कि क्या संभव है। Public edition में core का कोई मॉडिफ़िकेशन नहीं होता, इसलिए जो रिक्वायरमेंट गैर-मानक प्रोसेस पर टिके हैं, उन्हें नया रूप देना होगा या रद्द करना होगा। Private edition और on-premise ज़्यादा छूट देते हैं, अपग्रेड की मेहनत की कीमत पर।

इस फ़ैसले से पहले रिक्वायरमेंट जुटाएँगे, तो फ़ैसला आते ही उनमें से कई दोबारा लिखने पड़ेंगे।

हर गैप के लिए एक्सटेंशन का फ़ैसला

SAP के clean-core तरीके का मतलब है कि हर गैप के लिए एक दर्ज किया हुआ फ़ैसला चाहिए: उसे कॉन्फ़िगर करें, released API से एक्सटेंड करें (ABAP Cloud के साथ on-stack या SAP BTP पर side-by-side), या रद्द करें। Public edition में यह प्रोडक्ट ख़ुद लागू करवाता है। Private edition और on-premise में यह SAP की ज़ोरदार सलाह है, और आप जो भी मॉडिफ़िकेशन होने देते हैं, वह बाद में अपग्रेड का काम बन जाता है। यह फ़ैसला टेम्पलेट के सेक्शन 6 में परफ़ॉर्मेंस और सिक्योरिटी के बगल में रखें, और इसे मंज़ूर करने का अधिकार एक आर्किटेक्ट को दें। मेरी clean core गाइड लेवल समझाती है।

AI ड्राफ़्ट करता है, लोग फ़ैसला लेते हैं

AI अब कागज़ी काम में मदद करता है। SAP Cloud ALM में एक रिक्वायरमेंट जनरेशन फ़ीचर है, जो fit-to-standard वर्कशॉप के ट्रांसक्रिप्ट से रिक्वायरमेंट का ड्राफ़्ट एक टेम्पलेट में तैयार करता है, और इसका भुगतान AI यूनिट से होता है। Microsoft Copilot जैसे सामान्य असिस्टेंट मीटिंग नोट्स से समरी और मिनट्स का ड्राफ़्ट बनाते हैं।

सोर्स सामग्री साफ़ हो तो AI ड्राफ़्टिंग टूल कागज़ी काम में असली समय बचाते हैं। वे इंटरव्यू को नहीं बदलते। Five Whys अब भी कोई इंसान पूछता है। और कोई टूल किसी विभाग प्रमुख से एग्ज़ीक्यूटिव समरी पर साइन नहीं करवा सकता। वैलिडेशन, प्राथमिकता तय करना और साइन-ऑफ़ इंसानों का काम बने रहते हैं।

सॉफ़्टवेयर डेवलपमेंट। तकनीकी बाध्यताएँ, इंटीग्रेशन पॉइंट, यूज़र फ़्लो (यूज़र के असली कदम, सिर्फ़ फ़ीचर नहीं) और पास/फ़ेल स्वीकृति के मानदंड जोड़ें। एक कस्टमर पोर्टल प्रोजेक्ट में हमसे यह छूट गया, और हमने तीन महीने इस पर बहस में बिताए कि फ़ीचर “ठीक से काम कर रहे हैं” या नहीं।

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

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

छोटे प्रोजेक्ट के लिए: रिक्वायरमेंट को मंज़ूरी के चरणों से गुज़ारने के लिए Trello, रिव्यू के लिए कमेंट वाले Google Docs और वर्कशॉप में प्रोसेस मैपिंग के लिए Miro।

एंटरप्राइज़ प्रोग्राम के लिए: रिक्वायरमेंट मैनेजमेंट ऐड-ऑन के साथ Jira, जीवित डॉक्यूमेंट के लिए Confluence (इसके AI फ़ीचर अब Atlassian के Rovo ब्रांड के तहत हैं), और अगर आप Azure DevOps चलाते हैं तो Modern Requirements। SAP प्रोग्राम में SAP Cloud ALM रिक्वायरमेंट, यूज़र स्टोरी और टेस्ट केस एक जगह रखता है, SAP Activate रोडमैप से जुड़े हुए।

टूल से ज़्यादा कनेक्शन मायने रखता है। रिक्वायरमेंट को अपने प्रोजेक्ट प्लान और टेस्ट केस से जोड़ें, और रिक्वायरमेंट बदलने पर अपने आप नोटिफ़िकेशन भेजें। “मुझे पता नहीं था कि यह बदल गया” कमज़ोर टूलिंग से ज़्यादा प्रोजेक्ट मारता है। रिक्वायरमेंट साइन-ऑफ़ हो जाने के बाद, उन्हें वैसा ही बनाए रखने के लिए मेरी SAP इम्प्लीमेंटेशन में स्कोप क्रीप से बचने की गाइड देखें, और SAP क्वालिटी गेट दिखाता है कि रिक्वायरमेंट साइन-ऑफ़ गवर्नेंस साइकिल में कहाँ बैठता है।

जिस टेम्पलेट को साइन-ऑफ़ के बाद कोई खोले ही नहीं, वह नाटक है। जो काम करते हैं वे छोटे होते हैं, सेक्शन-दर-सेक्शन किसी के ओनर होते हैं, और हर बार अपडेट होते हैं जब कोई मन बदलता है, जो किसी भी चलाने लायक प्रोग्राम में हर हफ़्ते होता है।

रिक्वायरमेंट गैदरिंग के 5 चरण कौन से हैं?

1. एलिसिटेशन: इंटरव्यू, वर्कशॉप और अवलोकन से जानकारी जुटाना
2. एनालिसिस: रिक्वायरमेंट को व्यवस्थित करना, प्राथमिकता देना और उनके बीच के टकराव सुलझाना
3. डॉक्यूमेंटेशन: स्पेसिफ़िकेशन लिखना (मेथड के हिसाब से BRD, FRD या यूज़र स्टोरी)
4. वैलिडेशन: पुष्टि करना कि रिक्वायरमेंट असली ज़रूरतों को दर्शाते हैं और टेस्ट किए जा सकते हैं
5. मैनेजमेंट: प्रोजेक्ट के बाकी समय बदलावों को ट्रैक करना

हर चरण पिछले पर बनता है। एलिसिटेशन में जल्दबाज़ी, जो ज़्यादातर टीमें करती हैं, उसके बाद के हर चरण में समस्याएँ पैदा करती है।

BRD और FRD में क्या फ़र्क है?

बिज़नेस रिक्वायरमेंट्स डॉक्यूमेंट (BRD) बिज़नेस की ज़रूरतों को कवर करता है: पृष्ठभूमि, लक्ष्य, स्टेकहोल्डर, बाध्यताएँ और हाई-लेवल रिक्वायरमेंट। वह जवाब देता है “बिज़नेस को क्या चाहिए?”

फ़ंक्शनल रिक्वायरमेंट्स डॉक्यूमेंट (FRD) कवर करता है कि सिस्टम कैसे व्यवहार करेगा: यूज़र स्टोरी, सिस्टम का व्यवहार, इंटरफ़ेस और स्वीकृति के मानदंड। वह जवाब देता है “सिस्टम को क्या करना है?”

मैं हमेशा FRD से पहले BRD से शुरू करता हूँ ताकि बिज़नेस की सहमति बन जाए। जो टीमें सीधे FRD पर कूदती हैं, वे अक्सर तकनीकी रूप से सही सिस्टम बना देती हैं जो ग़लत समस्या सुलझाता है।

रिक्वायरमेंट के 3 प्रकार कौन से हैं?

1. बिज़नेस रिक्वायरमेंट: प्रोजेक्ट क्यों है, उसके उद्देश्य और सफलता के पैमाने
2. फ़ंक्शनल रिक्वायरमेंट: सिस्टम को क्या करना है
3. नॉन-फ़ंक्शनल रिक्वायरमेंट: उसे कितना अच्छा करना है (परफ़ॉर्मेंस, सिक्योरिटी, स्केलेबिलिटी, कंप्लायंस)

मैंने जितनी प्रोजेक्ट विफलताएँ देखी हैं, उनमें से ज़्यादातर नॉन-फ़ंक्शनल रिक्वायरमेंट के छूटने तक पहुँचती हैं। सिस्टम वही करता है जो माँगा गया था, फिर असली लोड में बैठ जाता है या कंप्लायंस ऑडिट में फ़ेल हो जाता है।

SAP डिप्लॉयमेंट मॉडल रिक्वायरमेंट गैदरिंग को कैसे बदलता है?

इसे सबसे पहले दर्ज करें। S/4HANA Cloud Public Edition में core का कोई मॉडिफ़िकेशन नहीं होता, इसलिए गैर-मानक प्रोसेस पर टिके रिक्वायरमेंट को नया रूप देना होगा या रद्द करना होगा। Private Edition और on-premise ज़्यादा लचीलापन देते हैं, पर हर मॉडिफ़िकेशन अपग्रेड की मेहनत बढ़ाता है।

फ़ैसले से पहले फ़ंक्शनल रिक्वायरमेंट जुटाएँगे, तो उनमें से कई दोबारा करने पड़ेंगे। हर गैप के लिए एक दर्ज किया हुआ एक्सटेंशन फ़ैसला जोड़ें (कॉन्फ़िगर करें, released API से एक्सटेंड करें, या रद्द करें)।

रिक्वायरमेंट को टेस्ट करने योग्य क्या बनाता है?

एक साफ़, मापने योग्य पास/फ़ेल शर्त। “सिस्टम तेज़ होना चाहिए” टेस्ट करने योग्य नहीं है। “स्टैंडर्ड लोड पर 95% क्वेरी के लिए सर्च रिज़ल्ट 2 सेकंड से कम में आने चाहिए” है।

मेरी कसौटी: क्या आप अभी, साफ़ पास/फ़ेल मानदंड के साथ, टेस्ट केस लिख सकते हैं? नहीं, तो रिक्वायरमेंट दोबारा लिखिए। जिन रिक्वायरमेंट को टेस्ट नहीं किया जा सकता, वे मेरे देखे किसी भी और चीज़ से ज़्यादा go-live के विवाद करवाते हैं।

रिक्वायरमेंट को लगातार बदलने से कैसे रोकें?

1. चेंज कंट्रोल: साइन-ऑफ़ के बाद का कोई भी बदलाव, मंज़ूरी से पहले, अपने समय, बजट और रिसोर्स के असर को दर्ज करता है। बदलाव की कीमत को दिखने दें।
2. पार्किंग लॉट: नए अनुरोध सीधे स्कोप में नहीं, पार्किंग लॉट में जाते हैं। हर महीने रिव्यू करें। ज़रूरी दिखने वाले ज़्यादातर अनुरोध इंतज़ार में टिकते नहीं।
3. क्वालिटी गेट: तय करें कि “रिक्वायरमेंट पूरे” का क्या मतलब है, और जब तक वह पूरा न हो, डिज़ाइन शुरू न करें।

SAP प्रोग्राम में एक्सटेंशन का फ़ैसला ऊपर से एक तकनीकी जाँच जोड़ता है: जिस अनुरोध के लिए core मॉडिफ़िकेशन चाहिए, उसे मंज़ूर होने से पहले आर्किटेक्ट से मंज़ूरी लेनी होगी।