آپ کسی پروجیکٹ پر 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 مسلسل "چھوٹی" تبدیلیاں شامل کرتے رہتے ہیں۔ آپ ایک مشترک scope-change log شروع کرتے ہیں۔ اچانک سب کو نظر آتا ہے کہ اصل دو ہفتے کا پروجیکٹ تین ہفتے کے اضافے کو جذب کر گیا ہے، اور ڈیڈ لائن کے بارے میں بات واضح اور آسان ہو جاتی ہے۔

## یہ کیوں اہم ہے

غیر منظم scope creep ڈیڈ لائن کا خاموش قاتل ہے، کوئی بھی ایک تبدیلی بڑی نہیں لگتی، لیکن وہ ناکامی میں جمع ہو جاتی ہے۔

ٹریڈ آفز کو واضح بنانا ٹیم کو محفوظ رکھتا ہے، اسٹیک ہولڈرز کو باخبر رکھتا ہے، اور جب scope غلط تھا، کوشش نہیں، تو الزام انجینئرنگ سے ہٹتا ہے۔