In this chapter, we will look at the key vocabulary used throughout the different phases of a project lifecycle. The terms we have chosen are commonly used in project documentation but can sometimes cause confusion. Before moving on to the next part of this course and diving deeper into each phase, we will clarify the following terms:
Learn the Meaning of Key Project Terms
Scope is what is (and isn’t) in the project. This list represents the requirements for the product/service you will produce at the end of this project.
We will talk more in later chapters about the importance of scope and where you need to capture it within your documentation, but for now, here's an excellent article on how you could capture your project scope.
A risk is something that could potentially impact your projects, concerning your timeline, scope, or budget.
Does this sounds a bit all-encompassing and a little vague? The key is to remember that:
You don't have to have all the answers. Be inquisitive, ask “so what” questions, and talk to team members and stakeholders. Maybe even hold a Risks Workshop.
Focus your time and energy on identifying risks that could impact your project the most. The table below shows a few risk examples, how they could affect a project, their probability, impact, and a mitigation plan.
In September, the client is often too busy to participate in the quality review process to ensure the product functions as needed.
We cannot obtain sign-off of the requirements without this, and it will delay the launch or stop the project altogether.
Make sure the client finds a solution well in advance. By July, they should have a plan, either having found a temporary replacement or having delegated critical tasks they are usually responsible for during the month of September. This will ensure they can dedicate their time to the quality review process.
Have the HR department identify potential backfill resources in May to commence interviewing.
We don't have enough cloud hosting capabilities to smoothly manage the service post launch.
The lack of available skilled resources could delay our quarterly maintenance schedule for this service. It could impact the functioning of the service, resulting in customer dissatisfaction.
Provide cloud environment training to three additional people within the IT operations department.
Schedule the MS Azure training for July.
An issue is something that occurred that has high or low impact on your project.
For example, a freelancer you hired to create your app’s interface design has called out sick mid-design.
UI designer off sick mid-design process
Graphics design to be delayed by two weeks.
However, it doesn't impact overall launch.
Already hired a new person. They are getting up to speed.
Assumptions are expected circumstances that are required for your project to succeed.
An easier way to explain this is with some standard examples of what assumptions can be:
There are enough available skilled resources to complete the tasks within the desired estimated budget.
There is enough available budget to complete the project to the required timeline, quality standards, and expectations.
How can I keep track of all the project assumptions?
You can create an assumptions log document to track the assumptions related to your project. This way, you have a record of topics you want to follow to assure the project’s success.
Demystify Risks, Issues, and Assumptions
Below, is an example of how to classify if something is a risk, issue, or assumption. While this classification is not based on a specific methodology, it is an easy way to get started.
Circumstances you typically don't want to come true, because if they do, they can negatively impact your project.
Something that has already come true.
Circumstances you want to remain true (e.g., the continuing available resources to assure your project's success).
The scope is what is (and is not) included within a project.
A risk can negatively impact your project.
Issues are problems that have already happened, and their impact on your project can range from low to high.
Assumptions are items you want to remain true to assure the success of your project.
Great, now you know the key terms you will need for creating quality project documentation. Before we look at each of the lifecycle phases of a project in more detail, check how much knowledge you’ve soaked up so far with the following quiz.