آپ پروجیکٹ کے خطرات کی نشاندہی اور انتظام کیسے کرتے ہیں (RAID)؟

Question

Accepted Answer

ایک **خطرہ** کچھ ایسا ہے جو *ہو سکتا ہے* اور اگر ہو تو پروجیکٹ کو نقصان پہنچائے گا۔ **خطرے کا انتظام** ان خطرات کی جلد نشاندہی کرنا اور اس سے پہلے فیصلہ کرنا ہے کہ ان کے بارے میں کیا کریں *قبل* وہ آپ کو متاثر کریں۔ سادہ سبق: مسائل سے نمٹنا بہت آسان ہے جب آپ نے پہلے سے انہیں سوچ لیا ہو۔

## RAID لاگ

پروجیکٹ کے خطرات اور اشیاء کو ٹریک کرنے کے لیے سادہ، وسیع پیمانے پر استعمال ہونے والا ٹول:

```text
R — RISKS        → might happen, would cause harm (manage proactively)
A — ASSUMPTIONS  → things we're taking as true (validate them)
I — ISSUES       → risks that have already materialized (deal with now)
D — DEPENDENCIES → things we rely on from others (track them)
```

## ہر خطرے کا جائزہ لیں

```text
For each risk, score:
  LIKELIHOOD (how probable?) × IMPACT (how bad?)
→ focus effort on high-likelihood, high-impact risks
```

## جواب منتخب کریں

```text
AVOID    → change the plan so the risk can't occur
MITIGATE → reduce its likelihood or impact
TRANSFER → shift it (insurance, vendor SLA)
ACCEPT   → live with it, but have a fallback ready
```

## ایک عملی مثال

ایک پروجیکٹ ایک تیسری طرف کی API پر منحصر ہے جو نیا اور غیر ثابت شدہ ہے۔ خطرہ: یہ کارکردگی دکھانے میں ناکام ہو سکتا ہے۔ امکان درمیانہ، اثر زیادہ۔ تدارک: اسے جلد ٹیسٹ کریں، ایک تجریدی سطح بنائیں تاکہ آپ فراہم کنندگان کو بدل سکیں، اور ایک متبادل رکھیں۔ اب ایک نامعلوم چیز ایک منظم خطرے میں بدل گئی ہے جس کے پاس منصوبہ ہے۔

## ایک عام خرابی

خطرے کے انتظام کو ایک بار کی ابتدائی چیک لسٹ کے طور پر سمجھنا۔ خطرات تبدیل ہوتے ہیں — RAID لاگ کا باقاعدہ جائزہ لیں اور نئے خطرات شامل کریں جیسے وہ سامنے آئیں۔

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

غیر منظم خطرات بحران بن جاتے ہیں، عام طور پر ڈیڈ لائن کے قریب بدترین ممکنہ لمحے میں۔

خطرے کو جلد سنبھالنے کی لاگت اسے روک دینے کے بعد اس سے نمٹنے کے مقابلے میں بہت کم ہے۔

خطرات کا نام بلند آواز سے لینا اعتماد بھی پیدا کرتا ہے — اہل افراد "یہاں یہ غلط ہو سکتا ہے اور ہمارا منصوبہ" کو پسند کرتے ہیں اعتماد کے ساتھ خاموشی اور پھر ناخوشگوار حیرت سے بہتر۔