लेखक पुरालेख
नीचे के दिशा निर्देशों को ध्यान में Microsoft Office परियोजना व्यावसायिक उपकरण के साथ लिखा है, लेकिन साथ ही अन्य समयबद्धन सॉफ्टवेयर उपकरणों के लिए अनुकूलित कर सकते हैं.
1) के रूप में संभव के रूप में बहुत, सारांश कार्यों डिलिवरेबल्स संज्ञा के रूप में होना चाहिए, और बड़ा.
2 प्रत्येक अनुभाग जो 3 या अधिक कार्य किया है की आखिरी पंक्ति) 'हो <deliverable चाहिए name> पूरा' 0 दिन की अवधि के साथ, यह एक मील का पत्थर बना. सिफारिश: Italic मील के पत्थर बनाओ और रंग उन से उन्हें अधिक से बाहर खड़े हरे.
लाभ:
- आराम से जब योजना ब्राउज़िंग डिलिवरेबल्स देखने के लिए, क्योंकि वे टोपी में हैं
- आराम से परियोजना रिपोर्ट में मील के पत्थर को पहचान
- हर वर्ग के अंत में एक मील का पत्थर रखने से, आप एक लाइन आइटम के तुम एक सारांश कार्य के लिए एक संसाधन निर्धारण के बाद से जहां एक संसाधन, जो पूरे अनुभाग के लिए जिम्मेदार है, असाइन कर सकते है की सलाह नहीं दी है. यह आसान देखो कौन प्रत्येक अनुभाग के लिए जिम्मेदार है जब तुम एक मील का पत्थर रिपोर्ट में लग रहा है बनाता है.
उदाहरण:
| कार्य का नाम | अवधि |
| DELIVERABLE 1 | |
| 1 टास्क | |
| 2 टास्क | |
| Deliverable पूरा 1 | 0d |
| DELIVERABLE 2 | |
| 1 टास्क | |
| 2 टास्क | |
| Deliverable 2 पूर्ण | 0d |
| कार्य का नाम | अवधि |
| लॉगआउट सर्वेक्षण रास () | |
| कोड रास | |
| रास आचार संहिता की समीक्षा | |
| Rework रास | |
| प्राप्त करने की मंजूरी और लोकसभा के लिए signoff | |
| इकाई परीक्षण रास | |
| लॉगआउट सर्वेक्षण पूरा | 0d |
3) कभी एक सारांश कार्य को संसाधन असाइन. इस परिपत्र संदर्भ कारण है, अगर एक लिंक सारांश कार्य के अंदर कार्य दूसरे वर्गों से जुड़े हो सकते हैं. अगर आप को दिखाने जो पूरे अनुभाग के लिए जिम्मेदार है, काम करने के लिए एक मील का पत्थर संसाधन आवंटित अनुभाग के अंत में चाहते हैं (देखें 'लाभ के ऊपर.)
) 4 विस्तार कार्य एक क्रिया शुरू करने के साथ, अधिमानतः चाहिए एक वस्तु है, और काम कर रही संसाधन द्वारा साध्य.
उदाहरण 1: 'सफलता की कसौटी' 'हो परिभाषित करें और दस्तावेज़ चाहिए सफलता' मानदंड.
उदाहरण 2: '' टेस्ट 'होना चाहिए टेस्ट VeriSign' एकता 'या' टेस्ट 'छठी
3 उदाहरण: 'सफलता का मापदंड' पर Signoff 'प्राप्त करने पर signoff होना चाहिए सफलता' मानदंड. (कार्यकारी हस्ताक्षर करने से नहीं है, परियोजना प्रबंधक (या अन्य) किया कार्य के लिए जिम्मेदार हो रही है - तो यह प्राप्त '' है)
) 5 विस्तार कार्य आदर्श 2 सप्ताह के लिए 1 दिन की अवधि सीमा होनी चाहिए. कुछ अपवाद भी हैं, लेकिन यह कठिन है ट्रैक और एक 2-एक 2 सप्ताह से अधिक पर कार्य महीने के कार्य प्रगति पर नियंत्रण ...
6) granularity के स्तर पर विस्तार से काम बनाएँ है कि आप को मॉनिटर करना चाहता हूँ. वहाँ विस्तार परियोजना योजना में डालने के लिए भी दानेदार कार्य हो सकता है. ये एक सूची में जा सकते हैं. तुम एक काम करने के लिए 'चेकलिस्ट लोग चर्चा करते हुए नाम के एक नोट संलग्न कर सकते हैं एक्स'. वैकल्पिक रूप से, बस टास्क नोट में सुधार सूची सही लगा.
7) विस्तार कार्य टास्क नाम अपनी परियोजना के भीतर अद्वितीय होनी चाहिए, और सारांश के विशिष्ट वर्ग वे हैं 'की', कार्य का नाम डिजाइन 'हो सकता है बजाय अंदर डिजाइन रिलीज 1', उदाहरण के लिए. यदि आप कई वर्गों पर कार्य के एक समूह दोहराने, एक उपसर्ग जोड़ने या कार्य का नाम है जो सारांश काम प्रत्यय को दर्शाता है.
लाभ: तुम कार्यों की सूची पर जब रिपोर्टिंग कर रहे हैं जो कर सकते हैं या सारांश सूचीबद्ध कार्य नहीं कर सकते हैं, यह स्पष्ट क्या काम है. आप संदर्भित पार परियोजना निर्भरता या पोर्टफोलियो स्तर की रिपोर्टिंग, अद्वितीय कार्य के नाम की पहचान करने के लिए जरूरी काम कर रहे हैं जब कर रहे हैं.
8. एक सामान्य नियम के रूप में, आरंभ तिथि या समाप्त तिथि किसी भी काम पर नहीं दर्ज है. एमएस परियोजना है कि आप के लिए, कार्य प्राथमिकता, प्रयास के आधार पर की गणना, निर्भरता, संसाधनों सौंपा, कैलेंडर, कार्य (अवधि या काम के प्रयास के लिए कार्य कॉलम के लिए अवधि कॉलम में) का अनुमान है, टास्क निर्भरता और संसाधन दर्ज आदि जाएगा, दो और परियोजना प्रारंभ की तारीख और समाप्त तिथि की गणना.
कारण: यदि आप मैन्युअल रूप से एक प्रारंभ दिनांक दर्ज करें, उदाहरण के लिए, MS परियोजना के काम पर एक 'पहले नहीं' से आरंभ की कमी कर देगा. यदि एक पूर्ववर्ती कार्य से पहले अनुसूचित खत्म, एक आरम्भ तिथि बाधा के साथ काम करने की योजना बनाई से पहले शुरू नहीं बदल; हो बाधा तारीख सम्मानित किया जाएगा. तुम जो दृश्यता में काम शुरू कर सकते हैं / खत्म करने से पहले खो देंगे मूल रूप से अनुसूचित.
