After a few months of silence, I am back with my new blog post. The inspiration for this post is a recent website project I finalized last month. The project started with lots of uncertainty, missing information and lack of clarity on the overall outcome of the project. From the very beginning, I knew that the project has the potential to go out of scope. 

So, as a project manager, I took all the necessary steps from the very start to avoid scope creep or make my grounds strong to easily raise the change request in case we go out of scope. 


What is a scope creep? 


Scope creep occurs when there is an unaccounted change in the project product features and deliverables which changes the baseline cost and timelines of the project. 

So, some of the ways you can avoid scope creep are by: 

  • Involving all stakeholders right from the beginning: It is best that the project plan clearly specifies the name/designation of the stakeholders who have the right to approval.

  • Right estimation approach: It is best to closely work with the team to gather the estimates. To make it accurate follow the “Bottom-to-Top” estimation method where every project activity is estimated and the aggregate amount along with the profit margin is considered as a final project budget.

  • Defining scope clearly: When you prepare the scope statement make sure to include not only what is the agreed to be the part of the scope but also what is NOT the part of the scope. 

If you take care of the above points during the initiation phase, you would be able to avoid scope creep. 


Scope creep case study based on my experience


Recently I experienced the scope creep situation in one of my projects. The scope of the project was to design and develop a website based on the sitemap and content provided by the client. As we proceeded with the project, I clearly sensed that we are heading towards scope creep. 

Here are some of the quick points that led the project to go out of scope. 

  • Missing project details:  In the project initiation phase, we received the sitemap. But, as we proceeded further with the project, new pages were added to the website. Also, the content for some pages was provided only at the later stage which impacted the approved budget and the timelines.

  • Involvement of new stakeholders: During the course of the project, new stakeholders were involved who has the right to take the decision. Addition of new stakeholders led us to do some repeat work in order to incorporate their feedback.

  • Several rounds of amendments: We basically had 4 project phases-

    • Project initiation and planning – By then end of this phase, we shared the project plan including the project timelines in the Gantt Chart.

    • Website design suggestions and layouts – By the end of this stage, we shared the website page layouts and received the approval from the client to move to the next phase. 

    • HTML programming and CMS update – By the end stage, we shared the programmed version of the website on the Development/Test site and received the approval to start the final deployment of the website. 

    • Website launch and project closure – And, in the last stage, we deployed the website to the production server and make it “live”. 

We followed the waterfall project approach where we divide the project into different stages. And, at the end of each stage, we have a scheduled delivery. We moved to the next phase only when we received the sign off to the current stage.                

But, the project starts going out of scope when we received “request for change” after the approval of a certain phase. For example, Several design elements were requested to be changed in the development phase. It leads to double the work as the changes needed to be implemented both in the design and the programme versions. 

So, if you closely look at the case study above, there was no possibility to save the project from going out of scope. Isn’t it? 

So, in this situation, all I can do is to make my ground strong for raising the change requests. That’s what I did ?


How I handled the situation: QUICK TIPS


1. Align with the client from the beginning:

It actually makes your life easier if you are a proactive project manager. The moment you sense that the project has a chance to go out of scope, share it with the client upfront. 

If you are aligned with the client from the beginning and make him aware that we might need to raise a change request then when the real-time come, there will be no surprises! 

I believe that dissatisfaction usually occurs when something unexpected happens. But, if you are transparent with your client and involve them throughout the project, the chances of project heading towards failure reduces to a great extent. 


2.  Define scope for the approved budget clearly: 

At the time of finalizing the project plan, define the scope of the project as clearly as you can. As also specified above, make sure your definition of scope includes both – What is considered as a part of the scope and what is excluded from the scope. 

If your scope statement clearly defines what features or deliverables are not part of the approved budget, then it gives a clear argument with the client in order to raise the change request. 


3.  Negotiate new requests by flagging upfront:

As soon as you receive a request from the client, never start implementing it right away. The best approach is to first analyze the request, estimate the efforts and its effect on the approved budget and timelines, prepare the change request proposal and share it with the client. 

In this particular project, whenever I received a new request, I followed this process every time, without a fail! It was also very important to align closely with the commercial team who help you in creating the change request proposals. 


4.  Clearly define how to handle change:

Change is inevitable in any project. So, it is best that you are prepared for it. The project plan should clearly specify how to handle change. 

You need to agree with the client if they want to settle the change request budget upfront or only after the delivery of the project. Whatever they decide, you as a vendor/supplier should share the proposal upfront so that they know what is due for payment. 


Wrap Up: 

In this particular project, I kept the client informed about all the new requests upfront and we shared the change request proposal at the end of the project. As the client was involved throughout the project and I had the solid arguments for all the new requests, we got the approval for the new proposal and the project ended with a “Happy-Quote” from the client. 

So, as a project manager, it is very important to manage a project by being proactive, transparent and detailed oriented. It will definitely help you come out of a “Scope-Creep” situation smoothly. 

Leave a Reply

Your email address will not be published. Required fields are marked *