Project Scope and Context

Managing Project Scope

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.

From the Trenches: Michael Mucha on Sustainability and Adaptive Challenges

Michael Mucha is Chief Engineer and Director for the Madison Metropolitan Sewerage District, serves as the current Chair for ASCE's Committee on Sustainability, and also serves on the Sustain Dane Board of Directors in Madison, Wisconsin. He explains that a project's scope is determined by the kind of problem you're trying to solve. Is it technical – with a clear-cut solution that engineers are traditionally trained to provide? Or is it adaptive – with no definite consensus on how to proceed, with every solution guaranteed to challenge stakeholders' values and beliefs? Or is it a mix of both?

Sustainable engineering solutions often involve adaptive challenges. As an example, he describes a recent project:

The distinction between adaptive and technical problems was first spelled out by Ronald A. Heifetz in his 1998 book Leadership Without Answers. For a hands-on, practical introduction to the topic, Mucha recommends The Practice of Adaptive Leadership.

Project Context

The Realities of Externalities

One term closely related to context is externality. It refers to a "consequence of an economic activity that is experienced by unrelated third parties". An externality can involve "a loss or gain in the welfare of one party resulting from an activity of another party, without there being any compensation for the losing party". For example, a sudden rise in oil prices could be a devastating externality in a project that depends on a steady and economical fuel supply. Some externalities are positive – for example, Ireland's decision to make public college education essentially free for all citizens made an already highly educated workforce even more attractive to pharmaceutical and software companies, which increased their investment in the country.

You and your project team have no control over externalities. But your job, as a project manager, is to be on the lookout for them at every turn, and to respond quickly and decisively when they do.

According to Merriam-Webster, the term context refers to "the situation in which something happens: the group of conditions that exist where and when something happens". All projects occur within multiple contexts – within an organizational context (both yours and the customer's), a market context, a technical context, and a social context. All of these can change over the life of a project, and in the permanent whitewater of the modern business world, they probably will. Good project managers pay attention to changing context. They realize that, as contexts change, the project will probably need to be adjusted. Completing the project in accordance with the original objectives could end up being a terrible outcome, if it turns out that the original objectives no longer fit the context of the organization.

The potential for changing contexts means that no two projects are the same. Even if you think you've completed an identical project recently, you'll almost certainly find that differences in context will force you to alter your approach in some way or another. For example, the fact that you successfully built a hospital in Detroit can't completely prepare you for the experience of building a hospital in San Francisco, where the area's volatile seismic activity means you need to consider a host of issues related to earthquake-resistance. In product development, you might find that the customer did not fully understand their needs at the outset. As you begin to learn what the customer wants, you might see the project in a much broader, more complicated context. Likewise, the introduction of new technology can increase the complexity of a project in ways you couldn't foresee during initiation. To deal with these changes, you need to be able to rely on a flexible project team that can adapt as the project unfolds.

An article by James Kanter in the New York Times describes the construction of two European nuclear power plants that were supposed to be "clones" of each other, with both built according to rigid standards specifying every aspect of the projects down to "the carpeting and wallpaper". The similarity of the projects was supposed to lead to clear sailing for both, but a host of unforeseen technical problems resulted in major delays and cost overruns. This is a perfect example of how contexts – one reactor was in Finland, the other in France – can dramatically affect the outcomes of supposedly identical projects. Problems at the Finnish site included a foundation that was too porous and therefore likely to corrode, inexperienced subcontractors drilling holes in the wrong places, and communication problems arising from a workforce composed of people speaking eight different languages. At the supposedly identical French site, a different array of problems included cracks in the concrete base, incorrectly positioned steel reinforcements, and unqualified welders. According to UniStar Nuclear Energy, the company behind the Finnish and French projects, a fleet of similar reactors are in the works around the world. Who knows what risks will arise on those projects. After all, France and Finland are at least stable, geologically speaking. But as Kanter points out, "Earthquake risks in places like China and the United States or even the threat of storm surges means building these reactors will be even trickier elsewhere".

Context is especially important in product development, where the backdrop for a new product can change overnight. In a paper arguing for a more flexible approach to product development, M. Meißner and L. Blessing discuss the many ways context influences the product development process:

Designers are influenced by the society in which they live, and their decisions depend on political, social, and financial pressures. The technological environment and the accelerating rate of change is a characteristic of modern times. Changing conditions produce new needs and thereby encourage new developments, innovation is rewarded, and new artifacts are created. Some products require design activity on a far larger scale than others.

Huge one-off products such as power plants or oil platforms require an immense and skillfully organized design operation. Less complex products such as hand tools or toys can be designed by a single person…. The designer could be working in a small company, carrying a variety of responsibilities including the marketing, design, and manufacturing of the product. Or he could be working in a larger company where many people work on a single design project with specified areas of activity and a hierarchy of responsibilities.

In changing contexts, flexibility is key. In his studies of successful project managers, Alexander Laufer found that the best project managers

deviate from the common "one best way" approach and adjust their practices to the specific context of their project. Avoiding the "one best way" approach does not imply, however, that there are no "wrong ways," that "anything goes," or that you must always "start from scratch". There is always the need to strike a balance between relying on the accumulated knowledge of the organization, on the one hand, and enhancing the flexibility and creativity within each individual project on the other.

Laufer argues that modern project managers need to employ a modern, more flexible approach than their predecessors:

The classical model of project management, in which standards are developed for virtually all situations, expects the project manager to serve primarily as a controller: to ensure that team members adhere to the established standard. This role entails only a minimal requirement for judgment and no requirement for adaptation. In reality, the project manager must constantly engage in making sense of the ambiguous and changing situation, and he must adjust the common practices to the unique situation. This process requires a great deal of interpretation and judgment based on rich experience.

In Lesson 5, we'll talk about the value of building diverse teams that bring together people with complementary skills – ideally, people of varying ages and levels of experience. But how can new project managers, who lack that all-important "rich experience," increase their overall understanding of their projects' multiple contexts? Start by researching past projects with similar characteristics, consulting with mentors, and, generally, checking as many formal and informal sources regarding lessons learned from previous projects as you can find. It also helps to stay well-informed – about your organization, your customers, your industry, and the world in general. For instance, if you were working on a construction project in the healthcare field in the past decade, you would have experienced a pronounced change in context, away from a doctor-centered system to a patient-centered system that seeks to empower patients to define value on their terms. If you were new to managing projects in that field, you would be wise to learn all you could about that shift. In the living order, such seismic changes are the norm, not the exception, in nearly all industries.

Practical Tips

• Engage all stakeholders: Your goal is to keep people meaningfully engaged in your project. You don't want stakeholders showing up for ceremonial appearances at project meetings. Instead, you want them seriously focused on the prospects for project success.
• Outcome clarity: Ask your customer to define success right at the beginning. Then, working with the customer and other stakeholders, define how success will be measured.
• Use a common vocabulary: At the beginning of any project, go to your end-customers and learn their vocabulary. Make sure you understand the terms that are important to them and what such terms mean to them. Whenever possible, use your customer's vocabulary, not yours. Also, strive to speak in plain English whenever you can, and avoid techno speak.
• Create a glossary of terms: On projects with a lot of complex jargon, consider creating a glossary of terms. Then publish it in a way that makes it accessible to all stakeholders, updating it as needed. Here's an example of one such glossary: "COSO Framework".
• Identify what you don't know: When you start a project, there are always things you don't know. The key is to know that you don't know them. The more you strive to recognize this, the better you will be at predicting those unknowns and making provisions for them.
• Have key team members sign major project documents: Research shows that the act of signing a document makes people much more committed to delivering on the promises described in the document. Consider asking the entire project team to sign the project charter and scope documents. This simple act can serve as a powerful inducement to completing the project successfully.
• Proactive concurrency: In the early stages, avoid the trap of plotting one thing after another, in a linear fashion. Instead, start fast, doing as many things as you can concurrently, as quickly as you can. This will give you a sense of whether or not the scope, budget, resources, and schedule are all in relatively close alignment at the macro scale. If you find they are not, report that to management right away.
• Permanent urgency: In the living order in which all modern projects unfold, permanent urgency is the new law of nature. In the traditional, geometric order form of project management, you could assume that you would have sufficient time and resources to do things in a linear, step-by-step manner. But in the modern world, that's rarely the case. Get used to an element of urgency in all projects. Try not to let this paralyze you and your team. Instead, let a sense of urgency spur you on to more agile, alert, and flexible project management techniques.
• Post the project documents prominently: Putting important documents front and center helps a team stay focused, especially if you have everyone sign them first. It also encourages the team to update them when necessary.
• Plan for errors: You and your team will almost certainly make mistakes, especially in the early stages of a project. So plan for that. Keep thinking ahead to what might go wrong, and how you could correct your course. Make a habit of keeping back-up plans in your back pocket.
• Define sign-off or acceptance criteria: One good way to get success defined is to start by drawing up sign-off criteria, or acceptance criteria as they are sometimes called. These are agreed-on deliverables for each key stage of the project that allows the stage to be considered complete. It's common to link these criteria to payments. The value of these criteria being defined at the beginning is that they are usually very objective and can continually be referred back to, thus ensuring that all activities are aligned with final deliverables. Major disagreements on whether a project was a success usually come down to a failure to define acceptance criteria. Achieving agreement on this is essential, as it drives everything else (resources, time, budgets, etc.).
• Be prepared for change: Don't be fooled into thinking that, just because you have created all the documents associated with project initiation, you have everything nailed down. It's often not possible to foresee the kinds of ongoing changes that arise in the living order.

Summary

• Project initiation is about laying the groundwork for the entire project. Although initiation marks the official beginning of a project, it involves looking into the future, envisioning the project's entire life cycle, which includes the making stage, the operating/using/changing stage, and the retirement/reuse stage. Even in the more traditional way of looking at project management, the phases of project management usually overlap and often entail looking back at the documents compiled during the initiation phase.
• These documents created during initiation typically provide a high-level view of the project. They include the project charter, the scope statement, and the business case. As you create these documents, you should be thinking ahead to creating the following items during the planning phase: work breakdown structure (WBS), organizational breakdown structure (OBS), work package, and the responsibility assignment matrix (RAM).
• Experienced project managers know that you need to start fast by defining what "success" means for your project and determining how to measure it. Success means different things in different industries. For example, in capital projects, the total cost of ownership (the total of direct and indirect costs related to the construction and use of a building) is crucial to determining whether or not a building is a success. Be as specific as possible when defining success for your project, without going into needless detail. Traditional project managers tend to define success in terms of completing a project on time and within budget. But Lean presumes a more expansive definition of success – one that prioritizes eliminating waste and maximizing value, and in the process building customer loyalty that will extend to as yet unforeseen projects. In Agile, success means delivering working software after each sprint, and, ultimately, delivering as much working software as the schedule and budget will allow.
• A well-defined project charter defines the project's goals, which in turn dictate the overall organization, schedule, personnel, and, ultimately, the work that will be accomplished.
• Of the three constraints on project management – scope, budget, and schedule – scope is the most difficult to pin down. 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. Ultimately, the definition of scope is based on what the customer wants, but sometimes you'll need to guide the customer toward a definition of the project's scope because the customer might not know what is possible. Take the time to articulate the scope carefully in the form of a scope statement. After you create a scope statement, refer to it regularly to avoid the unauthorized changes known as scope creep.
• A project's scope is determined by the kind of problem you're trying to solve. Technical problems have clear-cut solutions – the kind engineers are traditionally trained to provide. With adaptive problems, things are less clear, with no definite consensus on how to proceed, and with any solution guaranteed to challenge stakeholders' values and beliefs. Some problems are a mix of both.
• All projects occur within multiple contexts – within an organizational context (both yours and the customer's), a market context, a technical context, and a social context. All of these can change over the life of a project, and in the permanent whitewater of the modern business world, they probably will. A project will necessarily evolve as the project's context changes. Your job as a project manager is to be on the lookout for externalities that can affect a project's context.

Glossary

• business case – An "argument, usually documented, that is intended to convince a decision maker to approve some kind of action. The document itself is sometimes referred to as a business case. As a rule, a business case has to articulate a clear path to an attractive return on investment (ROI). At its simplest, a business case could be a spoken suggestion…. For more complex issues, a business case should be presented in a carefully constructed document. A business case document should examine benefits and risks involved with both taking the action and, conversely, not taking the action. The conclusion should be a compelling argument for implementation".
• context – According to Merriam-Webster, the "situation in which something happens: the group of conditions that exist where and when something happens".
• idea averaging – Taking a little from one idea, and a little from another, and a little from another – without fully committing to any.
• linear responsibility chart – See RACI chart.
• organizational breakdown structure (OBS) – A description of the project team. It explains "who reports to whom, the details of the hierarchy, and the reporting structure…. Organizational breakdown structures are normally communicated visually through the use of graphs or charts. A project or general manager is listed and underneath the PM several divisions might be created, such as product development, design, materials management, and production". See also responsibility assignment matrix (RAM), below.
• planning bias – The tendency to optimistically underestimate the amount of time required to complete a task.
• project charter – A "single, consolidated source of information" for project initiation and planning. It describes your current knowledge about the project and includes information such as the names of all stakeholders, a statement of your organization's needs, the history leading up to the project, the project's purpose, deliverables, and roles and responsibilities. A project charter is also sometimes called a project overview statement. It's sometimes helpful to think of the project charter as a contract between the project team and the project sponsors.
• project initiation – The early phase in which you lay the groundwork for the entire project.
• project overview statement – See project charter.
• project scope – All the work "that needs to be done to provide the product or service your project is delivering".
• responsibility assignment matrix (RAM) – A type of organizational breakdown structure in the form of a grid that typically lists project tasks in the first column, and stakeholders across the top row, with tasks assigned to the various stakeholders. You can use it to determine if you have enough resources for a project, and to record who is responsible for what. See also RACI chart.
• RACI chart – A type of responsibility assignment (RAM) matrix. Also known as a linear responsibility chart. The name "RACI" is an acronym of "responsible, accountable, consult, and inform".
• stakeholders – The people who will be affected by or who can affect a project.
• scope creep – Uncontrolled changes to a project that occur with no corresponding authorized changes in budget and schedule.
• scope statement – A document that defines the project's scope (or requirements).
• work breakdown structure (WBS) – A description of the tasks associated with project deliverables, often in the form of a tree diagram. A work breakdown structure "displays the relationship of each task to the other tasks, to the whole and the end product (goal or objective). It shows the allocation of responsibility, and identifies resources required and time available at each stage for project monitoring and management".
• work package – A "group of related tasks within a project. Because they look like projects themselves, they are often thought of as sub-projects within a larger project. Work packages are the smallest unit of work that a project can be broken down to when creating your Work Breakdown Structure (WBS)".