GDPM or Goal Directed Project Management

Three key tips for project management success

Many years ago, when working as a Principal Consultant with what was then Coopers and Lybrand (now PwC) I led the Distributed Systems Group and after having led a number of major client projects successfully myself began to get asked to review client IT projects and advise various blue chip companies on whether they were ever likely to deliver successfully.

That was a big responsibility and also fortunately one which gave me a great deal of insight into what works and what goes wrong, even when they are led by very senior people.  And the answer I concluded was really very simple.  Many of the projects, including in some very high profile (News at ten) ones with mega budgets,  focused far too much on activities and resources and insufficiently on goals and roles.

And the main tools in use, GANTT charts and PERT charts, encouraged this and indeed gave a false appearance of control.

It was only when I, as the external consultant arrived to borrow the watch and tell the time, that it became clear that the definition of what was to be done by the workers on the ground level of the project was vague, in some cases I experienced just three words on a GANNT chart, and the responsibility for verifying that it had been done completely and correctly was equally vague and woolly. (That was a £50M project by the way!)

Consequently I became a fan of a project management approach called GDPM – and abbreviation for Goal Directed Project Management.  So much so that in each of the three reasonably sized (from 100-500 staff) businesses I ran, I trained all the management team in this technique – and used it as a key tool to manage the changes in the business I needed to deliver.

I would emphasise that for big projects GDPM complements rather than replaces traditional project management methodologies.  More importantly for the business leader readers of this article, it is much more appropriate when everyone working on the project is doing so alongside or as part of their ‘day job’.  When the issue isn’t one of calculating how many hours of work are required for each step and how many people are required for the activity.  Rather the challenge is to ensure that everyone is clear about the point of the project and their role in ensuring it succeeds.

It is not practical to explain GDPM fully in a brief blog like this. However there are some useful basic principles I can share that will I am sure help the typical business leader to succeed in getting their projects completed effectively on time.  And in fact most of the techniques an be boiled down to just three key tips for project management success.  These are based on GDPM but I’ve taken the liberty of enhancing them with my own thinking based on my experience of many projects.

Ensuring the whole team are absolutely, clear on the true goal of the project and how it’s success will be measured.  

Invest time in ensuring that the whole team are 100%, clear on the true goal of the project and how it’s success will be measured by the business sponsor.  The goal of a project is rarely as it is first described.  How often does a Managing Director really want ‘to implement a new CRM system’?  Isn’t the true goal to enable the sales force to work more effectively?  Or maybe to grow revenues by 10% without needing a larger sales force? Or perhaps to grow revenues to £20M by the end of 2031.

A great technique in working out the true goal is to ask Why Why Why – at least three Whys will probably be needed to get to the real goal.

Break the end goal down into intermediate milestone sub-goals.

That need to be achieved en-route to the end goal.  In this case they might be achieved ‘when the decision on which CRM system will be used has been made by the board’, ‘when the contract with the CRM supplier has been signed’, ‘when the trial / test system installation has been signed off as accepted by the business sponsor’, etc.

Define goals such that whether they have been achieved is totally definitive, usually based on someone being accountable

Notice that the milestones above are also goals.  Most definitely not tasks. The prefix ‘when the…’ is useful in leading towards defining an outcome rather than an action. Most importantly notice the suffix ‘has been …agreed/signed/accepted’.  This leads to a definitive black / white state.  The goal has been achieved or it hasn’t.

No fudge, not compromise, no vagueness.  No 90% complete 90% of the time!  Unless the goal has been fully achieved it has not been achieved at all.

A car with only three wheels fitted is of no more use than one with one wheel (for travelling from A to B anyway). Until someone is prepared to sign to say the the car has four wheels (and has been shown to be actually) the project is NOT complete and to the person wanting to get from A to B is NOT worth any more than no car at all.

And that’s it.  If you have the true goal absolutely clear to all and the milestones tightly defined with clear definitive (YES/NO) measures of completion then you will stand a good chance of your project succeeding.