Common Project Deliverables
Jennifer Bridges, PMP, discusses what project management deliverables and how they impact your project…
Hello, I’m Jennifer Bridges, Project Director for ProjectManager.com. If a picture is worth a 1,000 words, a deliverables diagram saves a million meetings. So today what we want to talk about is the deliverables diagram for project. I’m sure this looks familiar, the actual project life cycle; initiating, planning, executing, controlling, and closing. One of the most important things to know is the actual deliverables that are required to come into this process and the critical deliverables coming out.
Today what we’re going to talk about is the deliverables for each phase. We’re going to talk about the inputs, we’re going to talk about the outputs and how valuable they are. The deliverables diagrams sets a vision for not only for the project manager but also for the team and the stake holders. So everyone knows where are we going, how are we going to get there, and what’s due when.
The important deliverables for initiating is the business opportunity and really knowing why are we even doing this project. Many times we get in the thrust of a project and everyone is so focused on their task list that they actually forget why are we doing this project and what is the main deliverable coming out from this project. We submit a business opportunity actually from the business and it can come in from many different directions, for many reasons, but the business opportunity identifies why we’re doing the project. That is the main input coming into the initiating process.
The process of working with the stake holders and critical team members take that information and they process it. From the output of that becomes a project chart or many people today may call that something different in their companies. It may be a Statement of Work, it could be an Estimate Response Document, it could be called a Proposal, or anything. That’s the main document coming out that identifies; what’s the scope, what’s the timeline — a high-level timeline, and what’s the high-level budget of this project.
Then the project charter feeds into the next phase, the planning phase, the project charter and the lessons learned. It’s very important to share the lessons learned even if it’s not the same type project, a similar type project lessons learned that we can glean things to actually improve performance of this project. The project charter and the lessons learned feed into the planning process including all the important stake holders and people on the planning team get that information. From there is produced the project plan.
From the project plan all the sub-plans that identify the deliverables diagram. Again, it’s very important to identify a picture, a picture for the team, not only for the project manager but the team and stake holders to say, what’s going to be done when and what’s going to be delivered. It’s a very important document, deliverables diagram.
Communications Plan. Communications plan is very important. One of the issues that I see over many teams is the communication plan and knowing what level of information needs to be communicated to the right level of person. As we know the project team needs to know information totally different than the executive committee or the stake holders, or the change control board. It’s different levels of information so it’s important to identify who needs to know what, when, and how.
In today’s times people get so many emails, some people now are texting information, the beauty of the mobile market and texting or even collaborative software, or collaborative systems, people are using now social media. It’s important to identify how the team needs that information. Do they need it real time, or how do they need it best?
As well as the risk and issues, knowing what risk or how are we going to manage risk? If risk occurs, how are we going to identify them? How are we going to mitigate them? Who are the actual decision makers that make those important decisions for us? The issues? How are we going to manage and track issues? At what point are we going to escalate those and who are the important decision makers?
Then the change management process. We all know that change will happen so, it’s important to know upfront what is the process we’re going to use to manage those changes? How are those changes going to come in? How are they going to be assessed? Who are the people who need to decide how we’re going to manage those changes?
Then procurement. How are we going to procure our resources and assets we need for the team? Are we going to actually get those from in-house? Are we going to use those from important vendor partners? What is the process that needs to be done? What are the approval levels that need to be made? At what time? As well as the cost management. How are we going to manage cost? How are we going to measure the cost?
It’s important to know upfront these important things. Then the schedules. How are we going to manage the schedule? As we know, we’re going to baseline the schedule, we’re going to baseline all of these things, then what happens when the schedule changes? How are we going to manage that?
Those are the important sub-plans identified in the project plan and that’s why it’s so valuable. It actually becomes the game plan or the execution plan that feeds into now the executing and controlling phase of the project. Once we now had the project charter because we want the project charter actually, remember maintains the baseline, the agreement, the approval for this project and what the project is, what the budget it, and the important stake holders again really keeping us inline of why are we even doing this project.
We find that so many projects fail because people aren’t tracking the baseline against the original charter, the original plan. That’s what taking the charter and the plan, taking that in and executing, controlling, actually executing that and from there comes the performance reports. Now we take the performance reports and we measure those against baselines to know where are we in the progress of the project.
One of the things that we need to do, using the project plan, how do we get those things back in line so we’re now meeting the original goal? If we’re not meeting the original goal, what are the steps we need to take to actually change it, modify it, modify the baseline and get the appropriate approvals? If we do that, we actually find that we can decrease the project failure rate by actually implementing project management best practices.
Then the issues and risks logs. Again, important to not only track them but log the risk or the issues that occur so that we know when they occurred, what are the issues that occurred, what are the risks that occurred, what action did we take, and who actually approved or signed off on the action to be taken.
Then the change logs, as we know we said change will occur, so actually logging what change did occur when and what decisions were made, and who made the decisions. Then the project progress knowing how are we doing against the baseline of the project.
Then the deliverables, at this point the executing and controlling, we’re now actually producing the deliverables for the project. We can actually begin of all the deliverables that get made, the ultimate deliverable is the actual project. The performance reports, the project progress, the project logs, and deliverables as the project comes to a close all feed into the closing part of the project.
Saving the best for last but not forgotten, the closing phase is actually very important to get the product acceptance from the users, the stake holders, the agreement that the project actually did meet the intent of the project and all the baseline or performance measures that had to be met.
The final and actual reports of how did we do against the baseline and how do we actually measure on this project. The project documents so that we’re actually archiving, saving, maintaining the documentation, the historical, the history of this project. If we need to revisit again, what happened and when and if we need to take that information to the next phase of a project or maybe even a subsequent or similar project.
Then the lessons learned. Always knowing what lessons did we learn? What did we glean? What do we want to take forward because as we know it’s going to feed back into the next project. So again, we feel like if a picture is worth a 1,000 words, it’s going to save a million meetings in project management. If you need any other additional tips, tools, techniques, or templates please visit us at ProjectManager.com. Thank you.