Agreeing on the Deliverables - Project Management

Scope definition is the first thing you'll want to tackle in the Planning process. Scope definition starts with the goals or objectives of the project and continues to refine them, breaking them down into smaller components until at last the deliverables and requirements are defined. The end product of scope definition is the publication of the scope statement, which spells out each of the things I just mentioned plus a few others we'll cover in the coming sections.

Goals, objectives, deliverables, requirements…what's the difference? These terms sometimes get used interchangeably, but there are some differences. We'll spend the next few sections examining what makes up each of these components and what their differences are.

Goals and Objectives

The title gives this one away. Goals and objectives are very closely related and probably can be used interchangeably without a lot of confusion. I like to think of objectives as having a little broader definition than goals. Goals, on the other hand, are more precise and are stated in tangible terms. But let's not get too hung up on goals versus objectives because objectives are subject to the same criteria as goals if you're using the terms interchangeably.

Let's suppose you've been appointed the project manager for the Logan Street Move project. Your company has purchased a new building and made some extensive renovations, and you're ready to move the existing staff, currently in two different locations in your city, to the new building. The objective for this project might read something like this, "Move the existing staff to the Logan Street location with no disruption in service to our customers."

While that's a good objective statement, it really doesn't qualify as a goal. Goals describe what you're trying to do or accomplish or produce by way of this project. When the goals are completed or accomplished, the project is complete. Goals must spell out exactly what's needed to accomplish the project. That means they must be specific enough to use as the criteria to determine whether the project was a success.

From here on out, I'm going to use the term "goal," but know that you could use "objective" just as easily as long as you follow the guidelines outlined in this section for defining them.

Project goals are the heart and soul of your project. Without a clear, written understanding of what the goals are, folks might take off in all different directions and, before you know it, you have a project disaster on your hands. At best, you'll find a lot of disgruntled team members and stakeholders mumbling their version of the project goals under their breath (or to your boss) and not understanding why you didn't understand that their version of the goals was the correct version. You don't want to go there.

Note:Goals describe the what your project is going to accomplish or produce.

The Logan Street Move project needs some further definition. Suppose I'm a team member on this project, and I'm working from the objective statement given in the opening of this section. I understand that the move is taking place on two separate days, and I've planned my tasks with this understanding in mind. But you, the project manager, know that the move from our two existing locations must occur on the same day. The first problem with this scenario is a lack of communication between the project team and the project manager, but that's another chapter. The second problem is that the goal is not stated clearly enough; it probably wasn't written down nor was it communicated to everyone involved on the project. So, let's fix it.


SMART project managers document the goals of the project and communicate them to all the team members and key stakeholders. You may have seen this acronym before, but it's one that we should review again. Goals should be SMART: specific, measurable, accurate and agreed to, realistic, and time bound. Each of these is explained in a little more detail below.

S = Specific Goals should be specific and stated in clear, concise terms. This means that if you were to leave the company somewhere in the middle of the project (not a recommended career move), another project manager would be able to read and understand what the goal is without confusion.

M = Measurable Goals are measurable. The results of the goal are verifiable through some means. This could include everything from complicated formulas and measurements to a simple determination that yes, the result occurred, or no, it did not.

A = Accurate and Agreed To The goal should be stated accurately so that you don't end up measuring the results incorrectly. (This also ties to the goal being specific.)

Goals should be agreed to. You'll want to gain consensus and agreement from the key stakeholders on the goals of the project. This assures that everyone understands what the final outcome is and will work toward that end.

R = Realistic Goals must be realistic. If both of the existing offices need to move on the same day to the new facility and there is only one moving van available, the goal is not realistic. (You would discover this problem during the Planning process and as a result would have to come back and revise your goals and thus the scope statement.)

T = Time Bound Goals must have a time frame that they're completed within, that is, an established end date. Just as projects have a definite end date, so do goals.

Now let's take another stab at writing a goal statement for this project using the criteria we just learned. "Move the existing staff from the Third Street location and from the Washington Street location on March 4 to the new Logan Street location with no disruption in services to our customers."

This statement meets all the requirements of a goal. It's specific because it states who, when, and where, and it's written clearly and concisely. It's measurable because the move will either occur or it will not. The service-disruption part of the goal statement is measurable also. It's accurate, attainable, and agreed to by all the key stakeholders. The goal is realistic, and it's time-bound by the March 4 date.

I like having one, over-arching goal for the project like the one stated in the previous paragraph. In one sentence, this statement conveys exactly what the purpose of the project is and what we hope to accomplish. It's concise and clear. This is a great motivator to print on attractive paper and hang in prime locations where team members, stakeholders, and management will see it often.

Note:A single goal statement keeps the team focused on the end result of the project. It's the reason they're assigned project activities—and all project activity should ultimately concern meeting the project goal.

Now that everyone understands the goal of the project, it's time to move on and establish the deliverables.



The specific items or services that must be produced in order to fulfill the goals of the project.

Deliverables include measurable results, measurable outcomes, or specific products or services that must be produced in order to consider the project complete. Deliverables, like goals, should be specific and measurable.

You can apply the same SMART criteria to deliverables as you do to goals. The clearer and more specific you make the deliverables, the easier it will be to plan and estimate project activities and communicate assignments. Deliverables are like mini-goals in that they describe what it is you're producing or going to accomplish. When all the deliverables are completed, the goal of the project is accomplished.

Now back to the Logan Street Move. Knowing that our goal is to move the staff on a specific day, we can start to document some of the more obvious deliverables needed to make the move happen. Here are a few:

  • Contract with a local moving company by January 15.
  • Provide boxes and labeling instructions to all employees by February 7.
  • Hold weekly town hall meetings to answer questions about the move, starting February 1.
  • Meet with the management team by January 7 to explain how seating arrangements should be identified.
  • Obtain floor plans from the management team by February 1 showing employee placements.
  • Contract with IT specialists by January 15 to coordinate and move network servers, switches, printers, and desktops.
  • Move telecomm equipment, network servers, switches, printers, and desktops the evening of March 3 starting at 5:01 P.M.
  • Connect and test all telecomm and network equipment by 6 A.M. March 4.

Each of these deliverables requires some type of action, and each has a completion date. They are measurable and verifiable and have specific results that will allow us to determine whether the deliverable was completed. Keep in mind that this list does not contain all the deliverables you'd have for a project like this. I've listed only a few of them here to give you an idea of what they may look like. An actual deliverables list for a project like this would be much more extensive.

You may be thinking that the deliverables for a project like this look fairly easy to come up with, but what about very large, complex projects? Are they all lumped in together or somehow segmented? I'm glad you asked. That leads us right into the next discussion of project phasing.

Phasing Multiple Deliverables

Suppose the executive management team decides that the upcoming move is the perfect opportunity to reorganize the departments and reporting structures, one of their favorite activities (but don't tell them I said that). They're convinced that this activity is part of the overall project, but you as project manager are convinced that it's a separate project. What should you do? Well, you can compromise.

Consider structuring the project, and the project plans, as a project with two phases. The completion of phase one, the reorg project, becomes a deliverable and an input into phase two, the move project. Therefore, phase one must be completed prior to the activities beginning in phase two. (But we're getting ahead of ourselves as these are scheduling issues, and we'll cover those in Chapter 8, "Developing the Project Plan.") I'd recommend having two goals in this case, one goal for the reorg phase of the project and another goal for the move phase. Deliverables should be associated with the appropriate goals as well.

Many large, complex projects have phased deliverables. For instance, phased projects are very common in the Information Technology arena.Users might decide that new programs are needed to capture data that's produced as the result of new business processes and equipment. However, due to resource limitations or budget constraints or both, only the most critical pieces of programming can be completed in phase one. The users, or stakeholders, and the project manager will work through each deliverable, determining which ones are critical to accomplishing the goals of the project and which ones can be delayed to phase two. If money and resources were no object, the project could be completed all at once, but this is rarely ever the case.

Note:Excellent project management techniques applied to the wrong goal or
deliverables will result in an unsuccessful project.

Keep in mind that no matter how good you are at applying project management techniques and managing your team, if you're working toward the wrong goals or the wrong deliverables, your project will not be successful. It's very important that you spend the time to define the project goals, deliverables, and requirements and then get agreement and sign-off. Our goal for the Logan Street Move project would not be successful if employees arrived on Monday morning and found that they had no computers or telephones to work with. The project couldn't be considered successful because the lack of computers and phones would definitely cause an interruption in customer service

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Project Management Topics