Learning Leader

'Programme Leader'?

Yesterday's seminar on how the UK Government got into commissioning best practice management methods was well received. I talked a little about how the design approaches in first PRINCE2 and MSP developed over the last seventeen years.

In the questions afterwards I was asked, in connection with the Leadership and the Business Change Manager role, whether I favoured role titles such as 'Programme Leader' and 'Business Change Leader'. I responded that I did not think this was wise.

I think of how, in the case of project management, people have used the title 'Project Leader'. In this case it has come to mean someone more junior than the project manager, perhaps at team leader or work package level. This sends a message that the 'real deal' is really about management, and that within a project leadership is pretty much confined to teams of people. This is a pity, and I wouldn't want to encourage the projection of this kind of thinking into programme management.

MSP compares and distinguishes leadership and management; both are necessary, neither is sufficient. If anything, leadership will, without doubt, need to come into play far more than in the project arena, for all kinds of reasons. Which is one instance of why it is so dangerous for project managers to approach the subject of programmes and being merely aggregated projects.

So thanks to my hosts from the BT Centre for Major Programme Management. It seems to me that they are stimulating some valuable and needy conversations around the whole area of managing within complexity in this seminar series.

benefits management, Business Change Manager, leading transition, programme management

When a great project is just not enough

A while back, just before it opened (and I stress that), I eulogised about the new Terminal 5 building at Heathrow. What happened after that became an embarrassment of national proportions. My embarrassment was as of nothing to the pain people in the centre of it went through in the first couple of weeks after opening.

So I've been thinking about the original business case for the darned thing.

Let's say you are the CEO of an organisation and the business case for a strategically important project crosses your desk. It looks good. One of your best project managers has signed up to deliver it. Everything seems to check out.

You sign it off.

What do you think the odds are of realising the full benefits from this project? Better than average? Evens?

You are probably wrong.

You may be shocked to know that less than one in five such projects realise any of their benefits at all. And if your project realises as much as 80% of the expected benefit, then you are doing very well indeed.

Why is this return rate so poor?

Part of the reason is that most of the management focus goes on the project itself. Traditionally business thinking has emphasised management of the project; focusing on delivering the required solution within time, cost and quality. Business schools and consultants across the West have stressed this for years, like some mantra. This has achieved some improvement to the project success rate; organisations are getting better at project management.

Something is still fundamentally wrong. So what is the problem?

Mainly this: we manage to the stuff (the deliverable) and ease up too soon. Small project investments right up to very large, public ones, like Terminal 5, make the same basic blunder: they overlook the engagement of key people, neglect leading the transition to new operations, and fail to persist until their target values of measurable benefit are realised. Terminal 5, as a project, was a magnificent success. I can testify to that, having used it. But the switch to the new capability was an unmitigated disaster with significant damage to British Airways and BAA.

There is a growing realisation that when it comes to business transformation, projects and their timely delivery are necessary, but not sufficient.

There is a value chain of realisation that goes beyond the canon of traditional project management thinking. This value chain builds upon what the project delivers, and involves cumulatively:

1. Engaging stakeholders - influencing those outside, or on the periphery of, the project; reducing resistance to change by negotiation, influencing and collaboration; helping all involved to understand the need and purpose of the project’s outputs.

2. Leading transition - where operational leaders prepare people, handle the transition from the old regime to the new. This involves the challenging chemistry of engaging hearts and minds, planning and managing tasks to achieve an operational outcome, and then keeping on until old ways are forever abandoned and new behaviours and skills are the now embedded change.

3. Realising benefits - the focus of it all, where measures are set, benefits mapped, owned and tracked to full realisation.

Working back from strategic goals and the realisation of the benefits that would achieve them, we soon realise that we need more than the outputs projects can deliver. We need to ensure that operations are not disrupted but are enhanced. This requires a tactical leadership of operations that can take people through the trauma of change, identifying and adding the necessary operational initiatives that the project would be unlikely either to identify or do. Benefits are most often not realised simply because there are missing links of business changes beyond projects, such as setting up the temporary support that operational teams need in order to make the radical switch from old to new.

In turn, working back from these operational changes, the co-operation of people who would otherwise see themselves as ‘victims’ becomes vital. We could have operatives positive and enthusiastic about the change, contributing creative ideas to improve the outcomes, but only if operational leaders have the courage to engage them early enough in the right manner. Traditionally, the culture of projects has been such that they have appeared ‘silos of communication’, inward-looking, with operational people regarded more as an interference. The reason one major European programme in a manufacturing company was still-born is best illustrated by how the French pilot site described the UK-based project: “Fortress ….” (where you can fill in the dots with the town’s name). What does that say about the need for earlier stakeholder engagement?

Moreover, if such value is added after the project, then why are 60% of project business cases never reviewed after they gain approval? In fact, research shows 70% are never reviewed after project implementation. The practice seems to be that business cases are simply a mechanism to gain approval and funding; after that you can forget them. Could your business case improve during and after a project? Of course it could! Strategy changes; the business environment is volatile. For example, rising energy costs can have interesting effects on your project portfolio and the way projects are prioritised. But how would you know?

On a recent BBC Radio 4 interview a senior manager from the UK high street banks’ clearing system was asked about a major performance transformation, where the time to transfer monies between accounts will be shortened from two days to two hours. The interviewer asked why the whole system didn’t go over to it immediately, rather than going through a phased implementation. The answer was something like this: “We don’t want another T5.”

That’s interesting. The story of Terminal 5’s operational meltdown from day one is now becoming a catchphrase for this fundamental business lesson.

Maybe one of the longer term benefits of Terminal 5 for the UK economy is that we will now all have a care to think beyond project delivery. “We don’t want a T5.”

So, next time you are asked to write a project business case or approve one, what will you do?

Technorati Tags: stakeholder engagement,stakeholder management,transition,leading transition,benefits management,benefits realisation management,business Case,project management,programme management,project,programme,project failure

Companies fail to realise 3 out of 4 benefits from change

That was one of the startling statistics that confronted us this morning over the sigma Breakfast Briefing. A group gathered at the Institute of Directors in Pall Mall, London, heard some other startling facts:

• Nearly 2 in every 5 systems to support business change deliver no benefits whatsoever.
• 3 out of 5 project never review the business case after approval, and 7 out of 10 never review the business case after implementation.
• Less than a third of organisations track and report back on benefits realisation
• More than 4 out 5 organisations are not satisfied with the review or benefits and change results.

Such stats were gathered from such sources as the UK Government's Office of Government Commerce, ChangeDirector survey of IT Executives, an IBM study on behalf of ING. and a Cranfield Institute survey of over 100 large organisations across Europe in April 2006.

Dismal reading, eh?

It reminded me of some research by Professor Clegg of Sheffield University that estimated that as little as 20% of the potential benefits in all change investment (programmes and projects) in the UK economy are fully realised. That seems a tad optimistic now.

No wonder Gerald Bradley, Chairman of sigma, went on to make the claim that with  proper Benefits Realisation Management the ROI could be more than 1200%(!).

Which begs the question, why don't we see more of it, then?

I came away with my colleague Richard Rose more convinced than ever that partnering with sigma is the right thing to do.

If you are interested in reversing this appalling waste and finding out how to establish benefits realisation management in your organisation why not attend sigma's one-day Forum.

My Recommended Books and Resources

Every so often someone emails me with a request for recommended books and resources on this subject or that.

Now I am able to maintain a prioritised list of my favourites under different categories.

Using Amazon's astore facility, I have created lists in the following categories:

• Personal Productivity (as above)
• Presentation Skills
• Programme Management
• Business Development
• Benefits Realisation Management
• Project Management
• Change Management
• Learning and Training Resources
• Creativity and Innovation, and
• Leadership

Check out my choices. If I have missed some book you think should be right up there, let me know.

Anyway, now you know my top favourites.

Beyond Crayons: Turning systems models into projects

My good friend Nick Duffill has done something interesting with my recent article on Outcome Relationship Models in his post Beyond Crayons: Turning systems models into projects.

In brief, what Nick has done has been to convert my example into his Funnel Timeline technique using MindManager. It’s interesting because for some, the systems thinking approach I presented in the Outcome Relationship Model (ORM) lacks enough structure and uni-directional flow. With the Project Funnel Timeline that Nick has perfected there is more structure, a clear centre of focus and a left-to-right flow.

I’m reminded of an experience I had in coaching one group in MSP a few months ago in London. We introduce the ORM as early as the afternoon of Day 1 of the learning programme and bring in the more linear Benefits Model in the morning of Day 4. (Benefits realisation is far too central a topic in managing programmes to reduce it to a single session.) Several in the group expressed dissatisfaction with ORM, complaining that their ‘result’ from the workshop looked too messy, confusing and unresolved. To my mind, these were the comments of left-hemisphere directed thinkers. There was real creativity in their work, but they wanted to resolve the tension to a linear plan too soon. One delegate even disliked the convention of ‘curvey’ lines, preferring more rigid straight lines(!).

When we made the ‘transformation’ of our ORM to the more structured, linear Benefits Model, where the entities are clearly classified, there was palpable relief among the group. Their desire for structure and linearity was appeased. We made a joke of it, but really, to explore creativity to any extent, we must allow R-directed thinking, as Daniel Pink would put it, to run its course for a little while.

Yes, I think both techniques have their merits, but let’s allow ourselves to live in the soft, divergent world of systems thinking a little while before we leap to resolving these causal links into more structured approaches. I believe this is particularly important when we are working towards the realisation of benefits and trying to model the dependencies between them, and with their enabling projects.

In Praise of ORMs

When I first came across the Outcome Relationship Model (ORM) I think I was pretty ‘under-whelmed’. I just couldn’t see the point of it. Over time, however, I have come to see it as an invaluable analysis tool. It helps me to break out of linear causal thinking; I can use it to move more towards what Pete Senge calls ‘Systems Thinking’.

On our MSP course we introduce people to the ORM fairly early on, under the whole discussion around identifying benefits. In a programme context the example given in the manual is at a fairly high level; it concerns social policy around improving public teaching at a national government level. As such, this example does not resonate with some delegates. I can see them show interest when I introduce them to benefits modelling; but not in the humble ORM.

Recently, whilst working with a client that seeks greater throughput on a large programme, I felt the need to explain better how attention to the basic disciplines of quality planning and review would help. I had observed remote, high-level quality plans, and fairly haphazard reviews by anyone who was available, against no clear criteria. Clearly this was not an environment where there was repeatable, managed process. So, to illustrate, I turned to the humble ORM.

This was the result. It shows a systems causal change from more consistent behaviours around quality planning and review, can lead to some interesting intermediate benefits, such as ‘Less defects slip through’, to the End Benefit (Great Throughput) that is the prize for this kind of client.

The ORM shows how the causal links are circular and amplifying – what Senge calls the ‘snowball effect’. For example, ‘Greater Throughput’ encourages people to engage even more with agile quality planning, and so on. This is helpful in the context of discussions around the value of Maturity Models such as P2MM and CMMI as I find there is not much illustration on how attention to basic disciplines such as these can result in a step change in an organisation’s performance.

I’ve added another twist to this example ORM. I’ve added colour coding to suggest where something is an enabling behaviour, an intermediate benefit, and an end benefits. So it is easier for the planner to make the transformation to a more linear benefits model.

Your comments on this would be very welcome.

Visual mapping of benefits

As promised in my post yesterday, here is a description of how to build an Outcome Relationship Model. For materials, in workshops we usually use good old Post-Its and flipchart paper. When we get serious, we transfer these to Visio.

Linear Logic and Language

When we engage with complex strategic change, we soon encounter a limitation with our language. Conventions of grammar encourage us to simplify cause and effect into simple linear explanations. The subject-verb-object inclines us into explaining a complex situation simplistically.

 

We need to think systems. Systems respect the complex, non-linear sequence of the forces at play whenever we engage with major change. Reality may look rather more like this:

 

Let’s consider an example from the MSP Guide. We could say, “Improved teacher motivation will improve teacher retention.” No doubt there is some truth in this; but it is only partially true.

The ‘What Else’ Question

We can ask the simple question, “What else – good or bad – will it lead to?” Then we could get something that looks like this:

 

By asking the ‘what else’ question we have identified another potential derivative benefit.

 

The ‘So What’ Question

We can take this further. What if we asked another question of the ‘effects’, in this case, ‘improved retention’ and ‘improved teaching’? Let’s ask, “So what?” “So what if we retain more teachers? So what if we improve teaching?” These derivative/dependent benefits may seem so obvious that they may not seem worth stating; but they are worth mapping. It drives out ambiguity. We are less likely to settle on intermediate benefits and more likely to drive through to identify truly end benefits. In our example, we might then get something like this:

 

 

 

Now, notice that the diagram is now no longer simply flowing left to right. There could be an amplification effect in realising ‘Improved teaching’ as we make the other three happen.

 

The Necessary Pre-Requisites

There is one more step we can take to develop this model further. For each entity on our model, we can ask this question: “What are all the necessary things that must happen or be in place for this to happen?” Now our model could look like this:

The full diagram in the MSP Guide looks like this, the final model:

(c) Crown Copyright 2007 Reproduced under licence from OGC

Open Systems

Or is it the final model? Like all open systems, it is a matter of judgement as to how wide and deep your map of the systems extends.

Best Practice Showcase 2006: 9th June 2006

Next Friday will be the Best Practice Showcase in the London Metropole. Yours truly will be there with some of my colleagues. If you are a reader of this blog, I’d be delighted to meet you.

More particularly John Edmonds and I are leading a couple of 40–minute workshops during the day (one of the so-called ‘Birds of a Feather’ workshops) called Visual mapping to identify benefits: Systems thinking using the Outcome Relationship Model. It’s a pithy little title, isn’t it? Anyway, the idea is that we take a group of 15 delegates each session and we get them to practice creating an Outcome Relationship Model (see an earlier post – In praise of ORMs on this technique).

If you are thinking of booking in on one of these sessions, I’m sorry but they are already fully booked. So why – apart from ego – am I blogging about this?

There are two reasons:

1. I promised everyone on the flyer for this that they would get briefing instructions for the session beforehand on this blog; and
2. You, dear reader, can benefit and contribute by responding to the briefing, as well as seeing some of the results of the workshops after the 9th.

Anyway, tomorrow I will post a brief explanation of the technique. I hope you find it useful, whether you are on the workshop or not. As always, comments gratefully received.

In Praise of ORMs

When I first came across the Outcome Relationship Model (ORM) I think I was pretty ‘under-whelmed’. I just couldn’t see the point of it. Over time, however, I have come to see it as an invaluable analysis tool. It helps me to break out of linear causal thinking; I can use it to move more towards what Pete Senge calls ‘Systems Thinking’.

On our MSP course we introduce people to the ORM fairly early on, under the whole discussion around identifying benefits. In a programme context the example given in the manual is at a fairly high level; it concerns social policy around improving public teaching at a national government level. As such, this example does not resonate with some delegates. I can see them show interest when I introduce them to benefits modelling; but not in the humble ORM.

Recently, whilst working with a client that seeks greater throughput on a large programme, I felt the need to explain better how attention to the basic disciplines of quality planning and review would help. I had observed remote, high-level quality plans, and fairly haphazard reviews by anyone who was available, against no clear criteria. Clearly this was not an environment where there was repeatable, managed process. So, to illustrate, I turned to the humble ORM.

This was the result. It shows how a change to more consistent behaviours around quality planning and review, can in turn lead to some interesting intermediate benefits, such as ‘Less defects slip through’, to the End Benefit (Great Throughput) that is the prize for this kind of client.

The ORM shows how the causal links are circular and amplifying – what Senge calls the ‘snowball effect’. For example, ‘Greater Throughput’ encourages people to engage even more with agile quality planning, and so on. This is helpful in the context of discussions around the value of Maturity Models such as P2MM and CMMI as I find there is not much illustration on how attention to basic disciplines such as these can result in a step change in an organisation’s performance.

I’ve added another twist to this example ORM. I’ve added colour coding to suggest where something is an enabling behaviour, an intermediate benefit, and an end benefits. So it is easier for the planner to make the transformation to a more linear benefits model.

Your comments on this would be very welcome.

The Benefits of PRINCE2- Down with Waste

I’ve been thinking about how to best explain what the benefits of PRINCE2 are without going into the detail of the features.

It strikes me that what most organisations seek to do is to change through projects with as little pain, delay or waste as possible. With this in mind I’ve come up with this set of questions:

How wasteful are your projects?

• Do you waste time and money by tactical decisions being made without regard to business strategy?
• Do you waste time and hesitate by misunderstandings of who should do such-and-such?
• Do you waste money because projects are hard to control or even stop?
• Do you waste time and money doing unnecessary work and by not being focussed on the end result?
• Do you waste time and money because of what was wanted is ambiguous?
• Do you waste precious time because someone else’s project is hard to pick up?
• Do you waste money because people are always ‘reinventing the wheel’?
• Do you waste opportunity because your projects do not learn from each other?

On this basis, the case for adopting PRINCE2 is cost and time reduction. Therefore the implementation of PRINCE2 should establish measures for these and demonstrate that they are being achieved.