Tag Archives: project management

शेविंग के बिना बहुत कुछ खोना पड़ जाता है (Better to Shave)

    आमतौर पर शेविंग करना भी एक शगल होता है, कोई रोज शेविंग करता है और कोई एक दिन छोड़कर, कुछ लोग मंगलवार, गुरूवार और शनिवार को शेविंग नहीं करते हैं । शेविंग करने से चेहरा अच्छा लगने लगता है और अपना आत्मविश्वास भी चरम पर होता है। केवल शेविंग करने से ही कुछ नहीं होता उसके बाद और पहले भी बहुत सारी क्रियाएँ होती हैं, जो शेविंग के कार्यक्रम को सम्पूर्ण करती हैं।
    शेविंग न करने से कुछ बड़े बड़े नुक्सान भी हो जाते हैं, यहाँ एक किस्सा बयान करना जरूरी है, जो कि हमारे सामने हमारे ही कार्यालय में हमने घटित होते देखा हुआ है। एक प्रोग्रामर था जो कि जबरदस्त प्रोग्रामिंग करता था, केवल उनका रहन सहन और बात करने के सलीका उनकी लिये नकारात्मक था, पर कई बार बात करने के बाद हमने सोचा कि चलो इन्हें कुछ सिखाया जा सकता है और हमने ओर हमारे कुछ सहकर्मियों ने उन्हें कपड़े पहनने के सलीकों के बारे में समझाया और उन्होंने सीख भी लिया।
    पर केवल कपड़े पहनने से कुछ नहीं होता, समस्या जस की तस थी क्योंकि वे रोज शेविंग करके नहीं आते थे, कहते थे कि शेविंग अपने से रोज नहीं होती है, केवल आलस्य के प्रमाद में वे रोज बेतरतीब कार्यालय आते थे, उनका काम जबरदस्त था, जब वर्ष के आखिर में रेटिंग की बारी आई तो हर किसी को अच्छे मूल्यांक मिलने की उम्मीद होती है, उनकी टीम को भी उनके अच्छे मूल्यांक की उम्मीद थी, पर जब मूल्यांक उन्हें बताये गये तो वे सामान्य थे जबकि काम में उनकी दक्षता बहुत अच्छी थी, तो उनके प्रबंधन ने उन्हें बोला कि  जाओ पहले अपना चेहरा शीशे में देखकर आओ, तो उसे मजाक लगा। परंतु प्रबंधन ने उन्हें कहा कि यह मजाक नहीं है, तो वह प्रोग्रामर शीशे में चेहरा देखकर आया तो प्रबंधन ने उनसे पूछा कि आपने शीशे में क्या देखा, वह बोला कि कुछ खास नहीं, तब प्रबंधन ने कहा कि आपका सब कुछ ठीक है, एक बात को छोड़कर कि आप आकर्षक नहीं दिखते हैं, आप कभी कभी शेविंग करते हैं, जो कि कंपनी की कार्यशर्तों की प्रमुख शर्तों में एक है, इसलिये आपको साधारण मूल्यांक दिया गया है।
   उस प्रोग्रामर को बाद में शेविंग का महत्व पता लगा और उसे शेविंग न करने का बहुत बड़ा जुर्माना भी अपने कैरियर के एक वर्ष में अच्छे मूल्यांक न मिलने के रूप में सहना पड़ा।
This post is a part of #WillYouShave activity at BlogAdda in association with Gillette
उस प्रोग्रामर ने तत्काल ही फ्लिपकार्ट से शेविंग किट के रूप में कुछ चीजें मँगवा लीं।

किसी भी कार्य को शुरु करने के पहले अपने अवयवों की ऊर्जा को एकत्रित करना होता है।

   मानव ऊर्जा हम जब भी कोई नया कार्य शुरु करते हैं, तो उसके बारे में अच्छे और बुरे दोनों विचार हमारे जहन में कौंधते रहते हैं, हम उस कार्य को किस स्तर पर करने जा रहे हैं और उस कार्य में हमारी कितनी रुचि है, इस बात पर बहुत निर्भर करता है। सोते जागते उठते बैठते कई बार केवल कार्य के बारे में ही सोचना उस कार्य के प्रति रुचि दर्शाता है।

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

    हरेक कार्य के सामाजिक प्रभाव होते हैं, और हरेक कार्य के तकनीकी पहलू होते हैं जो कि मानव जीवन पर बहुत गहन प्रभाव डालते हैं।

    पर सबसे जरुरी चीज है अपने अवयवों की संपूर्ण ऊर्जा एकत्रित करके कार्य की शुरुआत अच्छे से की जाये और उसके अंजाम तक पहुँचाने के लिये भी अपनी संपूर्ण ऊर्जा का उपयोग करना चाहिये।

परियोजना प्रबंधक के लिये ३ बेहतर उपाय, परियोजना लागत ज्यादा न होने के लिये| Not to exceed project cost, Three effective tips for project management.

परियोजना लागत (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 लाइसेंस नहीं है जो कि आपने अपनी परियोजना में शामिल करी हुई है (हालांकि अगर आपने पहले ही होमवर्क किया होता है जिसकी हम पहले चर्चा कर चुके हैं, तो आप इस तरह के संभावित “जाने अनजाने” से बचाव कर सकते हैं)।

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

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

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