Each week, project management veteran Tom Mochal provides valuable advice on planning and managing projects. He first describes a common problem scenario, based on a real-life situation, and then offers a solution, using practical project management practices and techniques.

The dilemma
A few days after I had a conversation with Chi-ling about reestimating her project for the finance division, she called with a problem that many people struggle with: identifying goals and objectives.

“I have difficulty defining the project objectives every time I complete a Project Definition,” Chi said. “I thought that I would get your help figuring them out once and for all.”

“I know what you mean about struggling with the objectives,” I said. “Of all the areas of defining a project, writing good objectives seems like the most difficult. What do you have to start with? Was some type of cost/benefit analysis done ahead of time?”

“Yes, we have a high-level cost/benefit analysis that was done as part of the project-approval process,” Chi noted. “That document does a good job of describing the overall benefits of the project.”

“Okay,” I said. “It is very common to see the benefits stated at a high level. At least we have something to start with. How about the details? If we look at the low level, are you pretty confident that you know what deliverables you are going to produce?”

“Yes,” Chi said confidently. “I have already received confirmation on the scope of the project and the deliverables to be produced.”

“Great,” I stated. “Part of the art of creating good goals and objectives is the crafting of the statements themselves. The other part is making sure that there is an alignment among the benefits, goals, objectives, and deliverables. Now let’s look at crafting some good goals and objectives for this project.”

Mentor advice
One of the most uncomfortable parts of defining a project is describing the project goals and objectives. There is no clear right or wrong way to define them, and crafting the statements is as much an art as a science. (In fact, they may be more art.) Here’s a simple process for outlining a project’s goals and objectives and a graphic to help you visualize how they fit in the overall project (see Figure A).

Figure A
How project goals and objectives fit in a project

Business benefit
Start at a high level. Every project should have business benefit, expressed in terms such as increased quality, faster response/delivery time, or reduced costs/increased revenue. Most often, the business benefit is quantified in some way to get the project funded and prioritized in the first place. For example, your project may be able to reduce purchasing expenditures, create your product 25 percent faster, or increase company sales by 10 percent. Other times, the benefits are more intangible, such as increased customer satisfaction or better information for decision-making.

Project goals
Once you identify the business benefit, you can look at the overall project goals. These are high-level statements that describe what this particular project is going to do to help achieve business benefits. For example, a reengineering project could have goals for shortening work processes, reducing costs, and increasing customer satisfaction.

Objectives statements
At a more granular level are the objectives statements describing the specific planned results of your project and what it is trying to achieve. When you write an objective, remember the SMART acronym: Each objective should be specific, measurable, achievable, realistic, and timebound.

The objectives state the meat of what the project is trying to achieve. When the project is complete, you need to be able to show that the objectives have all been satisfied. For example, in our reengineering scenario above, an objective might be to “reduce the time to process a sales order, from receipt to shipment, from ten days to two days, by September 30.” A deliverable to support that objective could be an in-house application that speeds the supply-chain process.

On the other hand, actively communicating with your customer is not a project objective. It is part of your project approach (or how you execute the project). Likewise, keeping scope change to a minimum is not an objective. It is part of the project management procedures. At times, you may have a vague idea of the goals and objectives but struggle with trying to determine the best way to express them.

Deliverables
The objectives should also be achieved through the completion of one or more deliverables, which are the items the project team is expected to provide. If an objective cannot be achieved based on the completion of one or more project deliverables, it is probably written at too high a level or perhaps it is an invalid objective for the project altogether.

Alignment
After you have the goals and objectives written, you should be able to line everything up. One or more deliverables are created to satisfy a project objective. One or more objectives will help to achieve a business goal.

If a deliverable doesn’t help to achieve a project objective, you need to question whether the deliverable is needed or whether you need to write a new objective statement. The completion of one or more goals will provide business benefit and help to achieve business goals and strategies. If the alignment does not work this way, you are either missing something or you have something you don’t need.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.