Scope, Risk, and Assumption in Project Management
The field of project management, much like any other area of expertise, has a unique vocabulary filled with acronyms and specialized terms. Three essential terms and concepts you must include:
It is an outline of these three essential project management terms and includes links and suggestions for additional reading.
In project management, scope is the set of boundaries that define the extent of a project. The scope describes what is to be delivered to the customer as a result of the project initiative.
Understanding the scope allows the project manager and project team to understand what falls inside or outside the boundaries of the project. If something is "not in scope," it is not factored in the planning work of the project. Activities that fall within the boundaries of the scope statement are considered “in scope” and are accounted for in the schedule and budget. If an activity falls outside the boundaries, it is considered “out of scope” and is not planned for.
Whether you’re a project manager or part of the project team, you’ll want to consider if something is in scope or out of scope as you move forward. As an example, imagine that a client has asked you to build a website. As you outline the scope (or set the boundaries) of the project, you indicate the following items as in-scope:
- Site design and wireframe diagramming
- Establishment of a test bed
- Coding to the approved wireframe
- Graphics development for the website theme
- Testing and debugging prior to making the site public
During the course of the project, the client asks you to include a video overview of the company. The video is not specified in the scope of the project and is therefore out of scope. While you may be happy to do the video work for an extra charge, this will require a revision of the scope and cost and time estimation for the project.
In the absence of a clear and agreed upon scope document, the issue of the video might have become contentious between your team and the customer's representatives. A clear scope statement allowed you to defuse the situation and deal with a change in an orderly way.
So how do you determine what is in or out of scope? You’ll first want to outline all the details of the project you currently know based on discussions with the client or the project owner. Then you’ll want to make key assumptions that will drive what’s considered in or out of scope.
At some point in your life, you’ve probably been told, “Never make assumptions.” However, making assumptions in project management is an everyday activity. Assumptions help you define scope and risks and fine-tune your estimates for time and cost. Of course, it is essential to document and validate your assumptions.
Consider something simple, such as creating a book. Let’s say your friend has an idea for a coffee table book and has asked you to manage the project. His first request is for a budget so he can secure funding. As you define the scope, it’s clear that your friend is uncertain on many details, including page count, image inclusion, cover style and the weight of the paper to be used for the pages.
Since all of these factors will impact cost and production complexity, you will have to make assumptions about the specifications and validate those assumptions as acceptable or unacceptable to your friend. After further discussion, your friend tells you he plans to include 50 photos in the book. You can base your assumption on the 50 images or, anticipating that this number will increase over time, you can make an assumption that there will be between 75-90 pages with images.
You can see how assumptions directly affect schedule as well. For instance, imagine you’re leading a project at a park that involves building a swing set. When setting up your project, you are given the budget and assigned team members, one of whom is in charge of materials. As you create your schedule, you ask the person in charge of materials when the cement will arrive. This person replies that he’s not sure when the cement will arrive but that he believes it will be between June 1 and June 10.
As you build your scope and schedule, you make the assumption that the cement will arrive no later than June 10. This example shows two benefits to making assumptions.
The first benefit is that the assumption of receiving the cement no later than June 10 allows you to plan for activities that rely on the cement arriving. The second benefit is that it provides the person in charge of materials with a deadline to deliver the cement, which he can then relay to his supplier. It has inadvertently set up a key deadline for the project to move forward.
Making assumptions creates benchmarks that are often revisited during the project to aid the project team in staying within scope, on time, and within budget. But what happens when assumptions are wrong? It is where the risk comes into play.
Once you’ve built your scope and identified the assumptions that are behind the scope and estimates, you will want to begin assessing areas of risk. Risk is the same in project management as it is in the real world; it is a hazard or chance that can create damage.
All projects contain risk, and if you are the project manager or project owner, it’s not only your responsibility to anticipate risk, but it’s also your job to communicate the potential impact of those risks to the project team and to prepare to mitigate the risks.
Risk comes in various degrees. Sometimes risk can mean the project will run slightly differently or take a small unexpected turn. In some cases, however, risk can lead to catastrophic results that turn your project on its head.
Let’s use the playground scenario from the above cement example. One of the risks is that the cement does not arrive by the assumed date of June 10. What are the potential effects of this risk? All of the successor activities that follow after the cement has been poured are delayed as a result of this problem.
Risks can be positive, as well. Consider the impact to the project if the cement shows up earlier than anticipated. While this seems like a positive outcome, it still creates a problem for the timing and sequencing of all of the other steps in the project.
Project managers work with their project teams to brainstorm and identify potential risks. They take the process a step further and look at the potential severity of the risk and its likelihood of occurrence. Furthermore, they identify those individuals best suited to identify when the risk is occurring, and they develop agreed-upon risk mitigation plans.
Many firms have detailed risk templates they have developed over time and from experience with other projects. Some industries have compiled risk profiles that are used as a starting point for risk analysis. Many industries practice very detailed statistical analysis for risk planning as well.