सीखे गए सबक अगले प्रोजेक्ट को क्यों नहीं बदलते

हर प्रोजेक्ट एक लिस्ट के साथ समाप्त होता है। क्या अच्छा रहा, क्या गलत हुआ, और हम क्या अलग करते। वह लिस्ट फाइल कर दी जाती है। अगला प्रोजेक्ट शुरू होता है, और टीमें जितना मानती हैं, उससे कहीं ज़्यादा बार, वे वही गलतियाँ दोबारा करती हैं।

समस्या शायद ही कभी डेटा कैप्चर करने की होती है। यह एक पहचाने गए lesson और एक लागू किए गए lesson के बीच की दूरी है। दुनिया के सबसे अधिक दस्तावेजीकृत 'lessons learned' प्रोग्रामों में से एक, NASA के प्रोग्राम ने इस दूरी को मापा है। इसके निष्कर्ष पहले आते हैं। दूरी को कम करने वाला एक छोटा लूप उसके बाद आता है।

पहचानना और सीखना एक समान नहीं है

एक सबक तब पहचाना जाता है जब कोई उसे लिखता है। वह तब सीखा जाता है जब संस्था उसके कारण अलग तरह से व्यवहार करती है। इन दोनों के बीच बहुत सारा काम होता है जिसे अधिकांश 'lessons learned' प्रक्रियाएं कभी किसी को सौंपती ही नहीं हैं।

प्रोजेक्ट संस्थाओं पर शोध इस पैटर्न का सीधा नाम लेता है। International Journal of Project Management में, Duffield और Whitty ने पाया कि 'lessons learned' प्रक्रियाएं शायद ही कभी होती हैं, और जब होती हैं, तो वे "संगठनात्मक सीखने के बजाय सबक पहचानने" पर ध्यान केंद्रित करती हैं। इसका आउटपुट एक दस्तावेज़ होता है। इसका इच्छित परिणाम अगली टीम के काम करने के तरीके में बदलाव लाना है। ये दोनों अलग चीज़ें हैं, और उनमें से केवल एक को तैयार करना आसान है।

NASA के अपने ऑडिट में क्या पाया गया

NASA सबकों को गंभीरता से लेता है। वह Lessons Learned Information System (LLIS) चलाता है, और उसकी प्रक्रियात्मक आवश्यकता NPR 7120.6, यानी Lessons Learned Process, यह निर्धारित करती है कि सबक कैसे इकट्ठा, मान्य, मूल्यांकित और संहिताबद्ध किए जाते हैं। यह उसके ऑडिट को एक उपयोगी टेस्ट केस बनाता है। यदि सबक वहां रुक जाते हैं, तो कारण इरादे की कमी नहीं है।

2001 में, U.S. General Accounting Office (अब Government Accountability Office) ने NASA प्रोग्राम और प्रोजेक्ट मैनेजरों का सर्वेक्षण किया। जवाब देने वाले 115 लोगों में से:

• 27% सर्वेक्षण से पहले LLIS के बारे में नहीं जानते थे।
• 17.5% ने एक ऐसा सबक लागू किया था जो उन्हें LLIS के माध्यम से मिला था।
• 58% ने कहा कि वर्तमान सिस्टम उन्हें सही समय पर सही सबक निकालने नहीं देते हैं।

GAO ने निष्कर्ष निकाला कि "सबक नियमित रूप से पहचाने, इकट्ठा या साझा नहीं किए जाते हैं।" सीखना तो हुआ, लेकिन ज्यादातर समीक्षाओं और सहकर्मियों के साथ बातचीत के माध्यम से, न कि इसके लिए बनाए गए सिस्टम के माध्यम से।

2012 में, NASA के Office of Inspector General ने इस सवाल पर फिर से ध्यान दिया। उन्होंने 2005 और 2011 के बीच शुरू किए गए 28 विज्ञान और अंतरिक्ष उड़ान प्रोजेक्ट्स का सर्वेक्षण किया। सोलह प्रोजेक्ट मैनेजरों ने कहा कि उन्होंने LLIS का उपयोग किया, और उनमें से केवल छह ने इसे उपयोगी पाया। बारह ने सबक दिए थे। केवल दस को सबक देने की आवश्यकता का पता था। मैनेजरों ने सिस्टम को पुराना और खोजने में कठिन बताया, और कई लोगों ने अपने प्रोजेक्ट्स को इतना अनूठा माना कि उन पर पुराने सबक लागू नहीं हो सकते। OIG ने यह भी पाया कि केवल दो NASA केंद्र ही अपनी प्रक्रिया चलाने में NPR 7120.6 का पूरी तरह से पालन करते थे।

यह पैटर्न ग्यारह वर्षों तक लगातार बना रहा। सबक स्टोर किए गए थे। बहुत कम निकाले गए। और उससे भी कम ने काम को बदला।

सबक क्यों रुक जाते हैं

ऑडिट को ध्यान से पढ़ें और तीन कारण बार-बार सामने आते हैं। ये अंतरिक्ष उड़ान से कहीं आगे भी लागू होते हैं।

• सबक कहानियों के रूप में लिखे जाते हैं, निर्देशों के रूप में नहीं। क्या हुआ इसके बारे में एक पैराग्राफ पर अमल करना कठिन होता है। यह नहीं बताता कि अब कौन सा दस्तावेज़, चरण या निर्णय अलग होना चाहिए।
• सबक काम से अलग रहते हैं। एक अलग डेटाबेस व्यस्त लोगों को खुद जाकर खोजने के लिए कहता है। ज़्यादातर लोग ऐसा नहीं करेंगे, खासकर शेड्यूल के दबाव में। GAO ने पाया कि मैनेजरों ने सिस्टम की तुलना में सहकर्मियों और समीक्षाओं से अधिक सीखा।
• कोई जाँच नहीं करता। कैप्चर करने को गिना जाता है। लागू करने को नहीं। जब एकमात्र पैमाना यह हो कि कितने सबक रिकॉर्ड किए गए, तो टीमें रिकॉर्ड करने में बहुत माहिर हो जाती हैं।

इनमें से कोई भी केवल तकनीक की समस्या नहीं है। प्रत्येक एक छूटी हुई कड़ी है: सबक और उस चीज़ के बीच जिसे उसे बदलना चाहिए, और उस बदलाव और इस साक्ष्य के बीच कि वह बदलाव हुआ है।

Pause and Learn: जब प्रोजेक्ट चल रहा हो तभी सीखना

NASA Goddard Space Flight Center ने इसका आंशिक उत्तर Pause and Learn नामक एक अभ्यास से दिया। क्लोजआउट रिव्यू का इंतज़ार करने के बजाय, एक प्रोजेक्ट टीम लाइफ साइकिल के महत्वपूर्ण बिंदुओं पर रुकती है और मिलकर Reflection करती है।

जैसा कि Edward Rogers और Barbara Fillip बताते हैं, एक स्टैंडर्ड सेशन में एक प्रोजेक्ट टीम के 10 से 20 लोगों को लगभग 90 मिनट के लिए एक साथ लाया जाता है। इसमें पहले से चुने गए चार या पांच विषयों पर चर्चा की जाती है और तीन सवालों पर काम किया जाता है: क्या अच्छा रहा, क्या अच्छा नहीं रहा, और हम अगली बार क्या अलग करेंगे। हर सेशन में ग्राउंड रूल्स पढ़े जाते हैं। चर्चा को एक नॉलेज मैप के रूप में दर्ज किया जाता है, प्रोजेक्ट मैनेजर के साथ इसकी समीक्षा की जाती है, और बाद के वर्कशॉप में साझा किया जाता है। सेशन्स की योजना प्रोजेक्ट के 'लेसन्स लर्न्ड' प्लान में पहले से बनाई जाती है, न कि केवल कुछ गड़बड़ होने पर बुलाए जाते हैं।

Pause and Learn दो चीजें सही करता है। यह याददाश्त ताज़ा रहने के दौरान ही सबक (lessons) दर्ज कर लेता है। और यह बातचीत को उसी टीम के भीतर रखता है जो उस पर अमल करेगी। लेकिन यह अपने आप में यह गारंटी नहीं देता कि अगला प्रोजेक्ट उस सबक को अपनाएगा। इसके लिए एक और कदम की आवश्यकता होती है।

एक लेसन्स लर्न्ड प्रोसेस जो लूप को पूरा करता है

नॉलेज मैनेजमेंट सिस्टम के लिए अंतरराष्ट्रीय मानक, ISO 30401, एक नॉलेज मैनेजमेंट सिस्टम को स्थापित करने, लागू करने, बनाए रखने, समीक्षा करने और उसमें सुधार करने के लिए आवश्यकताएं निर्धारित करता है। NIST Baldrige Excellence Framework अपने आइटम 4.2 में पूछता है कि आप संगठनात्मक ज्ञान का निर्माण और प्रबंधन कैसे करते हैं, आप बेस्ट प्रैक्टिसेज को कैसे साझा करते हैं, और आप अपने ज्ञान का उपयोग अपनी संस्था के कामकाज के तरीके में लर्निंग को शामिल करने के लिए कैसे करते हैं। दोनों एक ही विचार की ओर इशारा करते हैं: ज्ञान का एक लाइफसाइकिल होता है, और उसे दर्ज करना केवल उसका पहला चरण है।

व्यवहार में, एक वर्किंग लूप के तीन चरण होते हैं।

1. चार क्षेत्रों में दर्ज करें। प्रत्येक सबक के लिए लिखें कि आपने क्या उम्मीद की थी, वास्तव में क्या हुआ, अंतर क्यों आया, और आप क्या बदलेंगे। आखिरी क्षेत्र सबसे महत्वपूर्ण है। यदि कोई टीम किसी बदलाव का नाम नहीं ले सकती, तो वह केवल एक ऑब्जर्वेशन है, सबक नहीं।

2. सबक को उसके लक्ष्य से जोड़ें। हर सबक को उस प्रक्रिया, चेकलिस्ट, टेम्पलेट या निर्णय की ओर इशारा करना चाहिए जिसे वह बदलता है। उस डॉक्यूमेंट को अपडेट करें, और लिंक दर्ज करें। अब सबक वहां मौजूद होगा जहां अगली टीम काम करेगी, न कि किसी ऐसे फोल्डर में जिसे उन्हें याद करके खोलना पड़े।

3. जांचें कि क्या अगले प्रोजेक्ट ने इसे लागू किया। जब बाद का प्रोजेक्ट उस चरण पर पहुंचे जहां सबक का प्रभाव पड़ता है, तो पुष्टि करें कि अपडेट की गई प्रक्रिया का उपयोग किया गया था। यदि ऐसा किया गया था, तो सबक लागू हो गया है। यदि नहीं, तो पता लगाएं कि क्यों। शायद बदलाव स्पष्ट नहीं था, या वह चरण छोड़ दिया गया था। वह निष्कर्ष अपने आप में एक सबक है, और यह वापस पहले चरण पर जाता है।

Roadyom में हमारा नियम है: दावे से पहले प्रमाण। सबकों के लिए, इसका मतलब है कि जब तक बाद का कोई काम उसे साबित न कर दे, तब तक कुछ भी सीखा हुआ नहीं माना जाता। इसलिए लूप को उसके अंतिम चरण से मापें। एक उपयोगी संकेतक सरल है: पिछले साल दर्ज किए गए सबकों में से कितने प्रक्रिया (procedure) से जुड़े हैं, और उनमें से कितने को बाद के प्रोजेक्ट द्वारा लागू किया गया था? इस संख्या को दर्ज किए गए सबकों की गिनती की तुलना में बढ़ाना कठिन है। यह एकमात्र ऐसा पैमाना भी है जो आपको बताता है कि क्या आप वास्तव में सीख रहे हैं।

एक सबक जो किसी बदलाव का नाम नहीं लेता, वह केवल एक ऑब्जर्वेशन है। एक बदलाव जिसका बाद के किसी चरण में उपयोग नहीं किया जाता, वह केवल एक ड्राफ्ट है।

Prism इस लूप को कैसे चलाता है

Prism किसी संस्था के निर्णयों और ज्ञान को काम के चरणों के रूप में ही सुरक्षित रखता है। एक टीम किसी भी चरण पर Pause and Learn रिकॉर्ड खोल सकती है, क्या उम्मीद थी, क्या हुआ, क्यों हुआ, और क्या बदलाव किए गए, इसे दर्ज कर सकती है, और प्रत्येक सबक को उस प्रक्रिया से जोड़ सकती है जिसे उसे अपडेट करना चाहिए। Prism किसी सबक को तभी 'इन्फ्यूज्ड' मानता है जब वह किसी प्रक्रिया से जुड़ा हो और बाद के किसी चरण में उसे लागू किया गया हो। तब तक, यह 'ओपन' के रूप में दिखाई देता रहता है। लोग तय करते हैं कि क्या बदलना है; Prism इस बात का रिकॉर्ड रखता है कि क्या वह बदलाव कायम रहा।

स्रोत

1. NASA के लेसन्स लर्न्ड प्रोसेस का सर्वेक्षण (GAO-01-1015R). U.S. General Accounting Office (अब Government Accountability Office), 2001.
2. NASA के लेसन्स लर्न्ड इंफॉर्मेशन सिस्टम की समीक्षा (IG-12-012). NASA Office of Inspector General, 2012.
3. NASA में कॉन्टेक्स्टुअल लर्निंग सुधारने के लिए लेसन्स लर्न्ड की मैपिंग. NASA Goddard Space Flight Center (E. W. Rogers, B. Fillip), NASA Technical Reports Server, 2016.
4. प्रोजेक्ट्स के माध्यम से संगठनात्मक लर्निंग के लिए एक सिस्टमैटिक लेसन्स लर्न्ड नॉलेज मॉडल विकसित करना. International Journal of Project Management 33(2) (S. Duffield, S. J. Whitty), 2015.
5. ISO 30401:2018 Knowledge management systems — Requirements. International Organization for Standardization, 2018.
6. Baldrige Excellence Builder 2021–2022 (Item 4.2, Information and Knowledge Management). NIST Baldrige Performance Excellence Program, 2021.

कमेंट्स

आपका नामआपकी टिप्पणी

हमारी टीम द्वारा पढ़ने के बाद ही कमेंट्स दिखाई देंगे। कृपया मरीजों या सहकर्मियों का व्यक्तिगत विवरण शामिल न करें।

कमेंट पोस्ट करें