टर्नकी संकलन: पार्टियों की आपसी समझ

सभी को नमस्कार!

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

लेख "टर्नकी कार्यान्वयन" के शीर्षक में शब्द का अर्थ ग्राहक की अपेक्षाओं और आवश्यकताओं के अनुसार ईआरपी सिस्टम का पूर्ण वितरण और कार्यान्वयन है।

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

एक एकीकृत सूचना प्रणाली (CIS) का कार्यान्वयन पारंपरिक सेवाओं से कैसे भिन्न है?

उत्पाद उदाहरण और संबंधित सेवाएं

उदाहरण के लिए, कस्टम-निर्मित कालीनों का उत्पादन लें। एक उत्पाद - एक कालीन, और एक सेवा दोनों है - हम आपको न केवल एक कालीन बेचने के लिए तैयार हैं, बल्कि जिस कालीन की आपको आवश्यकता है, और हम इसे न केवल आपके ड्राइंग के अनुसार तैयार करेंगे, बल्कि आपको इसे वितरित भी करेंगे। कालीन - एक उत्पाद जिसकी पहचान उसके लेख संख्या, सीमा, पैटर्न, रंग योजना और आकार से होती है। गुणवत्ता वाले कालीन व्यक्तिगत और भारी हैं। इस वजह से, उन्हें एक जटिल योजना के अनुसार बेचा जाता है - वितरण के साथ एक व्यक्तिगत ऑर्डर, और बिचौलियों और अंत ग्राहकों दोनों द्वारा आदेश दिए जा सकते हैं।

सब कुछ सरल और स्पष्ट है। एक उत्पाद है, और संबंधित सेवाएं हैं।

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

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

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

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

अब आईपी, सॉफ्टवेयर और आईटी के बारे में

उत्पाद तथाकथित सॉफ्टवेयर (सॉफ्टवेयर) है। पहला गंभीर उपद्रव यह है कि यह एक अमूर्त संपत्ति है। यानी इसे कालीन की तरह महसूस और देखा नहीं जा सकता। सॉफ्टवेयर लोगों के दिमाग में ही मौजूद है। बहुत से लोग सोचते हैं कि यह कंप्यूटर में मौजूद है - एक भ्रम जो आसानी से सत्यापित किया जा सकता है (कंप्यूटर कवर खोलें और आप देखेंगे कि यह वहां नहीं है)।

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

सादृश्य क्या है? संगीत और सॉफ्टवेयर दोनों ही मुख्य रूप से लोगों के दिमाग में मौजूद हैं। और सभी लोग अलग हैं, और तदनुसार, प्रत्येक अमूर्त संपत्ति के सार की समझ कम से कम कुछ अलग, लेकिन अलग होगी।

इसलिए, हालांकि कालीन और सॉफ्टवेयर उत्पाद हैं, लोगों को उनके द्वारा दी जाने वाली डिग्री मौलिक रूप से भिन्न होती है। इसलिए, सॉफ़्टवेयर के लिए सामग्री उत्पादों की गुणवत्ता निर्धारित करने के तरीके काम नहीं कर सकते हैं। कोई भी व्यक्ति कुछ सॉफ्टवेयर को नहीं देख सकता है, और यह उसके विपरीत साबित करने के लिए बस बेकार होगा।

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

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

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

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

ऐसे अवसरों के कारण, सॉफ्टवेयर निर्माता अपने उत्पादों को दस्तावेजों के साथ आपूर्ति करते हैं, जिसमें वे सॉफ्टवेयर के संचालन के लिए विभिन्न विकल्पों के संभावित परिणामों के लिए कोई भी जिम्मेदारी देते हैं और उपयोगकर्ताओं पर ऐसी जिम्मेदारी पूरी तरह से थोपते हैं।

सीआईएस और संबंधित सेवाओं का एक उदाहरण

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

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

लेकिन सबसे महत्वपूर्ण बात यह है कि यह सॉफ्टवेयर चयन प्रक्रिया और टीके के डिजाइन में है कि अधिकांश समस्याएं इसके बाद के संचालन के साथ रखी गई हैं। अपूर्ण या "शो के लिए" संकलित टीके आसानी से परियोजना की विफलता की ओर जाता है। यही कारण है कि टीके को आकर्षित करने के लिए स्वतंत्र विशेषज्ञों को आकर्षित करना उचित है।

टीके ऑर्डर करने के लिए या नहीं करने के लिए?

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

तो, पीपी हमेशा की जरूरत है। पीपी परियोजना के उद्देश्यों से शुरू होता है, सॉफ्टवेयर की संरचना और कार्यान्वयन प्राथमिकताओं को निर्धारित करता है।

अगर कोई तैयार या समान सॉफ्टवेयर नहीं है तो TK आवश्यक है।

पीपी एक प्रकार की गारंटी के रूप में कार्य करता है जो खरीदे गए उत्पाद तैयार की गई समस्याओं को हल करेगा।

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

सॉफ्टवेयर का चयन कैसे करें

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

और एक जटिल परियोजना के लिए, अच्छे सलाहकार ढूंढना इतना सरल नहीं है।

इसके अलावा, जो कोई भी सॉफ्टवेयर की पसंद को सौंपा गया है, वह जवाब देने के लिए जिम्मेदार है कि यह (सॉफ्टवेयर) कार्य के साथ सामना करेगा। यानी सलाहकार शुरुआत में पसंद और परियोजना के अंत में सॉफ्टवेयर की स्वीकृति दोनों के लिए जिम्मेदार होना चाहिए।

कार्यान्वयन के विकल्प

कालीन की शुरूआत में इतने सारे विकल्प नहीं हैं - दीवार पर लटकाएं या फर्श पर रखें।

कस्टम सॉफ्टवेयर का कार्यान्वयन (उदाहरण के लिए, ईआरपी-सिस्टम) एक जटिल प्रक्रिया है जिसमें प्रस्तुतियों, डेमो, इंस्टॉलेशन, परीक्षण, संशोधन, पुन: परीक्षण और संचालन शामिल हैं।

इसके अलावा, ग्राहक अपना बहुत सारा समय उस पर खर्च करेंगे, अन्यथा इसके बिना यह परियोजना विफल हो जाएगी।

ग्राहक KIS से क्या आवश्यक है

आवश्यकताओं को स्पष्ट करना

हर चरण में चल रही भागीदारी की आवश्यकता को समझें

बुनियादी आईटी और कंप्यूटर साक्षरता का ज्ञान हो

एक विश्वसनीय उपयोगकर्ता के स्तर पर एक कंप्यूटर का मालिक है

परियोजना के प्रत्येक चरण के लिए समय आवंटित करें

डेडलाइन के लिए जिम्मेदार कर्मचारियों को नियुक्त करने के आदेशों द्वारा

अपने हिस्से के लिए एक सक्षम परियोजना प्रबंधक (समन्वयक) नियुक्त करना

नकदी आवंटित करें

इसी तरह की परियोजनाओं के अनुभव रखें और उनका उपयोग करें

कलाकार के लिए एक कार्यस्थल तैयार करें

CIS प्रदाता से क्या आवश्यक है

इसी तरह की परियोजनाओं के अनुभव रखें और उनका उपयोग करें

पर्याप्त सूचना प्रौद्योगिकी कार्य

पर्याप्त संख्या में सक्षम विशेषज्ञ हों

अपने हिस्से के लिए एक सक्षम परियोजना प्रबंधक (समन्वयक) नियुक्त करना

एक सॉफ्टवेयर उत्पाद का समर्थन करने के लिए प्रतिबद्ध है

कितना समय लगता है

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

परियोजना के दौरान, प्रत्येक चरण के पूरा होने के बाद समय को संयुक्त रूप से समायोजित करने की सिफारिश की जाती है। परियोजना की समय सीमा (यदि वे मूल रूप से संकुचित थे) को पूरा करने के मामले में ठेकेदार पर ग्राहक का दबाव अक्सर बाद के काम की गुणवत्ता को काफी कम कर देता है।

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

परीक्षण

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

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

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

मैं पूर्णता प्रमाण पत्र कब हस्ताक्षर कर सकता हूं

परियोजना के सबसे महत्वपूर्ण चरणों के अनुसार कई कार्य होने चाहिए:

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

2) प्रणाली (पीपी) के लिए आवश्यकताओं के संग्रह के पूरा होने पर अधिनियम। यह आईपी में सभी आवक और जावक डेटा के 50-80% के संग्रह के क्षण को ठीक करता है, साथ ही डेमो संस्करण के आधार पर ग्राहक के प्रतिनिधियों की मौजूदा आईपी कार्यक्षमता के साथ परिचित होने का पूरा होता है।

3) ट्रायल ऑपरेशन में डालने पर अधिनियम। यह आपूर्तिकर्ता द्वारा परीक्षण के पूरा होने और ग्राहक पर कॉन्फ़िगरेशन की स्थापना को ठीक करता है, समस्या के बयान में निर्दिष्ट आवश्यकताओं के अनुसार अनुकूलित, संयुक्त की शुरुआत (या ग्राहक से स्वतंत्र) परीक्षण। ग्राहक विशेषज्ञ प्रशिक्षण। पुराने सॉफ़्टवेयर उत्पादों से प्रारंभिक डेटा का परीक्षण हस्तांतरण।

4) वाणिज्यिक परिचालन में डालने पर अधिनियम। यह संयुक्त परीक्षण के पूरा होने और नई प्रणाली में काम करने के लिए ग्राहक के संक्रमण को ठीक करता है।

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

ध्यान दें: अंतिम अधिनियम के सफल हस्ताक्षर का मतलब केवल आईपी के विकास और रखरखाव के एक अंतहीन पथ की शुरुआत है, जो ग्राहक के व्यवसाय में निरंतर परिवर्तन और बाजार की स्थिति से जुड़ा है।

पर्दे के पीछे क्या रहता है

परियोजना का अनुमान और लागत

परियोजना प्रबंधन मुद्दे

प्रत्येक परियोजना की विशेषताएं और उनमें भाग लेने वाले लोग

और याद रखना: सड़क सड़क ले जाएगा!