Section 6.2. Identifying Project Objectives

6.2. Identifying Project Objectives

In Chapter 5, you defined the project mission statement, which was a statement of the desired outcome(s) for the project. You also selected the best solution based on various parameters. Based on both the desired outcome and the solution selected, you can now begin to define or identify several high-level project objectives. These objectives should identify what you want to accomplish, not necessarily how you're going to accomplish it. However, you will also begin to identify, at a high level, how you'll accomplish this project. The details of how to accomplish your project's objectives are discussed in detail in the next chapter.

6.2.1. Project Objective Statement

The first step in identifying project objectives or major deliverables is to create a project objective statement. It's similar to the project mission statement, but it should be much more specific to your project because it should incorporate the problem, the mission, and the selected solution (see Chapter 5). Here's a great rule of thumb about creating any of these statements (problem, mission, or objective): if you can't state it clearly and concisely (50 words or so) you probably don't have a good understanding of what the project is trying to accomplish. Again, this doesn't need to take days or weeks to accomplish, but if you can't describe the high-level objectives or deliverables quickly and in 50 words or less, you may need to revisit some of the steps in Chapter 5. For example, "Replace all servers used in the Marketing department with new servers to provide improved response time, reliability, and security with all new equipment in place no later than December 31, 2005."This begins to describe your approach to the project based on the parameters you've defined.

6.2.2. Project Objectives or Major Deliverables

Once you have your objective statement, you can further refine it by breaking it down into three to five high-level objectives or major deliverables that fit the project problem, mission, and solution. It's good to keep the problem and mission statements in mind when defining project objectives because it's easy to get off course other-wise. These objectives essentially define how you're going to approach the project, so spending time to develop these will help you moving forward.

We limit our objectives to three to five items for two primary reasons. First, if you cannot define your project in terms of five (or fewer) objectives or major deliverables, it's entirely possible the project is too large and should be broken in to several smaller projects. Second, if you cannot define your project's objectives in five or fewer major deliverables, you may be including too much detail in your list of high-level objectives. It's also true that three to five major deliverables may not be enough for your project. If your project demands six or eight or ten major deliverables, that's fine. Just be sure that each of the major deliverables or objectives you define is, in fact, a high-level one. It's very common for people to begin digging down into the project detail when developing objectives. All objectives at this point should define high-level categories. If all of your objectives are not at the same level of detail, you're probably going into detail in one or more areas. Later when you define the activities or tasks under each objective, you will probably delve into differing levels of detail since not all objectives will necessarily have the same level of detail. When defining high-level objectives, though, they should all be at the same level.

6.2.3. Define What IS and IS NOT Included

One exercise that many people find useful is to define what is and is not included in the project. When you're defining your project's major deliverables, you can begin by stating what the major deliverables are. To avoid confusion and to really help clarify the deliverables, you can also state what your deliverables are not. Other language that can be used to describe this process is to define what is in scope and out of scope or to define what the project includes and excludes. Obviously, your project is not a lot of things, but we're only concerned here with the things that are related to what your stated objectives are. For instance, if the project is to upgrade the network infrastructure, you might state, "Replace all network servers that were placed in service prior to July 1, 2002."That tells you what server hardware will be replaced, but it doesn't define specifically what hardware will not be replaced. In this case, you might say, "Departmental servers and application servers are not considered network servers and will not be included in this project." If the project is a software upgrade to your company's software product, you might state that, "Critical issues and hot fixes reported since the last release will be included in this project. File export and reporting capabilities upgrades and fixes will not be included."

By stating what is and is not addressed at this point in the project gives you another reality check. If you write all this up and bring it back to your sponsor (as you will do before you exit this phase), your sponsor might or might not agree with what you've stated as included or excluded. It's certainly better to know here that your project sponsor had different expectations or a different view of the project than you and your team did. If your project sponsor assumed that the software upgrade project would absolutely include fixes to the file export functionality and you state that is not part of the project, you've got a great opportunity to modify the project plan before anyone has written a single line of code. It might also be at this point that you begin to notice shifting ideas, plans, priorities, and directives from your project sponsor. Once a project starts taking shape, the project sponsor may realize that the project is not what he or she expected or that other things in the organization or external environment have shifted. That's fine as long as you are able to pin down the project details. If you can't, you will constantly be trying to hit a moving target and it's almost guaranteed that your project will fail to satisfy the sponsor or other stakeholders. If possible, don't leave this stage of project definition and organization until you have these details agreed upon and locked down. It will be harder later on to gain this level of clarity, especially if the project gets underway without these details.

You may have heard the term scope creep or you may have experienced scope creep in your projects. Scope creep happens when features and functionality are added without addressing the effects of these changes on the time, cost, or schedule of the project or without customer approval. These are considered uncontrolled changes that expand the scope (total work to be accomplished) of the project. Sometimes this happens through small "innocent" changes being requested and other times it happens through large changes being demanded. In either case, scope creep is one of the most important things to manage during the project and we'll discuss managing scope creep when we discuss managing change later in this book. We discuss it here because by clearly defining what is and is not part of the project, you begin to draw the lines around your project's scope. Doing so helps avoid finger pointing or confusion and helps you also avoid scope creep later on.

As with other steps we've already discussed, this should not take an inordinate amount of time. That said, the amount of time you spend on very clearly defining your project's major deliverables or objectives is time well spent. You may find that this step takes you a bit longer than previous steps took, but the payoff here is significant.

Figure 6-3. Project Objectives