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.

More on Workstreams!

Earlier, I wrote a blog about the word “Workstream” and I promised some more on this problem word. See “So, what is a workstream?” In that blog I recommended you don’t use it, as it could mean almost anything a person wanted it to. Further it isn’t defined anywhere. Do you notice Mr Gates’ wobbly red line reminding you it’s not a real word?

In that blog, I finished by saying that if you do use the term, then define what you actually mean in your Programme Management Plan. You can only use four management procedures, so which is the most appropriate for you?

  • Managing  a programme, if your workstream is a sub-programme, or a grouping (portfolio) of projects.
  • Managing a project, if your workstream is actually a proper project
  • Managing a department, if your workstream is discipline based, say “the testing workstream”, “the training workstream”.
  • Managing a work package, if your workstream is simply a chunk of work.

I wonder how many people paid any attention to that blog! Why should they? If we can use a word that is a meaningless fudge and then pin the future of an organisation on it, then why not?

Seriously, though, most large organisations nowadays, have lots of programmes stuffed full of lots of things called “workstreams” and people really love the word. So let’s go with the flow. I expect the drafters for MSP felt the same way because in their 2011 edition, they defined the term workstream for the first time!!! This is their defintion:

A workstream is a logical grouping of projects and activities that together enable effective management. Workstreams may delineate projects against a variety of criteria.

They have a “hint box” in their new manual, which goes on to provide some advice. They say this is particularly relevant where there are many projects in a programme or where management control would be enhanced by sub-grouping the projects. One of the key factors for defining a workstream is to concentrate the dependencies, as much as possible, within the workstream. This is good advice and a workable defintion.

As such, translating that definition to published methods, we can see that a workstream is usually directed and managed using methods like MSP, as in effect, a workstream, using the above definition, is a sub-programme. A workstream sits logically in the WBS between “programme” and “”project/department”.

I think that is quite a good use of the word but, here is a WARNING: in many organisations the term, “workstream” has in practice already been used in so many different ways in the past that you should always check what definition is being used locally. For example, sometimes people talk of “testing” workstreams, which is in effect all the activities in whatever project, being undertaken by the Test Department. Similarly the “training workstream” is the work done by the training people anywhere in the programme. This usage does not fall into the MSP definition – it is not like a “sub-programme”. This usage is also very common in organisations which are low on programme and project management maturity and are still mostly run down the siloes.

So, despite the best attempts of the MSP folk to try and pin this one down, I think people will continue to do what they have done in the past and use whatever definition suits them at the time. So, one plea – if you do use the term, then define what you mean in your Programme Management Plan and say which of the four management approaches you’d use to manage it.

If you have any advice to provide or think you are using the term in the RIGHT way or better way (even if it’s different to what MSP says!), then let’s hear from you. If you run an company or organisation’s enterprise method, what would you say about this?

What on earth is a “Workstream”?

A lot of my colleagues thought this would be a good topic for a blog. Do you know what a “workstream” is? Does everyone have the same interpretation of that word? Are you sure? I assume someone, somewhere does, as it is used very widely in many companies (probably driven by some consulting organization!).
Some quick research
I did some quick research and found that this word does not exist in any formal project management methodology (for example PMI, APM, DIN, PRINCE2).
The often quoted Max Wideman glossary makes no mention of it.
A quick scan of the web comes up with comments like this, which was in response to a person asking what the Spanish for “workstream” is:
My guess as to why you are having difficulty pinning down the meaning of the term “workstream” is this extract from a response to a forum question:

I think it is a proper name of various businesses and software packages which is gradually leaking into professional jargon for more general use. I think “workstream” has not yet reached the status of a real word with a settled meaning. I won’t go so far as to suggest that it is meaningless, pretentious jargonspeak. But . . . .

It can’t be translated! This rather explains why, on my work on the new international standard on project management, I haven’t come across it. The International Standards Organisation (ISO) only uses plain English terms from the Concise Oxford English dictionary, which are translatable. The Project Workout is aimed at international readers and so I have taken the view that everything in it should also be translatable.

Even Microsoft Corporation, that great source of jargon and acronyms, doesn’t include the word in its spell checkers.

Looking at real organisations, I have identified “workstream” to be used synonymously with a “department, function or directorate” and a “sub-programme”, which are entirely different dimensions in the classic organisation matrix. I also found it was used to group together virtually any number of unclassifiable clusters of activities.
The Project Workout
The Project Workout does not contain the term “workstream” for all the reasons given above and yet it is in common use, We are not living in George Orwell’s “1984”, so you can use the term “workstream” if you really want to, but if you do use it, consider exactly what you mean and what management procedure would be used to manage it; if you can’t determine that, then you can’t expect anyone else in your team to understand you.

 

My advice – don’t use it!
I am sure people will still use the term, perhaps because it is such excellent fudge or perhaps it just sounds “cool”, “techno” or even “heroic”! My advice is to avoid using the word, when we have well defined, plain English, alternatives. What do you think?

For an update on this topic, see the later blog  “More on Workstreams“.