Outcomes – do your projects keep their promises?

Several comments on my last post about flabby project methodologies focused on “outcomes”, particluarly from the public sector.  The rationale is pretty straightforward:

  • As the client, we know what we want to get out of the project (a more efficient call-centre, faster turnaround time on website changes, instant access to documents from wherever I’m working, etc.)
  • As our IT partner, you will know how best to use the technology available to achieve these outcomes.
  • Therefore we won’t prescribe how we want the systems to work, but we will prescribe what we need them to do for us.  You will compete with other candidate IT partners and we’ll pick the one that on balance offers us the best value, which may not be the cheapest.

This is great – the board can focus on outcomes and not get bogged down in detail.  Of course, somebody has to deal with the detail don’t they – and this falls to the project team.

Project managers tend to be task focused and they love sequences of activities that add up to completing a deliverable, and sequences of deliverables that add up to completing a project.  Everybody understands nice, clear, concrete activities and deliverables, and when they are put in a Gantt chart and ticked off on a regular basis it becomes competitive and the plan seems to hold hypnotic powers over the PM, and even more so over the PMO and other assurance folk!

The great danger is that all focus shifts towards completing activities and deliverables, and away from the expected outcomes of the project.  Who cares if you delivered your new call-centre system on time and within budget?  What matters is whether it has given you the 20% staff reduction, or the 10% more sales, or the 15% fewer complaints …whatever was promised in order to get the project approved!

Deliverables must achieve the promised outcomes Cartoon @Giggle

Tricky eh?  Project teams do need to focus on tasks and deliverables – after all there’s a deadline and budget to meet!  Similarly the project board needs to maintain its own discipline of focusing on outcomes – only delving into the detail by exception.

It is the project sponsor’s job to set the context within which the project team can focus on its tasks.  To be fair, most kick-off meetings do talk about the outcomes – or at least the outcomes that aren’t too sensitive.  But the memory of the tub-thumping sponsor evangelising about the joy of multiskilled homeworking staff quickly fades and newcomers to the project get (at best) a look at the kickoff slides on day 1 while they are waiting for their user account to be set up.

It falls to the PM to reinforce the project context by constantly reminding the current team why they are producing the deliverables.  The PM must set the focus of the project plan and the project meetings not on “go live”, but on delivering the promised outcomes.

Take a back seat at your next project progress meeting – does the dialogue show a good balance between understanding what needs to be delivered and how it contributes to the promised outcomes?

This entry was posted in Process and tagged , , , , , . Bookmark the permalink.

2 Responses to Outcomes – do your projects keep their promises?

  1. Ali Safri says:

    Outcome based/ Realization of benefit focus should be the consideration, but in terms of roles I would differ that this should be the job of the Program manager or value management office.
    Also the IT solution is only part of the problem in every project, organization cultural changes, trainings, procedures and processes also need to be aligned otherwise the outcomes or benefits cannot be realized.

    Getting the project on budget, on time and on scope is too much of a task for a project manager hence they should focus on How part only and not on What to do because PM might not have that formal authority as per the project charter. Also this may go wrong due to organization politics. Also an absence of a formal RACI creates more chaos and only succeeds because of heroics and thus in terms of mature processes, is non-repeatable.

    Benefit realization approach was discussed at length in the book “Information Paradox” (free download copy available from )
    http://www.fujitsu.com/us/news/publications/books/ip.html

    in which program management (outcome based focus), considering IT projects as investments etc was some of the findings specified by the author.

    Those are formally instituted in VAL IT specification by ISACA in the form of Value Management and Delivery best practicies that falls in the broader scope of IT Governance.

    Read
    http://alisafri.wordpress.com/2010/09/11/value-management-way-how-to-realize-the-benefits/
    for my understanding in this regard.

  2. admin says:

    Hi Ali,

    Thanks for your thoughtful comment and the links to the Fujitsu eBook and your blog – I like the breadth of your blog, you clearly have a hungry mind!

    “Getting the project on budget, on time and on scope is too much of a task for a project manager” …so get rid of that PM and get one that deserves the job title!

    Of course you make a valid point and there is a good argument for separating responsibility benefit realisation from project delivery. I think it is very dangerous for a PM to focus exclusively on delivery because in the pressure to get things done, the *reason* for getting them done is often forgotten. This is how benefits are not realised.

    You picked up I think that I am quite relaxed about roles and responsibility. That’s probably true to some extent – I believe in giving people clear roles and responsibilities, but I believe there is a collective responsibility to ensure a project delivers the outcomes it promised. I don’t want individuals in my team to use their R&Rs as blinkers and ignore the elephant in the room!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>