‎‎ ‎‎ ‎‎ ‎‎ 86- خزش محدوده یا Scope Creep - دروس آموخته

86- خزش محدوده یا Scope Creep

 یکی از مشکلات بسیار مهمی که تقریبا همه پروژه ها به نوعی با آن دست به گریبان هستند، خزش محدوده یا Scope Creep است. بر اساس تعریف ارائه شده در نسخه سوم راهنمای PMBOK، خزش محدوده عبارتست از "اضافه شدن مشخصات یا عملکردهایی به محدوده پروژه بدون توجه به تاثیر آن بر روی زمان، هزینه و منابع یا بدون تایید مشتری".

 


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

خزش محدوده در اغلب پروژه ها رخ می دهد و حتی می تواند در پاره ای از موارد باعث خارج شدن پروژه از توجیه اقتصادی گردد. اما آیا خزش محدوده همیشه بد است؟

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

یک مدیر پروژه موفق، کسی است که بتواند در مواقعی که لازم است تغییرات لازم را با لحاظ تاییدات مشتری در پروژه پیاده سازی کرده و از تغییرات غیر مفید در پروژه جلوگیری کند.

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

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

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

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

سپس این پیشنهادات باید ارزیابی گردیده و در صورت مفید و ضروری بودن برای پروژه، به تایید مدیر پروژه و مشتری و ذینفعان مربوطه برسد. در ارزیابی این پیشنهاد می توان از فنون توجیه اقتصادی نظیر (ROR) و غیره استفاده کرد. فاکتورهای مختلفی ممکن است در تایید یا عدم تایید تغییر دخیل باشند از جمله زمان، هزینه، مسائل فنی، اعتبار سازمان، منافع تجاری و غیره. اهمیت هر یک از این عوامل بسته به شرایط پروژه و محیط پروژه متفاوت خواهد بود. پس از تایید این تغییرات در تیم پروژه، گزارش مربوط به توجیه این تغییر باید به منظور تایید مشتری و ذینفعان مربوطه برای آنها ارسال گردد. نا گفته پیدا است که پیاده سازی یک تغییر، اگرچه توجیه پذیری بالایی نیز داشته باشد، بدون تایید مشتری امری خلاف منطق و عقل است. چون این مشتری است که به شما پول می دهد نه توجیه منطقی تغییر! شاید این جمله خیلی بدیهی به نظر برسد، اما باید بدانید که هم اکنون لحاظ نکردن این اصل بدیهی در پروژه ها، بخش اعظمی از Claim های بین پیمانکار و کارفرما در پروژه ها را به دنبال داشته است.

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

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

 

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

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

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

 

 

اشتراک و ارسال مطلب به:

  
نویسنده : صادق روزبهی- PMP ; ساعت ۳:٥٥ ‎ب.ظ روز ٢٢ دی ۱۳۸٧


‎ ‎‎ ‎‎ ‎
‎ ‎‎ ‎
‎ ‎
‎ ‎‎ ‎‎ ‎
‎‎ ‎‎