scope creep Archives

Tag Archive for: scope creep

A project manager is tasked with keeping everything running smoothly, from project launch to completion. Scope creep, which happens when stakeholders unexpectedly change requirements and demands, occurs in about 52% of projects, and the consequences can be serious.

Imagine that a customer is hiring a package solution vendor to migrate data into a new package. Halfway through the project, the customer decides to add six additional data conversions to the workload. The customer believes the workload is within the original scope, but the vendor disagrees. This miscommunication leads to frustration, lost time and, ultimately, the project’s cancellation.

Scenarios like these can be avoided when you reexamine how you handle project scope management and make changes that improve communication and processes. Stakeholders will have a clear understanding of what tasks are in scope, and when something comes up that is out of scope, everyone will have a road map of how to move forward.

What is project scope?

A project has both a product scope and a project scope. The concepts sound similar, but there are major differences. Features and functionality are the main focus of the product scope. The work that needs to be completed to deliver on the product scope is the focus of the project scope.

Product scope: features and functionality of the product

Imagine a project that is focused on building a new software application. The product scope is to create a new workflow application that meets the requirements of the internal and external stakeholders. Project scope management will ensure the work gets done accurately, on time and without potential miscommunication.

What is scope creep?

Projects can get bloated with extra tasks that weren’t included in the initial discussions. Project scope management clearly defines what is and what is not included in the project.

A natural control mechanism is created that helps if a client decides to add tasks to the project that weren’t included upfront. Customers won’t always understand why the work isn’t in scope if you can’t refer them to the initial approved document.

For example, a customer might decide they want to include an online tutorial to help users with a new learning system. This expands the scope of the project and adds more work for your team. Investing time in project scope management will protect you from scope creep and make sure your team gets paid more if work is added to the project.

How are project scope and project requirements different?

The project scope defines the specific work that needs to be completed. Project requirements are focused on the specific items that should or should not be included in the project. What does the user want from the product? The answer to this question will shape the project requirements.

A carpenter requires the ability to drill holes that are two inches deep. Accomplishing this requires the carpenter to have a drill bit that is capable of drilling two-inch-long holes.

The scoping of the project is focused on the materials and processes that go into creating the drill bit that is able to drill a two-inch-deep hole. Typically, requirements are scoped during each phase of a project rollout.

What is involved in project scope management?

A project scope management plan will help you proactively avoid scope creep and ensure that your customer receives the outcome they expect. This process includes involving key stakeholders in the conversation early to get a clear definition of the project and what is and isn’t included. There are several important aspects of scope management, which include:

Kick off the scope management process. Who are the key stakeholders for the project? Define these stakeholders upfront, and set expectations for what to expect and what will be required of the client.
Define the necessary requirements. This is an information-gathering stage. Hold interviews with stakeholders, take surveys and begin a deep dive into what’s required to make the project a success in the eyes of the customer.
Create a project scope statement. With research in hand, you can now define project scope. This definition is important because it’s the backbone of all upcoming project activities and will serve as a guide during the project. A project manager should be able to look at it and determine what is included in a scope. For example, if an additional request comes up, the project manager can ask “What is the project scope?” and “Does this task fit into that scope?”
Seek approval of the scope of a project. It’s critical to have the customer’s formal approval of the project scope. If scope creep happens in the future, you can redirect the client to the agreement and figure out the best way forward.
Define the work breakdown structure (WBS). Everyone knows that if you’re completing a large project, you need to break it down into small pieces. The WBS is where this happens. You are clearly defining the deliverables at each turn in the project.
Validate the project scope. A project manager needs to continually check to ensure the scope of the project is being controlled. This may include matching performance reports to project requirements to identify any potential gaps. And if changes are required, it could include going back to the initial agreement to determine if those fit within the scope of project or a change order is required. Ultimately, the goal is to ensure that the deliverable is completed on time and within budget.

Most people have heard the expression “measure twice, cut once,” and that’s what you’re doing during project scope management. The project scope management process is time-consuming, but investing at this stage of the project has the potential to save you time, money and frustration in the future. Everyone understands what work is required upfront, and they can easily stay focused on the final delivery.

Accommodating increases in scope

There will be times when the customer wants to add work. The scope will make it clear the work is outside the original agreement, but you can still accommodate those requests with a few strategies:

Define functions with lower priority or less time sensitivity than were planned for the current release in order to create room for scope additions.
Bring on more development staff to handle the additional tasks and reach your target launch date.
Outsource some of the work to meet the client’s deadline.
Extend the schedule for the current release to accommodate the requested additions to the project functionality.

If you’ve done a thorough job during project scope management, it will be clear that the client will need to pay more to accommodate the request. But you can still keep the customer happy by staying agile to meet their deadline or making other accommodations.

Avoiding common scope management pitfalls

If you want to improve project scope management, it helps to understand common pitfalls. There are mistakes that many companies make that transform happy customers into frustrated and confused customers. Consider these common pitfalls when creating scope management documentation:

Work that is not clearly defined. Ambiguity is not your friend in the area of scope management. A lack of clarity opens the door to confusion and the prospect of completing unnecessary work. Clearly define the scope and leave no room for misinterpretation.
An incomplete scope. The scope should include all critical elements of a project. No area is too small to include, because if the scope is incomplete, the potential cost is high.
A lack of collaboration. Stakeholders are a critical part of scope management because they are the ones who clearly define project requirements. Make sure that no key stakeholders are left out of the process or, worse, added later, when the project scope has already been defined.
A lack of formal approval of the scope. All stakeholders need to formally approve the project scope. Receiving buy-in keeps you on track and helps you anticipate potential challenges before you’re underwater in project tasks.

Understanding potential pitfalls upfront will assist with successfully navigating the scope management process. But it’s also important to periodically evaluate your technology tools and ask whether there are tools available that could help you manage projects more effectively. Many technologies can help you streamline projects and gain greater efficiency.

Tools and software that help manage project scope

Technologies and tools can help you build complex products, systems and software to improve cycle times, increase quality, reduce work and mitigate efforts in proving compliance. A requirements management software program can be leveraged to help software teams include test and risk management capabilities, enabling teams to scale their product development.

Jama Connect helps you deliver high-quality products on time and on budget by aligning stakeholders through efficiency and collaborative reviews; identifying risk early; and visualizing connections between regulations, requirements and test cases through the development process.

See how Jama Software helps product teams define and manage scope by downloading our solution overview.

There are many reasons why a project might stray from its original plan, but a leading factor is often underestimating complexity at the project’s outset. And that mistake is costing companies.

McKinsey recently analyzed 1,800 completed software projects and 1,600 integrated-circuit design projects for a deeper understanding of the state of product development.

The study found that only 30% of software projects met their original delivery deadline, while the average overrun was around 25%.

With hardware projects, the problem was worse: More than 80% of projects were late and the average overrun was nearly 30%.

Overruns such as these cost companies greatly, with both a direct impact on budget and an indirect effect on market position and perspective. This is a tough problem to tackle, especially when teams are building increasingly complex products at a faster rate than ever before.

At Jama, we believe the way to overcome this challenge is to make your development process more standardized. Here are three ways to take your development process to the next level and decrease costly overruns for good.

Focus on the Definition Stage

Multiple handoffs, interactions and iterations take place throughout the development process. Yet, because of antiquated and disparate tooling, teams are often disconnected and lack visibility into what other groups are doing or how those actions affect scope.

The result is often tradeoffs without market context. This can lead to scope creep and quality issues entering the process downstream, all due to poor communication in earlier development stages.

To smooth handoffs and create a refined process, you need to focus upstream at the definition phase of development. If you get that right, you can mitigate issues downstream so they don’t become much larger and more significant problems.

Use the Right Tools for the Job

Products are more complex than ever, so it follows that development of those products has grown more complicated. Still, many companies continue to use the same, unstructured tools they’ve always used in their development process.

Today’s highly structured, highly governed work requires technology that can not only withstand the changing landscape but also ease the transition and manage complexity at scale.

Modern product development platforms like Jama Connect empower your teams and support the workflow you need to compete in today’s market.

Managing complexity at scale means defining relationships among requirements and items through to defects, as well as validating and verifying that what you’re building is what the market needs.

This is exactly what Jama Connect™ provides. Seamless integrations with best-in-breed tools like Jira Software increase the visibility of activities across a unified environment.

You can operate with the confidence that your teams are working collaboratively; your review process supports your structure, and you can deliver on time – all with live traceability along the way.

Avoid Past Mistakes

Teams often underestimate complexity because they believe that issues they’ve encountered in the past won’t come up again. Avoiding past mistakes requires leveraging what you’ve already done and benchmarking for the future. A structured approach backed by consistent data lets you see how projects are progressing in real time.

To dive deeper into the relationship between rising product complexity and effective requirements management, download our report: “Design Teams: Requirements Management & Product Complexity.”

Requirements will change and grow over the course of any software project. This is a natural aspect of software development. In fact, if a project doesn’t experience some requirements evolution, the team likely is ignoring reality and risks releasing an irrelevant product. The prudent project manager anticipates and plans to accommodate some requirements growth.

Scope creep (also known as feature creep, requirements creep, featuritis, and creeping featurism), however, refers to the uncontrolled growth of functionality that the team attempts to stuff into an already-full project box. It doesn’t all fit. The continuing churn and expansion of the requirements, coupled with inadequate prioritization, makes it difficult to deliver the most important functionality on schedule. This demand for ever-increasing functionality leads to delays, quality problems, and misdirected energy.

Scope creep is one of the most pervasive challenges of software development. The techniques I described in the first two articles in this series (adapted from my book More about Software Requirements) provide several ways to define a project’s scope. In this final article in this series, I’ll give you some suggestions about how to manage the insidious scope creep.

The first step in controlling scope creep is to document a clearly stated and agreed upon scope for the project. Without a scope definition, how can you even tell if you’re experiencing scope creep? Project teams following an agile development life cycle should write a brief scope statement for each iteration. This helps make sure that everyone understands the goal of the iteration and what functionality the team will—and won’t—implement during that iteration.

An ill-defined scope boundary can have serious consequences. In one situation I know of, a customer had hired a package-solution vendor to migrate three sets of existing data into the new package. Partway through the project, the customer concluded that six additional data conversions were required. The customer felt that this additional work fell within the agreed-upon scope, but the vendor maintained that it was out of scope and demanded additional payment. This scope ambiguity, and the resulting conflict, was one factor that led to the project being cancelled and a lawsuit being filed. Not the desired outcome.

The second step for managing scope creep is for the business analyst or project manager to ask “Is this in scope?” whenever someone proposes some additional product capability. This could be a new or extended use case, a set of functional requirements, another user story, or a new feature or report. Note that the project scope could also encompass activities and deliverables besides the software products themselves. Perhaps your customers suddenly decide they want an online tutorial to help users learn the new system. This doesn’t change the software deliverables, but it certainly expands the scope of the overall project.

There are three possible answers to the question, “Is this in scope?” If the new capability is clearly in scope for the next release, the team needs to address it. If it’s clearly out of scope, the team does not need to address it, at least not now. They might schedule the new capability for a later release.

Sometimes, though, the requested functionality lies outside the scope as it’s currently defined, but it’s such a good idea that the management sponsor should expand the project scope to accommodate it. Less frequently, a proposed change could even modify the strategic product vision in some fundamental way. The question to consider is whether the proposal to expand the scope of the current release will significantly enhance the success of that release.

Electing to increase project scope is a business decision. When weighing whether to increase project scope, the key stakeholders need to consider cost, risk, schedule, and market or business implications. This demands negotiation between the project manager, management sponsor, and other key stakeholders to determine how best to handle the scope alteration. Referring to my three-level model of business, user, and functional requirements, the stakeholders must decide whether proposed changes in user or functional requirements will become the project manager’s responsibility through a scope expansion (Figure 1).

Following are some possible strategies for accommodating a scope increase:

Defer some lower-priority or less time-critical functionality that was planned for the current release or iteration to make room for the proposed scope additions.
Obtain additional development staff to handle the additional work.
Obtain additional funding, perhaps to pay overtime (OK, this is just a little joke), outsource some work, or leverage productivity tools.
Extend the schedule for the current release to accommodate the extra functionality. (This is not a joke.)
Compromise on quality by doing a hasty job that you’ll need to repair later on (not your best option).

Increasing the project’s scope—or, even more profoundly, the product vision—always has a price. The people who are paying for the project must make a considered decision as to which scope management strategy is most appropriate in each situation. The objective is always to deliver the maximum customer value as soon as possible, while achieving the defined business objectives and success criteria, within the existing constraints.

There’s no point in pretending the project team can implement an ever-increasing quantity of functionality without paying a price. In addition, it’s always prudent to anticipate a certain amount of scope growth over the course of the project. A savvy project manager will incorporate contingency buffers into project plans so the team can accommodate some scope growth without demolishing its schedule commitments. This isn’t simply padding or a fudge factor. Thoughtful contingency buffers are simply a sensible way to deal with the reality that things change and projects grow.

Effective scope management requires several conditions be met:

The requirements must be prioritized so that the decision makers can agree upon the capabilities to include in each release or iteration, and so they can evaluate change requests against the priorities of unimplemented requirements in the backlog.
The size of the requirements must be evaluated so that the team has an approximate idea of how much effort it will take to implement them.
The team must know its average productivity (or velocity, in agile terms) so it can judge how many requirements or user stories it can implement and verify per unit time.
The team must assess the impact of change requests they have a good understanding of what it will cost to implement each one.
The decision makers need to be identified and their decision-making process established so they can efficiently decide to modify the scope when appropriate.

Don’t be victimized by the specter of creeping scope or attempt in vain to suppress change. Instead, establish a clear scope definition early in the project and use a practical change control process to cope with the inevitable—and often beneficial—requirements evolution.

Check out Part 1, Defining Project Scope: Context and Use Case Diagrams

Check out Part 2, Defining Project Scope: Feature Levels and System Events

Learn how product development teams can leverage analytics to improve efficiency and quality in “The Essential Guide to Software Development Team Metrics.”