Source: Image of project manager female, tablet watch on hand, Creative Commons, Kelly Eddington; Image of arrow, signpost, exclamation point sign, Public Domain, Sparkol VideoScribe Internal Image.
Hi, I'm Jeff. And in this lesson, we'll discuss how to determine project outcomes. Project managers will define outcomes so that they can determine what work will be in scope and what will be out of scope. This is done by documenting the deliverables, requirements, and assumptions for a project. And that's what we'll cover in this lesson.
You should now be familiar with project deliverables. Remember that these are the outcomes that are the focus of the project, and all work is targeted at creating deliverables. A project might have one deliverable, or it might have many interrelated deliverables.
For example, in the case of a project that creates a watch with tablet computer like functionality, the watch itself is of course a deliverable. But a prototype watch might also be a deliverable. The software that runs on the watch is likely a deliverable. And documentation on the operation of the watch will almost certainly be a deliverable.
It's the responsibility of the project manager to list all deliverables that must be created by the time the project ends. It's also the responsibility to note which deliverables won't be created by the project. In our example, perhaps the sales and marketing material are not a deliverable.
The details about these deliverables are called requirements. These come out of the project goals and objectives, and from the list of stakeholder expectations. Though some objectives or goals result in a single requirement, most will require the generation of multiple requirements.
And example of a requirement for our tablet watch would be the watch shall allow the user the ability to receive instant notification of a phone call. Then answer the call with no more than one action. Notice how this requirement is very specific about the project work that must be accomplished. And the criteria to determine if this work is a success. The requirements set the quality standard for performance.
Project managers must also document the assumptions made about a project or it's deliverables. These also emerge from reviewing expectations and consulting stakeholders. Assumptions are different than expectations, though. Because assumptions are assumed to be a true prediction of the future. While expectations will only occur if the project delivers on its work.
For example, an assumption on the tablet watch project might be the project may assume that the existing tablet development team will contribute three software engineers to the tablet watch team. Assumptions can be made about nearly anything assumed to be true and applicable to a project, such as the resources available for work, the technology available, or the support organizations or individuals might provide a project. Project managers will need to use discretion to determine what assumptions are listed. Otherwise, this list might be too detailed. A guideline for this, if an assumption that turns out to be false is a risk to the project, then that assumption should be included.
Deliverables and requirements are, then used by the project manager to determine what work is in scope and out of scope for a project. In scope means the project is responsible for the work. Out of scope means that it is not. Or in other words, what the project will do, and what it won't do.
It's simple to understand why we document what a project will do. But why document what it won't do? Successful project managers do this because projects and deliverables are complex. And it's difficult to gather 100% of the stakeholder expectations. So by discussing what won't be in a deliverable, you continue to gather information about those expectations.
With the tablet watch, for example, work that is in scope would be the ability to make and receive phone calls. Out of scope work might be the ability to take photos. Now, some stakeholders might disagree with this. And that's why it's important to document in scope and out of scope work, so those discussions can occur. It is then up to the project manager to resolve those conflicts. And that's how you determine the outcomes for a project.
Good job. In this lesson, you learned that a project manager must document deliverables, requirements, and assumptions. And that they use that documentation to determine what is in scope and out of scope for a project. Thanks. And have a great day.
