You're reading...
Project Management

My project’s objectives are “foggy”! What do I do?

foggy_projects_wordcloudQuite often, when I am running project management workshops, there are participants who have been given vague, woolly or foggy objectives by their manager and told to “run a project to sort things out”.

They can get frustrated that their boss hasn’t given them the clarity they need to set up and manage a project. In an ideal world, project initiators and Sponsors would hand over beautifully crafted SMART Objectives to the Project Manager. In the real world, it just doesn’t happen like that, so what can the poor PM do to move out of the fog and into a place where they can begin to define and plan a project?

As a PM, if you can’t get clarity on what success will look like once the project has ended, it’s going to be very difficult to work out how to set it up and manage it. So, helping the Sponsor answer the “why?” question is a crucial first step. You’re probably going to have to have a series of “plain English” conversations with the Sponsor and other key stakeholders. By “plain English” I mean speaking with them about their vision and ambition for the project. I don’t mean asking them to help you fill in a Project Initiation Document!

I usually try to translate the result of those conversations into 2-3 SMART Objectives and a series of supporting Benefit statements. It’s then often easier for these senior people to look at what’s been written and say “yes that’s what we want to achieve” or “no, what we really need to improve is this”.

By differentiating SMART Objectives from Benefit statements, I find it’s usually possible to get right to the heart of what the project is expected to improve. The SMART Objectives describe the quantified, new levels of performance that are expected to be achieved by a specific point in time. The Benefits are the additional positive performance improvements that are expected. You can make them SMART later, but to begin with, it’s important to get clarity on the small number of things that have to be achieved.

I tend to think that anyone who tells me their project has 10 objectives really doesn’t have a clear grasp of what’s important. It’s highly unlikely that any sensible project would need that many; indeed more than 5 is probably pushing it. There is always a hierarchy of objectives and, very often, the Benefits arise as a consequence of achieving the core objectives. For example, if a core objective is to reduce end-to-end cycle-time on some customer-facing process, there’s probably an associated objective of improving customer satisfaction. Achieving both of these will almost certainly result in a series of benefits such as reduced operating cost per transaction, reduced complaints and maybe improved staff motivation as a result of implementing more streamlined processes.

In setting objectives, we always need to be aware of the dangers of unintended consequences, which is why having several core objectives is important. Some organisations have discovered (though I’m not sure why it should be a surprise) that setting an overarching objective to reduce costs (e.g. by 15%) is easily achieved, but is at the expense of reduced quality and increased customer dissatisfaction. Single objectives can also sometimes lead to “gaming behaviour”, where it’s easy to hit the objective by introducing some simple change. The call centre technique of increasing the number of calls handled per hour by “accidentally” cutting off customers’ calls easily gets the call volume up, but annoys the customers. The public sector has been riddled with government-set performance targets that led to gaming behaviour. The targets were easily “met” but customer service was never improved.

So, my overall advice to a PM who has been given a foggy project is to talk to a few key people and have a stab at writing something down for those people to critique. With a few iterations, you should be able to arrive at the core purpose of the project. You probably won’t get it right first time, but it’s a much more agile approach and will let you home in on what’s wanted. You will probably also flush out other expectations people have of the project and can then figure out how you might need to configure the project (will it need to be run using an agile approach, or will waterfall work, or a combination?).

Read more about Project Initiation.

.

.

.

.

.

.

.

 

..

.

 

 

Advertisements

Discussion

Comments are closed.

Connect with Ian Seath

Find us on Facebook Improvement Skills Consulting Ltd. on LinkedIn Follow IanJSeath on Twitter

Archives

Copyright Notice

© Improvement Skills Consulting Ltd. and Ian Seath, 2007-17. Unauthorised use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Improvement Skills Consulting Ltd. and Ian Seath with appropriate and specific direction to the original content.
%d bloggers like this: