Pin Me

The Why and the How of Project Scope Creep

written by: N Nayab • edited by: Ronda Bowen • updated: 8/25/2011

Conventional project management wisdom recommends planning a project before execution, but incorporating new interests to project requirements at different stages of project execution is commonplace and unavoidable. Such changes however can make or mar a project, and require due diligence.

  • slide 1 of 3

    Causes

    Project Scope Creep Usually changed circumstances dictate the need to incorporate new interests, or scope creep to existing project requirements. Today’s business environment is in a rapid state of flux, and fast-paced changes are the order of the day. In such a scenario, new technologies or developments may make some components of the projects obsolete overnight, or require inclusion of some additional features to ensure competitiveness.

    Scope creep may also come owing to a poor planning, with the project poorly defined in the first place, requiring changes during execution phase. Part of the problem may also be indecisive or inexperienced project managers who cannot come to a decision, do not understand the requirements fully or underestimate the complexity of the problem. Too many stakeholders with competing interests to the extent that they keep on arguing about the functionalities makes it impossible to reconcile all interests at the onset, and the project manager invariably gives in to conflicting interests of stakeholders depending on the extent of pressure each stakeholder apply, throughout the project execution phase, to avoid conflicts.

    At times, requirements may change when the project venture into the unknown, with no one knowing exactly how it would unfold at the onset.

  • slide 2 of 3

    How to Incorporate

    Approving New Interests to Project Requirements The best way to incorporate new interests is to infuse flexibility in the project plan. A thorough requirements gathering and a well-crafted project initiation documents leads to a robust work breakdown structure, but for projects with changes of changes in requirements, it is best to leave the work breakdown structure flexible, and not go into too much detail at the initiation stage. The work breakdown structure in such cases should ideally cover the broad outline and resource allocation, with the specifics worked out only some time before actual implementation.

    To accommodate further changes during implementation phase, break the project into major and minor milestones, leaving considerable slack time, of say, about 150 percent of the time normally required.

    Incorporating the possibility of changes in the project plan itself is another way of accommodating scope creep. Have a specific change request system in place for stakeholders make a formal request to change. On receipt of such a request, project managers may discuss the cost-benefit analysis and accept the case. Acceptance automatically triggers a notification to finance, resources, human resources and other departments. Project a band-value rather than absolute values in the initial financial, human resource, and deliverable schedules to cater to possible changes. A key requirement fo smooth execution of this approach is awareness training for the project drivers.

    Extending this concept further, structuring the project in an entirely different way may also work at times. Traditional project management is waterfall or sequential based, and changes in any one element cause changes everywhere. A modular approach of breaking down the project intro smaller units or parts, completing each unit independently, and joining it together helps. In such cases, the changes requirements affect only the specific module. This approach suits software and other projects, but may not be possible for all projects.

  • slide 3 of 3

    How to Avoid

    Regardless of the flexible approach, scope creep and adding new interests to existing projects results in all plans going awry. For instance, the new requirements may require repeating the recruitment process for additional workforce, and re-doing the budget and costing all over again for new resources. As such, most project managers try to avoid it as far as possible. The following are some ways top do so:

    • Establish effective channels of communication with project stakeholders to gather all requirements and clarify expectations at the onset
    • Delay freezing the project initiation documents and work breakdown structure until the last possible moment, to incorporate as much of the changed requirements as possible
    • Circulate a draft scope statement for feedback before finalization, to ensure all stakeholders understand what is going on
    • Understand priorities and evaluating whether the request for change fits in with such priorities. Some request for change may be “gold plating" or unnecessary add-on under the mistaken notion that such add-ons add value (when they don’t). At times, the customer may be trying to eke more without spending extra. At other times, influential parties involved in some part of the project may prompt incorporating new interests to cover up their failure or mess-ups. Altering the requirements would result in re-working the budget, timelines, and other projections, giving such parties a good opportunity to cover-up their misdeeds. Project managers can resist incorporating such changes.

    Incorporating new interest to project requirement is a double-edged sword. It may either that the project retains its relevance, or conversely result in the project the project missing deadlines, going above budget, and in short turning into a commercial disaster for the executioners.

References