प्रोजेक्ट मैनेजर इंटरव्यू के सवाल और जवाब (हिंदी में)

मैं पहले सभी activities, उनकी अवधि और dependencies की सूची बनाता हूं और network diagram तैयार करता हूं। Forward pass से हर activity का सबसे जल्दी शुरू और ख़त्म होने का समय निकलता है, और backward pass से सबसे देर वाला। जिन activities में float शून्य होता है, वही critical path है, यानी उनमें एक दिन की देरी पूरे प्रोजेक्ट को एक दिन आगे धकेल देगी। Float बताता है कि किस काम में कितनी ढील है, इसलिए लोगों को ज़रूरत पड़ने पर उन्हीं कामों से हटाकर critical काम पर लगाता हूं।

सबसे पहले मैं पक्का करता हूं कि baseline scope लिखित में हो, यानी signed statement of work और acceptance criteria। जब भी कोई नई मांग आती है, चाहे छोटी लगे, उसे change register में दर्ज करता हूं। फिर टीम के साथ उसका असर देखता हूं: कितना समय, कितनी लागत और किस risk पर फ़र्क पड़ेगा। यह असर क्लाइंट को विकल्पों के साथ बताता हूं, जैसे इसे अगले phase में ले लें या किसी कम ज़रूरी चीज़ से बदल दें। बिना मंज़ूरी के कोई बदलाव टीम तक नहीं पहुंचता।

CPI यानी earned value को actual cost से भाग, और SPI यानी earned value को planned value से भाग। दोनों 0.8 होने का मतलब है कि हर एक रुपये के ख़र्च पर हमें सिर्फ़ अस्सी पैसे का काम मिल रहा है, और योजना का भी सिर्फ़ अस्सी प्रतिशत काम हुआ है। मैं पहले देखूंगा कि गड़बड़ी किन work packages में है और कारण क्या है, जैसे गलत estimate, rework या कम लोग। फिर sponsor को सुधार की योजना और नया forecast दूंगा, ताकि फ़ैसला अंदाज़े पर नहीं, आंकड़ों पर हो।

जहां requirements स्थिर हों और बाद में बदलाव बहुत महंगा पड़े, वहां मैं waterfall चुनता हूं, जैसे ऑफ़िस का fit-out या data centre shift करना। जहां users से feedback लेकर product बार-बार सुधारना हो, वहां agile बेहतर है, क्योंकि छोटे sprint में काम दिखता रहता है। बहुत से प्रोजेक्ट में hybrid ठीक रहता है: hardware या contract वाला हिस्सा तय योजना से, और software वाला हिस्सा sprints में। मेरे लिए असली सवाल यह है कि बदलाव कितना संभावित है और गलती की कीमत कितनी है।

Kickoff पर मैं टीम और मुख्य स्टेकहोल्डर के साथ risk workshop करता हूं। हर risk को कारण, घटना और असर के रूप में लिखता हूं, साथ में probability, impact, एक owner और वह trigger जिसे देखकर हमें कदम उठाना है। जवाब चार तरह के होते हैं: avoid, यानी योजना बदलकर risk हटाना; transfer, जैसे fixed-price contract या insurance; mitigate, यानी संभावना या असर कम करना; और accept, जब कीमत फ़ायदे से ज़्यादा हो। हर हफ़्ते की review में register अपडेट होता है, सिर्फ़ kickoff पर नहीं।

पहले मैं पक्का करूंगा कि देरी critical path पर है, क्योंकि दूसरे कामों की देरी शायद launch पर असर न डाले। फिर दो तरीके देखूंगा। Fast tracking में जो काम एक के बाद एक होने थे, उन्हें कुछ हद तक साथ चलाया जाता है, जैसे design पूरा होने से पहले कुछ development शुरू करना, पर इसमें rework का risk बढ़ता है। Crashing में critical काम पर ज़्यादा लोग या overtime लगाया जाता है, जिससे लागत बढ़ती है। अगर दोनों से भी बात न बने, तो sponsor के साथ scope कम करने पर बात करूंगा।

एक warehouse system rollout में operations head त्योहारी सीज़न से पहले go-live चाहते थे, और finance controller उसके बाद, ताकि month-end पर risk न हो। दोनों की बात में दम था। मैं दोनों से अलग-अलग मिला और उनकी असली चिंता लिखी। फिर एक विकल्प रखा: पहले एक warehouse में pilot, month-end के तुरंत बाद, और बाकी जगह पर सीज़न के बाद। दोनों विकल्पों का risk और फ़ायदा sponsor के सामने रखा। pilot वाला रास्ता मंज़ूर हुआ और rollout बिना बड़ी रुकावट के पूरा हुआ।

एक manufacturing क्लाइंट के payroll system में पुराने system से data migration उम्मीद से बहुत धीमा चल रहा था, क्योंकि कर्मचारियों के records में बहुत गड़बड़ी थी। छठे हफ़्ते तक मुझे साफ़ दिख गया कि migration milestone छूटेगा। मैंने आख़िरी दिन का इंतज़ार नहीं किया। क्लाइंट को उसी हफ़्ते बताया, गड़बड़ी के उदाहरण दिखाए और दो विकल्प रखे: उनकी टीम data साफ़ करने में मदद करे या तारीख़ दो हफ़्ते आगे बढ़े। उन्होंने मदद चुनी और देरी सिर्फ़ एक हफ़्ते की रही।

एक insurance portal प्रोजेक्ट पर एक developer ने लगातार तीन task deadlines छोड़ीं। मैंने stand-up में यह मुद्दा नहीं उठाया, बल्कि उनसे अकेले में बात की और पूछा कि क्या हो रहा है। पता चला कि उन्हें एक पुराने प्रोजेक्ट का support भी दिया गया था, जिसकी जानकारी मुझे नहीं थी। मैंने उनके manager से बात करके वह काम किसी और को दिलवाया, और उनके tasks छोटे हिस्सों में बांटे ताकि रोज़ progress दिखे। अगले sprint से उनका काम समय पर आने लगा।

मैंने कुछ साल प्रोजेक्ट चलाने के बाद PMP किया। सच कहूं तो certificate से मैं रातोंरात बेहतर मैनेजर नहीं बना, लेकिन तैयारी से मुझे एक साझा भाषा मिली और कुछ कमियां भरीं। पहले मैं risk को सिर्फ़ दिमाग़ में ट्रैक करता था, अब हर प्रोजेक्ट में लिखित risk register और owners होते हैं। Earned value का इस्तेमाल भी मैंने उसके बाद ही शुरू किया, जिससे sponsor को progress आंकड़ों में दिखा पाता हूं। आगे मैं agile से जुड़ा certification लेने की सोच रहा हूं।

अभी मैं एक IT services कंपनी में बारह से पंद्रह लोगों की टीम वाले प्रोजेक्ट संभालता हूं, और मेरी current CTC की जानकारी मैं salary slip के साथ दे सकता हूं। इस भूमिका में प्रोजेक्ट बड़े हैं और क्लाइंट की सीधी ज़िम्मेदारी भी है, इसलिए मैं अपनी current CTC से उचित बढ़ोतरी की उम्मीद रखता हूं, जो इस शहर में ऐसी भूमिका के आम दायरे में हो। Fixed और variable का बंटवारा और बाकी benefits देखकर मैं बातचीत के लिए तैयार हूं।

मेरा notice period दो महीने का है। अभी मेरे पास दो प्रोजेक्ट हैं, एक user testing में जाने वाला है और दूसरा शुरुआती planning में। पहले प्रोजेक्ट के लिए मैं योजना, risks, खुले मुद्दे और स्टेकहोल्डर संपर्क लिखकर दूंगा और नए मैनेजर को दो-तीन हफ़्ते अपने साथ meetings में रखूंगा। दूसरे प्रोजेक्ट को सौंपना आसान है, क्योंकि अभी फ़ैसले कम हुए हैं। अगर handover जल्दी पूरा हो जाए तो मैं कंपनी से जल्दी relieve करने का अनुरोध करूंगा।