आप एक परियोजना पर scope creep को कैसे प्रबंधित करते हैं?

Question

Accepted Answer

**Scope creep**, "बस एक और चीज़" का क्रमिक संचय, यही तरीका है जिससे ट्रैक पर परियोजनाएं चुपचाप फिसल जाती हैं। समाधान सब कुछ अस्वीकार करना नहीं है; यह **प्रत्येक जोड़ को समय के विरुद्ध एक दृश्यमान, स्पष्ट ट्रेड-ऑफ बनाना** है, चुप अवशोषण के बजाय।

## Scope को कैसे नियंत्रित करें

```text
✓ Define DONE up front — written, agreed scope
✓ Make the cost of every addition VISIBLE ("yes, and that pushes us a week")
✓ Track changes — a changelog of what got added/cut
✓ Protect a core MVP — defend the must-haves fiercely
✓ Use a PARKING LOT — capture good ideas for "later," don't reject them
✓ Escalate trade-offs to whoever owns priority — let them choose
```

## मुख्य कदम

नई अनुरोधों को सीधे अस्वीकार न करें, जिससे आप ब्लॉकर बन जाते हैं। इसके बजाय ट्रेड-ऑफ को सामने लाएं: "हम वह जोड़ सकते हैं। इसका मतलब है कि समय सीमा एक सप्ताह आगे बढ़े या हम फीचर X को हटा दें। आप क्या चाहते हैं?" अब यह *व्यावसायिक* निर्णय है, सही व्यक्ति द्वारा किया गया, आंखें खुली।

## एक ठोस उदाहरण

परियोजना के बीच में, PM "छोटी" tweaks जोड़ता रहता है। आप एक साझा scope-change लॉग शुरू करते हैं। अचानक सभी देखते हैं कि मूल दो सप्ताह की परियोजना ने तीन सप्ताह के अतिरिक्त को अवशोषित किया है, और समय सीमा के बारे में बातचीत स्पष्ट और आसान हो जाती है।

## यह क्यों महत्वपूर्ण है

अप्रबंधित scope creep समय सीमा का मूक हत्यारा है, कोई भी परिवर्तन बड़ा नहीं लगता, लेकिन वे एक विफलता में जुड़ जाते हैं।

ट्रेड-ऑफ को स्पष्ट करना टीम को सुरक्षित रखता है, हितधारकों को सूचित रखता है, और इंजीनियरिंग से दोष को दूर रखता है जब scope था, प्रयास नहीं, कारण।