Demystifying Project Management:
Step 2: Define Your Deliverables
PMI Talent Triangle: Technical
The main focus of any project is what you will deliver to the customer at the end of the project that satisfies the customer’s original need. These things that you hand to the customer at the end of the project are called “deliverables”. Everything about the project should be geared to creating the deliverables and getting them into the customer's hand. When this is done, the project is considered complete. In the world of professional project management, the deliverables are often referred to as scope. The scope of a project is another way of talking about the outcomes of a project that satisfy a customer’s need.
Deliverables ALWAYS fall into one of three categories: products, services, data. You can give something physical to the customer (a product); you can do something for the customer (a service); and you can provide the customer with information (data). A project is all about creating the product, providing the service and/or the data, then delivering it all to the customer. If I build a bicycle and hand it to you, I’ve developed and delivered a product. If I create an electric bicycle riding and maintenance program and teach it to you, I’ve developed and delivered a training service. If I provide you with the design specifications and maps for driving, I’ve provided you with data. These are the only three forms deliverables can take.
In order to fully define the deliverables, I like to proceed with following steps:
Deliverables ALWAYS fall into one of three categories: products, services, data. You can give something physical to the customer (a product); you can do something for the customer (a service); and you can provide the customer with information (data). A project is all about creating the product, providing the service and/or the data, then delivering it all to the customer. If I build a bicycle and hand it to you, I’ve developed and delivered a product. If I create an electric bicycle riding and maintenance program and teach it to you, I’ve developed and delivered a training service. If I provide you with the design specifications and maps for driving, I’ve provided you with data. These are the only three forms deliverables can take.
In order to fully define the deliverables, I like to proceed with following steps:
- Make a list of all features and functions your customer requires in order for them to officially accept the final deliverables.
- Make bulleted, shorthand lists of all the deliverables, breaking them down into as much detail as possible.
- Plan out what it will take to create each deliverable and get it into the hands of the customer.
- Create a receipt (acceptance package) that the customer agrees to use as a guideline for accepting the final deliverables.
It isn’t enough to say that your customer needs something. You must also be clear about the features and characteristics the customer requires in order for it to really satisfy the customer’s need. These features and characteristics required by the customer are usually called “requirements” in the project management world. These feed into the signature event of the project when the customer receives the deliverables and agrees that all project objectives have been met. This event is called “Acceptance” and the metrics used to define success are "Acceptance Criteria".
Let’s continue the 7-Step process by creating acceptance criteria for the electric bicycle prototype we used as an example in the Marching Orders blog. In that blog, the marching orders and accompanying narrative identified three requirements:
- The project must produce both an electric bicycle prototype and a training/maintenance manual.
- The prototype and the manual need to be delivered to the test group by June 1.
- The bicycle must have a range of 20 miles between charges.
Hypothetically, further discussions with the marketing and engineering departments would reveal certain other requirements the electric bicycle must have:
- The bicycle production cost must be $50.
- The bicycle must be a “one size fits all” design for large and small riders.
- The bicycle’s top speed must be 20+ miles per hour.
Obviously, the list of requirements could go on into greater detail. We could add color, type of seat, type of handlebars, gearing system, tire type, frame type, all the different options available for bicycles. The importance of this list is that the customer agrees to use it as the checklist for final inspection that triggers acceptance and payment. It is SO important to get this list as complete as possible at the beginning. If this list of requirements and acceptance criteria keeps changing during your project then you are trying to design to a moving target. This will waste both time and money, and you will probably end up with an unhappy customer at the end of the project. Make sure the acceptance criteria are well-defined and agreed upon at the beginning of the project.
Along with the customer agreeing that meeting these requirements will be sufficient to accept the final product, the project team must be held accountable in that they shouldn’t be doing any work that isn’t required. Work that isn’t required is considered “out of scope” and wastes money and time. Why do it if the customer doesn’t want it?! If you are working under contract you won’t get paid for work you do that isn’t required in the contract. If the customer decides they really want some new feature, then get the contract modified so that the work is “in scope” and you will get paid for it.
Finally, just to make sure everything is organized and everyone has the same expectations for how the project will end, you need to do two things. First, capture all these requirements in one document and have both the customer and the project manager sign it up front. Second, define exactly what event (milestone) will result in the customer acknowledging that all acceptance criteria have been met and project payment is to be made. This milestone typically involves inspection, demonstration, or testing of some kind, often called "verification". Capture this milestone so that everyone has an eye on that upcoming event.
List of Deliverables
Finally, just to make sure everything is organized and everyone has the same expectations for how the project will end, you need to do two things. First, capture all these requirements in one document and have both the customer and the project manager sign it up front. Second, define exactly what event (milestone) will result in the customer acknowledging that all acceptance criteria have been met and project payment is to be made. This milestone typically involves inspection, demonstration, or testing of some kind, often called "verification". Capture this milestone so that everyone has an eye on that upcoming event.
List of Deliverables
Now comes the heart of project management, the list of deliverables. This is a list of all of the products, services and data you will give to the customer by the end of the project. This may sound simple, but you would be shocked how often this list simply doesn’t exist on a project. I’ve seen projects that have a needs analysis, and a beautiful schedule, or action plan. But nowhere is there a single list of all the deliverables the customer should receive at the end of the project.
A list of deliverables is really quite simple to put together. You list the main, independent products and services and data that you will be providing to the customer, then break those down into a little more detail if you can. Here is the generic template I use for listing deliverables:
It may not make sense now, but the first item in the list of deliverables should always be the name of the project. Just stay with me and do it this way. It will become clear later when we develop our action plan (schedule). The numbering system may seem cumbersome, but this is industry standard. You can use any system of numbers (or letters!) that makes sense to you.
On this project, we have two major deliverables, the electric bicycle prototype and the manual. That list of deliverables looks like this:
On this project, we have two major deliverables, the electric bicycle prototype and the manual. That list of deliverables looks like this:
Usually, when you are just starting a project, you can add one more level of detail to the list of deliverables. This is called "breaking the deliverables down to level 3". In our case it would look like this:
All of these could be broken down further if it is useful. That’s up to the project manager to decide. When in doubt, DON’T proceed with further detail. Let the team doing the work break it down if you aren’t sure. Forcing early “decomposition” can lead to rework and confusion. Only break it down far enough to serve the needs at the time. In the bicycle project, we are going to use this level of decomposition for developing an action plan and estimating a budget.
The decomposed deliverables list goes by several names. The Project Management Institute (PMI) calls this a Work Breakdown Structure (WBS). Unfortunately, this causes a great deal of confusion in the project management world. The problem stems from the fact that there is a button in Microsoft Project, a popular scheduling tool, called “create WBS”. When you click on this all it does is create an outlined numbering system for the schedule similar to the numbering system I used in the deliverables list above. Consequently, there is an entire generation of project managers who think a WBS is simply a numbered schedule. I like to avoid this semantic confusion by calling this a “Deliverables Breakdown Structure” or, more simply, “List of Deliverables”.
At this point in the 7-Step Project Management process, you have clearly established your marching orders (see previous blog) and now you have developed a well-defined list of deliverables with acceptance criteria that looks something like this:
The decomposed deliverables list goes by several names. The Project Management Institute (PMI) calls this a Work Breakdown Structure (WBS). Unfortunately, this causes a great deal of confusion in the project management world. The problem stems from the fact that there is a button in Microsoft Project, a popular scheduling tool, called “create WBS”. When you click on this all it does is create an outlined numbering system for the schedule similar to the numbering system I used in the deliverables list above. Consequently, there is an entire generation of project managers who think a WBS is simply a numbered schedule. I like to avoid this semantic confusion by calling this a “Deliverables Breakdown Structure” or, more simply, “List of Deliverables”.
At this point in the 7-Step Project Management process, you have clearly established your marching orders (see previous blog) and now you have developed a well-defined list of deliverables with acceptance criteria that looks something like this:
Many project managers and organizations use much more complicated approaches to defining deliverables. If the nature of your work requires that, then that’s what you have to do. But what I’ve shown you here is enough to get the job done and nothing more. No fluff, no extra writing, no unnecessary process, no busy work. Just enough to capture the objectives and scope of the project and make sure that your customer is happy with what you deliver at the end of the day and you get paid!
Responsibility Assignments
After you have created your list of deliverables, it’s a good idea to assign responsibility for each line of the deliverables list to a specific person or organization. I’m sure you know the old adage that if nobody is responsible for something it won’t get done. Don’t let that happen to you. Create a responsibility assignment chart (RAC), like the one below, to let everyone on the team know what they are responsible for, or who to look to for guidance when they are working on any particular part of the project. This might sound like a small thing, but your team will really thank you for it. People like knowing exactly what is expected of them.
To summarize, this second step (Defining Deliverables) in our 7-Step Process is crucial to having a successful project and a happy customer.
Director of Programs
7-Step Project Manager
Please use the comments feedback area below to let us know your thoughts. How do you capture the end goals of a project? How do you make sure the customer is going to be satisfied with your work? 7stepPM readers want to know!
After you have spent 15 minutes reading this blog and participating in the discussion forum below, don’t forget to fill out the Pennies for PDUs form to get your certificate of PDU credit.
Comments
Post a Comment