Hardly anyone who has managed a software project has not had a project that just will not end. The reason those projects never seem to finish is not necessarily inexperienced personnel or a flawed technology. The common cause is allowing requirements to pass in and out of the revolving door of project scope. There are several simple rules to effectively manage this experience known as scope creep.
Plan for Scope Creep
Scope creep is the weed that grows from seeds of unclear planning. The kickoff meeting is the event where the rules for handling scope creep are addressed. Scope creep should be managed through a formal change control document. Change control refers to modifications to the business or technical requirements once sign-off has taken place.
Poor planning does not create change control. The identification of additional requirements is quite common beyond the planning stage. It is nearly impossible to anticipate all the requirements during planning, development and even into testing. In many instances the testing phase is where gaps in requirements become most apparent.
There are situations when change control is imperative for the success of the project, but planning and communicating the process for change will reduce the element of surprise for all project participants.
Get Formal Sign-off
Scope creep occurs more frequently when formalized sign-off does not take place. Some corporate cultures avoid actual sign-offs like the plague. This is largely due to an underlying fear of accountability when requirements are not completely understood. Therefore, ensure that project stakeholders have a clear understanding of what is and is not delivered during the project. The stakeholders required to sign-off, who do not clearly understand or agree with the requirements, often are the sources that desire major changes to scope.
The advent of email has allowed for a higher level of comfort with sign-off. Many stakeholders are reluctant to physically sign a document, but have no problem responding via email that they agree with the requirements.
Although not a preferred method, verbal agreements in a team meeting can be used for sign-off. It is important to document in the meeting minutes all individuals, by name that verbally agreed with the requirements.
Those who sign off and understand the expectations of the project are less likely to institute a change control. Although, there are times when change control makes sense and is necessary for the success of the project.
Document Change Control
The change control outlines the business justification for adding or deleting requirements that were agreed upon earlier in the project. The modifications can, and will likely, result in code changes, re-testing, later delivery dates and demand on resources.
At the kickoff meeting, it should be determined who produces the change control document. It is always a good idea to have the initiator complete the change control. The approval process for change control also should be outlined upfront. There are several variations depending on the complexity of the project and/or project office methodology. The most common are core team approval, business sponsor approval, steering committee approval or any hybrid combination.
The impacts to various components of the project should be quantified and evaluated against the value of the enhancement to the requirements. This exercise quickly differentiates the “nice to haves” from critical requirements.
Know When to Say ‘No’
The project manager’s responsibility is quality delivery in a timely manner with minimal cost. Scope creep usually negatively impacts at least two of the three elements (timeliness and cost-effectiveness). This must be weighed against the benefits of the enhanced requirements.
Project managers rarely have unilateral authority to decide what is included or excluded from scope, although they certainly can influence the decision. Other project participants often rely on the project manager’s best judgment for what to attempt in the scope of the project. Phased-in approaches to projects allow for the iterative benefits and compromises to added requirements that result in win-win scenarios for those who prefer additional enhancements and those who do not.
Conclusion: Plan to Manage
Scope creep almost always presents itself within the lifecycle of a project. Therefore communicate the process for addressing change at the kickoff meeting. Project participants that have a clear understanding of the components in the delivered project are less likely to ask for enhancements in mid-stream. It is the project manager’s responsibility to ensure that all project stakeholders have been communicated to and understand the objectives of the project. When changes are required, it is important to document the business justification with specific impacts to timing, cost and resources in order to ensure decision-makers have all the necessary information to weigh the value against. Project managers typically are influential members of project teams and should use their influence to advise what is best for the overall project.
Advanced planning will allow the project team to manage scope creep instead of having scope creep managing the project.