तपाई स्कोप कसरी व्यवस्थापन गर्नुहुन्छ र स्कोप क्रीप कसरी बचाउनुहुन्छ?

Question

Accepted Answer

**Scope** भनेको एक परियोजनाले डिलिभर गर्ने काम गरिएको सहमति हो। **Scope creep** भनेको त्यो स्कोपको क्रमिक, अनियन्त्रित विस्तार हो — "साना थपिनहरू" को निरन्तर प्रवाह जसले चुपचाप समयरेखालाई उडायो। स्कोप व्यवस्थापनको अर्थ *परिवर्तन* नियन्त्रण गर्नु हो, त्यसलाई अस्वीकार गर्नु होइन।

## स्कोप सुरुमा स्पष्ट रूपमा परिभाषित गर्नुहोस्

```text
✓ Document what's IN scope
✓ Document what's explicitly OUT of scope (the underused half)
✓ Define "done" / acceptance criteria
✓ Get stakeholders to agree before work starts
```

एक लिखित, सहमत सीमा भनेको जो तपाईलाई पछि "यो एक परिवर्तन हो" भन्न सक्षम बनाउँछ।

## परिवर्तनहरू जानाजानी हेर्नुहोस्

परिवर्तनहरू खराब छैनन् — अनियन्त्रित हरू हुन्। जब नयाँ अनुरोध आयो, यसलाई साधारण गेटमा चलाउनुहोस्:

```text
1. Is it really needed now, or is it a "nice to have"?
2. What's the impact on timeline / cost / other work?
3. Make the trade-off VISIBLE → "yes, but it pushes the date / drops X"
4. Get the stakeholder to decide with full information
```

मुख्य चाल: अतिरिक्त काम कहिले पनि चुपचाप सोच्नु हुन्न। प्रत्येक थपना एक सचेत ट्रेड-अफ बनाउनुहोस् जसको लागि स्टेकहोल्डरले स्वामित्व लिन्छ।

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

मध्य-परियोजनामा, एक स्टेकहोल्डरले "पनि bulk upload समर्थन गर्नुहोस् — द्रुत हुनुपर्छ" सोध्छ। यसलाई अवशोषित गर्नको सट्टा, तपाई जवाफ दिनुहुन्छ: "हामी सक्छौं, तर यसले लगभग एक हप्ता थप गर्छ। के हामी मिति सरांग गर्छौं, वा analytics सुविधा अगिलो रिलिजमा धक्का दिन्छौं?" अब यो तिनीको कल हो, लागत तालिकामा छ।

## एक सामान्य समस्या

सहायक हुन प्रत्येक अनुरोधमा हाँ भन्नु, त्यसपछि समयसीमा मिस गर्नु। टीम असफल जस्तो देखिन्छ, जब साँच्चै यसले चुपचाप अतिरिक्त काम लियो।

## यो किन महत्त्वपूर्ण हो

Scope creep परियोजनाहरू फिसलने सबैभन्दा सामान्य कारण हो — किनभने कुनै एक परिवर्तन ठूलो छ भन्ने कारणले होइन, तर दर्जन चुपचाप जमा हुन्छन्।

स्कोप व्यवस्थापन परियोजनालाई ईमानदार रखिदछ: परिवर्तन ठीक छ, तर यसको लागत सधैँ स्पष्ट र जो यसलाई चाहन्छ उनको स्वामित्व हो।