On the right track yet?

I wrote an article in 2015 in which I talked about the eternal causes of project failure (do I hear your groan!) and related them to how we could improve project delivery for infrastructure. I read it again this week and thought that some things in the world of project management don’t seem to change and the integration of ‘project management’ and each of the engineering disciplines is a case in point. Or have I got that wrong? I have updated the article very slightly as some words are in vogue, like ‘digital’ instead of ‘IT’, but essentially it is the same as 5 years ago.

Have a read of the article and share your experience is: On the right track

Getting the team to work as one can be a challenge . . .

The Programme and Portfolio Workout is launched

PP workout 1e pngThe Programme and Portfolio Workout has been launched. Together with its companion, The Project Workout, this book aims to help you run your organization in a structured, yet agile way so you can meet your strategic goals and make sure all parts of your organization are aligned.

I have made three short videos introducing the books:

  1. The first video shows how these books have grown out of the original ‘Project Workout’, first published in 1997 and how they now give you the knowledge and thinking to make your organization succeed.
  2. The second video describes The Project Workout and how you can direct and manage one project at a time.
  3. The third video describes The Programme and Portfolio Workout, and how you can direct the tens, hundreds or even thousands of piece of work in your organization.

You can see these videos on Robert’s web site

A really expensive experiment

I was speaking at a PMI conference in Sweden and took the opportunity to listen to some of the other speakers, one of whom was Henrik Kniberg. Henrik is a guru on agile and lean and he told the story of a rather large public sector project in Sweden. The inadvertent experiment was that they did the same project TWICE!
To start with, Henrik discussed what “success” is and he defined it as being happy customers, happy users and happy development team. With apologies to PMI’s “triple constraint” he said to forget about time, cost and scope . . . actually this bit of the talk mirrored the start of my own talk at that conference, so “Mr Classic PM” and “Mr Agile” are on the same page. Why you undertake work is more important than what or how you deliver.

Henrik's different perspectives on success, over and above the "triple constraint". This thinking matches my thinking in Project Workout.

Henrik’s different perspectives on success, over and above the “triple constraint”. This thinking matches my thinking in Project Workout.

Henrik’s case study was all about improving society by helping the Swedish police force work more effectively. You’ve all read those dark, gloomy Scandinavian crime thrillers, so you get the idea. As we were in Sweden in “Wallender” country, it all seemed appropriate.
So, the first project was like this:

  • Mission Improve society
  • Requirements Unclear
  • Delivery Agile (= Iterative/incremental)
  • User involvement Continuous
  • Team’s influence over technology choices High
  • Technical platform Java

It took two years and comprised a series of releases, starting with the first one after 6 months, which the police hated, then after 18 months a nation-wide release and ending up with something they all really liked. SUCCESS!

Then “someone” had a bright idea to rebuild the whole thing in Oracle Siebel as Oracle said it would be better and cheaper. And as they were in a hurry to save money, they would go “big bang”. After all, they knew the requirements as the project had already been completed. So this is project 2:

  • Mission Reduce maintenance cost
  • Requirements Clear
  • Delivery Big bang
  • User involvement None
  • Team’s influence over technology None
  • Technical platform Oracle Siebel

This turned out to be a train wreck in slow motion:

Stakeholder response: outrage
Cost 200m KR (double that of project 1)
Time 24 months (as opposed to 18 months for project 1
Measured impact: Police blocked from using it several hours a day; error rate increased.

Lesson to be learned

So, the lessons are:

  • Focus on solving user needs not just cost: effective nearly always out-strips efficient;
  • Deliver iteratively and incrementally if you don’t know what you really need;
  • Involve real users.

Beware of standard platforms:

  • They might not be as standard as you think;
  • Listen to your technical people not just to a vendor selling stuff.

How many of you are building major capabilities on the promise of using a “standard” platform? I can certainly think of one I was involved with recently!

How do you think the re-platforming should be handled? . . or even should it be done at all, if what is there isn’t broken?

What about migrating from one to the other? Should we always design this in from the start? Or is it like turkeys voting for Christmas?

So agile is always better, is it?

Oh, and the stuff about ‘agile’ and ‘big bang’? That is just a red herring. You should use whatever delivery approaches are appropriate and proportionate to what you are doing. I expect some people reading this have had senior executives issue an edict: “do all projects agile!” This approach is just as mistaken as not trying agile at all – it underlines the classic IT confusion between a development approach and a project method. It’s not a case of ‘agile’ versus ‘project management’. Nor of thinking ‘waterfall = project management’. ‘Agile’ and ‘waterfall’ are delivery methods. Project management is a wrapper, which can contain any number of delivery methods, depending on the type of deliverables being produced.

Whose success is it?

In my “enemies within” blog, we looked at how senior management often gets the project performance they deserve. In that blog I  explored the important role of the programme and project sponsor in making sure that an organisation’s programmes and projects succeed. But what does “success” mean? Success is often interpreted through the differing eyes and motivation of stakeholders.

Successful project management ensures the delivery of a specified scope, on time and to budget (what PMI refers to as the triple constraint). It is related to how efficiently a project is managed. This should be assessed during the project closure review, documented in a project closure report and measured by timeliness of delivery milestones, adherence to budgets and quality. This is commonly associated with the role of the project manager.

A successful project delivers the outcomes and realises the business benefits it was set up to achieve as stated in a business case. It is related to the effectiveness of the project in meeting the objectives set. The post implementation review (post-project review) assesses this. Measures of success here must be indicative of the business objectives being achieved. This review therefore has to happen some time after the output of the project has been put into use and outcomes are assessable. It is more associated with the role of the sponsoring body and the project sponsor.

A successful organisation drives towards its strategic objectives while fulfilling expectations of shareholders, managers, employees and other stakeholders. Measures for this are at a corporate level and should be financial and non-financial, such as a balanced score card. This is associated with the role of the chief executive and board.

A project which has been successfully ‘project managed’, however, might actually deliver little of value to the organisation. Further, a ‘successful project’ might not further the strategic objectives of the organisation, as its objectives could be out of alignment to that of the organisation. A failing company can be full of ‘successful project management’ and ‘successful projects’ all driving in different directions.

Further reading: you will find my book, The Project Workout (5ed), advocates this approach, which I call business-driven or benefits-led project management. It is also the approach taken in ISO 21502:2020, BS6079:2019, PRINCE2:2017 and the UK government’s GovS 002 Project delivery.

 

Whatever you do must help you move towards your strategic objective. Otherwise there's no point.

Whatever you do must help you move towards your strategic objective. Otherwise there’s no point.