स्कोप क्रीप समय, बजट या संसाधनों में अनुमोदित परिवर्तनों के बिना परियोजना आवश्यकताओं का अनियंत्रित विस्तार है। स्पष्ट स्कोप बेसलाइन, इनटेक लॉग, प्रभाव विश्लेषण, नामित अनुमोदन प्राधिकारी और परिवर्तन स्वीकृत होने के बाद ही शेड्यूल अपडेट के साथ इसे रोकें।
स्कोप क्रीप क्या है?
स्कोप क्रीप, समय, बजट या संसाधनों के अनुमोदित समायोजन के बिना, काम शुरू होने के बाद परियोजना आवश्यकताओं का अनियंत्रित विस्तार है। एक नई आवश्यकता स्वचालित रूप से स्कोप क्रीप नहीं है। यह तब गुंजाइश बन जाती है जब टीम इसे अनौपचारिक रूप से स्वीकार कर लेती है, यह पता नहीं लगा पाती कि इसे किसने मंजूरी दी है, या चुपचाप इसकी डाउनस्ट्रीम लागत को अवशोषित कर लेती है।
व्यावहारिक बचाव यह नहीं है कि “कभी परिवर्तन न हो।” साक्ष्य, विनियमन, जोखिम या ग्राहक मूल्य में परिवर्तन होने पर परियोजनाओं को बदलने की आवश्यकता होती है। रक्षा अनुरोध → प्रभाव विश्लेषण → निर्णय → अद्यतन आधार रेखा और अनुसूची से एक छोटा, दृश्य पथ है।
स्कोप क्रीप सामान्य स्कोप परिवर्तन से किस प्रकार भिन्न है?
एक नियंत्रित दायरा परिवर्तन स्पष्ट, मूल्यांकन, अनुमोदित, वित्त पोषित और रिकॉर्ड किया गया है; स्कोप क्रीप उस नियंत्रण के बिना प्रोजेक्ट में प्रवेश करता है। गोल्ड प्लेटिंग फिर से अलग है: डिलीवरी टीम बिना अनुरोध के काम जोड़ती है क्योंकि यह फायदेमंद लगता है। फ़ीचर क्रीप, परिवर्धन के माध्यम से एकत्रित होने वाली उत्पाद जटिलता का वर्णन करता है, चाहे स्वीकृत हो या नहीं।
| अवधि | इसका क्या मतलब है | विशिष्ट आरंभकर्ता | औपचारिक रूप से स्वीकृत? | सामान्य प्रतिक्रिया |
|---|---|---|---|---|
| दायरा रेंगना | ट्रेडऑफ़ के मिलान के बिना सहमत आधार रेखा के बाहर कार्य का विस्तार होता है | कोई भी हितधारक या टीम सदस्य | नहीं, या अनुमोदन अस्पष्ट है | रुकें, लॉग इन करें, मूल्यांकन करें और निर्णय लें |
| नियंत्रित दायरा परिवर्तन | स्वीकृत दायरे को जानबूझकर संशोधित किया गया है | प्रायोजक, ग्राहक, नियामक, या टीम | हाँ | दायरा, लागत, शेड्यूल और संचार अपडेट करें |
| सोना चढ़ाना | टीम उन अतिरिक्त चीज़ों को जोड़ती है जिनका अनुरोध नहीं किया गया था | डिलिवरी टीम | आमतौर पर नहीं | परिवर्तन के रूप में निकालें या सबमिट करें |
| फ़ीचर रेंगना | एक उत्पाद सुविधाओं और जटिलता को संचित करता है | उत्पाद, बिक्री, ग्राहक, या इंजीनियरिंग | कभी-कभी | परिणाम, मूल्य और जीवनचक्र लागत की पुनः पुष्टि करें |
| खोज | नए तथ्य यह परिष्कृत करते हैं कि क्या वितरित किया जाना चाहिए | अनुसंधान या वितरण टीम | अभी नहीं | तय करें कि निष्कर्ष स्पष्टीकरण है या परिवर्तन |
अमेरिकी ऊर्जा विभाग का प्रोजेक्ट-मैनेजमेंट लेक्सिकॉन स्कोप बेसलाइन को स्वीकृत स्कोप स्टेटमेंट, वर्क ब्रेकडाउन स्ट्रक्चर और WBS डिक्शनरी के रूप में परिभाषित करता है। यह परिवर्तन नियंत्रण को स्वीकृत बेसलाइन में परिवर्तनों की पहचान करने, समीक्षा करने, अनुमोदन करने, कार्यान्वयन करने, परीक्षण करने और दस्तावेज़ीकरण करने की प्रक्रिया के रूप में परिभाषित करता है। वे दो परिभाषाएँ समस्या की जड़ को उजागर करती हैं: आधार रेखा के बिना, टीम यह साबित नहीं कर सकती कि कुछ बदल गया है।
स्कोप रेंगने का क्या कारण है?
स्कोप में कमी आम तौर पर कमजोर सीमाओं और कमजोर निर्णयों से आती है, किसी एक कठिन हितधारक से नहीं। सबसे आम कारण हैं:
- अस्पष्ट डिलिवरेबल्स। “बिल्ड रिपोर्टिंग” का मतलब एक कार्यकारी, विश्लेषक और इंजीनियर के लिए अलग-अलग चीजें हैं।
- अनुपलब्ध स्वीकृति मानदंड। कोई नहीं कह सकता कि अनुरोधित परिणाम कब पूरा होगा।
- अनौपचारिक सेवन। अनुरोध मीटिंग, चैट और ईमेल में आते हैं लेकिन कभी भी एक लॉग में प्रवेश नहीं करते हैं।
- अनुमोदनकर्ता नामित नहीं। लोग मानते हैं कि बैठक में उत्साह प्राधिकरण के बराबर है।
- छिपी निर्भरताएँ। दो घंटे का दृश्य परिवर्तन डिजाइन, विकास, परीक्षण, प्रशिक्षण और तैनाती कार्य बनाता है।
- निश्चित तिथि आशावाद। टीम समय सीमा और स्टाफिंग तय होने का दिखावा करते हुए गुंजाइश जोड़ती है।
- अप्रबंधित खोज। उपयोगी निष्कर्षों को मूल्यांकन के बजाय स्वचालित रूप से शामिल माना जाता है।
- सोना चढ़ाना। टीम के सदस्य रखरखाव लागत पर विचार किए बिना सहमत परिणाम से परे समाधान में सुधार करते हैं।
यही कारण है कि लोगों को “नहीं कहने” के लिए कहना कमज़ोर सलाह है। एक विश्वसनीय प्रणाली टीम को यह कहने देती है: “हाँ, यदि हम भी इस लागत को स्वीकार करते हैं, तो इस तिथि को आगे बढ़ाएँ, इस अन्य वस्तु को हटा दें, या इस जोखिम को स्वीकार करें।“
स्कोप क्रिप के प्रारंभिक चेतावनी संकेत क्या हैं?
सबसे पहली चेतावनी यह है कि किसी के अनुमोदित परिवर्तन रिकॉर्ड को इंगित करने से पहले काम पर चर्चा की जा रही है या शुरू किया जा रहा है। इन सात संकेतों पर नज़र रखें:
- नए कार्य बिना किसी अनुरोध आईडी के स्प्रिंट या शेड्यूल में दिखाई देते हैं।
- वितरण योग्य विवरण बदलता है, लेकिन आधारभूत दस्तावेज़ नहीं बदलता है।
- डिलीवरी टीम द्वारा इसका अनुमान लगाने से पहले एक हितधारक अनुरोध को “छोटा” कहता है।
- टीम के सदस्य बार-बार शाम को काम करते हैं जबकि रिपोर्ट किया गया दायरा अपरिवर्तित रहता है।
- स्वीकृति समीक्षाएँ उन अपेक्षाओं को प्रकट करती हैं जिन्हें कभी लिखा नहीं गया था।
- मील के पत्थर आगे बढ़ते हैं, लेकिन परियोजना अभी भी “योजना पर” रिपोर्ट करती है।
- बैकलॉग पूर्ण या स्पष्ट रूप से हटाए गए कार्य की तुलना में तेजी से बढ़ता है।
शेड्यूल एक उत्कृष्ट डिटेक्टर है क्योंकि यह अनुरोध को समय लेने और पूर्ववर्तियों और उत्तराधिकारियों से जुड़ने के लिए बाध्य करता है। यह अपने आप में अनुमोदन प्रणाली नहीं है. गहन शेड्यूल तर्क के लिए, देखें निर्भरता नेटवर्क कैसे डाउनस्ट्रीम प्रभाव को उजागर करते हैं और चार गैंट निर्भरता प्रकार.
काम शुरू होने से पहले आप स्कोप क्रीप को कैसे रोकते हैं?
परियोजना की सीमा को निष्पादन से पहले परीक्षण योग्य बनाकर स्कोप रेंगने से रोकें। लोगों द्वारा उपयोग की जाने वाली एक छोटी आधार रेखा उस बड़े दस्तावेज़ से बेहतर है जिसे कोई नहीं पढ़ता है।
कम से कम रिकॉर्ड करें:
- परिणाम और नामित डिलिवरेबल्स;
- स्पष्ट बहिष्करण और धारणाएँ;
- प्रत्येक वितरण योग्य के लिए स्वीकृति मानदंड;
- उस स्तर पर कार्य विश्लेषण संरचना जिसका अनुमान टीम लगा सकती है;
- अनुमोदित बजट और प्रमुख मील का पत्थर तिथियां;
- कौन किस वर्ग के परिवर्तन को मंजूरी दे सकता है;
- परिवर्तन अनुरोध कहां लॉग किए जाते हैं और उन्हें कितनी जल्दी निर्णय प्राप्त होता है।
फिर सहमत कार्य को एक शेड्यूल से जोड़ें। प्रत्येक डिलिवरेबल का मालिक, अवधि, पूर्ववर्ती तर्क और स्वीकृति मील का पत्थर होना चाहिए। यदि टूल किसी शेड्यूल बेसलाइन का समर्थन करता है तो उसे सहेजें। यदि ऐसा नहीं होता है, तो दिनांकित निर्यात या नामित योजना संस्करण को सुरक्षित रखें; एक संस्करण विज़ुअल बेसलाइन ओवरले की तुलना में कम सुविधाजनक है, लेकिन फिर भी यह ट्रैसेबिलिटी बनाता है।
कौन सी परिवर्तन-नियंत्रण प्रक्रिया नौकरशाही बनाए बिना दायरे में कमी को रोकती है?
एक फॉर्म, एक निर्णय स्वामी और एक जोखिम-आधारित अनुमोदन सीमा का उपयोग करें। एक छोटी टीम को प्रत्येक शब्द परिवर्तन के लिए एक उद्यम समिति की आवश्यकता नहीं होती है, लेकिन उसे एक सुसंगत रिकॉर्ड की आवश्यकता होती है।
| मैदान | उदाहरण प्रविष्टि | यह क्यों मायने रखता है? |
|---|---|---|
| निवेदन | लॉन्च से पहले SSO जोड़ें | प्रस्ताव को ठोस बनाता है |
| व्यावसायिक कारण | हस्ताक्षरित उद्यम ग्राहक द्वारा आवश्यक | मान को प्राथमिकता से अलग करता है |
| डिलिवरेबल्स प्रभावित | प्रमाणीकरण, व्यवस्थापक सेटिंग्स, समर्थन दस्तावेज़ | वास्तविक सीमा का पता चलता है |
| अनुसूची प्रभाव | +8 कार्य दिवस; रिलीज़ चाल 21 अगस्त → 2 सितंबर | समय को दृश्यमान बनाता है |
| लागत/संसाधन प्रभाव | 40 घंटे के लिए पहचान विशेषज्ञ | अदृश्य ओवरटाइम को रोकता है |
| जोखिम का प्रभाव | खाता जोखिम कम करता है; लॉन्च जटिलता जोड़ता है | दोनों पक्षों को दर्शाता है |
| विकल्प | दिनांक जोड़ें और स्थानांतरित करें; विश्लेषण हटाएं; SSO को स्थगित करें | अनुमोदनकर्ता को विकल्प देता है |
| निर्णय स्वामी/तिथि | प्रायोजक, 10 अगस्त | प्राधिकार और पता लगाने की क्षमता स्थापित करता है |
एक हल्का प्रवाह है:
- डिलीवरी का वादा किए बिना अनुरोध को कैप्चर करें।
- परिणाम और स्वीकृति मानदंड स्पष्ट करें।
- प्रत्यक्ष कार्य और प्रभावित निर्भरता का अनुमान लगाएं।
- महत्वपूर्ण पथ, बजट, संसाधन और जोखिम पर प्रभाव दिखाएं।
- ट्रेडऑफ़ की पेशकश करें - न कि केवल स्वीकार/अस्वीकार करें।
- नामित अनुमोदनकर्ता का निर्णय प्राप्त करें।
- स्कोप बेसलाइन, शेड्यूल, बजट, बैकलॉग और हितधारक संदेश को एक साथ अपडेट करें।
एपीएम परिवर्तन नियंत्रण को उन मुद्दों के लिए उपयोग की जाने वाली प्रक्रिया के रूप में वर्णित करता है जो दायरे या बेसलाइन योजना के किसी अन्य भाग को संशोधित करते हैं। डीओई इसी प्रकार परिवर्तन-नियंत्रण लॉग को दस्तावेज़ सूची परिवर्तन, स्थिति और कार्यों के रूप में परिभाषित करता है। महत्वपूर्ण व्यवहार रिकॉर्ड को सिंक्रनाइज़ करना है: शेड्यूल को अपरिवर्तित छोड़ते हुए ईमेल में बदलाव को मंजूरी देना सत्य का दूसरा संस्करण बनाता है।
गैंट चार्ट “छोटे” अनुरोध की वास्तविक लागत को कैसे प्रकट करता है?
तर्क से जुड़ा गैंट चार्ट दिखाता है कि जब नया कार्य शेड्यूल में प्रवेश करता है तो कौन सी डाउनस्ट्रीम तिथियां चलती हैं। ग्राहक प्रोफ़ाइल में एक फ़ील्ड जोड़ने के अनुरोध पर विचार करें:
| कामकाज प्रभावित | अतिरिक्त प्रयास | निर्भरता परिणाम |
|---|---|---|
| उत्पाद स्पष्टीकरण | 0.5 दिन | ब्लॉक डिज़ाइन |
| यूएक्स और सत्यापन नियम | 1 दिन | फ्रंटएंड और API अनुबंध को ब्लॉक करता है |
| API/डेटाबेस परिवर्तन | 1.5 दिन | एकीकरण परीक्षण को रोकता है |
| अग्रभाग परिवर्तन | 1 दिन | प्रतिगमन परीक्षण को रोकता है |
| परीक्षण, दस्तावेज़, और रिलीज़ | 1.5 दिन | रिलीज़ मील का पत्थर आगे बढ़ाता है |
| कुल | 5.5 दिन | पहले वर्णित “त्वरित क्षेत्र” नहीं |
यदि वे गतिविधियाँ चालू हैं, तो अंतिम समय सीमा आगे नहीं बढ़ सकती है। यदि वे बैठते हैं महत्वपूर्ण पथ, समाप्ति तिथि तब तक आगे बढ़ती रहती है जब तक कि टीम अनुक्रम, क्षमता, या दायरा कहीं और नहीं बदल देती। चार्ट एक भावनात्मक बातचीत को एक स्पष्ट शेड्यूलिंग निर्णय में बदल देता है।
GanttFather FS, SS, FF, और SF निर्भरता को अंतराल के साथ मॉडल कर सकता है और वर्तमान महत्वपूर्ण पथ दिखा सकता है। GanttFather वर्तमान में एक समर्पित शेड्यूल-बेसलाइन ओवरले प्रदान नहीं करता है, इसलिए औपचारिक बेसलाइन तुलना की आवश्यकता होने पर एक अनुमोदित निर्यात या नामित संस्करण को सुरक्षित रखें। देखें प्रोजेक्ट बेसलाइन गाइड लाइव पूर्वानुमान और अनुमोदित संदर्भ योजना के बीच अंतर के लिए।
स्कोप क्रिप पहले ही हो जाने के बाद आप कैसे उबरते हैं?
नए काम को संक्षेप में स्वीकार करना बंद करें, वर्तमान दायरे का पुनर्निर्माण करें, और प्रायोजक-स्तरीय ट्रेडऑफ़ को मजबूर करें। पुरानी आधार रेखा को चुपचाप बदलकर भिन्नता को न छिपाएं।
- सूची सभी कार्य प्रगति पर और पूर्ण कार्य जो अनुमोदित दायरे में नहीं थे।
- अनिवार्य परिवर्तनों को वैकल्पिक संवर्द्धन और सोना चढ़ाना से अलग करें।
- बचे हुए काम का उन लोगों के साथ फिर से आकलन करें जो इसे वितरित करेंगे।
- निर्भरता तर्क का पुनर्निर्माण करें और एक विश्वसनीय पूर्वानुमान की गणना करें।
- वर्तमान विकल्प: तिथि को आगे बढ़ाएं, योग्य क्षमता जोड़ें, गुंजाइश हटाएं, केवल स्पष्ट स्वीकृति के साथ गुणवत्ता/जोखिम नियंत्रण कम करें, या परियोजना को रोकें।
- एक पुनर्प्राप्ति योजना को मंजूरी दें और सीखे गए पाठों के लिए मूल आधार रेखा को बनाए रखें।
स्वीकृत बड़े बदलाव के बाद रीबेसलाइनिंग वैध हो सकती है। इसे इस सबूत को नहीं मिटाना चाहिए कि मूल योजना अलग हो गई है। डीओई शब्दकोष भिन्नता को स्वीकृत दायरे, लागत या शेड्यूल बेसलाइन से विचलन के रूप में वर्णित करता है और कहता है कि भिन्नताओं को समाप्त करने के बजाय ट्रैक किया जाना चाहिए और रिपोर्ट किया जाना चाहिए।
GanttFather किसी दायरे में बदलाव के शेड्यूल प्रभाव को कैसे दृश्यमान बना सकता है?
Excel निर्यात के साथ स्वीकृत शेड्यूल को सुरक्षित रखें, फिर किसी भी तारीख का वादा करने से पहले प्रस्तावित गतिविधियों, अवधियों और निर्भरता लिंक को कार्य योजना में जोड़ें। GanttFather अंतराल के साथ FS, SS, FF, और SF संबंधों को मॉडल कर सकता है और महत्वपूर्ण पथ की पुनर्गणना कर सकता है, ताकि अनुमोदक यह देख सके कि अनुरोध फ़्लोट का उपभोग करता है या अंतिम मील के पत्थर को स्थानांतरित करता है। Unlimited दर्शक और मेहमान लाइव परिणाम की समीक्षा कर सकते हैं जबकि संपादक की दो सीटें मुफ़्त स्वामित्व वाले प्रोजेक्ट में परिवर्तनों को नियंत्रित करती हैं।
GanttFather शेड्यूल साक्ष्य प्रदान करता है, परिवर्तन प्राधिकारी नहीं। इसमें कोई समर्पित बेसलाइन ओवरले या स्वचालित संसाधन लेवलिंग नहीं है, इसलिए दिनांकित निर्यात को बनाए रखें और निर्णय को प्रोजेक्ट के परिवर्तन लॉग में रखें। एक काल्पनिक अनुरोध के साथ प्रक्रिया का परीक्षण करने के लिए, एक निःशुल्क GanttFather प्रोजेक्ट बनाएं और नया कार्य जोड़ने से पहले और बाद की समाप्ति तिथि की तुलना करें।
अक्सर पूछे जाने वाले प्रश्न
क्या हर नई आवश्यकता का दायरा रेंगता है?
नहीं, सहमत परिवर्तन प्रक्रिया के माध्यम से जोड़ी गई एक आवश्यकता एक नियंत्रित दायरा परिवर्तन है। स्कोप क्रीप कार्य का अस्वीकृत या अप्राप्य विस्तार है। यदि प्रत्येक परिवर्तन में दृश्य प्राधिकरण, प्रभाव, वित्त पोषण और अद्यतन रिकॉर्ड हों तो एक परियोजना बिना “रेंगने” के कई वैध परिवर्तनों को स्वीकार कर सकती है।
स्कोप क्रिप को रोकने के लिए कौन जिम्मेदार है?
प्रायोजक प्रमुख कार्यक्षेत्र निर्णयों का स्वामी होता है, परियोजना प्रबंधक नियंत्रण प्रक्रिया का स्वामी होता है, उत्पाद या व्यवसाय स्वामी मूल्य स्पष्ट करते हैं, और वितरण टीम प्रयास और निर्भरता को उजागर करती है। यदि हितधारक सेवन को बायपास कर सकते हैं या यदि टीम के सदस्य अस्वीकृत कार्य शुरू करते हैं तो कोई भी व्यक्ति स्कोप रेंगने से नहीं रोक सकता है।
क्या एजाइल टीमों में स्कोप रेंग सकता है?
हाँ. लचीले बैकलॉग का मतलब किसी निश्चित रिलीज़ के अंदर असीमित काम नहीं है। फुर्तीली टीमें बैकलॉग का आदेश देकर, स्प्रिंट या रिलीज़ लक्ष्यों को परिभाषित करके, क्षमता को दृश्यमान बनाकर और मौजूदा प्रतिबद्धताओं के विरुद्ध नई वस्तुओं का व्यापार करके दायरे को नियंत्रित करती हैं। किसी भी डिलीवरी पद्धति में गैर-रिकॉर्ड किए गए जोड़ और अदृश्य ओवरटाइम की गुंजाइश कम होती है।
जब कोई हितधारक अधिक काम का अनुरोध करता है तो उपयोग करने के लिए सबसे अच्छा वाक्य क्या है?
उपयोग: “हम उस परिवर्तन का आकलन कर सकते हैं; प्रतिबद्ध होने से पहले, हम तारीख, लागत, निर्भरता और वर्तमान प्राथमिकताओं पर इसका प्रभाव दिखाएंगे।” वाक्य अनुरोध को अस्वीकार नहीं करता. यह डिलीवरी प्रभाव को समझने से पहले बातचीत को प्राधिकरण बनने से रोकता है।
क्या गैंट चार्ट अपने आप स्कोप क्रीप को रोकता है?
नहीं, एक गैंट चार्ट समय और निर्भरता को दृश्यमान बनाता है, लेकिन यह व्यवसाय प्राधिकरण को परिभाषित नहीं कर सकता है या अनुमोदन लागू नहीं कर सकता है। शेड्यूल को स्कोप बेसलाइन, परिवर्तन लॉग, स्वीकृति मानदंड और नामित निर्णय स्वामी के साथ जोड़ें। चार्ट प्रभाव साक्ष्य प्रदान करता है; शासन निर्णय प्रदान करता है।
स्रोत
- अमेरिकी ऊर्जा विभाग, परियोजना प्रबंधन शर्तों का शब्दकोश
- परियोजना प्रबंधन एसोसिएशन, परिवर्तन नियंत्रण क्या है?
- एसोसिएशन फॉर प्रोजेक्ट मैनेजमेंट, स्कोप क्रीप क्या है और हम इसे कैसे कम कर सकते हैं?
- परियोजना प्रबंधन संस्थान, स्कोप क्रीप को नियंत्रित करना
- परियोजना प्रबंधन संस्थान, शेड्यूलिंग के लिए अभ्यास मानक



