project scope Archives

Tag Archive for: project scope

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.

In part 1 of this three-part series, adapted from my book More about Software Requirements, I described the importance of documenting the scope of each software development project or iteration. The context diagram and the use case diagram are two useful techniques for representing scope. This article describes two other methods for documenting scope: feature levels and system events.

Feature Levels

Customers, marketers, and developers often talk about product features, but the software industry doesn’t have a standard definition of this term. I define a feature as: “A set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective.” Features are product capabilities that a user can recognize, as opposed to capabilities that the product needs to have “under the hood” but aren’t visible to end users. Marketing materials often state the features that the new (or improved) product will offer to the customer. Therefore, feature lists help customers make purchase decisions. You can think of each product feature as having a series of levels that represent increasing degrees of capability or feature enrichment. Each iteration or product release implements a certain set of new features and perhaps enhances certain features that were partially implemented in earlier releases. One way to describe the scope of a particular product release, then, is to identify the specific levels for each feature that the team will implement in that release. A sequence of releases represents increasing levels of capability—and hence user value—delivered over a period of time. During requirements analysis, the analyst determines just which functional requirements must be implemented in a particular release to deliver the planned feature levels, beginning with the top-priority or foundational levels of the top-priority features. To illustrate this approach to scope definition, consider the following set of features from our hypothetical cafeteria ordering system: FE-1: Create and modify cafeteria menus FE-2: Order meals from the cafeteria menu to be picked up or delivered FE-3: Order meals from local restaurants to be delivered FE-4: Register for meal payment options FE-5: Request meal delivery FE-6: Establish, modify, and cancel meal service subscriptions FE-7: Produce recipes and ingredient lists for custom meals from the cafeteria Table 1 illustrates a feature roadmap, which depicts the various levels for each of these features that are planned for implementation in forthcoming releases. FE-2 and FE-5 in Table 1 represent features that each have three enrichment levels, but there’s nothing special about three levels. Some product features may have four or five levels of increasing functionality enrichment. Others might just have a single level that’s implemented all at once, such as FE-1, Create and modify cafeteria menus, which the team will fully implement in the first release. The full functionality for each of these features is delivered incrementally across the three planned releases. The analyst can also indicate dependencies between features or feature levels. As an illustration, the level of FE-2 scheduled for release 1 will let users pay for meals by payroll deduction. Therefore, the capability of FE-4 that lets users register for payroll deduction payments cannot be deferred to a later release, because the first level of FE-2 depends on the first feature level of FE-4. Understanding these dependencies is essential for effective release planning. Notice that this sample feature roadmap indicates that the team won’t work on feature FE-3 at all until the third planned release. Also, feature FE-6 is of lower priority than the others. We’d like to get it out in the first release if we can, but it’s okay to defer it to release 2 if necessary. Table 1: A Sample Feature Roadmap

Feature	Release 1	Release 2	Release 3
FE-1	Fully implemented
FE-2	Standard individual meals from lunch menu only; delivery orders may be paid for only by payroll deduction (depends on FE-4)	Accept orders for breakfasts and dinners, in addition to lunches; accept credit and debit card payments	Accept group meal orders for meetings and events
FE-3	Not implemented	Not implemented	Fully implemented
FE-4	Register for payroll deduction payments only	Register for credit card and debit card payments
FE-5	Meals will be delivered only to company campus sites	Add delivery from cafeteria to selected off-site locations	Add delivery from restaurants to all current delivery locations
FE-6	Implemented if time permits	Fully implemented
FE-7	Not implemented	Not implemented	Fully implemented

The feature level approach is the most descriptive of the four techniques I’m presenting for defining the project scope. The farther into the future you look, the less certain the scope plans become and the more you can expect to adjust the scope as project and business realities change. Nonetheless, defining the product vision and project scope lays a solid foundation for the rest of the project work. This helps keep the team on track toward maximizing stakeholder satisfaction.

System Events

The final scoping technique I’m going to describe focuses on external events the system must detect. Each event causes the system to produce a particular response. There are three types of system events to consider:

Business events, which are user actions that cause the system to respond in some way. The trigger that initiates the execution of a use case typically is a business event.
Temporal or time-based events, such as scheduled program executions. Examples are automatically producing a database extract at the same time every night or having an antivirus program check for virus signature updates once an hour.
Signal events, which could be input signals received from sensors or switches in a system that contains both software and hardware components.

Event analysis works well for real-time systems. Consider a complex highway intersection. It might include road sensors and cameras to detect vehicles (though sometimes they don’t seem to spot me when I’m on my motorcycle), traffic lights, buttons pedestrians can press to cross the street, pedestrian walk signals, and so forth. This system has to deal with a variety of events, including these:

A sensor detects a car approaching in one of the through lanes.
A camera detects a car approaching in a left-turn lane.
A pedestrian presses a button to request to cross a street.
One of several timers counts down to zero.

At the scope level, you can just list the external events to which the system must respond without worrying about additional details. For an iterative development approach, you can allocate the handling of specific events to different iterations or releases. This initial events list also leads nicely into more detailed functional requirements specifications, expressed in the form of an event–response table. Exactly what the system does in response to an external event depends on the state of the system at the time it detects the event. Table 2 presents a fragment of what an event–response table might look like for such a system. This sort of layout is an effective alternative to the traditional list of natural-language functional requirements, which can be tedious to read and review. Table 2: Partial Event-Response Table for a Highway Intersection

Event	SystemState	Response
Road sensor detects vehicle entering left-turn lane.	Left-turn signal is red. Cross-traffic signal is green.	Start green-to-amber countdown timer for cross-traffic signal.
Road sensor detects vehicle entering left-turn lane.	Left-turn signal is green.	Do nothing.
Green-to-amber countdown timer reaches zero.	Cross-traffic signal is green.	Turn cross-traffic signal amber. Start amber-to-red countdown timer.
Amber-to-red countdown timer reaches zero.	Cross-traffic signal is amber.	Turn cross-traffic signal red. Wait 1 second. Turn left-turn signal green. Start left-turn-signal countdown timer.

Now that we’ve seen several methods for representing a project’s scope, in the final article in this series I’ll offer some suggestions about how to effectively manage the dreaded specter of scope creep. Check out Part 1, Defining Project Scope: Context and Use Case Diagrams Check out Part 3, Defining Project Scope: Managing Scope Creep Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.