Is your parrot (I mean project) dead?

A risk register is sometimes not enough.Dead Parrot

Projects are not simple things to manage, even when there is a book, like the the Project Workout, to help you.  So, how do you know if your project is “healthy” and likely to meet the business objectives it was set up to achieve? How do you know it’s not well and truly dead, like the proverbial Monty Python parrot?

Well, a quick look at the risk log may help, together with a view on the issues. The schedule plan updates should show you how you are doing against your baselined plan. (what do mean you don’t have a baseline?)

These are all good ways to gain a feel; they are your day to day instruments. Sometimes, though, it’s good to rise above all the detail of methods, tools, reports and logs and consider in an holistic way, “Will this project really do what we need?”.

The Project Health Check

This is where the project health check comes in. It asks five searching question on each of the following areas of project management:

Project plan
Resources
Ownership
Justifiable case
Expertise
Clear solution
Targeted control

If anyone of those is not adequately covered, then your parrot may indeed be dying.

Let’s have a look at the output from an example:

Example of an output from the Health Check

Example of an output from the Health Check

Overall the tool’s analysis suggests the project is medium risk. Well, you might say, that’s ok, isn’t it? However, if you look at the problem areas you can see they relate to:
Solution – we don’t know what we’re building
Resources – we haven’t got anyone to do whatever it is
Expertise – we don’t fully have the expertise we need.

Now this cluster makes sense. All the management stuff is okay, but if we haven’t got the expertise for the specialist work, then perhaps that’s why we don’t yet have a solution. Also, if there is no solution yet, you can’t really know what resources you need.

So is it okay? If you are in the investigative stages of the project then, yes, you could be okay, assuming you take action to fill the gaps. If however, you are in the development stages or later, then your parrot is probably going to die.

As with all these types of tools, they are there to help you think and self-delusion in answering the questions will reinforce any delusional opinions. For that reason, it’s often good to do this type of assessment in groups and gain a consensus; the value of the discussion will far out weight the paper result.

When would you use this?

I suggest that you use at as an input to every gate decision to provide the decision makers with a summary of the ares which need attention. You can also do it “ad-hoc” in response to any concerns which have been raised.

Is it worth it?

Yes. One company I work ed with employed some consultants to review 12 of their most critical projects. The consultants used their own, very extensive, tools and check lists. When they’d finished their work they took this tool and applied it to all twelve projects. The found a full correlation. In fact, they said if the company had applied this tool first, as a filter, they could have saved 60% of the consulting fee as most of the projects were fine.

You can find the tool in the CD which accompanies the Project Workout.

Enemies within – why it doesn’t work

Far too many projects fail.

Far too many projects fail.

Project management, in the modern sense, has been with us a long time now. Some people have spent most, if not all their careers engaged in it in one form or another. Research and anecdotal evidence, however, seems to indicate that we still don’t “get it”. Reports continue to be written on “causes of project failure”. Eminent committees are set up to “get to the root of the problem”, international and national standards are created and yet:

  • we still see failure.
  • we still see organisations which ignore the benefits.

Why is this? If I could answer that, then I would be able to charge massive consulting fees! The question is rather like that posed in “Hitchhikers guide to the galaxy” asking, “What is the meaning of life?”  As we all know, the answer is “42” – which doesn’t help us one jot. If I ever came across anyone who knew the solution to stopping “project failure”, I would be very skeptical.

So why can’t people grasp the significance and advantages of business-led project management? We have:

  • lots of good books – like the Project Workout!
  • National and international standards such as BS6079 and ISO21500
  • Leaned societies, like the APM and PMI
  • Conferences galore

Actually, when the Project Workout came out in 1997 it was probably the first to put project management in a business context; earlier books were focused on project management techniques.

Cover all four basesBack to the topic! Having good methods and process supported by good tools and systems with clear accountabilities is necessary but not enough. The critical difference comes from an organisation’s culture; how they behave and their values. Give me the right culture and mediocre process over poor culture and brilliant process, any day. Organisations where project management “doesn’t work”, are likely to have a culture which actively prevents it from working. For example, for project management to be effective, we need more than just good project managers; for example:

  • project sponsorship is vital if the projects are to be linked to strategy
  • portfolio management (called business programme management in the Project Workout) is necessary to balance risk and choose those projects which will get you towards your strategic intent faster
  • finance systems, which enable project sponsors, managers and teams to see, their operational figures “live”
  • resource management so you can take account of constraints in choosing and implementing your projects.

Hunter Thompson, in 1970, said “In a democracy, people usually get the kind of government they deserve and they deserve what they get.” In this he blames the people in a democracy. Organisations, however are not democracies and so I would turn that quotation on its head:

Senior teams get the project management performance they deserve“.

The CEO sets the culture and “the way they want to run their business” and the following list indicates where the culture and values promote failure, rather than success. Running a project is difficult enough, but we often make it more arduous than it need be by creating problems for ourselves. Here are a few examples:

  1. Reorganising – either the company or a part of it. Tinkering with your structure is usually NOT the solution to your problems, it just confuses people. If you are a senior executive, however, reorganising is a great way to hide non-delivery!
  2. Functional thinking – not taking the helicopter, the organisation-wide view. This often happens when executives’ or individuals’ bonuses are based on targets which are at odds with the organisation’s needs, e.g. sales bonus rewarded on revenue, regardless of profit or contribution.
  3. Having too many rules – the more rules you have, the more sinners you create and the less happy your people become. Have you ever met a happy bureaucrat?
  4. Disappearing and changing sponsors – without a sponsor there should be no project. Continual changing of the ‘driver’ will cause you to lose focus and forget WHY you are undertaking the project. Consider terminating such a project to see who really wants it!
  5. Ignoring the risks – risks don’t go away, so acknowledge them and manage them. If I said that a certain aeroplane is likely to crash, would you fly on it? And yet, every day executives approve projects when a simple risk analysis shows they are highly likely to fail.
  6. Dash in and get on with it! – if a project is that important, you haven’t the time NOT to plan your way ahead. High activity levels do not necessarily mean action or progress.
  7. Analysis paralysis – you need to investigate, but only enough to gain the confidence to move on. This is the opposite to dash in and ignore the risks. It is also a ploy used to delay projects: ‘. . . I haven’t quite enough information to make a decision, just do some more study work.’
  8. Untested assumptions – all assumptions are risks; treat them as such.
  9. Forgetting what the project is for – if this happens, terminate the project. If it is that useful, someone will scream and remember why it is being done.
  10. Executive’s ‘pet projects’ – have no exceptions. If an executive’s idea is really so good, it should stand up to the scrutiny that all the others go through. He or she may have a helicopter view, but might also have their head in the clouds.

I’m sure you can add to that list, so please do, by adding a comment. Over the next few months, I’ll investigate a number of the above symptoms.

In the meantime, you can find out more about these from The Project Workout (4th edition):

  • lessons on what works: Chapter 2
  • enemies within – page 41
  • sponsorship: Chapter 4
  • portfolio management: Chapters 14 and 15
  • resource management: Chapter 16
  • finances: Chapter 17

Lifecycles and fuzzy back-ends

I have just spent a really great few days at the APM’s PMO conference near Birmingham, UK. My task there was to give a “master class”, three times, to about 60 of the delegates, on the topic of “Lifecycles”. This covered project, programme and portfolio lifecycles, as defined in the latest APM Body of Knowledge.  I promised the delegates, I’d write a blog about some of the key points which came out of those sessions. As project lifecycles are the most complex and the most critical, I’ll concentrate on that. By the way, congratulations to Eileen Roden for organising such a great conference!

Where does it all go wrong?

In designing gated and staged project lifecycles, I have found mistakes are usually made in the following key areas: the front end and the back end and in the middle! So, lots of scope for problems there!

Getting gates wrong
Firstly, people often treat gates as “exit points” from a stage. I have never met a senior manager who makes decisions walking backwards, so this approach does not match basic human behaviour. Gates are better seen as entry points to the next stage and are, therefore, about making decisions as to what to do next. If you want to look backwards, then have a “review”.

Problems at the start
All too often, I see frameworks with minimal initiation activity, immediately followed by a load of development and testing basically going from ‘idea’ to ‘do it’ in one small step. In all but the simplest projects, such a leap is naïve and may account for why so many projects are ill-defined and doomed to failure. By all means, make it easy to start the project off, but do ensure there is rigour in the actual investigative work itself. A project comprises both investigative work and “doing” work.

Problems in the middle
I sometimes see lifecycle stages with no decision point prior to them. If there is no decision point, then there is no need for a separate stage. Remember, project stages are chosen to manage risk. They are NOT steps in a process. The way risk is managed is by dividing the project into stages, each of which is preceded by a decision point (gate) prior to starting each stage. The riskier the project, the more lifecycle stages there should be.

Problems at the back end
I see many project plans which stop as soon as the output has been handed over. The only time this might work is IF the delivery has been perfect and there is no remedial or snagging to do and the outputs do not need fine tuning, launching or communicating . . . i.e. almost never. This is why the last stage of the Project Workout’s lifecycle covers initial operations, with closure happening only at the very end.

At the back end, people often confuse Project Closure with Post-Project Review. The former looks at project efficiency and delivery, whilst the latter looks at benefits realisation and operational effectiveness. These two views cannot usually be combined as the measurement points are separated by time.

Also note that ‘Identify project” and ‘Review project outcome” are not stages of a project. They are activities which happen before and after the project, respectively.

Depicting frameworks
The use of the circle, arrow and diamond icons in lifecycle diagrams is designed to ensure that the above mistakes do not happen. This form of iconography is now enshrined in the latest British Standard (BS6079 Part 1). If you haven’t seen it, then you really should get a copy.

A five stage project lifecycle taken from the Project Workout.

Naming project gates (and stages)
As best practice is that gates are entry points to stages, then the most logical name for a gate is the name of the stage that follows. Thus the Definition Gate precedes the Definition Stage. Very simple . . . really. The only common exception is the RFS (Ready for Service) gate where the term is self explanatory. When choosing names for your stages, however, be very careful. I suggest you avoid words which can be misunderstood. In my experience the words “Concept” and “Implementation” should be avoided as they can be interpreted in many different ways and cause confusion. Similarly, avoid the word “Execution”: the International Standards Organisation has not used it in their draft project management standard as a majority of member states took exception to it as it can also mean “judicial killing” and hence translation into other languages can be problematic.

More help?

  • Book: Chapter 3 of the Project Workout tells you all about project lifecycles, helping you to design one that works for your situation. In Chapters 5 to 11 it describes the detail for each stage and then in Chapter 12 it tells you how you can tailor it.
  • Articles: You’ll also find some articles you can download from the community pages of my projectwout.com site.
  • Video: Here is a video taking you through the project lifecycle in the Project Workout
  • Click for yourself: you can investigate the model in the video above yourself. Go to the community pages in my projectwout.com site.