Why bother with processes?

I expect many of you, on hearing the word “process” may have some bad feelings based on your experience. Perhaps there was gower-prgmngta critical point in your programme and you were side-tracked by someone telling you that you hadn’t gone through the seemingly trivial, but lengthy, check list on page 42 or perhaps the processes you had to use didn’t really help you and any feedback you gave just went into a “black-hole”.  That’s all very legitimate and this is indicative of “bad” processes.

This year Gower launched their 2nd edition of the Handbook of Programme Management and I was asked to write the chapter on processes. Good processes are key to increasing organizational maturity and hence business performance.  They are also essential if we are to manage through the increasing levels of complexity which face us; have a look at my two minute video  on why processes are becoming more important and  why we can’t ignore them.

 

Portfolio management – the next frontier?

Earlier this month I was speaking at the “Passion for Projects” conference in Sweden. I must say it was a really well organised event and I was delighted to have been invited to speak there. The topic I chose to talk about covered portfolios, project, projects, matrices and maturity. I’ll go into it more in some later blogs. I’ll assume you know a little about portfolio management. Just to recap, portfolio management is all about making sure you pick the right projects to do.  In “The Project Workout” i call them “business programmes” as at the time I wrote the book, the term “portfolio” hadn’t really settled down in the way it has now.  So, in portfolio management you have to make decisions on what to do and which meet the following criteria:

  1. It is aligned to your strategy
  2. You have the resources to undertake it and operate its outcome
  3. The risks are acceptable  (i.e. robust business case)
  4. The portfolo, as whole is still balance if you take this on
  5. The organisation can absorb the change.

So, the decision makers need to bbe able to make those decisions and have the data available to verify the criteria.

I was asked a question about this: “If a programme has been approved as part of a portfolio, has the programme sponsor the authority to authorise the project within the programme, or do they all have to be referred to the decision maker at portfolio level?”

My instincts were that if the programme as a whole has been approved, then the programme sponsor should be able to make the decisions . . . however it is not that simple. It all comes down to shared impact. For example, if the programme team has all their own “ring-fenced” resources, then they can make decisions relating to criteria 2. If they share resources with other programmes or components of the portfolio, then they can’t. Similarly, if they are the only ones impacting a “target user group” (change absorbtion) then they can verify criteria 5. If niot, then the decision has been elevated.

Further, the degree of to which there is knowledge of the programme, its resources and impacts at the time it was approved also matters. It may be that the first chunks of work are pretty weel known and as long as these stay in the bounds expected, decision making can be at programme level.

As you see, what appears to be a simple question is actually very complex. The more you ring-fence resources, the greater you can delegate decisions to programme sponsors but, you lose potential efficiencies for using those resources on other work. It’s a balance. Whatever you choose, remember:

  1. What ever you do must align with your strategy
  2. There is little point in authorising work that cannot be undertaken – in fact it is really damaging
  3. You need to ensure the risks of adding this to your work-stack are acceptable
  4. You nee to ensure your portfolio remains balanced, when you add the new work in
  5. There is little point in doing work, which the operational teams, customer etc cannot accommodate in terms of change.

You’ll find a lot more about this in The Project Workout, section 3. Many organisations are only just starting to “get it”; it’s all applied common sense.

 

Project management excellence is not enough

Beware of doing too many projects, even if they do fit your strategy and have a good business case.

Beware of doing too many projects, even if they do fit your strategy and have a good business case.

The opening plenary sessions of the 2013 Gartner PPM and IT Summit in London, set the tone for a mind-set shift in how Gartner looks at “IT management”.  To date they have focussed in on “IT” and the “CIO”, and, in my view, perpetuating the gap between what they term “IT” and the “Business” . This year, to my delight, they were starting to talk about “the business” and IT’s part in it. It’s a brave thing to do, but the right thing to do. Most organisations still have their IT split off as separate organisational units ,with a separate strategy and loads of money, which tries to work out what “the business” wants and then all too often fails to meet those expectations. What is guaranteed though, is if you give an IT department money, they will spend it all, even if the business need is unclear. . . . that’s the “business’” fault!

Mike Langley from PMI was a key note speaker and gave his view on the all important question of “how do we ensure our (IT) projects fit our strategy?”  Notice I put “IT” in brackets – the department is irrelevant as we want all our projects to align with strategy . . . don’t we?

Mike based his talk on PMI’s recent “Pulse of the profession” survey.

We are all familiar with “strategy” and “execution” (sorry for using the “e” word, but when at an American conference, you can’t get away from it!).  The story is that the business leaders set the strategy and then the “business” implements it. If it goes wrong, it’s usually the fault of the business and their dreadful requirements and poor implementation!  What new research for Harvard Business Review is now talking about is that implementation is part of strategy and we should not separate them. (look out McKinsey and Bain!.) After all, if your strategy doesn’t include how to implement itself, then it’s a poor strategy.  The new buzz words for making this happen is “portfolio management”. This is a discipline of making sure that the programmes, projects and other activities that a business decides to do are the rights ones in terms of strategic direction, fit and balance in terms of risk and skills use. It’s all about selecting the right projects.

Mike says his research shows that organisations which are good at portfolio management are more agile, and have better project outcomes. Portfolio management is integral to how the top level leaders want to manage their business; it’s an integral part of business planning. Traditional business planning adds up costs of departmental budgets, checks against revenue and makes sure there is “interlock” if different departments need to work together.  Usually this is done a year or so in advance and is therefore totally pointless for organisations in fast moving environments. It is however a neat and simplistic way to blame people when things go wrong or costs to much. Hence, getting portfolio management working right is as much to do with mind-set as having the processes, systems and operating model.

Getting this right, means organisations can continuously tune their plans, not be tied to outdated annual budgets and use their people and money where the benefit is most attractive.  The money will follow the business need, not the department doing the work. Now that is what I call true organisational agility and if you have read the Project Workout, it will be very familiar to you.

This isn’t new as a concept, but it is something many organisations struggle with.  Have a look at this article: Excellence is not enough from the Project Workout “articles” web page.

The secrets of successful programmes

CranfieldI recently went to the International Centre for Programme Management (at Cranfield) for a forum on learning and knowledge management  and as part of that we were given a white paper called “Beating the odds – the secrets of successful programmes”.

The white paper describes the findings from a recent two-year study of 21 major programmes of many types, with varying levels of success in a wide range of organisations in Europe. Those findings explain many of the causes of the differeing levels of programme performance and how business leaders can improve the success rate for their own organizations.

Seldom do I read an article or paper with the words “Yes, yes, yes” ringing in my head. It is packed with useful insights and wisdom, gleaned for the programme teams who took part in the study. The wisdom in this paper won’t be found in methods and processes, they are more about how experienced and skilled people apply them and the issues they face.

I recommend this to any person who considers themselves to be (or aspires to be) a business leader. As expected, there is lots about vision, strategic alignment, business readiness, foggy objectives, stakeholder engagement, business cases, planning and behaviours. If, as a business leaders, you believe you have a great strategy, then good for you. On its own, however, that is not enough. You need to be able to convert your vision and your strategy into action on the ground. Do you have the right mind set, tools, methods to do this?  Read this article and decide for yourself.

This is the executive summary:

  1. Strategic alignment. From the programmes studied, those identified as integral to the future business strategy were all at least partially successful. It could be concluded that the ‘positive’ nature of the programmes’ intentions meant that there was little stakeholder resistance to the initiative and hence the organisation was able to deploy its most capable resources. Senior management and executive involvement was sustained throughout the programme. Conversely those programmes that had primarily ‘reductionist’ intentions, e.g. restructuring to reduce costs or eliminate inefficiencies, were less successful. Executive involvement in the programmes was weak and stakeholders’ commitment quickly waned.
  2. Need and readiness. Interestingly and perhaps counter intuitively, in most of the successful programmes the need was ‘high’ – clearly recognised as a business priority – but initially the readiness was ‘low’. In these the argument for investment and change was endorsed at executive level and time and effort spent at the start to achieve the buy-in of the rest of the organisation and develop the ability to undertake the changes. In the majority of those that were partially successful the readiness appeared to be ‘high’ as well as the need. Why they were not entirely successful is best explained as over-ambition or even over-enthusiasm; rather too many optimistic assumptions were made at the start with little assessment of the potential risks involved.
  3. Value drivers,benefits and business cases. The more successful programmes were also based on a clear strategic driver plus a strong financial business case. Those with weaker strategic drivers but good financial cases gained less commitment and were usually less successful. Very often financial benefits were overestimated, while the risks and the problems in making the changes were underestimated, perhaps because realistic estimates might have made it difficult to secure funds and resources. During the programme, as the scope becomes clearer, this inevitably leads to changes to the costs involved and the benefits that can actually be delivered, but only a minority of organisations revisit the business cases as programmes evolve.
  4. Foggy objectives. Programmes cannot be fully planned in advance and have to adapt to both changing business conditions and programme achievements. This is not necessarily a comfortable position for senior management and requires a knowledgeable, accountable and empowered governance group to oversee and, where necessary, adapt the programme. Rather than decrease during the programme, uncertainty can often even increase, especially due to changes in the external environment.
  5. Planning. Some organisations thought they may have ‘over-planned’ things at the start, due largely to the demands of some stakeholders for detailed plans, which were then not really used. However, the planning activities were seen as essential to bring stakeholders together and for reconciling their different priorities and interests. The process of planning was more important than the plans produced and helped address many of the initial uncertainties.
  6. vision and stakeholders. Having a clear vision of the intended future business and organisational models and then allowing compromises and trade-offs in the detail of how they are implemented, is more likely to achieve stakeholder commitment than imposition. The successful transformation programmes usually addressed the organisational, people and capability aspects first, before dealing with the process and technology aspects. The less successful tried to do the reverse.
  7. Learning and un-learning. Most ‘strategic’ programmes require the development or acquisition of new capabilities and knowledge in order to be carried out successfully. Management generally underestimate how much has to be learned by the organisation and individuals to define, manage and implement a major programme. Introducing new ways of working may also require considerable ‘un-learning’ by large numbers of professional people – not easy to achieve without actually removing the old processes. If the programme relies heavily on the capabilities of suppliers (especially IT suppliers), they may exert undue influence over what is done – the scope and achievable benefits – rather than on how the programme can be successfully delivered.
  8. Realising the benefits. Most business change programmes involve at least two distinct and different phases – first to create a new capability and second to exploit it. In most of the cases the new capability, for example a global HR database or Finance & Accounting Service Centre, was created, but not always used effectively, hence the benefits achieved were often less than those originally envisaged. While creating a new capability can be done ‘off-line’, separately from business as usual, using and exploiting it often competes with other operational priorities or can have negative effects on other aspects of operational performance, as was observed in some of the cases.
  9. Organisation and governance. Programme governance structures and staffing profiles are likely to change significantly over the life cycle. There seem to be three basic approaches to organising programmes: (1) a separate task force, (2) as part of business-as-usual (BaU), or (3) a combination (matrix). Not surprisingly the last of these proves most problematic. Some programmes have dedicated change managers, others have senior managers assigned to the programme, but they can find it difficult to reconcile achieving change at the same time as sustaining performance. Running change programmes in parallel with BaU causes tensions within the organisation and a clear statement of priority for which takes precedence is essential.
  10. Portfolio management. Few organisations, as yet, have the capabilities in place to manage multiple concurrent programmes with varying levels of uncertainty, competing for the same resources over extended periods. No organisation in the study had an effective mechanism in place for managing a combined large portfolio of ‘strategic’ programmes and more traditional projects – although some are trying to address this issue. Managing multiple programmes (Programme Portfolio Management) requires an additional governance structure or regular strategic and operational review and reconciliation at executive level especially if there are programme inter-dependencies or contention for critical and scarce resources.

Do you want to know more?

Cranfield had very kindly let me make the full article available to you here

So why was I saying “yes, yes, yes,” to myself? Many of the lessons are embedded in the Project Workout:

  • vision, strategic alignment: are covered in the gated approach to projects, from the very beginning(Chapters 3 to 11)
  • portfolio management is covered in Project Workout as “Business Programmes” in Chapters14 to 17.
  • business readiness,is a prerequisite for Project Workout’s Ready for Service Gate (page 118)
  • foggy objectives,are discussed in Chapter 12, along with other types of “Eddie Obeng” projects
  • stakeholder engagement,is covered in Chapter 19 as well as threaded throughout the book
  • business case, is at the heart of the Project Workout’s business led approach
  • planning in Chapter 19
  • behaviours are covered in Chapter 18

Of course, in the “real world” these are not isolated activities but happen in a complex network of cause and effect and that is why it is all so difficult to do in practice.

More on meetings

Are your meetings a bit like this?

Are your meetings a bit like this?

I did a blog on meetings last year, called I hate (some) meetings and one of the comments asked for some advice on conducting meetings. I suppose meetings are so common place that few people give any thought to making them run effectively. As a consequence, we find far too many meetings are an inedible waste of time. So, here we is some advice to take us back to the basics.

Firstly, do not hold a meeting at all if there is a better way of achieving the objective. The time taken during the meeting should typically represent only 10% to 20% of the total time needed to prepare for and follow up the meeting; use your time appropriately.

Before the meeting, the person calling the meeting should:

  • fix the objective, venue, date, time and attendance well in advance; keep numbers to a minimum
  • ensure all required parties are invited and have authority/knowledge to take decisions and/or make a valid contribution
  • set accountability and time limits for each agenda item, taking into account the participants’ different interest levels for each item
  • send out agenda and written submissions in time to allow participants to prepare.
    Those invited should accept the invitation, decline or provide a substitute attendee, as appropriate.

At the meeting:
The Chair should:

  • confirm who the note taker is
  • confirm the objective of the meeting
  • start and finish the meeting on time: censure late arrivals.
  • stick to the agenda and timetable.
  • ensure there is an agreed approach for undertaking each agenda item.
  • keep the meeting focused.
  • ensure full, participative discussion takes place.
  • guillotine “knotty” issues for resolution outside the meeting.
  • summarise each agenda item at the end and ensure agreements and actions are recorded .
  • agree and fix date for next meeting, if needed.
  • seek meeting participants’ feedback on the effectiveness of the meeting.

The Note taker should:

  •   act as the Chair’s right hand person.
  •   ensure all decisions and agreements are noted.
  •   take brief, relevant, action oriented notes.

Meeting participants should:

  • keep to the point and be brief.
  • listen to others and should not hold private meetings.
  • be constructive, adopting a “can do” approach
  • agree realistic plans/actions.
  • make a note of their own actions (including recipient and date).

After the meeting:
The Chair should:

  • review the effectiveness of the meeting and note improvement points for the next meeting.

The Note taker should:

  • publish the notes or minutes to the participants and those who need them within 1 day. What is the point of “old minutes”, they are no good to anyone. It takes the same time to do them straight away as to do them a month later – it’s just a matter of you organizing yourself.

Participants should:

  • assess their own effectiveness at the meeting and note areas for improvement; make suggestions to the Chair if appropriate.
  • read the minutes and address all actions and note those actions where they are the “recipient”.

HINTS
If you use a collaboration tool such as SharePoint or Livelink, use a task list to record the meeting’s actions. In this way, no actions are lost and those accountable for each action can readily find them.

Place “Review of Previous Minutes” towards the end of the meeting agenda, rather than at the beginning. This will encourage the meeting to go forward rather than starting by dwelling on what happened last time. If important, many of these items will be dealt with in the main agenda items.

If the notes are not for a formal meeting then consider the use of hand-written notes or as a photocopied page in your work book:

  •  record actions, in hand-writing at the meeting,
  • photocopy the sheet(s) just before the end of the meeting,
  • distribute to participants before they leave.
  • scan and file the handwritten note if you need a record.

. . . and make sure you all behave well at the meeting:

  • Start on time
  • Switch off or silence mobile devices
  • Keep to the agenda – Stick to the point
  • No private meetings
  • No interruptions or walk-outs
  • Be constructive
  • Speak out during the meeting – not afterwards
  • Be polite
  • LISTEN!
  • Agree conclusions and actions
  • FINISH ON TIME

I hate (some) meetings

I wonder how many people agree with the title of this article? In fact, I have not been fully honest; I hate badly run meetings. You’ve probably been there:

You turn up on time and hang around while others drift in. Someone spends the next 10 minutes looking for a chairman’s code so the “dial-in” attendees can participate. Then someone says, “Let’s start”. . . . . and everyone ignores him or her. Finally someone says, “Shall I chair this?”. “Oooo yes please”, comes the reply.
“Okay, what’s this about?”


SILENCE.


“Err, ok, lets look at the minutes of last month’s meeting. We got these yesterday, didn’t we?”
They all then go through some cryptic meeting notes and argue about what was really said. In fact for this one hour meeting, half of it is spent going over the last meeting. . . . with no progress at all and all the “agreements” made at the last meeting were disputed as the wording in the minutes was rather ambiguous.
“Sorry, I need to go”, says one person, “I have to walk the dog, she’ll chew the table legs if I don’t go.”
In a vain attempt to gain control the Chair says, “Let’s look at the actions from the preceeding meetings”. He then goes through them and they argue as to what the action really was and who was meant to do it. One action is done however, but no one can remember why it was needed or who the output was meant to go to.
“Ah,” says the Chair, “we are out of time, but could everyone stay on for another half hour? We do have some really important things to discuss.” He looks daggers at one person who walks out . . . .
He then lists the topics on a flip chart. The remaining attendees then discuss what order to take the “important items” in.
“Wasn’t there an agenda?”, says a new joiner (Aren’t they naive when they are young!).
“Oh no, we don’t go in for that bureaucracy. It’s such a waste of time. We always have the same agenda”.
They actually get through one item and then the meeting fizzles to a close.
“Well, that was good – we had that item sorted.”
“Did we?”
“Yes”
“Who got the action?”
“I don’t know; it’s not me any way”.
“Who was taking notes?”
“I don’t know. See you next time.”
“Who was on the conference phone?”
“I don’t know, we never asked . . . . “

I’m not sure if the story above reflects your reality or just pieces of reality; only you can tell, from your experience. In the meantime, if you end up in the “meeting from hell“, perhaps you can do something about it. and not be a victim. If you want , I could publish some “best practice” notes on meetings. Let me know.

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?