Blog - IT CSI

How to Avoid this Pitfall

(Managing Projects blog 6 of 8)

Whenever something goes wrong in a project’s performance it is often blamed on “scope creep.” Scope creep has become such a familiar feature in project management that it is mostly accepted as the correct reason and even worse, being accepted as a fact of project life. The prevailing belief is that it cannot be helped, it is “beyond the PM’s control,” and therefore is part of the necessary evil in managing projects. Not True!!

To decide what to do about this scope creep excuse we need to first investigate the reasons why we are experiencing scope creep. We will make suggestions what could be done to minimize the probability of experiencing the scope creep situation. The most common reasons for experiencing scope creep include the following:

• Poor initial alignment of stakeholder expectations – We dealt with this in section one. This is when the initial requirements or expectations are not actively discussed, detailed and aligned with the end-user and/or customer. We are undertaking this project to satisfy a customer need and if not met and completed we will not be able to earn revenue with this service.
  
  
• Poor initial scoping of the project – The customer agreed to expectations and requirements, which are interpreted in project deliverables that would be summarized by the project’s scope. If we do not understand the exact implications of the customer needs then the chances are poor that we would be able to interpret this in appropriate deliverables. This results in a poor scope that will have to be modified as we progress through the project. uPoor monitoring and control – If you were not keeping your finger on the pulse, how will you know that you need to take action? Taking action could avoid additional actions and hence avoid pressure on scope requirements. u uPoor “feedback loop” – Not getting feedback in time or not getting feedback in specific enough details could also put pressure on the initial scope. Most project issues can be resolved fairly successfully if detected and action taken in time. Getting into the habit of identifying GAPS with the project requirements early could save you and your project a lot of time, effort and rework.
  
  
• “Poor speak” – This is all about being specific and again this was covered in detail in section three. Specificity plays a major role in all of the bullet points above. Not verifying in detail what has been communicated can leave room for personal biased interpretation, which is not good.
  
  
• Legitimate reasons – This is where we had technology improvements or the scope of the project genuinely altered due to market or condition changes. 

So, how do we suggest you tackle this issue of scope creep successfully? Firstly, we suggest that you do not freak out when it happens, but immediately try to find the underlying reasons why it occurred. Knowing what caused it might alert you to future similar problems with this same project and you need to treat this instance as a warning sign of what is to come. This should be the ideal time to fix the problem and to avoid more serious potential future scope creep situations.

We would suggest the following strategy:

1. Based on past experience it all starts with having vague, ill defined or poorly stated client/end-user expectations. Do not use a “junior” person to formulate the client expectations, because they do not always have the necessary business experience to interpret what the business meant by a specific requirement. You might think that this is going over the top, but we can guarantee you that you will “thank your stars” over and over as you progress through your own project. This is going to save you many iterations of the project scope.
   
   
2. Once you have all the expectations you need to translate this into project deliverables. This is not easy to do and we suggest you do this in small teams with a combination of stakeholders until you have your final list. This final list should state emphatically what is not included in these deliverables. There is nothing more clear than stating what will not be delivered.
   
   
3. In the midst of all this is the nagging requirement of being as specific as possible. This is true for all the points above. The listing of expectations and project scope deliverables to the way the internal project communications are handled needs to be highly specific.
   
   
4. Create an effective feedback loop that ensures you and your staff have their “ears to the ground” all the time to gather project intelligence. Nothing can be as effective as being proactive. This will also ensure that if anything does go wrong, it is contained and dealt with quickly and effectively.