Goal Directed Project Management – oldie but goodie

toolkit_logo2

My go-to basic project management method

Why?

– It’s simple

– It supports (and improves) the use of other methodologies

– It’s generally applicable to all sorts of projects

If you don’t know what I’m talking about I’ve attached a brief description…..

gdpm intro

Let me know if you’ve got a fave – and why


4 thoughts on “Goal Directed Project Management – oldie but goodie

  1. I think they miss out the usefulness of product-based planning. You can’t jump from objectives to milestones easily. It’s better to work out what products are needed to meet your objectives, and then establish key milestones.

    But the essence of being focussed on goals instead of activities is good. I think a really good PID can help to achieve this. If a lot of work goes into producing a really good PID then you achieve a lot of what they recommend. But a PID written in isolation by a PM is a recipe for a disaster! Same with the plan. Get these two right and you can seem like the “Lazy Project Manager”. Which is good, not bad, as it shows that you’ve communicated clearly from the start and have worked out a clear plan (see https://www.wrike.com/blog/interview-with-lazy-project-manager/).

    If someone were a PM novice and asked me which methodology to follow I’d probably still say that they should become familiar with PRINCE2 as it set the language that most projects use. But that they should also follow these principles (as there is no one silver bullet PM methodology):

    – focus on objectives not activities (as per this methodology)
    – develop a really clear PID with the stakeholders at the beginning (this therefore covers off scope, governance, benefits etc)
    – ensure governance is tackled at the very beginning with no ambiguity about who is calling the shots (and not splitting the top role just to appease)
    – get the team together to create the plan, and run product-based planning work shops
    – communicate vigorously throughout
    – get key milestone dates in people’s diaries, not just on a plan
    – get people taking ownership of their area (a presentation by them to the rest of the team can help this)
    – if you can, get your governance body e.g. Project Board to really understand their roles and to voice their support
    – be terrier-like with your task allocation (don’t let go until someone’s name is on the task!)
    – seek common sense and clarity in all meetings. E.g don’t let tech or methodology ‘speak’ obfuscate what’s really important.
    – break the programme or project down into manageable chunks
    – deal with the nasty stuff / elephant in the room first
    – prototype whenever possible (even if made out of paper) as it will stop the team analysing themselves into dead ends
    – get business experts on the actual project team
    – don’t delegate key roles that shape the final product to third parties e.g. Product Owner
    – motivate your team!

  2. I have a copy of the book (naturally) I’ll read it in a couple of weeks time when my belongings come out of storage. I’m interested in what it has to say on benefits management. I like the benefits driven approach in CHAMPS2. What would happen if the desired goal no longer deliver the expected benefits – how would this be recognised? What happens at the milestone planning stage, or worse after, if the scope suddenly changes, say in response to some competitive threat of something like that? How are changes dealt with? Accepted as part of project life or avoided at all cost?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s