স্কোপ হল একটি প্রকল্প যা সরবরাহ করবে তার সম্মত কাজের সেট। স্কোপ ক্রিপ হল সেই স্কোপের ক্রমান্বয়, অনিয়ন্ত্রিত সম্প্রসারণ — "ছোট সংযোজন" এর ধারাবাহিক প্রবাহ যা নীরবে সময়সূচী উড়িয়ে দেয়। স্কোপ পরিচালনা মানে পরিবর্তন নিয়ন্ত্রণ করা, এটি প্রত্যাখ্যান করা নয়।
আগাম থেকে স্কোপ স্পষ্টভাবে সংজ্ঞায়িত করুন
✓ Document what's IN scope
✓ Document what's explicitly OUT of scope (the underused half)
✓ Define "done" / acceptance criteria
✓ Get stakeholders to agree before work starts
একটি লিখিত, সম্মত সীমানা হল যা পরে আপনাকে প্রমাণের সাথে "এটি একটি পরিবর্তন" বলতে দেয়।
পরিবর্তনগুলি উদ্দেশ্যমূলকভাবে পরিচালনা করুন
পরিবর্তনগুলি খারাপ নয় — অনিয়ন্ত্রিত গুলি খারাপ। যখন একটি নতুন অনুরোধ আসে, এটি একটি সহজ গেটের মাধ্যমে চালান:
1. Is it really needed now, or is it a "nice to have"?
2. What's the impact on timeline / cost / other work?
3. Make the trade-off VISIBLE → "yes, but it pushes the date / drops X"
4. Get the stakeholder to decide with full information
মূল পদক্ষেপ: অতিরিক্ত কাজ নীরবে শোষণ করবেন না। প্রতিটি সংযোজনকে একটি সচেতন ট্রেড-অফ করুন যা স্টেকহোল্ডার মালিকানা নেয়।
একটি বাস্তব উদাহরণ
প্রকল্পের মাঝপথে, একজন স্টেকহোল্ডার "বাল্ক আপলোড সমর্থন করতেও চান — দ্রুত হওয়া উচিত।" এটি মধ্যে চেপে ধরার পরিবর্তে, আপনি উত্তর দেন: "আমরা পারি, কিন্তু এটি প্রায় এক সপ্তাহ যোগ করে। আমরা তারিখ সরাই, নাকি বিশ্লেষণ বৈশিষ্ট্য পরবর্তী রিলিজে ঠেলে দিই?" এখন এটি তাদের কল, টেবিলে খরচ সহ।
একটি সাধারণ ফাঁদ
সহায়ক হওয়ার জন্য প্রতিটি অনুরোধে হ্যাঁ বলা, তারপর সময়সীমা মিস করা। দলটি যেন ব্যর্থ হয়েছে মনে হয়, যখন সত্যিই এটি নীরবে অতিরিক্ত কাজ নিয়েছে।
এটি কেন গুরুত্বপূর্ণ
স্কোপ ক্রিপ প্রকল্পগুলির বিলম্বের সবচেয়ে সাধারণ কারণ — কারণ কোনো একটি পরিবর্তন বড় নয়, বরং ডজনখানেক নীরবে জমা হয়।
স্কোপ পরিচালনা প্রকল্পকে সৎ রাখে: পরিবর্তন ভাল, কিন্তু এর খরচ সবসময় স্পষ্ট করা হয় এবং যে কেউ এটি চায় তার দ্বারা মালিকানা নেওয়া হয়।