BUS605: Strategic Project Management

Time, cost, and scope are known as the triple constraints of project management. It's not possible to change one without changing at least one of the others. If the project takes twice as long as expected to complete, then the cost will almost certainly go up. On the other hand, a decision to cut costs, perhaps by using less experienced labor, could lead to a work slowdown, extending the schedule. Such a decision might also result in a change to the project's scope, perhaps in the form of a lower quality product.

The initiation phase is too early in the project to nail down precise details about time and cost, but it is a good time to think long and hard about scope, which is "all of the work that needs to be done to provide the product or service your project is delivering". In this early stage, you and the project stakeholders might do some blue sky thinking about what your project could possibly achieve, without regard to the constraints of time, cost, and scope. But before too long you'll need to zero in on a definition of the project's scope, formalizing it as a scope statement, using the information currently available to you.

Except for the simplest projects, any scope definition will almost certainly evolve as you learn more about the project and the customer's needs. The term scope evolution refers to changes that all stakeholders agree on, and that are accompanied by corresponding changes in budget and schedule. Scope evolution is a natural result of the kind of learning that goes on as a project unfolds – for example, learning that arises from fresh insights into the needs of the end user, new regulations, or upheaval in the marketplace. As long as all stakeholders agree on the scope changes (and the associated changes to the budget and schedule), scope evolution ensures that customers actually get what they want out of the project. The more you talk with the client and learn about their needs, the more you will be able to refine the scope.

Indeed, one of the main jobs of a project manager is managing scope evolution. But different types of projects will involve varying amounts of scope evolution. For example, if you're working on a project related to satisfying a specific environmental regulation, the initial definition of the project's scope might be clear, requiring little refinement as the project unfolds, as long as the regulation itself is not altered. But if you are working on a product designed to satisfy a brand-new market demand, you might need to refine the scope continually to ensure that you satisfy your customers' needs.

Perhaps the most common cause of scope evolution is a change in the context in which a project is planned and executed. Alterations in market forces, changing demographics, new or more vigorous competition, and technological advancements can all change a project's context, forcing you to rethink its scope. This potential for changing contexts means that no two projects are the same. You might think Project B is nearly identical to Project A, but then a sudden shift in context can change everything.  As shown in Figure 3-4, context is largely defined by the organizational, social, and political structures in which a project occurs.

While you need to stay open to the possibility of scope evolution, it's essential to resist scope creep, an uncontrolled cascade of changes to the scope with no corresponding authorized changes in budget and schedule. The difference between the two is the difference between managed and unmanaged change:

• Scope evolution is managed change. It is an approved alteration to the project scope that occurs as the project participants learn more about the project. It results in an official change in the project scope, and therefore to the project budget or schedule, as agreed to by all project participants. This kind of managed change is a natural and rational result of the kind of learning that goes on throughout the course of a project. It is a conscious choice necessitated by new information forcing you to reconsider project essentials in order to achieve the intended project value.
• Scope creep is unmanaged change. It is caused by uncontrolled changes to the project scope. Such changes might add value from the customer's perspective, but the time, money, and resources consumed by the change of scope lead to additional overruns. Scope creep tends to happen bit by bit because no one is paying close attention to the project's scope. For example, in a kitchen remodeling project intended to replace countertops and cabinets, deciding at the last minute to replace all appliances might be an example of scope creep.

Creating a Clear Scope Statement

The key to managing scope is a carefully crafted scope statement, which should be clear and precise. The details of how you plan to carry out a project may be vague at first, but want you want to achieve should be perfectly clear. Vagueness can lead to small changes to the project's scope, which in turn lead to other changes, and so on, until the original project is no longer recognizable.

Writing a scope statement, the document that defines the project's scope, is a major part of the initiation phase. However, according to Brad Bigelow in an article for the Project Management Institute, it is "usually expressed in qualitative terms that leave room for interpretation and misunderstanding. Consequently, it's often the biggest source of conflicts in a project".

To avoid such problems, experienced project managers put a lot of effort into learning what should and shouldn't be included in the project, and then articulating these boundaries as clearly as possible in the form of a scope statement. According to Bigelow, this work is essential to ensuring a project's success: "No project's scope can ever be entirely free of fuzziness – free from subjectivity and imperfect definitions – as long as human beings are involved. On the other hand, it's also highly improbable that any project will ever survive initiation if its scope is entirely vague, undefined, and subject to unpredictable expectations".

If the scope is poorly defined, then what is or isn't within the project scope is reduced to a matter of perspective. Not surprisingly, these "different perspectives…can often be the root of conflicts within a project". Bigelow describes a project in which the team and the customer see things very differently:

When the scope is poorly defined, satisfying the customer can grow increasingly difficult, with the team going off and creating what it thinks the customer wants, only to be told, "No, that's not it".

Opinions vary on exactly what a scope statement should include, but at the very least it should contain the following:

• A brief justification of the project's purpose, including a summary of the business needs the project will address.
• An explanation of the project's goals.
• Acceptance criteria that specify the conditions the product or service must satisfy before the customer will accept the deliverables.
• Deliverables, which are "the quantifiable goods or services that will be provided upon the completion of a project. Deliverables can be tangible or intangible parts of the development process, and they are often specified functions or characteristics of the project".
• An explanation of anything excluded from the project – in other words, an explanation of what is out of scope for the project. This list should be "as detailed as is necessary to define the project boundaries to all stakeholders".
• Constraints, such as budget and schedule.
• Assumptions, including anything you currently believe to be true about the project. It's also helpful to include ideas "about how you will address uncertain information as you conceive, plan, and perform your project".
• An explanation of any new or unusual technology you plan to use throughout the project. This is not a typical part of a scope statement, but "it's likely that stakeholders will appreciate the transparency and feel more comfortable with the project moving forward".

Some Practical Ideas for Working with Scope

A successful project manager is skilled at guiding customers, who simply may not know what they want until they see it. For truly innovative products, customers may not even be able to define what they want. An adage attributed to Henry Ford sums this up neatly: "If I had asked people what they wanted, they would have said faster horses". The Sony Walkman was not created to satisfy any identified consumer demand for portable music, but in response to a request from Sony Co-founder Masaru Ibuka for a convenient way to listen to opera. A Sony designer got to work on the special request, and the result was one of Sony's most successful products of all time.

When developers at Facebook introduced Facebook Home, they thought they were guiding their customers to a new way of using their mobile phones, just as Sony guided their customers to a new way of listening to music. But because the Facebook developers knew so little about the needs of their Android-using customers, they ended up creating a useless product. The moral of the story: before you attempt to guide your customers, make sure you understand their needs.

Here are a few other tips to keep in mind when thinking about scope:

• Engineers tend to focus too much on what they know, with little regard to what they don't know. Take some time to think about what you know you don't know. Then try to imagine how you would deal with the possible risks those unknowns might entail.
• Engineers tend to be highly detailed people. This can be a problem during project initiation if it compels you to map out every single detail of the project with no regard for the big picture. Of course, the details are important, but you also need to take a high-level view at the beginning. Not all details are of equal importance and the details that are important may vary over time.
• Engineers tend to focus on doing rather than thinking. They like to jump right in and starting executing a project. But remember that project initiation is your time to do some thinking first. Scope definition, in particular, is a thinking process in which you try to conceptualize what you don't know.
• Not all project requirements are equal. They can range from "absolutely must have," to "would like to have". When discussing requirements with the customer, make sure you understand where each requirement fits on this scale.
• Ask the customer as many different questions as possible about the project. "By probing the customer's requirements and expectations from as many angles as possible, a project team can significantly reduce the number of uncertain elements of project scope and reduce the potential variability of these elements. It does not guarantee that conflicts over project scope will not occur, but it can help isolate the potential sources of these conflicts".
• The best project managers understand the importance of learning all they can about their clients' definition of "value" and "success," and then suggest ways to achieve those goals that go beyond what their clients might be able to envision. Such project managers focus on performance requirements and options to achieve them, and avoid locking into one approach too quickly.
• As the project progresses past initiation and into planning and execution, remember to review the project's scope definition regularly to ensure that it is still appropriate. As the project moves forward and stakeholders learn more about it, scope changes are typically inevitable. "Indeed, the failure of a project to accommodate a change in scope can have far more serious consequences for the organization as a whole than if the change had been accepted – even if the change increased the project's budget and extended its schedule. The ability of a project to adapt to such changes can make a crucial difference in its ultimate value to the organization. After all, the project's objectives are subordinate to those of the organization – not vice versa. Therefore, it is crucial for the project team to understand at the very start of a project: which is more important? Avoiding change or managing it?".
• One risk is specifying a product that has all the best features of every competitor on the market – for example, designing an industrial motor with the smallest possible footprint, highest efficiency, lowest cost, highest torque, and every accessory available at launch. Merely attempting to surpass the competition in specs prevents a team from looking for a breakthrough solution.
• Teams that successfully define project scope typically start by spending time watching customers use the relevant products or services.
  
  

Source: Board of Regents of the University of Wisconsin System, https://wisc.pb.unizin.org/technicalpm/chapter/project-initiation-scope-and-structure/
This work is licensed under a Creative Commons Attribution 4.0 License.