परियोजना लागत (Project Cost), लागत से ज्यादा होना अविश्वसनीय किन्तु आम हैं, लेकिन थोड़ा सा आकलन करने के बाद आईटी परियोजना प्रबंधक (IT Project Managers) इस तरह की गलतियों को करने से बच सकते हैं।
——————————-

अधिकांश आईटी परियोजना प्रबंधक(IT Project Managers) उस दबाब को जानते हैं जब पहली बार आकलन त्रुटि (Estimation) के कारण परियोजना लागत अधिक हो जाती है। दुर्भाग्य से, परियोजना लागत अधिक होना अविश्वसनीयता के साथ आम होता जा रहा है।

ग्राहक अपनी आदत के अनुसार महत्वपूर्ण जानकारियों को देने में उपेक्षा करता है, या प्रणाली विन्यास(System Configuration) की साधारणतया उपेक्षा या पहले की लचर रणनीति पर वास्तव में तो परियोजना प्रबंधक को अपने बाल नोंचना पड़ते हैं। फ़िर भी मैं चकित होता हूँ कि बहुत सारी परियोजनाऐं तय समय एवं तय लागत में पूर्ण हो जाती हैं। अनगिनत बहुत सारे “जाने अनजाने” कार्य जादुई रुप से तकनीकी पेशेवर (IT Professionals) अपनी नौकरी में दक्षता से करते हैं, जो उनसे अपेक्षित होता है जैसे कि पुराने प्रणाली विन्यास (System Configuration) को कार्यरत रखना, विरासती तंत्र (Legacy Code) और स्वामित्व तंत्र (Proprietary systems).

यहाँ पर एक उदाहरण मैं अनुभव से बाँटता हूँ। जैसे एक खुदरा श्रृंखला (Retail Chain) अपनी कई दुकानों में अपना वित्तीय प्रबंधन मंच (financial managemengt platform) का उन्नयन (upgrade) करती है। समीक्षा के बाद ग्राहक द्वारा तैयार की गई उपकरण सूची, सर्वर और विन्डोज लाइसेंस के विकल्प की तलाश, रूटर और फ़ायरवाल (firewall) मॉडल पर शोध, परियोजना लागत अनुमान तैयार करने के बाद, 25000000 में परियोजना ग्राहक को बेचने के बाद अब इस योजना को लागू (implement) करने का समय आता है। उस परेशानी की कल्पना करिये जब ग्राहक के द्वारा गलत स्टाक का पता चलता है। सीखने की इस धीमी प्रक्रिया में १८ प्रणालियों (systems) में से करीबन ७ प्रणालियों में न्यूनतम हार्डवेयर जरूरतों (minimum hardware requirements)को पूरा नहीं करते एवं परियोजना को खत्म कर सकते हैं ।( वर्कस्टेशन प्रतिस्थापन (workstations replacement) आसानी से मूल बजट के ३०% से चल सकता है।)

आप इस तरह की गलत लागत आकलन से पूरी तैयारी करने पर बच सकते हैं, और यही “जाने अनजाने” कार्यों से बचने का उपाय है। उन “जाने अनजाने” कार्यों को अपनी परियोजना से बाहर निकाल कर परियोजना पूर्ण करने के अवरोधों (disruption) को कम कर सकते हैं । यहाँ पर परियोजना लागत में गलतियों से बचने के सबसे अच्छे तीन सुझाव क्रम से दे रहा हूँ ।

# 1: सभी मान्यताओं की पुष्टि करें (confirm all assumptions)(उर्फ किसी पर भरोसा न करें) अक्सर ग्राहक का भ्रम आईटी परियोजना प्रबंधकों को परेशानी में डाल देता है । कभी भी ग्राहक या दूसरे आईटी परियोजना प्रबंधकों की बातों को स्वीकार न करें । ग्राहक की उन आवश्यकताओं को समझना, जिसके बारे में कभी कभी ग्राहक को भी पता नहीं होता है कि उसे क्या चाहिये।

कैसा है?

यदि ग्राहक कहता है कि उसके पास 25 32 बिट Windows XP Professional workstations हैं, आप ग्राहक की बात पर विश्चास मत करिये जब तक कि खुद ग्राहक के कार्यस्थल पर जाकर मुआयना न कर लें।

अन्यथा, कुछ 64 बिट Windows Vista workstations बाद में पता चलने पर आप परेशानी में फ़ँस सकते हैं और ग्राहक आपसे यही उम्मीद करेगा कि आप अतिरिक्त लागत (extra cost) के बिना प्रबंधन कर लेंगे (प्रोग्रामर ही बता सकते हैं कि दो विभिन्न ओपरेटींग प्रणाली (os) से सॉफ्टवेयर विकास (software development) में बाधा तो नहीं होगी)।

या, यदि ग्राहक बताता है कि उसके पास पहले से ही दो Windows सर्वर 2008, SQL सर्वर 2008 के साथ उपलब्ध हैं (जो कि आवश्यक हो उस प्लेटफ़ार्म को ताकतवर बनाने के लिये जिसमें आपकी कंपनी साफ़्टवेयर विकसित करती है), आप उन पर ध्यान मत दीजिये जब वास्तव में आप नए हार्डवेयर और सॉफ्टवेयर खरीदने या उन्नयन का आकलन करते हैं। आपको स्वयं ही हार्डवेयर और सॉफ्टवेयर निर्भरता को जाँचना होगा (या फ़िर आपकी कंपनी से एक प्रतिनिधि यह कार्य करे)।साधारणतया ग्राहक हमेशा भ्रमित ही रहते हैं। मैंने ऐसे भी ग्राहक देखे हैं जो SQL सर्वर 2008 और SQL सर्वर 2008 एक्सप्रेस के बीच अंतर करने में असमर्थ रहे हैं। इस तरह के भ्रम के कारण आप अपने परियोजना लागत बढ़ने मत दें, जब परियोजना लागत का अनुमानित आकलन कर रहे हों तो छोटे से छोटे विवरण की पुष्टि कर लें। इस तरह के संभावित तत्वों को समाप्त करके आप “जाने अनजाने” या सामान्य तत्वों से परियोजना लागत दो बढ़ने से रोक सकते हैं।

# 2: परेशानी मुक्त परियोजनाओं की उम्मीद मत करो (उर्फ़ अनचाही अनजानी तत्वों की योजना)
केवल आपके पास ही अनुमानों के आधार पर इतनी जानकारी है। चूंकि परियोजना लागत अनुमान में समय के साथ ही सामग्री भी शामिल है, यह महत्वपूर्ण है कि आवंटित किये हुए उस समय में आप अप्रत्याशित कार्य, दिये गये कार्यक्षेत्र में परिवर्तन, परिस्थिती अनुकूल न होना, और अन्य मुद्दों का भी निपटान करना है।

हालांकि एक सरल मानक या गणना सभी परियोजनाओं के लिए इस्तेमाल करना बहुत मुश्किल है, फ़िर भी कम से कम समय में और न्यूनतम राशि में परियोजना पूरी होनी चाहिये। फ़िर, पुराने अनुभव के आधार पर इस तरह की परियोजनाओं को पूरा करना, और चरणबद्ध तरीके से अनुभव के आधार पर आगे आने वाली मुसीबतों से लड़्ने के लिये तैयार रहना चाहिये और अनुमान लगाना चाहिये कि इन संभावित मुसीबतों को हल करने में तय समय सीमा से कितना ज्यादा समय लगेगा।

मैंने हार्डवेयर विक्रेताओं को देखा है कि वो हमेशा समय पर सामान नहीं भेजते हैं। माल भाड़ा कंपनियों सामान खो देती हैं; डेवलपर्स और प्रशासक बीमार हो जाते हैं, और वो ओपरेटिंग सिस्टम मंच जो कि सब हार्ड्वेयर को अपने आप कर ढ़ूँढ लेते हैं वे भी असफ़ल हो जाते हैं ।

सुनिश्चित करें कि सिफारिशों, प्रस्तावों में परिवर्तन, लागत की अपरिहार्य समस्या आदि के लिये मूल परियोजना की योजना के दस्तावेजों को बनाते समय समुचित समय लिया गया है।
आप “जाने अनजाने” तथ्यों की क्षतिपूर्ती समय सीमा में तो नहीं कर सकते, पर आप यह कर सकते हैं तो कम से कम आकस्मिक समय के लिए एक ठोस योजना बना सकते हैं ।

# 3: बिल्कुल साफ़ बता दें कि कि अनुमानित योजना में क्या शामिल किया गया है (उर्फ सभी चीजें सभी को बता दें और पत्राचार कर दें) क्योंकि बताया नहीं गया कहना बहुत आसान है। ग्राहक अगर आपसे जानना चाहे तो आप बता सकते हैं कि परियोजना में लगने वाला समय, उपकरण और सॉफ्टवेयर जो कि एक नए अनुकूलित डेटाबेस को तैयार करने के लिए जरुरी है सबका अनुमान शामिल है । back-end SQL सर्वर की आवश्यकताओं और क्लाइंट साइड माइक्रोसॉफ्ट access की आवश्यकताओं में ग्राहक अंतर नहीं कर पायेगा | परिनियोजन एक बुरा समय है, ग्राहक सोचता है कि उसके Microsoft Office लघु व्यवसाय संस्करण लाइसेंस समझौते में माइक्रोसॉफ्ट access भी 25 मशीनों के लिये है।

सभी चीजें जो कि परियोजना का अनुमान और प्रस्ताव बनाते वक्त ध्यान में रखी गई थीं, सटीकता से दर्शायें । सुनिश्चित करें कि अनुबंध या परियोजना समझौते में साफ़गोई से लिखा गया हो कि अतिरिक्त श्रम, उपकरण, और सॉफ्टवेयर इस परियोजना के लागत अनुमान में शामिल नहीं है जो कि इस परियोजना को पूरा करने के लिए आवश्यक हो सकता है। उदाहरण के लिए, एक कस्टम डेटाबेस को उपयोग करने के लिये, एक नया सर्वर की लागत में, एक नया सर्वर, एक विशिष्ट CPU, रेम, डिस्क विन्यास (disk configuration), ऑपरेटिंग सिस्टम, और सीएएल लाइसेंस गिनती और अतिरिक्त सॉफ्टवेयर हों यह सुनिश्चित करें।

इस तरह यदि एक विसंगति आती है जब पता चलता है कि ग्राहक के पास निर्धारित मात्रा में माइक्रोसॉफ्ट access लाइसेंस नहीं है जो कि आपने अपनी परियोजना में शामिल करी हुई है (हालांकि अगर आपने पहले ही होमवर्क किया होता है जिसकी हम पहले चर्चा कर चुके हैं, तो आप इस तरह के संभावित “जाने अनजाने” से बचाव कर सकते हैं)।

आत्म विश्लेषण कर पक्षाघात होने का डर केवल राजनेताओं और अन्य उद्योगों के अगुआ लोगों को ही नहीं, यह आईटी प्रबंधकों को भी प्रभावित करती है।

वहाँ तुम सिर्फ परियोजना तैयार करने का काम ही कर सकते हो । कुशल परियोजनाओं पर जल्दी काम शुरु कर देना चाहिये, तो देरी से अनुमानित लागत बढ़्ने के डर से बाहर रह सकते हैं। आप अपना सबसे अच्छा प्रयास करो, अपने कौशल और अनुभव पर भरोसा करो और काम शुरू करो।

अगर आपने ध्यान से हर कार्य की समीक्षा, अप्रत्याशित मुद्दों के लिए समय, और लिखित में इस परियोजना के विस्तार का दस्तावेजीकरण कर लिया है। तो आप बेहतर तरीके से बीच में आने वाले “जाने अनजाने” कार्यों को समायोजित कर पायेगें। आप बेहतर करेंगे आप अपने अच्छे निरीक्षण की वजह से संभावित लागत (समय या पैसे) को अधिक नहीं होने देंगे।