जोखिम हे असे काहीतरी आहे जे घडू शकते आणि जर ते घडले तर प्रकल्पाला नुकसान पोहोचवेल. जोखीम व्यवस्थापन म्हणजे त्या धोक्यांना लवकर ओळखणे आणि त्यापूर्वी त्याबद्दल काय करायचे हे ठरविणे. सोपी अंतर्दृष्टी: समस्या मागच्या विचार केल्यास हाताळणे खूप सोपे होते.
प्रकल्पातील धोक्े आणि आयटम ट्रॅक करण्यासाठी एक साधी, व्यापकपणे वापरलेली साधन:
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)
For each risk, score:
LIKELIHOOD (how probable?) × IMPACT (how bad?)
→ focus effort on high-likelihood, high-impact risks
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 लॉग नियमितपणे पुनरावलोकन करा आणि नवीन आयटम जसे ते उदयास येतात तसे जोडा.
व्यवस्थापित न केलेल्या जोखिम संकट बनतात, सामान्यत: अंतिम मुदतीजवळ सर्वात वाईट क्षणी.
लवकर जोखिम हाताळण्याचा खर्च हे नंतर लढवणे पडलेल्या खर्चाच्या तुलनेत नगण्य आहे.
जोखिम मोठ्याने नाव देणे आस्था देखील तयार करते — हितधारकांना "येथे काय चूक होऊ शकते आणि आमची योजना" असे पसंद आहे आत्मविश्वासी शांतता आणि नंतर एक अप्रिय चमकीपणा यापेक्षा.