कार्य का विवरण (एसओडब्ल्यू) एक दस्तावेज (और, आमतौर पर, एक कानूनी अनुबंध) है जो एक ठेकेदार और एक ग्राहक के बीच समझ को औपचारिक बनाता है। प्रत्येक परियोजना के लिए, SOW वितरित की जाने वाली विशिष्ट सेवाओं (आमतौर पर, अलग-अलग कार्यों को पूरा करने के लिए विभाजित), वह समय जिसमें उन कार्यों और सेवाओं को किया जाना है, और भुगतान के लिए राशि और देय तिथियां बताती हैं। इसका मूल उद्देश्य परियोजना के रोडमैप के रूप में कार्य करना और पार्टियों की अपेक्षाओं का दस्तावेजीकरण करना है। यह "क्यों," "कौन," "क्या," "कैसे," "कब," "कहां," और "कितना?" का स्पष्ट, सादा-अंग्रेजी विवरण होना चाहिए।
कदम
विधि 1 में से 2: सामान्य दिशानिर्देशों का पालन करना
चरण 1. काम शुरू करने से पहले SOW लिखें।
SOW आमतौर पर मुख्य अनुबंध वार्ता पूरी होने के बाद बनाया जाता है, लेकिन किसी परियोजना पर कोई काम शुरू होने से पहले। कभी-कभी, हालांकि (विशेष रूप से समय-संवेदनशील परियोजनाओं के साथ), काम शुरू होने के बाद बातचीत जारी रह सकती है और जब तक परियोजना अच्छी तरह से चल रही है तब तक एसओडब्ल्यू को अंतिम रूप नहीं दिया जाता है।
चरण 2. आवश्यक SOW प्रारूप पर शोध करें।
एक भी मानक SOW नहीं है क्योंकि विभिन्न उद्योगों और परियोजनाओं में अलग-अलग डिलिवरेबल्स और वर्कफ़्लो हैं। एक अच्छा SOW एक अनुकूलित SOW है।
चरण 3. इसे पहली बार ठीक करें।
जबकि मूल SOW को आमतौर पर संशोधित नहीं किया जाता है, एक अलग साइड एग्रीमेंट जिसे चेंज ऑर्डर कहा जाता है, आमतौर पर SOW की शर्तों को संशोधित करने के लिए उपयोग किया जाता है। SOW के साथ एक खाली चेंज ऑर्डर फॉर्म शामिल करना एक अच्छा विचार है। ध्यान रखें, आदेश बदलें परियोजना की लागत बढ़ा सकते हैं। एक अच्छी तरह से लिखित SOW एक चेंज ऑर्डर की आवश्यकता को कम करने में मदद कर सकता है। कोई भी ग्राहक ऐसी स्थिति में नहीं रहना चाहता जहां उसकी विशिष्ट अपेक्षाओं को बिना दस्तावेज के छोड़ दिया जाता है, जिससे देरी हो सकती है, कुल लागत में वृद्धि हो सकती है, या असंतोष हो सकता है।
विधि 2 का 2: SOWs में शैली और विशिष्टताओं में महारत हासिल करना
चरण 1. उद्देश्य शामिल करें।
यह खंड "क्यों?" प्रश्न का उत्तर देता है। यह परियोजना और उसके उद्देश्यों का एक उच्च-स्तरीय अवलोकन है। परियोजना के इस "पक्षी-दृष्टिकोण" का मसौदा तैयार करते समय सामान्य विवरण स्वीकार्य हैं, लेकिन ऐसी भाषा से बचें, जिसकी व्याख्या एक से अधिक तरीकों से की जा सकती है। स्पष्ट रहिये; मापने योग्य और प्राप्त करने योग्य उद्देश्यों का वर्णन करें जिन्हें वास्तविक रूप से निर्दिष्ट समय सीमा में पूरा किया जा सकता है।
चरण 2. दायरे की चर्चा शामिल करें।
यह खंड "क्या?" का एक निश्चित कथन (कोई विकल्प या विकल्प नहीं) प्रदान करता है। और कैसे?" व्हाट दो वर्क? इसे कैसे पूरा किया जाएगा? या, अक्सर, क्या काम नहीं है और क्या पूरा नहीं किया जाएगा। धारणाएं क्या हैं? क्या डिलिवरेबल्स (वस्तुओं को ठेकेदार समीक्षा और अनुमोदन के लिए एक ग्राहक को प्रस्तुत करता है) का उत्पादन किया जा रहा है? डिलिवरेबल्स के अलावा, प्रगति रिपोर्टिंग, समय पर नज़र रखने और अन्य संचारों के संदर्भ में प्रशासनिक रूप से (परियोजना प्रबंधन) क्या होना चाहिए।
चरण 3. यदि संभव हो तो स्थान जोड़ें।
यह वैकल्पिक खंड बताता है कि कार्य कहाँ किया जाएगा (यदि प्रासंगिक हो)।
चरण 4. एक समय सीमा शामिल करें।
यह वैकल्पिक खंड परियोजना के पूरा होने के लिए अनुमत कुल समय, प्रति समय अवधि के लिए अधिकतम बिल योग्य घंटे और औपचारिक समीक्षा या अन्य परियोजना मील के पत्थर के लिए विशिष्ट समय निर्दिष्ट करता है।
चरण 5. अनुसूची निर्धारित करें।
यह खंड बताता है कि कौन से कार्यों को किस तिथि/समय तक पूरा किया जाना चाहिए, और ऐसा करने के लिए कौन जिम्मेदार है। कार्यों और परिणामों का विवरण (मुख्य रूप से डिलिवरेबल्स) विस्तृत, स्पष्ट और सीधा होना चाहिए ताकि उन्हें समझना आसान हो। डिलिवरेबल्स के अलावा, शेड्यूल में गुणवत्ता आश्वासन परीक्षण, उपभोक्ता परीक्षण और प्रगति रिपोर्ट के लिए प्रविष्टियां शामिल हो सकती हैं।
- जबकि शेड्यूल विशिष्ट होना चाहिए, "कैसे" पर ध्यान केंद्रित न करें क्योंकि यह सफल परियोजना के पूरा होने में बहुत सारी बाधाएं डाल सकता है। उपयोग की जाने वाली आवश्यक कार्यप्रणाली का एक बुनियादी विवरण पर्याप्त है।
- अनुसूची में अक्सर स्वीकृति मानदंड (परिणाम की गुणवत्ता को मापने के लिए) और भुगतान मील के पत्थर (आमतौर पर प्रमुख डिलिवरेबल्स की स्वीकृति पर) का विवरण शामिल होता है, हालांकि इन्हें एक अलग, अलग खंड में वर्णित किया जा सकता है।
चरण 6. स्वीकृति पर एक अनुभाग शामिल करें।
यह खंड तंत्र का वर्णन करता है कि कैसे पक्ष यह निर्धारित करेंगे कि उत्पाद या सेवा स्वीकार्य है या नहीं। मानदंड मापने योग्य गुणवत्ता मानकों से लेकर एक निर्दिष्ट संख्या में परीक्षण तक हो सकते हैं, लेकिन किसी भी मामले में वस्तुनिष्ठ मूल्यांकन के लिए खुद को उधार देना चाहिए।
चरण 7. मानक निर्दिष्ट करें।
यह खंड किसी भी उद्योग मानकों का वर्णन करता है जिन्हें अनुबंध को पूरा करने के लिए पूरा किया जाना चाहिए। SOW में उद्योग मानकों को भौतिक रूप से पुन: प्रस्तुत करने के बजाय, विशेष रूप से मानकों के एक सेट को संदर्भित करना पर्याप्त है।
चरण 8. किसी भी कार्यबल आवश्यकताएँ शामिल करें।
यह खंड किसी विशेष कार्यबल आवश्यकताओं को निर्दिष्ट करता है, उदाहरण के लिए, परियोजना के कर्मचारियों की संख्या, शिक्षा आवश्यकताओं (डिग्री या प्रमाणपत्र)।
चरण 9. मूल्य पर ध्यान दें।
यह खंड "कितना?" के प्रश्न को संबोधित करता है। क्या भुगतान एक निश्चित शुल्क है? खर्च/लागत कैसे कारक हैं? क्या भुगतान एकमुश्त या किश्तों में किया जाएगा? भुगतान अनुसूची क्या है? क्या भुगतान मील के पत्थर हैं?
चरण 10. किसी भी धारणा को शामिल करें।
अधिकांश परियोजनाओं को विभिन्न अज्ञात द्वारा अनुमति दी जाती है, जिसके लिए पार्टियों को कई तरह की धारणाएँ बनानी चाहिए। संक्षेप में, धारणाएं वे शर्तें हैं जिनकी ठेकेदार अपेक्षा करता है कि एसओडब्ल्यू की शर्तों के अनुसार परियोजना को पूरा करने के लिए मौजूद रहेंगी। उदाहरण के लिए, ठेकेदार यह मान सकता है कि सुपुर्दगी योग्य सॉफ़्टवेयर स्थापित करने के लिए उसके कर्मचारियों को क्लाइंट के कंप्यूटर नेटवर्क तक पहुंच प्रदान की जाएगी। अनुमान अनुभाग को यथासंभव अधिक से अधिक ऐसी धारणाओं की पहचान करनी चाहिए और एक आकस्मिक योजना या किसी भी धारणा के विफल होने की स्थिति में परिणाम निर्धारित करना चाहिए।
चरण 11. परियोजना प्रबंधन के लिए पैरामीटर शामिल करें।
यह खंड परियोजना की प्रगति की निगरानी के लिए प्रक्रिया का वर्णन करता है। जैसे आइटम शामिल करें: साप्ताहिक बैठकें, नियमित स्थिति रिपोर्ट, नियमित प्रगति रिपोर्ट, और परियोजना प्रबंधन टीम बैठकें। यह खंड किसी भी अतिरिक्त दायित्वों का वर्णन करने के लिए एक अच्छी जगह है जो परियोजना से प्रवाहित हो सकता है, जैसे प्रारंभिक डिजाइन और/या स्थापना के बाद रखरखाव और मरम्मत।
टिप्स
- यदि लागू हो, तो आम तौर पर अंतिम भुगतान के एक हिस्से को रोकना ग्राहक के हित में होता है जब तक कि सभी डिलिवरेबल्स को एक साथ काम करने के लिए नहीं दिखाया जाता है।
- आम तौर पर, एक अच्छी तरह से तैयार किए गए SOW को किसी बाहरी दस्तावेज़ (उद्योग मानकों से अलग) का संदर्भ नहीं देना चाहिए।
- प्रोजेक्ट शुरू होने से पहले अपने SOW में सेल्स पिचों और अनुबंध वार्ताओं के दौरान किए गए सभी वादों को पूरा करना सुनिश्चित करें।
- शेड्यूल का विवरण देने में, कैलेंडरिंग भाषा का उपयोग करें जो कुछ लचीलेपन की अनुमति देता है। उदाहरण के लिए, "X के दो महीने बाद, Q. A. परीक्षण पूरा हो जाएगा," के बजाय "5 जून को, क्यू.ए. परीक्षण पूरा हो जाएगा।” यह परियोजना को सुचारू रूप से आगे बढ़ने की अनुमति देता है (बिना परिवर्तन आदेश के) प्रक्रिया में पहले देरी होनी चाहिए।
- SOW को "गोपनीय" नामित किया जा सकता है। यदि ऐसा है, तो SOW में किसी भी गोपनीयता भंग के परिणामों (आमतौर पर एक निश्चित मौद्रिक दंड) का वर्णन करने वाला एक संक्षिप्त खंड होना चाहिए।
