MONOLITH LAW OFFICE+81-3-6262-3248काम करने के दिन 10:00-18:00 JST [Englsih Only]

MONOLITH LAW MAGAZINE

IT

सिस्टम विकास में प्रोजेक्ट प्रबंधन की जिम्मेदारियां क्या हैं

IT

सिस्टम विकास में प्रोजेक्ट प्रबंधन की जिम्मेदारियां क्या हैं

सिस्टम विकास एक ऐसी प्रक्रिया है जो उपयोगकर्ता और विक्रेता के बीच पारस्परिक सहयोग के माध्यम से आगे बढ़ती है, जिसमें उपयोगकर्ता कार्य का आदेश देता है और विक्रेता उसे स्वीकार करता है।

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

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

विक्रेता की परियोजना प्रबंधन की जिम्मेदारी क्या है

प्रोजेक्ट मैनेजमेंट की छवि

सबसे पहले, विक्रेता की परियोजना प्रबंधन की जिम्मेदारी के बारे में देखते हैं।

न्यायाधीश के फैसले के अनुसार, परियोजना प्रबंधन की जिम्मेदारी निम्नलिखित होती है:

– सहमति के अनुसार विकास कार्य को आगे बढ़ाने के साथ-साथ, स्थिति की निगरानी रखने, विकास कार्य को बाधित करने वाले कारकों की पहचान करने की कोशिश करने और इनका उचित समाधान करने की जिम्मेदारी।

यह विक्रेता से अनुरोध करता है कि वह समझौते के अनुसार तय की गई समय-सारणी के अनुसार परियोजना को आगे बढ़ाए, और परिस्थितियों के अनुसार उपयोगकर्ता को विकास को सुचारू रूप से आगे बढ़ाने के लिए प्रेरित करे।

– उपयोगकर्ता के विकास में हस्तक्षेप को उचित रूप से प्रबंधित करने, और विशेषज्ञता के बिना उपयोगकर्ता द्वारा विकास कार्य को बाधित करने वाले कार्य को रोकने के लिए उपयोगकर्ता को प्रेरित करने की जिम्मेदारी।

यह उपयोगकर्ता को निर्णय लेने के लिए मामले और समय सीमा दिखाने, उपयोगकर्ता के निर्णय की देरी से उत्पन्न होने वाली बाधाओं को दिखाने, विक्रेता द्वारा उपयोगकर्ता को निर्णय लेने के लिए प्रेरित करने, और विकास की प्रगति के अनुसार स्वीकार करने के लिए अस्वीकार्य मांग होने पर, कारणों को पूरी तरह से समझाने और उपयोगकर्ता की मांग को अस्वीकार करने का तत्पर्य है।

इस प्रकार, विक्रेता की ओर से, विकास कार्य को आगे बढ़ाने के साथ-साथ, उपयोगकर्ता को निर्णय लेने के लिए प्रेरित करने, और सिस्टम विकास को सफल बनाने के लिए प्रयास करने की जिम्मेदारी होती है।

उपयोगकर्ता की सहयोग की जिम्मेदारी

हालांकि, सिस्टम विकास में, विक्रेता केवल सभी जिम्मेदारियों को एकतरफा तौर पर स्वीकार नहीं करता है। मूल रूप से, यह आदेश देने वाले की कंपनी के लिए आईटी सिस्टम होने के नाते, आदेश देने वाले के लिए भी उस सिस्टम विकास परियोजना को “दूसरों का काम” मानना उचित नहीं होना चाहिए।

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

उपयोगकर्ता की सहयोग की जिम्मेदारी में निम्नलिखित बातें शामिल होती हैं:

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

② उत्पादन की जांच करना।

③ विक्रेता के सहयोग के अनुरोध का पालन करना।

उपयोगकर्ता को सिस्टम से मांग की गई सुविधाओं को स्पष्ट रूप से विक्रेता को बताने, और सक्रिय रूप से विकास में सहयोग करने की आवश्यकता होती है।

परियोजना प्रबंधन आसान नहीं है

प्रोजेक्ट मैनेजमेंट की छवि
परियोजना के जोखिम प्रबंधन को ध्यान में रखते हुए आगे बढ़ाना।

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

स्क्रीन को देखने से ही कल्पना नहीं हो सकती जहां कार्य की कठिनाई होती है, और यह दृष्टिकोण बदलने पर, परियोजना का ‘जलना’ का कारण भी होता है। सबसे पहले इन बातों को समझना, “आईटी सिस्टम को विकसित करने की परियोजना को प्रबंधित करना, बिल्कुल आसान नहीं है” यह बात जानना, परियोजना के जोखिम प्रबंधन के बारे में सीखने का महत्वपूर्ण आधार होगा।

प्रोजेक्ट मैनेजमेंट की अनिवार्यताओं का उल्लंघन होने पर क्या हो सकता है

तो, अगर प्रोजेक्ट मैनेजमेंट की अनिवार्यताओं का उल्लंघन हुआ है, तो विशेष रूप से क्या हो सकता है?

इस पर, कोई स्पष्ट धारा नहीं है, और “प्रोजेक्ट मैनेजमेंट की अनिवार्यताएं ऐसी होती हैं” ऐसा कोई नियम तैयार नहीं किया गया है।

हालांकि, पिछले न्यायाधीशों के फैसलों से, विक्रेता के द्वारा अनिवार्यताओं का उल्लंघन होने पर उपयोगकर्ता क्या कर सकता है, इस पर कुछ हद तक एक सामंजस्यपूर्ण दृष्टिकोण को समझा जा सकता है।

यदि विक्रेता ने अनिवार्यताओं का उल्लंघन किया है, तो उपयोगकर्ता विक्रेता के खिलाफ हानि का दावा या अनुबंध रद्द करने का दावा करेगा। हालांकि, यदि उपयोगकर्ता की भी समस्या है, तो विक्रेता को दोषी नहीं माना जाएगा, या उसे दोषी माना जाएगा, जिससे हानि की राशि कम हो सकती है।

वहीं, यदि उपयोगकर्ता ने सहयोग की अनिवार्यताओं का उल्लंघन किया है, तो इसके कारण कार्य पूरा नहीं होने पर, खतरे का बोझ (नागरिक संहिता 536 धारा 2) या कर्ज अव्याहृत के आधार पर, विक्रेता उपयोगकर्ता से पुरस्कार के बराबर राशि का दावा कर सकता है।

प्रोजेक्ट मैनेजमेंट कर्तव्यों को दर्शाने वाले न्यायाधीश के फैसले

प्रोजेक्ट मैनेजमेंट कर्तव्यों के बारे में व्याख्या करने वाले प्रमुख न्यायाधीश के फैसलों में निम्नलिखित हैं।

निम्नलिखित मामले में, सिस्टम विकास में वितरण की समय सीमा में देरी हुई थी और विक्रेता ने मूल अनुमान की बढ़ोतरी की मांग की थी, जिससे विवाद न्यायालय तक पहुंच गया था। उपयोगकर्ता और विक्रेता की जिम्मेदारी को कैसे विभाजित करना चाहिए, इस पर विवाद न्यायालय तक पहुंच गया, जिसे “जलता मामला” कहा जा सकता है।

प्रतिवादी, सिस्टम विकास के विशेषज्ञ व्यापारी के रूप में, अपने पास मौजूद उच्च स्तरीय विशेषज्ञता और अनुभव के आधार पर, इस मामले के इलेक्ट्रॉनिक सिस्टम विकास समझौते के समझौते और इस मामले के इलेक्ट्रॉनिक सिस्टम प्रस्ताव के अनुसार, इनमें से हर एक में उल्लिखित सिस्टम का निर्माण करने का दायित्व था।
इसलिए, प्रतिवादी को, इलेक्ट्रॉनिक सिस्टम को समय सीमा के भीतर पूरा करने के लिए, इस मामले के इलेक्ट्रॉनिक सिस्टम विकास समझौते के समझौते और इस मामले के इलेक्ट्रॉनिक सिस्टम प्रस्ताव में प्रस्तुत विकास प्रक्रिया, विकास तरीका, कार्य प्रक्रिया आदि के अनुसार विकास कार्य को आगे बढ़ाने के साथ-साथ, हमेशा प्रगति की स्थिति को प्रबंधित करने, विकास कार्य को बाधित करने वाले कारकों की खोज में जुटने और इस पर उचित तरीके से समाधान करने का दायित्व था। और, सिस्टम विकास एक ऐसी प्रक्रिया है जिसमें आदेशदाता के साथ बैठकें होती हैं और उसकी इच्छाओं को ध्यान में रखते हुए काम किया जाता है, इसलिए प्रतिवादी को, आदेशदाता के रूप में मूल प्रतिवादी के सिस्टम विकास में हस्तक्षेप को भी, उचित तरीके से प्रबंधित करने, और सिस्टम विकास में विशेषज्ञता नहीं रखने वाले मूल प्रतिवादी द्वारा विकास कार्य को बाधित करने वाले कार्य को रोकने के लिए मूल प्रतिवादी को प्रभावित करने का कर्तव्य (नीचे, इन कर्तव्यों को “प्रोजेक्ट मैनेजमेंट कार्य” कहा जाता है।) था।

टोक्यो जिला न्यायालय, 10 मार्च 2004 (हिसेई 16)

उपरोक्त निर्णय के मुख्य बिंदु से, विस्तृत शब्दों और जटिल मामले के विवरण को समझना महत्वपूर्ण नहीं है। सबसे महत्वपूर्ण बात यह है कि “प्रोजेक्ट मैनेजमेंट कर्तव्य” शब्द का उपयोग किया गया है। यद्यपि कोई स्पष्ट धारा मौजूद नहीं है, लेकिन न्यायालय मुख्य रूप से कानूनी जिम्मेदारी को विभाजित करने के लिए दिशा-निर्देश स्थापित करने की कोशिश कर रहा है।

उपरोक्त निर्णय की सामग्री को सरल भाषा में पुनः संगठित करने के बाद, इसे बुलेट पॉइंट्स में संगठित करते हैं। यहां “प्रोजेक्ट मैनेजमेंट कर्तव्य” का तात्पर्य है,

  • पूर्वनिर्धारित योजना (विकास प्रक्रिया, तरीका, कार्य प्रक्रिया आदि) के अनुसार कार्य को आगे बढ़ाना
  • कार्य की सुचारू प्रगति की निगरानी करना
  • यदि कार्य सुचारू रूप से नहीं बढ़ रहा है, तो “बाधक तत्व” की खोज और उपाय करना

इसके अलावा, उपरोक्त तीन बिंदुओं के लिए,

  • विक्रेता की एकतरफा प्रयास के बजाय, उपयोगकर्ता से आवश्यक सहयोग मांगने आदि, संचार की कोशिश भी साथ-साथ करना

इसे सामान्य रूप से संगठित किया जा सकता है।

वैसे, सिस्टम विकास के मामले में, कानूनी रूप से यह अधिकांशतः संविधान और समय और सामग्री संविधान के रूप में होता है। और संविधान अनुबंध, सीधे शब्दों में कहें तो, “मुआवजा प्राप्त करने और उस मुआवजे के अनुरूप काम करने” का अनुबंध होता है, इसलिए प्रोजेक्ट मैनेजमेंट कर्तव्य भी, उसके “गुणवत्ता आदि” के भीतर समाहित होने वाली अवधारणा होती है।

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

विचारधीन न्यायाधीश द्वारा प्रोजेक्ट मैनेजमेंट की जिम्मेदारी को संविधान के पूर्व चरण में भी लागू करने की सूचना दी गई

इसके अलावा, प्रोजेक्ट मैनेजमेंट की जिम्मेदारी को संविधान के पूर्व चरण में भी लागू किया जा सकता है, ऐसा माना जाता है। निम्नलिखित न्यायाधीश के फैसले में, संविधान के पूर्व चरण, अर्थात संविधान से पहले के विभिन्न प्रस्ताव और योजनाओं के दौरान भी, विक्रेता की ओर से प्रोजेक्ट मैनेजमेंट की जिम्मेदारी होने का संकेत दिया गया है।

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

पूर्वोक्त न्यायाधीश के फैसले में प्रोजेक्ट मैनेजमेंट की जिम्मेदारी के विचारधारा को, संविधान के पूर्व चरण की बात भी शामिल होती है, यह निम्नलिखित को पढ़ने से अच्छी तरह से समझ में आएगा।

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

तोक्यो हाई कोर्ट, 26 सितंबर 2013 (हिजी 25)

वैसे भी, IT प्रोजेक्ट की बात छोड़कर, सभी व्यापारिक लेन-देन और कानूनी बातचीत में, संविधान के पूर्व चरण में भी, उसके प्रतिद्वंद्वी के प्रति कुछ कानूनी जिम्मेदारियाँ होती हैं, ऐसा विचारधारा मूल रूप से मौजूद है।

आमतौर पर बड़े लेन-देन के लिए, ‘समझौता’ की प्रक्रिया ‘संविधान’ के लक्ष्य तक पहुंचने के लिए लंबी होती है। इस प्रक्रिया में भी, प्रतिद्वंद्वी के प्रति ईमानदार होना चाहिए, यह बात कम से कम नैतिक रूप से अच्छी तरह से समझी जा सकती है। सीधे शब्दों में कहें तो, ऐसी बातें, केवल भावनात्मक नैतिक भावनाओं तक ही सीमित नहीं होती हैं, बल्कि कानूनी रूप से भी महत्वपूर्ण होती हैं। (निम्नलिखित में धारा का उद्धरण दिया गया है। रेखांकन लेखक ने जोड़ा है।)

सिविल कोड धारा 1, उपधारा 2
अधिकारों का अभ्यास और जिम्मेदारियों का पालन, ईमानदारी के अनुसार सत्यनिष्ठा से किया जाना चाहिए।

उपरोक्त सामग्री को संक्षेप में दर्शाने वाला ‘ईमानदारी का नियम’ न्यायाधीश के फैसले में एक कीवर्ड हो सकता है।

वैसे भी, इस लेख में प्रकाशित किए गए न्यायाधीश के फैसले भी, एक पहलू में, ‘उपयोगकर्ता की सहयोग की जिम्मेदारी और विक्रेता की प्रोजेक्ट मैनेजमेंट की जिम्मेदारी की सीमा को निर्धारित करने के लिए दिशानिर्देश’ का अर्थ होता है। IT सिस्टम के विकास में उपयोगकर्ता की सहयोग की जिम्मेदारी के बारे में, कृपया निम्नलिखित लेख देखें।

सारांश: प्रोजेक्ट मैनेजमेंट के दायित्व उल्लंघन से संबंधित समस्याओं पर वकील से परामर्श करें

कानूनी सलाह लेने वाला व्यक्ति

इस लेख में, हमने सिस्टम विकास में प्रोजेक्ट मैनेजमेंट के दायित्वों के बारे में समग्र व्यवस्थापन की कोशिश की है। सिस्टम विकास में विभिन्न समस्याएं और मुसीबतें होती हैं, लेकिन जब ऐसी स्थिति आती है, तो महत्वपूर्ण होता है कि हर विवाद स्थल के लिए ‘आधार’ हो। व्यक्तिगत अनियमित स्थितियों के बारे में, निश्चित रूप से अनंत विविधता हो सकती है।

हालांकि, ऐसी स्थिति के सामने ‘मूल रूप से कानूनी दायित्व किसने और कितना स्वीकार किया था?’ पूछने की महत्वता, मामले की व्यक्तिगतता से अधिक, किसी प्रकार की सार्वभौमिकता का धारण करती है।

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

यदि प्रोजेक्ट मैनेजमेंट के दायित्व उल्लंघन से संबंधित कोई समस्या उत्पन्न होती है, तो तुरंत वकील से परामर्श करें।

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

ऊपर लौटें