आयटी आणि सॉफ्टवेअर प्रकल्पांसाठी EVM
आयटी आणि सॉफ्टवेअर प्रकल्पांवर Earned Value Management (EVM) लागू करणे बांधकामाच्या तुलनेत अधिक आव्हानात्मक आहे. सॉफ्टवेअरचे काम अमूर्त असते, प्रकल्पाच्या मध्यभागी आवश्यकता बदलू शकतात आणि एखाद्या वैशिष्ट्याची 'पूर्ण टक्केवारी' मोजणे स्वाभाविकपणे व्यक्तिनिष्ठ असते. तरीही योग्य बदलांसह, EVM आयटी प्रोग्राम व्यवस्थापनासाठी आणि तांत्रिक नसलेल्या स्टेकहोल्डर्सना बजेट व वेळापत्रकाची स्थिती संप्रेषित करण्यासाठी प्रचंड मूल्य प्रदान करते.
मुख्य आव्हान: सॉफ्टवेअरमध्ये Earned Value (EV) मोजणे
बांधकामात तुम्ही भौतिक प्रगती (ओतलेले घनमीटर, घातलेले मीटर) मोजू शकता. सॉफ्टवेअरमध्ये तुम्ही न दिसणारे काम मोजता. तीन सर्वात सामान्य दृष्टिकोन:
1. स्टोरी पॉइंट्स (Agile EVM)
Scrum किंवा Kanban वातावरणात, टीम कामाचा अंदाज स्टोरी पॉइंट्समध्ये (story points) बांधतात. तुम्ही यावर आधारित EVM तयार करू शकता:
- BAC = एकूण स्टोरी पॉइंट्स × प्रति स्टोरी पॉइंट सरासरी खर्च
- PV = या स्प्रिंटपर्यंत पूर्ण करण्याचे नियोजित स्टोरी पॉइंट्स
- EV = प्रत्यक्ष पूर्ण झालेले स्टोरी पॉइंट्स × प्रति स्टोरी पॉइंट सरासरी खर्च
- AC = त्या कालावधीसाठी प्रत्यक्ष टीमचा खर्च (पगार, पायाभूत सुविधा, परवाने)
हा दृष्टिकोन केवळ तेव्हाच स्टोरी पूर्ण झाल्याचे मानतो जेव्हा ती टीमच्या 'Definition of Done' ची पूर्तता करते — ज्यामुळे "90% पूर्ण" चा सापळा टळतो.
2. टप्पे-आधारित EVM (Waterfall)
वॉटरफॉल (waterfall) प्रकल्पांसाठी, टप्प्यांना बजेटचे वजन द्या (उदा. आवश्यकता = 15%, डिझाइन = 20%, डेव्हलपमेंट = 40%, टेस्टिंग = 20%, डिप्लॉयमेंट = 5%). Earned Value (EV) तेव्हाच दिली जाते जेव्हा प्रत्येक टप्पा पूर्णपणे पूर्ण आणि स्वीकारला जातो.
3. भारित वर्क पॅकेजेस (Weighted Work Packages)
सॉफ्टवेअरला कार्यात्मक मॉड्यूल्समध्ये (ऑथेंटिकेशन, रिपोर्टिंग, API, UI) विभागून घ्या. प्रत्येकासाठी खर्च आणि कालावधीचा अंदाज घ्या. मॉड्यूलच्या स्तरावर पूर्णत्वाचा मागोवा घ्या. निश्चित-किंमत (fixed-price) IT करारांसाठी हा सर्वात पारंपारिक EVM दृष्टिकोन आहे.
प्रात्यक्षिक उदाहरण: सॉफ्टवेअर डेव्हलपमेंट प्रकल्प
एक कस्टम CRM डेव्हलपमेंट प्रकल्प: BAC = $400,000, 8 स्प्रिंट्स (16 आठवडे). 4थ्या स्प्रिंटमधील स्थिती (आठवडा 8):
- एकूण स्टोरी पॉइंट्स: 800. प्रति पॉइंट सरासरी खर्च: $500.
- 4थ्या स्प्रिंटपर्यंत नियोजित स्टोरी पॉइंट्स: 400. PV = 400 × $500 = $200,000
- प्रत्यक्ष पूर्ण झालेले स्टोरी पॉइंट्स: 320. EV = 320 × $500 = $160,000
- प्रत्यक्ष खर्च (टीमचे पगार + पायाभूत सुविधा): AC = $195,000
SPI = EV ÷ PV = 160,000 ÷ 200,000 = 0.800 (20% योजना मागे)
EAC = BAC ÷ CPI = 400,000 ÷ 0.821 = $487,211
VAC = 400,000 − 487,211 = −$87,211
EVM आणि Agile: सामान्य आक्षेप
| आक्षेप | उत्तर |
|---|---|
| "Agile ची व्याप्ती निश्चित नसते" | EVM प्राधान्य दिलेल्या बॅकलॉगसह (backlog) कार्य करते — BAC संपूर्ण उत्पादन बॅकलॉग नव्हे, तर मान्य केलेल्या रिलीझच्या व्याप्तीचे प्रतिनिधित्व करते. |
| "प्रत्येक स्प्रिंटमध्ये आवश्यकता बदलतात" | बदल नियंत्रण (change control) प्रक्रिया वापरा. मंजूर व्याप्ती बदल BAC अद्यतनित करतात. अनियोजित बदल म्हणजे तपासणी करण्यासाठी तफावत (variances) आहेत. |
| "स्टोरी पॉइंट व्हेलॉसिटी (velocity) अधिक उपयुक्त आहे" | व्हेलॉसिटी टीमसाठी उत्तम आहे; EVM प्रायोजकांना आणि अधिकाऱ्यांना आवश्यक असलेले आर्थिक चित्र प्रदान करते. |
| "आम्ही आगाऊ अंदाज बांधत नाही" | EVM ला बेसलाइनची (baseline) आवश्यकता असते. सापेक्ष आकाराच्या (relative-sized) स्टोरीज देखील सातत्याने आकारल्यास आधार बनू शकतात. |
आयटी प्रकल्प व्यवस्थापकांसाठी व्यावहारिक टिप्स
- तुमचा BAC स्प्रिंट नंतर नव्हे तर आधी सेट करा: EVM अर्थपूर्ण होण्यासाठी बेसलाइन स्थिर असली पाहिजे.
- अपूर्ण स्टोरीजसाठी केवळ 0% किंवा 100% मोजा: आंशिक श्रेयाचे (partial credit) टाळा; ते EV ला वाढवते आणि वेळापत्रकाचा धोका लपवते.
- CPI ट्रेंडचा साप्ताहिक मागोवा घ्या: सॉफ्टवेअर प्रकल्प वेगाने चालतात. मासिक EVM अहवाल समस्या पकडण्यास खूप उशीर करू शकतात.
- पायाभूत सुविधा/ऑपरेशन्स आणि डेव्हलपमेंटसाठी BAC वेगळे ठेवा: पायाभूत सुविधांच्या खर्चाचे घटक वेगळे असतात आणि त्यांचा मागोवा स्वतंत्रपणे घेतला पाहिजे.
- प्रोग्राम स्तरावर EVM वापरा: जर तुमच्याकडे एकाधिक Agile टीम असतील, तर कार्यकारी अहवालासाठी त्यांचा EV/AC डेटा प्रोग्राम स्तरावर एकत्रित करा.