خزش محدوده (Scope Creep) چیست؟

5/5 - (1 امتیاز)

همه ما می دانیم که محدوده و محتوای پروژه (scope)، فعالیت های مورد نیاز پروژه را تعریف می­کند. و مدیریت محدوده و محتوای پروژه بخشی از نقش‌های مدیر پروژه است، به خصوص هنگامی که پروژه در حال انجام است و ناگهان متوجه می­شویم که دامنه پروژه ما به مراتب فراتر از مرزهای اولیه خود گسترش یافته است.

PMPiran
23 اسفند 1396 دقیقه 2 دیدگاه

همه ما می دانیم که محدوده و محتوا پروژه (scope)، فعالیت های مورد نیاز پروژه را تعریف می‌­کند. و مدیریت محدوده و محتوا، بخشی از نقش‌های مدیر پروژه است، به خصوص هنگامی که پروژه در حال انجام است و ناگهان متوجه می­شویم که دامنه پروژه ما به مراتب فراتر از مرزهای اولیه خود گسترش یافته است و ما در معرض ناپایداری محدوده و محتوای پروژه خود قرار گرفته‌ایم. اولین اقدام برای جلوگیری از خزش محدوده و محتوا، شناسایی چگونگی بروز آن است.

خزش محدوده و محتوا (Scope Creep) چیست؟

خزش محدوده و محتوا (گاهی اوقات به عنوان “خزش مورد نیاز” و یا حتی “خزش ویژگی” شناخته می شود) اشاره به اینکه چگونه نیازهای پروژه در طول چرخه حیات پروژه افزایش می یابد، مثلا تولید یک محصول با سه ویژگی اساسی آغاز می­شود، اما در ادامه با 10 ویژگی اساسی به پایان می­رسد. ویا در میانه پروژه، نیازهای مشتریان تغییر می کند و باعث ارزیابی مجدد نیازهای پروژه می­شود. معمولا خزش در محدوده و محتوا پروژه به همین واضحی و روشنی رخ نمی دهد و این تغییرات معمولا به آرامی رخ می‌دهد. مشکل اینجاست که این تغییرات کوچک در هنگام وقوع توجه کسی را به خود جلب نمی کند و اغلب مدیر پروژه، ذینفعان و تیم پروژه به راحتی از کنار آن عبور می کنند، اما در انتهای پروژه، انباشته این خزش ها باعث تغییرات وسیعی در محدوده پروژه شده اند که باعث تحمیل هزینه فراوانی بر پروژه خواهد شد.

علل خزش محدوده:

  1. ناشناخته ها (Unknown):

پروژه ها به قلمرو ناشناخته می پردازند. گاهی اوقات پیچیدگی مشکلی که ما با آن مواجه هستیم دست کم گرفته می شود.

  1. کمال گرایی(Perfectionism) :

گاهی اوقات فراموش می کنیم که به اندازه کافی  و مورد نیاز، خوب وکافی است. این ماهیت ذهن است که به “بیشتر” تمایل دارد. طبیعی است که بیشتر بخواهید. ثروت بیشتر ، زمان بیشتر، ویژگی های بیشتر. اما ویژگی های بیشتر بی فایده، بی فایده هستند و تنها بار هزینه ایی و زمانی و.. به پروژه شما تحمیل می­کنند.

  1. آرام کردن اختلافات (Placating conflict):

ما هر کاری میکنیم تا از بروز درگیری جلوگیری کنیم. ما حتی حاضر هستیم تا محدودهو محتوای پروژه را گسترش دهیم تا تمامی ذی‌نفان متضاد و متعارض را راضی نگاه داریم. زمانی­که ما از این طریق به آرام کردن اختلافات می­پردازیم پروژه ای را به­وجود می­آوریم که کسی قادر به انجام آن نیست.

  1. اکتساب، حاکمیت (Acquisition):

گاهی به منظور حفظ منابع مصرف شده در یک پروژه شکست خورده، شروع به تعریف پروژه های دیگر برای افزایش کارآیی و یا بیرون کشیدن پروژه از شکست می­کنیم. اما این پروژه های جدید بار مختص به ­خود را به پروژه تحمیل میکنند و از طرفی در بعضی موارد، افزایش کارآیی غیر ممکن است. همانطور که در کتاب 1970 توسط نیکلاس تامالین و رون هال توضیح داده شد، الگوی زندگی او برای مقابله با پروژه های با محدوده در حال رشد، پنهان کردن الگوی شکست است. مانند دونالد کوهورست، بعضی از پروژه ها محدوده خود را گسترش می دهند تا از تصدیق شکست ها جلوگیری شود. شکست و یا راه اندازی مجدد باید گزینه های واقع بینانه برای هر مدیر پروژه باشد.

  1. پیشرفت شغلی (Career advancement):

مدیران یا رهبران یک پروژه می توانند قدرت های سازمانی خود را تقویت کنند. مدیران ارشد باید یاد بگیرند که این تاکتیک ها را تشخیص دهند و تنها بر اساس اصول مدیریت صحیح، گسترش دامنه را تأیید کنند. گاهی به دنبال ایجاد یک پیشرفت مسیر اشتباهی بکار گرفته میشود. جذابیت ظاهری یک اقدام و عدم بررسی تمامی جنبه های یک تصمیم می­تواند باعث خزش محدوده ومحتوا و ایجاد بار منفی برای پروژه شود.

  1. انتظار کاربران (Users need this feature):

همیشه یک کاربر وجود دارد که نیاز به یک ویژگی بیشتر دارد. و اگر این کاربر یک مشتری کلیدی باشد، این ویژگی قطعا به لیست ویژگی­ها افزوده خواهد شد. اما اغلب نیازهای اضافه مشتریان غیرمنطقی هستند. این آرزوها برای مشتریان هیچ هزینه ای ندارند، اما قطعا تیم پروژه برای آنها هزینه می کنند.

برای فهم بهتر، مثالی از یک بسته نرم افزاری که برای کارکنان فروش ما طراحی شد را برایتان شرح می­دهم. توسعه‌دهندگان ما متقاعد شدند که بدون تغییر در برنامه، “فقط یک ویژگی دیگر” به بسته نرم افزاری اضافه کنند. آنها توافق کردند که در حال حاضر کد منبع این ماژول را ویرایش می­کنند، بنابراین هیچ تغییر بزرگی در کار نیست، با این حال، در مرحله بعدی، تیم تضمین کیفیت ما با یک لیست طولانی تر از ویژگی ها برای تست، مواجه شد. تغییری کوچک در کد منبع باعث بروز تغییرات کیفی بسیاری در حوزه های دیگر شده بود، که بر برنامه زمان بندی آنها تاثیر گذاشت.

  1. اتحاد همه سوء تفاهم ها (The union of all misunderstandings):

اگر محدوده و محتوا، در ابتدا به وضوح تعریف نشده باشد، بدفهمی ها قوت می­گیرند. هنگامی که این اتفاق می افتد، برای حفظ توافق در مورد اینکه پروژه باید ادامه یابد، ممکن است ما مجبور به گسترش دامنه پروژه باشیم تا شامل همه­ی توافق های اولیه شود. جنگ اول به از صلح آخر!

جمع بندی

خزش محدوده و محتوا در اغلب پروژه ها رخ می دهد، اما آیا خزش همیشه بد است؟  یک مدیر پروژه موفق، کسی است که بتواند در مواقعی که لازم است تغییرات لازم را در پروژه پیاده سازی کرده و از تغییرات غیرمفید در پروژه جلوگیری کند. در واقع وقوع تغییر در پروژه اجتناب ناپذیر است. بی شک با گذشت زمان اطلاعات بیشتری از پروژه و عدم قطعیت های آن در اختیار تیم پروژه قرار می گیرد. پس”وقتی نمی توان از وقوع تغییر جلوگیری کرد، باید آن را کنترل نمود. اگر یک فرایند سفت و سخت برای جلوگیری از تغییر در محدوده وجود داشته باشد، مدیران پروژه به طور غریزی، تغییرات محدوده­ای که برای پروژه سودمند هستند را رد می­کنند. ما این را “کشتن محدوده” می نامیم. تیم پروژه باید تغییراتی را که حامی یا دیگر اشخاص مجاز، مفید تشخیص می­دهند اعمال کنند. خزش محدود علل متعددی می­تواند داشته باشد. با شناخت ریشه این تغییرات می­توانیم تصمیم گیری بهتر و هدف­مندتری برای مدیریت پروژه خود داشته باشیم.


PMPiran

PMP

مجموعه PMPiran با سال‌ها تجربه در حوزه آموزش و مشاوره مدیریت پروژه


2 پاسخ

  1. پوراقا نیم‌رخ
    پوراقا

    عالی وسودمند

  2. محمدی نیم‌رخ
    محمدی

    سلام ببخشید یه سوال اگر پروژه ای مثلا سد سازی که شامل چند محصول می باشد در یکی از محصولات تغیر نقشه ای ایجاد شود و یا قسمتی به اون محصول جزعی اضافه شود خزش محدوده اتفاق افتاده یا ملاک خزش کل پروژه رو شامل میشه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *