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?