Scope creep can derail a project very quickly. Particularly when the initial requirements were vague and when there isn’t a change control process in place. It may seem ok to allow small changes to be made to the system in development, however these add up and eventually impact your schedule, budget or system quality – or even all three. No matter how influential the stakeholder is, any changes to scope should be properly assessed before being implemented.
Prevention is better than cure. In order to prevent sticky situations which could result in damage to stakeholder relationships, safeguards against scope creep should be put in place at the start of the project. Too often project initiation is rushed as sponsors and stakeholders put pressure on the project management team to start delivering. This is a mistake as without clearly defined, unambiguous project objectives the project team only have a vague idea of what they have to develop, therefore opening the project up to different scope interpretations, inaccurate requirements, gaps and of course scope creep.
Clearly defined project objectives
Project managers have to define a clear project mission statement with definitive project objectives and outcomes. They have to ensure that the scope is clear and well-defined, and importantly they have to ensure that scope exclusions are stated. Managing customer expectations begins right from the start of the project therefore sponsors and key stakeholders should be involved in clarifying the project mission statement so to avoid future misunderstanding. Once the project scope has been agreed it must be communicated to the wider project community so that everyone has a clear understanding of what the project will and won’t do, and so that the team works towards a common goal.
Scope creep control mechanisms
Even with a clearly defined project scope it would be naïve to think that there won’t be any change requests. Changes occur for many reasons, some of which will be valid. An agreed change control process must be established upfront to avoid any future conflicts with stakeholders or team members due to developers “slipping in” a quick change for the stakeholders. A formalised process ensures that all changes are managed properly, that their impacts are assessed and that effort is officially allocated thereby reducing the risk to the schedule or budget.
Comprehensive requirements analysis
Detailed requirements gathering should be just that. Sometimes business/systems analysts write the requirements at too high a level or will make assumptions based on their previous experiences, particularly when the stakeholders are difficult to get hold of. Both of these scenarios lead to gaps between the customer expectations and what is being delivered which in turn enables scope creep. When conducting detailed requirements gathering it is imperative that the right business users are involved, that a gap analysis is completed and all assumptions are validated. The requirements must be clear and unambiguous, and detailed enough so that the developers know exactly what to develop. All requirements should also be checked against the initial scope to ensure that they are aligned to the agreed scope.
Know your critical path
Your critical path identifies all the tasks that directly impact the project end date. Any changes to these activities could potential cause you to overshoot your delivery date therefore you need to understand and monitor your critical path. Uncontrolled scope creep will impact your critical path which is why when a change request is raised it must be properly analysed and its impact to your critical path assessed. You can then approve or reject the change request based on your analysis.
Preventing scope creep is all about having good controls in place, managing customer expectations from the start, and ensuring that everyone is clear on the project objectives. Sometimes it is difficult to say no to a customer demand but as long as you are respectful, include them in the decision-making by showing them the impact of the scope change and assure them that it will be logged as a future requirement, most customers will be understanding. After all they too want the project to be successful and delivered on time and too budget.