آپ scope کا انتظام کیسے کرتے ہیں اور scope creep سے کیسے بچتے ہیں؟

Question

Accepted Answer

**Scope** وہ متفقہ کام ہے جو ایک project فراہم کرے گا۔ **Scope creep** اس scope کی بتدریج، غیر کنٹرول شدہ توسیع ہے — چھوٹی اضافیوں کا مسلسل سلسلہ جو خاموشی سے timeline کو تبدیل کر دیتا ہے۔ Scope کا انتظام کرنے کا مطلب *تبدیلی* کو کنٹرول کرنا ہے، اسے مسترد کرنا نہیں۔

## شروع میں Scope کو واضح طریقے سے متعین کریں

```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
```

اہم چال: اضافی کام کو خاموشی سے قبول نہ کریں۔ ہر اضافے کو ایک شعوری تبدیلی بنائیں جس کا مالک stakeholder ہو۔

## ایک حقیقی مثال

منصوبے کے دوران، ایک stakeholder "bulk upload کو بھی سپورٹ کرنے" کے لیے کہتا ہے — جلدی ہونا چاہیے۔ اسے اندر دبانے کے بجائے، آپ جواب دیتے ہیں: "ہم کر سکتے ہیں، لیکن یہ تقریباً ایک ہفتہ شامل کرتا ہے۔ کیا ہم تاریخ کو آگے بڑھائیں، یا analytics خصوصیت کو اگلی release میں ڈالیں؟" اب یہ ان کا فیصلہ ہے، خرچ ٹیبل پر ہے۔

## ایک عام خطرہ

ہر درخواست کے لیے ہاں کہنا مدد دینے کے لیے، پھر deadline کو miss کرنا۔ ٹیم ایسا لگتا ہے کہ ناکام ہو گیا، جب حقیقت میں اس نے خاموشی سے اضافی کام لیا۔

## اہمیت

Scope creep سب سے عام وجہ ہے کہ projects slip ہوتے ہیں — کیونکہ کوئی بھی تبدیلی بڑی نہیں ہے، بلکہ کیونکہ درجن خاموشی سے جمع ہو جاتے ہیں۔

Scope کا انتظام منصوبہ کو ایمانداری سے رکھتا ہے: تبدیلی ٹھیک ہے، لیکن اس کی قیمت ہمیشہ واضح اور اس کا مالک جو چاہتا ہے وہ ہے۔