iSixSigma

Beat the Omnipresent Scope Creep With Communications

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.

Handpicked Content :   An Affinity for Scope

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.

Handpicked Content :   Current Reality Tree Helps to Identify Hidden Barriers

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.

Handpicked Content :   Successful LSS Projects Start with Proper Metric Selection

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.

Handpicked Content :   Goldilocks Dilemma: Getting Project Scope 'Just Right'

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.

Handpicked Content :   15 Criteria for Selecting a Viable DMAIC Project

Advanced planning will allow the project team to manage scope creep instead of having scope creep managing the project.

Comments 1

  1. Dima13

    Excellent material, Richard. Thank you. We, in my company, tried several methods already. And as always, the simplest has proved to be the most effective.

    As it turned out, our programmers (the team has only 15 people) do not like long meetings, regular monitoring, and reports – it annoys them and distracts from working. So at the end of it, we concluded that it needs only 2-3 techniques, which do not detract their attention away, while the project/product manager does the rest for them – analysis and grooming of tasks, prioritization of them, the implementation plan for new features, and so on. So, we employ the following practices:

    1. daily stand-ups, but not in the classic version, standing and alive, but through a bot in Slack. Even if the team is in the same office, they prefer this way of reporting and meetings
    2. retrospectives at the end of the sprint
    3. sometimes, quite rarely, we run polls on the current sprint or on the priority of tasks.

    0

Leave a Reply