Project goals: How can you know the way when you don’t know the destination?

Everyone likes to talk about the importance of defining project goals. Yet most projects don’t have any goals. Or worse, they have goals, but they're not measurable. You might be thinking: “My projects always have goals!” Do they? Or are these goals more like wishes?

The title of this blog post pretty much sums it up. How should I know how to get there, if I don't know where I want to go? This is exactly what project goals tell you – the destination of your trip. How we will get there is then up to the project team.

Project goals provide a framework for every activity in the project. For example, requirements are always compiled with the project goals in mind. Every person in the project team has to constantly ask himself/herself if their work is bringing the project closer to its goals or not. This ensures that everyone is heading in the right direction. Without project goals, everyone will have their own interpretation of where they’re heading to and take off in different directions or pursue their own interests.

But project goals also serve some other important functions. Have you ever asked when a project is considered to be in crisis? What defines a crisis? The deficit of a resource? Too many bugs? No – the project is in crisis if one or more project goals cannot be attained. Because this questions the meaning of the project.

Easy question – easy answer: the project customer. Conventional project goals for many of our projects: replacing the existing system. Let’s be honest. No customer is going to launch a project costing hundreds of thousands or even millions of Euros with nothing more in mind than to replace their existing system. There’s more behind it. For example, boosting efficiency, transparent reporting, faster business transactions and deliveries, etc.

As simple as the answer may be, implementing it is more difficult, I’m afraid. Many people are not aware of the importance of project goals. That’s why one of the jobs of Project Management is to provide support and guidance. Defining the actual project goals is up to the project customer. The goals are then formulated in collaboration with Project Management.

Let’s take the example from above: replacing the existing system. Is this a goal? Or is it more like a wish? And what is actually the difference?

Wishes are usually very loosely defined and, most of all, they have no time reference. Goals, however, are more specific and measurable. Go online and look up SMART objectives. SMART is an acronym that actually comes from human resource management. It defines how goals/objectives should be formulated so that they’re clear and comprehensible.

• Specific
• Measurable
• Attainable
• Relevant
• Timely

If we flesh it out, the example above might look like this: By implementing a new system, we intend to reduce by at least 30% the time it takes from order receipt to start of production by the end of the project.

Normally, considerations like cost reductions are part of the decision with regards to the project; they’re just not usually stated. Why this is important is apparent from the path you take in order to reach the goal. If the maintenance costs are to be reduced, then the system will be selected with this in mind. But the implementation of the requirements can also be geared to this, and you’d probably formulate them differently, too.

Now another question comes up. When should project goals be defined? During the project kick-off? You often read in literature that project goals should be defined at the project kick-off. From our experience, though, that’s usually too late. It makes more sense to start thinking about it and defining project goals at the pre-project stage – even before selecting your tools. That way, your goals will influence the tools you select, making them as effective as they should be.

Agile projects need goals, too. Otherwise, it would just be a bunch of people working blindly for no reason. Instead of conventional project goals, you formulate a product vision that you’ll then work towards. Such a product vision actually works well for conventional projects, too.

Unlike project goals, the product vision puts the focus on the product’s utility to the user. Since this aspect often gets overlooked in project goals, it can help to start by coming up with a product vision (the “product” being the result of the project) and then using it to derive project goals to support the product vision.