विषय 5.1 — परियोजना-नेतृत्व वाला काम

एक वाक्य में: परियोजना-नेतृत्व वाला काम सही उपकरण है जब काम का एक परिभाषित दायरा, एक परिमित जीवन, और एक स्पष्ट अंतिम स्थिति होती है — एक अस्थायी, नियंत्रित प्रयास जो सहमत समय, लागत, और गुणवत्ता तक दिया जाता है, फिर बंद कर दिया जाता है।

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

सब कुछ एक जीवित सेवा नहीं है। स्वास्थ्य और देखभाल में सबसे महत्वपूर्ण काम में से कुछ वास्तव में परिमित है: एक इलेक्ट्रॉनिक रोगी रिकॉर्ड से दूसरे में माइग्रेट करना, एक अस्पताल संपत्ति में Wi-Fi रोल आउट करना, जीवन-के-अंत सर्वर बदलना, एक आपूर्तिकर्ता अनुबंध समाप्त होने से पहले एक विरासत सिस्टम को डीकमीशन करना, या एक नए अस्पताल निर्माण के डिजिटल तत्व को देना। इस काम की एक शुरुआत, एक मध्य, और एक निश्चित अंत है। इसे एक ओपन-एंडेड उत्पाद के रूप में प्रबंधित करना पैसे बर्बाद करेगा और जवाबदेही को धुंधला करेगा; इसे एक परियोजना के अनुशासन की आवश्यकता है।

परियोजना प्रबंधन यहां ठीक-ठीक इसलिए अपना स्थान अर्जित करता है क्योंकि दांव ऊंचे हैं और बाधाएं कठोर हैं। एक डेटा-माइग्रेशन कटओवर का एक निश्चित गो-लाइव सप्ताहांत है, यदि रिकॉर्ड खो जाते या भ्रष्ट हो जाते हैं तो एक रोगी-सुरक्षा जोखिम, और यदि पुराना सिस्टम बंद हो जाता है तो एक संविदात्मक चट्टान-किनारा है। सार्वजनिक धन एक व्यावसायिक मामले के विरुद्ध प्रतिबद्ध है, और संसद, ऑडिटर, और बोर्ड पूछेंगे कि क्या इसे अनुमोदित के रूप में खर्च किया गया। परियोजना-नेतृत्व वाला काम प्रशासन प्रदान करता है — एक व्यावसायिक मामला, चरण द्वार, और एक नियंत्रित समापन — जो एक बोर्ड को आत्मविश्वास से पूंजी प्रतिबद्ध करने देता है और यदि औचित्य दूर हो जाता है तो काम को साफ़ तरीके से रोकने देता है।

खतरा गलत काम के लिए इस उपकरण का उपयोग करना है। एक विकसित होती डिजिटल सेवा पर लागू परियोजना-नेतृत्व वाला प्रशासन "इसे बनाएं और इसे छोड़ दें" विकृति उत्पन्न करता है जो विषय 5.0 — उत्पाद-नेतृत्व वाला काम में वर्णित है। यह विषय बताता है कि परियोजना-नेतृत्व वाला काम कहां सही उपकरण है, और इसकी सीमाएं कहां शुरू होती हैं। यह विषय 5.2 — कार्यक्रम-नेतृत्व वाला काम के साथ बैठता है, जो कई परियोजनाओं का समन्वय करता है, और विषय 5.3 — एंटरप्राइज़ पोर्टफोलियो और परियोजना प्रबंधन (EPPM), जो इन उपकरणों के बीच चुनाव करता है।

मुख्य अवधारणाएं#

परियोजना। एक अस्थायी संगठन जो समय, लागत, और गुणवत्ता की बाधाओं के भीतर एक सहमत विनिर्देश में एक या अधिक परिभाषित आउटपुट देने के लिए बनाया गया है। परिभाषित विशेषता यह है कि यह अस्थायी है — यह एक परिभाषित अंत तक पहुंचने और फिर भंग होने के लिए मौजूद है।

लौह त्रिकोण (दायरा, समय, लागत)। शास्त्रीय बाधा मॉडल: दायरा, समयसारिणी, और बजट परस्पर निर्भर हैं, और गुणवत्ता इस बात से प्रभावित होती है कि उन्हें कैसे संतुलित किया जाता है। एक को बदलें और आप दूसरों को बदलते हैं; परियोजना नियंत्रण काफी हद तक इस व्यापार को पारदर्शी रूप से प्रबंधित करने का अनुशासन है।

PRINCE2 (PRojects IN Controlled Environments)। UK सरकार की संरचित परियोजना पद्धति, NHS और सार्वजनिक क्षेत्र में व्यापक रूप से उपयोग की जाती है। यह सिद्धांतों पर बनी है (निरंतर व्यावसायिक औचित्य, परिभाषित भूमिकाएं, चरणों द्वारा प्रबंधन, अपवाद द्वारा प्रबंधन, उत्पादों पर ध्यान, अनुभव से सीखना, वातावरण के अनुरूप ढालना) और काम को एक परियोजना बोर्ड द्वारा दिशा प्रदान करते हुए नियंत्रित चरणों में व्यवस्थित करती है।

PMI / PMBOK। Project Management Institute का Guide to the Project Management Body of Knowledge प्रमुख अंतरराष्ट्रीय समकक्ष है, परियोजना काम को एक निर्धारित चरणबद्ध प्रक्रिया के बजाय प्रदर्शन डोमेन और सिद्धांतों के आसपास फ्रेम करता है। PRINCE2 और PMBOK एक ही अनुशासन पर पूरक लेंस हैं।

व्यावसायिक मामला। वह दस्तावेज़ जो परियोजना को न्यायोचित ठहराता है: समस्या, मूल्यांकित विकल्प, अपेक्षित लाभ, लागत, और जोखिम। PRINCE2 में व्यावसायिक मामला जीवित है — इसे हर चरण सीमा पर जांचा जाता है, और यदि निरंतर औचित्य गायब हो जाता है, तो सही निर्णय रुकना है। UK सार्वजनिक निकायों में यह आमतौर पर HM Treasury के Five Case Model (रणनीतिक, आर्थिक, वाणिज्यिक, वित्तीय, प्रबंधन) के रूप में संरचित है।

चरण द्वार। एक PRINCE2 परियोजना निर्णय द्वारों से अलग किए गए प्रबंधन चरणों में विभाजित होती है। हर सीमा पर परियोजना बोर्ड एक जानबूझकर रोक/आगे बढ़ें निर्णय लेता है: यह प्रगति और व्यावसायिक मामले की समीक्षा करता है, अगले चरण की योजना को अनुमोदित करता है, और केवल उस चरण के लिए संसाधन प्रतिबद्ध करता है। यही है कि एक बोर्ड कैसे नियंत्रण बनाए रखता है और खराब के बाद अच्छा पैसा फेंकने से बचता है।

RAID लॉग। जोखिम, धारणाओं, मुद्दों, और निर्भरताओं का एक एकल रजिस्टर — परियोजना प्रबंधक की मुख्य नियंत्रण कलाकृति। RAID अनिश्चितता को दृश्यमान और प्रबंधनीय बनाता है: जोखिम वे चीज़ें हैं जो हो सकती हैं, मुद्दे वे चीज़ें हैं जो हुई हैं, धारणाएं वे हैं जिन पर योजना निर्भर करती है, और निर्भरताएं वे हैं जिनकी योजना को कहीं और से आवश्यकता है।

सर्वोत्तम प्रथाएं#

1. एक ईमानदार व्यावसायिक मामले से शुरू करें और इसे जीवित रखें। एक पूर्व-निर्धारित उत्तर के बजाय वास्तविक विकल्पों का मूल्यांकन करने के लिए एक मान्यता प्राप्त संरचना (UK सार्वजनिक निकायों में Five Case Model) का उपयोग करें। फिर व्यावसायिक मामले को हर चरण द्वार पर समीक्षित एक जीवित दस्तावेज़ मानें — निरंतर व्यावसायिक औचित्य पहला PRINCE2 सिद्धांत है, और इसे खोना रुकने का एक वैध कारण है।

2. दायरे को सटीक रूप से परिभाषित करें और इसमें परिवर्तनों को नियंत्रित करें। एक परियोजना का मूल्य "पूर्ण" की एक स्पष्ट, सीमित परिभाषा है। दायरे पर सहमत हों, इसे बेसलाइन करें, और हर प्रस्तावित परिवर्तन को एक परिवर्तन-नियंत्रण प्रक्रिया के माध्यम से चलाएं ताकि दायरा रेंगना चुपचाप बजट और समयरेखा का उपभोग न करे।

3. वास्तविक निर्णय द्वारों के साथ चरणों द्वारा प्रबंधन करें। काम को प्रबंधन चरणों में तोड़ें और हर सीमा पर एक वास्तविक रोक/आगे बढ़ें समीक्षा रखें। एक द्वार जो हमेशा "आगे बढ़ें" कहता है थिएटर है; अनुशासन केवल तभी काम करता है जब रुकना या फिर से योजना बनाना एक वास्तविक विकल्प है जिसे बोर्ड प्रयोग करेगा।

4. एक लाइव RAID लॉग चलाएं और अपवाद द्वारा बढ़ाएं। एक जगह में जोखिम, धारणाओं, मुद्दों, और निर्भरताओं को बनाए रखें, इसे नियमित रूप से समीक्षा करें, और PRINCE2 के "अपवाद द्वारा प्रबंधन" का उपयोग करें — परियोजना प्रबंधक सहमत सहनशीलता के भीतर चलता है और केवल तभी बोर्ड तक बढ़ाता है जब एक सहनशीलता को खतरा हो। यह वरिष्ठ समय को वास्तविक निर्णयों पर केंद्रित रखता है।

5. स्पष्ट, एकल-बिंदु जवाबदेही असाइन करें। PRINCE2 परिभाषित भूमिकाओं पर ज़ोर देता है: एक परियोजना बोर्ड जिसमें व्यावसायिक मामले का स्वामी एक वरिष्ठ जिम्मेदार स्वामी/कार्यकारी, आउटपुट का उपयोग करने वालों का प्रतिनिधित्व करने वाला एक वरिष्ठ उपयोगकर्ता, और एक वरिष्ठ आपूर्तिकर्ता है। अस्पष्ट जवाबदेही बहाव का सबसे आम कारण है।

6. शुरू करने से पहले लाइव सेवा में संक्रमण की योजना बनाएं। एक परियोजना एक आउटपुट देती है; किसी को बाद में इसे संचालित करना चाहिए। परियोजना के हिस्से के रूप में प्राप्त करने वाली टीम, समर्थन मॉडल, और क्लिनिकल-सुरक्षा हैंडओवर (तैनाती के लिए DCB0160) पर सहमत हों, ताकि गो-लाइव एक स्वामित्व शून्य में चट्टान-किनारा न हो।

7. क्लिनिकल सुरक्षा, सूचना प्रशासन, और परीक्षण को बेक करें। रोगी डेटा को छूने वाले किसी भी सिस्टम के लिए, क्लिनिकल सुरक्षा मामला, DPIA, और कटओवर/रोलबैक परीक्षण वैकल्पिक अतिरिक्त नहीं हैं — वे गेटिंग डिलीवरेबल हैं। परीक्षित रोलबैक योजना के बिना एक माइग्रेशन लाइव जाने के लिए तैयार नहीं है।

8. परियोजना को जानबूझकर बंद करें और सबक कैप्चर करें। एक परिभाषित अंत का अर्थ है एक परिभाषित समापन: पुष्टि करें कि आउटपुट स्वीकार किए गए हैं, संचालन को सौंपें, टीम को रिलीज़ करें, और सीखे गए सबक रिकॉर्ड करें (PRINCE2 का लेसन लॉग)। एक अबंद परियोजना अनिश्चित काल तक संसाधन और जवाबदेही लीक करती है।

आपकी टीम के साथ चर्चा करने के लिए प्रश्न#

1. क्या हमारे सामने का काम एक परिभाषित अंतिम स्थिति के साथ वास्तव में परिमित है, या क्या हम परियोजना प्रशासन के लिए पहुंच रहे हैं क्योंकि यह वह वित्तपोषण मार्ग है जिसे हम जानते हैं? यह निर्णायक प्रश्न है जिस पर विषय घूमता है, क्योंकि परियोजना-नेतृत्व वाला अनुशासन केवल तभी सही उपकरण है जब काम की वास्तव में एक शुरुआत, एक मध्य, और एक निश्चित अंत होता है। एक स्वास्थ्य और देखभाल संगठन में परियोजना आकार की ओर खिंचाव मज़बूत है — पूंजी बजटिंग, व्यावसायिक-मामला मशीनरी, और बोर्ड रिपोर्टिंग सभी इसके लिए बनाए गए हैं — इसलिए एक विकसित होती डिजिटल सेवा को केवल इसलिए एक परियोजना के रूप में तैयार किया जा सकता है क्योंकि पैसा इसी तरह जारी किया जाता है, जो तब निर्माण-और-परित्याग विकृति पैदा करता है। बहस को हर उम्मीदवार को ईमानदारी से जांचना चाहिए: एक पैथोलॉजी सिस्टम प्रतिस्थापन एक आपूर्तिकर्ता के समर्थन वापस लेने से पहले एक कठोर संविदात्मक चट्टान-किनारा है और निस्संदेह परिमित है, जबकि "रोगी ऐप में सुधार करें" की कोई अंतिम स्थिति नहीं है और यह विषय 5.0 से संबंधित है। विचार करें कि क्या एक वास्तविक गो-लाइव है जिसके बाद टीम को भंग होना चाहिए, या क्या किसी को अनिश्चित काल तक चीज़ को सुधारते रहने की आवश्यकता होगी। एक अच्छा उत्तर एक आदत के रूप में परियोजना प्रशासन का उपयोग करने का विरोध करता है, ठोस अंतिम स्थिति और उस घटना को नाम देता है जो "पूर्ण" को परिभाषित करती है, और यह कहने के लिए तैयार है कि हम वर्तमान में जो कुछ परियोजनाओं के रूप में चलाते हैं वह वास्तव में कभी परियोजनाएं नहीं होनी चाहिए थीं।

2. हमारे चरण द्वारों पर, क्या यह बोर्ड वास्तव में एक परियोजना को रोकेगा या फिर से योजना बनाएगा जिसने अपना औचित्य खो दिया है — और क्या हम एक ऐसे समय की ओर इशारा कर सकते हैं जब हमने ऐसा किया? चरण द्वार केवल तभी एक नियंत्रण हैं जब रुकना बोर्ड के लिए एक वास्तविक विकल्प है जिसे वह प्रयोग करेगा; एक द्वार जो हमेशा "आगे बढ़ें" कहता है थिएटर है, और निरंतर व्यावसायिक औचित्य पहला PRINCE2 सिद्धांत ठीक-ठीक इसलिए है क्योंकि इसे खोना काम को समाप्त करना चाहिए। स्वास्थ्य और देखभाल में तनाव तीव्र है: एक आंशिक-निर्मित EPR माइग्रेशन या एक प्रयोगशाला-सिस्टम कटओवर को रोकना विफलता स्वीकार करने, डूबी हुई लागत बर्बाद करने, और उन क्लिनिशियनों को बाधित करने जैसा महसूस होता है जिन्होंने पहले ही अपनी योजनाएं बदल दी हैं, इसलिए बोर्ड आगे बढ़ने को तर्कसंगत बनाते हैं भले ही व्यावसायिक मामला चुपचाप वाष्पित हो जाए। चर्चा में एक वास्तविक उदाहरण लाएं — एक परियोजना जहां परीक्षण ने प्रकट किया कि डेटा-मैपिंग जोखिम मान्यता से बदतर था, या जहां लाभ फिसल गए — और पूछें कि क्या द्वार को डिज़ाइन के अनुसार उपयोग किया गया था या रबर-स्टैम्प किया गया। विचार करें कि कौन सी सहनशीलताएं वृद्धि को ट्रिगर करती हैं, बोर्ड में किसकी रोकने की स्थिति है, और क्या डूबी-लागत तर्क को कमरे में नाम दिया और चुनौती दी जाती है। एक ईमानदार उत्तर स्वीकार करता है कि द्वार कहां औपचारिकताएं रहे हैं, उन स्थितियों का वर्णन करता है जिनके तहत बोर्ड वास्तव में रुकेगा या फिर से दायरा तय करेगा, और एक सार्वजनिक राइट-ऑफ से पहले रुकने के अधिकार को एक धमकी के बजाय अनुशासन के वास्तविक मूल्य के रूप में मानता है।

3. हर परियोजना का आउटपुट एक लाइव सेवा के रूप में कौन प्राप्त करता है, और हम क्लिनिकल-सुरक्षा हैंडओवर और चालू स्वामित्व को एक चट्टान-किनारे के बजाय एक गेटिंग डिलीवरेबल कैसे बनाते हैं? एक परियोजना एक आउटपुट देती है; कुछ परिमित समाप्त होता है, लेकिन इसने जो उत्पन्न किया उसे टीम के भंग होने के बहुत बाद तक संचालित, सुधार, और सुरक्षित रखा जाना चाहिए — और सबसे आम मौन विफलता यह है कि दूसरी तरफ कोई इसका स्वामित्व नहीं रखता। रोगी डेटा को छूने वाले एक सिस्टम में यह प्रशासनिक सफ़ाई नहीं है: DCB0160 तैनाती सुरक्षा मामला, DPIA, एक परीक्षित रोलबैक, और एक नामित प्राप्त करने वाली टीम वे हैं जो एक नियंत्रित गो-लाइव और एक स्वामित्व शून्य के बीच खड़े हैं जहां सुरक्षा जोखिम अप्रबंधित जमा होते हैं। बहस को परियोजना शुरू होने से पहले संक्रमण के बारे में स्पष्टता मजबूर करनी चाहिए, गो-लाइव सप्ताहांत पर नहीं: कौन सी परिचालन टीम इसे लेती है, समर्थन मॉडल क्या है, और क्या उस टीम के पास इसे सुधारते रहने की क्षमता और काम करने का तरीका है (उत्पाद-नेतृत्व वाला, विषय 5.0 के अनुसार)। ठोस हालिया गो-लाइव पर विचार करें और क्या हैंडओवर की योजना बनाई गई थी या तात्कालिक थी, और क्या "परियोजना पूर्ण है" को "और अब यह किसी का काम नहीं है" का अर्थ रखने की अनुमति दी गई थी। एक अच्छा उत्तर पहले से प्राप्त करने वाली टीम और समर्थन मॉडल को नाम देता है, सुरक्षा हैंडओवर को एक द्वार मानता है जिसके बिना परियोजना पास नहीं हो सकती, और स्पष्ट रूप से लाइव सेवा के चालू सुधार को इसे बहने देने के बजाय काम करने के सही तरीके को असाइन करता है।

4. जब लौह त्रिकोण काटता है और दायरा, समय, और लागत टकराते हैं, तो हम कौन सी बाधा लचीली बनाते हैं, और क्या रोगी सुरक्षा को कभी वह चर बनने की अनुमति है जो देता है? हर वास्तविक परियोजना अंततः उस क्षण से टकराती है जहां समयसारिणी, बजट, और वादा किया गया दायरा सभी टिक नहीं सकते, और टीम उस निचोड़ को कैसे हल करती है यह प्रकट करता है कि यह वास्तव में क्या महत्व देती है। स्वास्थ्य और देखभाल में जाल विशिष्ट है: क्योंकि अंत तिथि अक्सर एक कठोर संविदात्मक चट्टान-किनारा है — एक आपूर्तिकर्ता समर्थन वापस ले रहा है, एक पट्टा समाप्त हो रहा है, एक डेटा-सेंटर बंद हो रहा है — समय अक्सर हिल नहीं सकता, इसलिए दबाव चुपचाप गुणवत्ता पर उतरता है, जिसका एक क्लिनिकल सिस्टम में अर्थ है परीक्षण काटना, सत्यापन संकुचित करना, या ज्ञात डेटा-मैपिंग दोषों के साथ शिपिंग करना। चर्चा को पहले से नाम देना चाहिए कि संगठन त्रिकोण के किस कोने की रक्षा करेगा और किसे बलिदान करेगा, और स्पष्ट रहें कि क्लिनिकल सुरक्षा और सूचना प्रशासन रिलीज़ वाल्व नहीं हैं भले ही बाकी सब कुछ निश्चित हो। एक हालिया कटओवर को देखें और पूछें कि जब तारीखें टिकीं तो चुपचाप क्या दिया: क्या यह रोलबैक पूर्वाभ्यास था, क्लिनिकल-सत्यापन विंडो, प्रशिक्षण? विचार करें कि सुरक्षा मार्जिन को क्षय करने के बजाय गो-लाइव तारीख को स्थानांतरित करने का अधिकार किसके पास है, और क्या वह बातचीत बोर्ड में खुले तौर पर होती है या ज़मीन पर डिफ़ॉल्ट रूप से। एक ईमानदार उत्तर क्रंच से पहले प्राथमिकता क्रम बताता है, एक फिसली हुई तारीख या एक फिर से योजनाबद्ध चरण को एक वैध परिणाम मानता है, और अनकहे समयसारिणी दबाव को अनलॉग किए गए क्लिनिकल जोखिम में बदलने से इनकार करता है।

5. क्या हमारा RAID लॉग एक लाइव उपकरण है जो बदलता है कि हम क्या करते हैं, या एक दस्तावेज़ जिसे हम शासित दिखने के लिए बनाए रखते हैं — और क्या यह उस जोखिम को सतह पर लाएगा जो वास्तव में परियोजना को डुबोता है? एक RAID लॉग केवल तभी अपना स्थान अर्जित करता है जब इसकी समीक्षा निर्णय बदलती है; आम विकृति एक ऐसा रजिस्टर है जो किकऑफ पर लिखा जाता है, बोर्डों में प्रस्तुत किया जाता है, और कभी वास्तव में कार्य नहीं किया जाता जबकि मायने रखने वाले जोखिम अनदेखे परिपक्व होते हैं। एक माइग्रेशन या कटओवर में निर्णायक जोखिम अक्सर विशिष्ट और ज्ञात होते हैं — ऐतिहासिक परिणाम जो नई संदर्भ सीमाओं में साफ़ तरीके से मैप नहीं होंगे, दूसरी टीम के फ़ायरवॉल परिवर्तनों पर एक निर्भरता, एक धारणा कि क्लिनिकल सत्यापन संसाधन आवश्यकता होने पर मुक्त होगा — और प्रश्न यह है कि क्या लॉग उन्हें ठोस रूप से नाम देता है या "संसाधन बाधाओं" जैसी सामान्य प्रविष्टियों के पीछे छुपता है। बहस को यह परीक्षण करना चाहिए कि क्या अपवाद द्वारा वृद्धि वास्तविक है: क्या परियोजना प्रबंधक सहमत सहनशीलता के भीतर चलता है और केवल तभी बोर्ड का ध्यान बढ़ाता है जब एक को खतरा हो, या क्या सब कुछ या तो मौन रहता है या एक संकट बन जाता है? विचार करें कि क्या नज़दीकी-चूकें और साकार हुए मुद्दे इस बारे में वापस फीड करते हैं कि अगले चरण की योजना कैसे बनाई जाती है, या केवल लॉग और भुला दी जाती हैं। एक अच्छा उत्तर एक निर्णय की ओर इशारा कर सकता है जिसे RAID लॉग ने वास्तव में बदला, उन दो या तीन जोखिमों को अलग करता है जो वास्तव में परियोजना को रोक सकते हैं छोटे लोगों की लंबी पूंछ से, और लॉग को आश्वासन के लिए उत्पन्न एक कलाकृति के बजाय एक कार्यशील नियंत्रण मानता है।

6. हमारे बंद होने और भंग होने के बाद, क्या कोई जांच करता है कि व्यावसायिक मामले में लाभ वास्तव में साकार हुए — और क्या हमें पता चलेगा कि यदि वे नहीं हुए? व्यावसायिक मामला खर्च को न्यायोचित ठहराने के लिए लाभों का वादा करता है, लेकिन परियोजना-नेतृत्व वाला काम स्वाभाविक रूप से गो-लाइव और टीम रिलीज़ पर समाप्त होता है, इसलिए सच्चाई का क्षण — क्या माइग्रेशन ने वास्तव में जोखिम कम किया, लागत काटी, या देखभाल में सुधार किया — आमतौर पर हर किसी के आगे बढ़ने के बाद गिरता है और कोई इसकी पुष्टि करने के लिए जवाबदेह नहीं है। यह सार्वजनिक स्वास्थ्य और देखभाल में तीव्रता से मायने रखता है, जहां पैसा एक Five Case व्यावसायिक मामले के विरुद्ध प्रतिबद्ध है जिसे संसद, ऑडिटरों, और बोर्डों को बताया गया था कि यह विशिष्ट परिणाम देगा, फिर भी लाभ साकारीकरण वह कदम है जिसे सबसे अधिक बार छोड़ा जाता है क्योंकि परियोजना जिसने इसका स्वामित्व लिया होता अब मौजूद नहीं है। चर्चा को तय करना चाहिए कि परियोजना बंद होने पर लाभ ट्रैकिंग कौन विरासत में लेता है, किस अवधि में, और किन बेसलाइन मापों के विरुद्ध — जिन्हें गो-लाइव से पहले कैप्चर किया जाना चाहिए अन्यथा वे खो जाते हैं। एक हालिया पूर्ण परियोजना पर विचार करें और सीधे पूछें कि क्या किसी ने तब से इसके वादा किए गए लाभों की जांच की है, और क्या एक कमी कभी उस बोर्ड तक पहुंचेगी जिसने इसे अनुमोदित किया था। एक ईमानदार उत्तर भंग की गई टीम के बजाय एक स्थायी फ़ंक्शन को समापन-बाद लाभ स्वामित्व असाइन करता है, परियोजना अभी भी लाइव होने पर बेसलाइन कैप्चर करता है, और यह रिकॉर्ड करने के लिए तैयार है कि एक परियोजना ने समय पर और बजट पर अपना आउटपुट दिया फिर भी वह मूल्य नहीं दिया जिसने इसे न्यायोचित ठहराया।

व्यवहार में: एक स्वास्थ्य और देखभाल उदाहरण#

एक तीव्र ट्रस्ट को अपने वृद्ध पैथोलॉजी प्रयोगशाला सूचना प्रबंधन सिस्टम को मौजूदा आपूर्तिकर्ता के 14 महीनों में समर्थन वापस लेने से पहले बदलना होगा। यह पाठ्यपुस्तक परियोजना-नेतृत्व वाला काम है: निश्चित अंत तिथि, परिभाषित दायरा, एक कठोर संविदात्मक चट्टान-किनारा, और यदि माइग्रेशन में परिणाम खो जाते हैं तो तीव्र रोगी-सुरक्षा जोखिम।

ट्रस्ट तीन विकल्पों (जगह पर अपग्रेड, एक नया सिस्टम खरीदना, एक क्षेत्रीय इंस्टेंस साझा करना) का मूल्यांकन करते हुए एक Five Case व्यावसायिक मामला लिखता है, खरीद चुनता है, और एक स्पष्ट बोर्ड के साथ एक PRINCE2 परियोजना खड़ी करता है: व्यावसायिक मामले का स्वामी एक कार्यकारी, एक वरिष्ठ उपयोगकर्ता (मुख्य बायोमेडिकल वैज्ञानिक), और वरिष्ठ आपूर्तिकर्ता। काम को प्रबंधन चरणों में विभाजित किया गया है — खरीद, बिल्ड और कॉन्फ़िगरेशन, डेटा माइग्रेशन, परीक्षण, और गो-लाइव — हर एक एक निर्णय द्वार में समाप्त होता है।

परियोजना प्रबंधक एक RAID लॉग चलाता है। एक मुख्य जोखिम यह है कि ऐतिहासिक परिणाम नए सिस्टम की संदर्भ सीमाओं में साफ़ तरीके से मैप नहीं हो सकते; एक निर्भरता नेटवर्क टीम के फ़ायरवॉल परिवर्तन हैं; एक धारणा यह है कि क्लिनिकल सत्यापन संसाधन परीक्षण के लिए उपलब्ध होगा। माइग्रेशन चरण द्वार पर, परीक्षण प्रकट करता है कि डेटा-मैपिंग जोखिम मान्यता से बदतर है, इसलिए बोर्ड द्वार का उपयोग डिज़ाइन के अनुसार करता है: यह अंधाधुंध आगे नहीं बढ़ता, बल्कि एक विस्तारित सत्यापन विंडो और एक परीक्षित रोलबैक योजना के साथ एक फिर से योजनाबद्ध चरण को अनुमोदित करता है, मूल समयसारिणी से ऊपर रोगी सुरक्षा की रक्षा करते हुए।

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

क्षेत्र दृष्टिकोण#

स्टार्टअप#

एक छोटी डिजिटल-स्वास्थ्य कंपनी शायद ही कभी औपचारिक PRINCE2 परियोजनाएं चलाती है, लेकिन वास्तव में परिमित काम अभी भी दिखाई देता है — एक नए क्लाउड प्लेटफ़ॉर्म पर एक-बार का डेटा माइग्रेशन, एक Cyber Essentials या DTAC प्रमाणन पुश, एक बड़े NHS अनुबंध से पहले पेन-टेस्ट सुधार। स्टार्टअप इन्हें हल्के, समय-सीमित प्रयासों के रूप में एक नामित स्वामी और पूर्ण की एक स्पष्ट परिभाषा के साथ संभालता है, अनुशासन (निश्चित दायरा, एक अंत तिथि, एक जाओ/न-जाओ) उधार लेते हुए समारोह के बिना (कोई औपचारिक परियोजना बोर्ड नहीं, कोई पांच-चरण गेटिंग नहीं)। वित्तपोषण वास्तव में संस्थापक ध्यान और रनवे है, इसलिए जोखिम यह है कि परिमित काम उत्पाद स्प्रिंट के बीच निचोड़ा जाता है और वास्तव में कभी बंद नहीं होता। सुधार एक एकल स्वामी और एक कठोर समय सीमा को नाम देना है, और प्रमाणन या माइग्रेशन को स्थायी रूप से "प्रगति में" के बजाय पूर्ण-और-हो-गया मानना है।

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम, या एक एकल-साइट क्लिनिक — परियोजना-नेतृत्व वाले काम से कभी-कभार लेकिन अपरिहार्य घटनाओं के रूप में मिलता है: क्लिनिकल सिस्टम आपूर्तिकर्ता बदलना, एक नए प्रैक्टिस-प्रबंधन प्लेटफ़ॉर्म में माइग्रेट करना, या समर्थन समाप्त होने से पहले जीवन-के-अंत डिवाइस बदलना। संगठन के पास वास्तविक रोगी और चालू संचालन हैं लेकिन कोई समर्पित परियोजना या IT फ़ंक्शन नहीं है, इसलिए "परियोजना टीम" आमतौर पर प्रैक्टिस मैनेजर या एक पंजीकृत मैनेजर होता है जो दिन की नौकरी के साथ यह करता है, अक्सर माइग्रेशन चलाने के लिए आने वाले आपूर्तिकर्ता पर झुकते हुए। जो अनुशासन इस वास्तविकता के संपर्क में जीवित रहता है वह हल्का मूल है: एक स्पष्ट अंतिम स्थिति, एक बेसलाइन किया गया दायरा ताकि आपूर्तिकर्ता इसे चुपचाप विस्तारित न करे, एक नामित जवाबदेह व्यक्ति, और रोगी रिकॉर्ड को छूने वाले किसी भी कटओवर से पहले एक परीक्षित रोलबैक। जाल केवल काम को नहीं बल्कि निर्णय को भी आउटसोर्स करना है — स्वतंत्र जांच के बिना आपूर्तिकर्ता की गो-लाइव तारीख और डेटा-मैपिंग आश्वासनों को स्वीकार करना — क्योंकि वही क्लिनिकल-सुरक्षा और सूचना-प्रशासन कर्तव्य (DCB0160, एक DPIA) लागू होते हैं संगठन चाहे जितना भी छोटा हो। सुधार जाओ/न-जाओ निर्णय और स्वीकृति मानदंडों का स्वामित्व इन-हाउस रखना है, भले ही बाकी हर हाथ आपूर्तिकर्ता का हो।

बड़ा संगठन#

एक बड़ा NHS ट्रस्ट या integrated care system (ICS) वह जगह है जहां परियोजना-नेतृत्व वाला काम सबसे अधिक घर जैसा है: EPR प्रतिस्थापन, संपत्ति-व्यापी Wi-Fi, डेटा-सेंटर निकास, और कटओवर सभी कठोर संविदात्मक और रोगी-सुरक्षा चट्टान-किनारे रखते हैं। यहां पूरा उपकरण न्यायोचित है — एक Five Case व्यावसायिक मामला, एक नामित कार्यकारी/SRO के साथ एक PRINCE2 बोर्ड, वरिष्ठ उपयोगकर्ता और वरिष्ठ आपूर्तिकर्ता, वास्तविक द्वारों के साथ प्रबंधन चरण, और एक लाइव RAID लॉग — क्योंकि रकम बड़ी है, सुरक्षा उजागरता तीव्र है, और आंतरिक ऑडिट और बोर्ड खर्च की जांच करेंगे। इस पैमाने पर विशिष्ट विफलता एक ही प्रशासन को जीवित सेवाओं (विषय 5.0 — उत्पाद-नेतृत्व वाला काम) और परिमित काम पर अंधाधुंध लागू करना है, इसलिए एक पोर्टफोलियो दृष्टिकोण (विषय 5.3 — एंटरप्राइज़ पोर्टफोलियो और परियोजना प्रबंधन) जो काम के हर टुकड़े को सही मोड में रूट करता है मायने रखता है। क्लिनिकल सुरक्षा (DCB0160) और एक परीक्षित रोलबैक गेटिंग डिलीवरेबल हैं, वैकल्पिक अतिरिक्त नहीं।

सरकार#

राष्ट्रीय या प्रमुख-परियोजना पैमाने पर, परियोजना-नेतृत्व वाला काम सरकार की आश्वासन व्यवस्था के अंदर बैठता है: Infrastructure and Projects Authority गेटवे समीक्षाएं चलाता है, HM Treasury की Green Book और Five Case Model व्यावसायिक मामले को शासित करती है, और सबसे बड़ी परियोजनाएं संसद और National Audit Office के प्रति प्रकाशित जवाबदेही के साथ Government Major Projects Portfolio में प्रवेश करती हैं। जवाबदेही तीव्रता से सार्वजनिक है — वरिष्ठ जिम्मेदार स्वामी व्यक्तिगत रूप से जवाबदेह है और एक चयन समिति के सामने बुलाया जा सकता है — इसलिए चरण द्वार और विकल्प मूल्यांकन वैधानिक-श्रेणी नियंत्रण हैं, थिएटर नहीं। वित्तपोषण अनुमोदित व्यावसायिक मामलों के विरुद्ध किश्त-दर-किश्त जारी किया जाता है और जोखिम भूख कम है, क्योंकि विफलता फ्रंट-पेज समाचार बन जाती है। यहां अनुशासन का वास्तविक मूल्य एक असफल परियोजना को एक सार्वजनिक राइट-ऑफ बनने से पहले रोकने या फिर से दायरा तय करने का अधिकार है।

सामान्य विफलता मोड#

• एक विकसित होती सेवा को परियोजना-प्रबंधन करना। एक जीवित डिजिटल उत्पाद पर निश्चित-दायरा, अंत-में-भंग प्रशासन लागू करना परित्याग विकृति पैदा करता है। फिक्स: जहां सेवा चालू है वहां उत्पाद-नेतृत्व वाले काम (विषय 5.0) का उपयोग करें।
• वित्तपोषण के लिए एक-बार के टिकट के रूप में व्यावसायिक मामला। पैसा अनलॉक करने के लिए एक बार लिखा गया, फिर कभी फिर से नहीं देखा गया। फिक्स: हर चरण द्वार पर इसकी समीक्षा करें; रुकने के लिए तैयार रहें।
• रबर-स्टैम्प चरण द्वार। द्वार जो कभी "रुको" नहीं कहते कोई नियंत्रण प्रदान नहीं करते। फिक्स: रुकने या फिर से योजना बनाने को एक वास्तविक बोर्ड विकल्प बनाएं और इसका उपयोग करें।
• कोई परिवर्तन नियंत्रण के बिना दायरा रेंगना। अनियंत्रित जोड़ समय और लागत को उड़ा देते हैं। फिक्स: दायरे को बेसलाइन करें और हर परिवर्तन को परिवर्तन नियंत्रण के माध्यम से रूट करें।
• कोई सेवा-में-संक्रमण योजना नहीं। परियोजना समाप्त होती है और कोई आउटपुट का स्वामित्व नहीं लेता। फिक्स: गो-लाइव से पहले प्राप्त करने वाली टीम और समर्थन मॉडल पर सहमत हों।
• एक फाइलिंग कैबिनेट के रूप में RAID। एक लॉग जो लिखा जाता है और कभी उस पर कार्य नहीं किया जाता। फिक्स: RAID को नियमित रूप से समीक्षा करें और अपवाद द्वारा बढ़ाएं।
• वास्तव में कभी बंद न होना। ज़ोंबी परियोजनाएं जो बिना किसी अंत के संसाधन का उपभोग करती हैं। फिक्स: स्वीकृति, हैंडओवर, और कैप्चर किए गए सबक के साथ एक जानबूझकर समापन।

परिपक्वता मॉडल#

जांच-सूची#

• क्या काम एक परिभाषित दायरे और अंतिम स्थिति (एक चालू सेवा नहीं) के साथ वास्तव में परिमित है?
• क्या हर चरण द्वार पर समीक्षित एक जीवित व्यावसायिक मामला (Five Case Model) है?
• क्या दायरा एक कार्यशील परिवर्तन-नियंत्रण प्रक्रिया के साथ बेसलाइन किया गया है?
• क्या काम के चरण परिभाषित हैं, हर एक एक वास्तविक रोक/आगे बढ़ें निर्णय द्वार में समाप्त होता है?
• क्या परियोजना बोर्ड भूमिकाएं स्पष्ट हैं — कार्यकारी/SRO, वरिष्ठ उपयोगकर्ता, वरिष्ठ आपूर्तिकर्ता?
• क्या एक लाइव RAID लॉग बनाए रखा जाता है, अपवाद द्वारा वृद्धि के साथ?
• क्या क्लिनिकल सुरक्षा (DCB0160), DPIA, और कटओवर/रोलबैक परीक्षण गेटिंग डिलीवरेबल हैं?
• क्या गो-लाइव से पहले प्राप्त करने वाली परिचालन टीम और समर्थन मॉडल पर सहमति है?
• क्या एक जानबूझकर समापन है: स्वीकृति, हैंडओवर, टीम रिलीज़, लॉग किए गए सबक?
• क्या लाइव सेवा के चालू सुधार को काम करने के सही तरीके को असाइन किया गया है?

मुख्य स्रोत#

• AXELOS / PeopleCert — Managing Successful Projects with PRINCE2 (7वां संस्करण) और PRINCE2 सिद्धांत, विषय, और प्रक्रियाएं।
• Project Management Institute (PMI) — A Guide to the Project Management Body of Knowledge (PMBOK Guide) और The Standard for Project Management।
• HM Treasury — Guide to Developing the Project Business Case (Five Case Model / Green Book)।
• Infrastructure and Projects Authority (IPA), Cabinet Office — प्रमुख परियोजनाओं के लिए आश्वासन और गेटवे समीक्षा मार्गदर्शन।
• NHS Digital Clinical Safety मानक DCB0160 (स्वास्थ्य IT सिस्टमों की तैनाती)।
• NHS England — NHS Service Manual और Digital Service Standard (सेवा-संक्रमण और उपयोगकर्ता-आवश्यकता संदर्भ के लिए)।

संदर्भ#

1. Project management — Wikipedia — https://en.wikipedia.org/wiki/Project_management
2. PRINCE2 — Wikipedia — https://en.wikipedia.org/wiki/PRINCE2
3. Project management triangle (iron triangle) — Wikipedia — https://en.wikipedia.org/wiki/Project_management_triangle
4. Project Management Institute — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Institute
5. Project Management Body of Knowledge — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
6. Business case — Wikipedia — https://en.wikipedia.org/wiki/Business_case
7. Phase-gate process (stage gates) — Wikipedia — https://en.wikipedia.org/wiki/Phase-gate_process
8. Scope creep — Wikipedia — https://en.wikipedia.org/wiki/Scope_creep
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
11. HM Treasury — Wikipedia — https://en.wikipedia.org/wiki/HM_Treasury
12. Managing Successful Projects with PRINCE2 (7th edition) — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/PRINCE-2-1005
13. A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute — https://www.pmi.org/
14. The Green Book and Guide to Developing the Project Business Case (Five Case Model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
15. Assurance and gateway review guidance for major projects — Infrastructure and Projects Authority, Cabinet Office — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
16. Clinical risk management standard DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety