But what does the phrase really mean?

Does it mean… change for the better? Change for the worse? Or even just change for change’s sake?

It’s a peculiarly nebulous and directionless term.

“It’s obvious” some would argue, “it’s change for the better”.

But industry analysts report the rate of failure of business change programmes as typically in the range 60 to 80%. In other words, the odds are heavily against success. Which in turn suggests that it often turns out that “change for the worse” could be the more accurate description.

And if the odds are so heavily weighed against success, then the charge of “change for change’s sake” could well be justified.

Leaving the usual outcomes aside for a moment, let’s go with the intention of a business change programme as to introduce change for the better in some way,

Then… let’s replace the idea of “business change” with the notion of business improvement. That is, rather than introducing change for change’s sake, the aim is to improve the way an organisation performs its business functions – business performance improvement.

Importantly, we now have the notion of direction; a positive direction, improvement.

We also have the beginning of the idea of improving performance from some current level… to some new, desired level within a certain time scale.

We can establish a measurement scale and use it to clarify, define and quantify the performance aims.

Then we can say, “well, yes… that’s the desired new level of business performance. That’s where we’d like to be, but we could accept a bit less than that, and we would still have succeeded.

So let’s define a minimum improvement level for this business performance improvement initiative.

If we score above this level,  it’s acceptable; falling below it, would represent failure – a “fail” level.

For example, maybe the organisation wouldn’t be commercially viable below the ‘fail’ level.

In the other direction, upwards, there can be too much of a good thing. In other words, there could well be an upper limit to the performance improvement, beyond which we deem undesirable.

It could be for example, we couldn’t finance or resource too high a performance level in the business.So there could be a maximum, upper performance level at one end. A minimum acceptable level (fail) at the other, and a desirable (target) level at some point in between.

And that’s just the start. In pursuit of clearly communicating the improvement aims, we can take these ideas a lot further – but that’s for another blog post.

Given the clarity, measurability and specificity we can bring with a ‘Business Performance Improvement’ approach, proposals for ‘Business Change’ can look decidedly fluffy! Where would you invest your money?

Conventional ‘Waterfall’ Project Structure Model (eg. PRINCE2®)

The conventional structure of projects typically starts with an initiation stage – and that’s not quite the statement of the blindingly obvious it may seem! A proposal for a project is reviewed formally, or informally. Approval is given for the proposed approach and for the allocation of funding, resources or whatever else is needed. The formality or informality of this and the subsequent stages will of course vary enormously depending upon the scale of the project, the size of the foreseen costs, the management norms of the organisation and so on.

The initiation and approval stages are followed by a series of project stages. Typically, the stages are defined in a sequence such as Requirements Analysis, Design, Build/ Construction, Test, Implementation or Deployment, and project closure. In actuality, the neatly defined stages may well meld into each other – which will injure the manageability of the project. There are good reasons for why the ‘melding’  happens, which we’ll discuss elsewhere.

In the case of PRINCE2, ongoing maintenance or support of what has been implemented is outside the scope of the project. Depending on the methodology, there may then be the ‘retirement’ stage in which whatever has been implemented is deemed no longer serving its purpose in some way, and is decommissioned.

Gateways
There may be formal reviews or ‘gateways’ between the stages. The intention is that the completeness of each stage is reviewed by senior stakeholders – folk with an interest in the outcome of the project. The idea is that their approval is needed before further funding and other resources are consumed in the next stages.

In theory, there are several further options available to the reviewers. Those options include; directing that rework is done to achieve the expected requirements of the current stage, redirect the project in some other way (such as change its objectives) or decide the project is not viable and declare its termination.

Unfortunately, the ‘Best Practice’ project structure means that the information generated by the process for discussion in Gateway reviews, has little relevance to the real-world operational or commercial interests of senior stakeholders.

Along with progress against the project plan time scales and budget, Gateway reviews are intended to assess the ‘products’ (generally, documentation deliverables) which are prescribed by the project method to be delivered at the end of each stage. Reviews ask: have products been produced, and to the required quality?

The unfortunate significance is that what is assessed in a gateway review has little connection with whether or not the project will make a useful business contribution in the real world. Gateway reviews are denied that information.

That’s because the project structure – shown in the sketch above, doesn’t put anything into operation in the real world until the final ‘implementation’ stage. The first real-world information feedback or measurement on whether the project has done something useful or not, comes at/after the end of the project. Obviously, that’s too late to provide useful guidance to the project. The money, time and resources have already been consumed.

Hence, Gateway reviews provide little value beyond administrative purposes.  Which in turn, leads to the traditional difficulties of getting senior stakeholders either to prioritise the meetings as important – or to attend.

The Problems with Conventional Project Structure Models
Many organisations will have experienced serious problems in delivering useful outcomes and results when using this kind of conventional project management method.

Our discussion here refers primarily to the use of those conventional methods in projects concerned with moving an organisation forward in some way. That is projects such as: business change management; business performance improvement; organisational and business process design/redesign; IT systems implementation and systems development.

These are the kind of complex projects we characterise as essentially learning-processes.

They are ‘learning processes’ because – however confident the sponsors may be in the success of the outcomes, the reality is that the oft-reported failure of 60 to 80% of these types of projects, speaks to the difficulties of predicting exactly how a significant sized project will fare when it encounters the true complexities of a real-life organisation.
To borrow from Field Marshall von Moltke, “no battle plan survives contact with the enemy“.

The Focus is on Tasks – it shouldn’t be
The emphasis in conventional project methods is on tasks, activities and products. Many of those tasks will be concerned with generating documentation deliverables known as ‘management products’. Progress tends to be measured in terms of completed products, completed tasks or review stages passed. In effect, conventional project structures place the emphasis upon ‘doing stuff’ or ‘busy-ness’. Although many people in organisations will feel that their job security depends upon looking busy – and their perception is probably accurate, we argue that this emphasis on ‘doing stuff’, on tasks, is misplaced.

Focus on Improvement Results
In our view, the emphasis should more valuably be placed upon delivering useful, practical, improved performance results which directly contribute to the achievement of the real objectives of the organisation. Few would argue with that. Many would agree with it,  and then go straight back to structuring their projects in the conventional way. They do that because of a mistaken belief that the conventional methods share their aim of achieving results. They don’t.

The aim of conventional methods is simply to follow a defined process in order to deliver a product or ‘solution’ of some kind; that’s distinctly different from the improved performance wanted by the organisation.

‘Best Practice’ may not be Best
Those shortcomings mean that for many organisations wishing to achieve earlier practical results, at lower cost, reduced risk, with strong stakeholder engagement and in shorter time scales, PRINCE2 will not be an appropriate choice.

Our analysis shows that conventional ‘Best Practice’ project management methods – such  as PRINCE2, will generally increase project costs and lead to lengthy phases (each of many months) during which costs accrue and resources are consumed, without benefit to the wider organisation.

Lengthy project phases also means that it is difficult to incorporate changes to requirements,  which in turn increases the risk of project failure.

The probability that requirements will change in the real world, is of course, increased when project phases each extend over many months.

‘Freezing Requirements’ – increases Project Risk
If projects are not truly capable of anticipating the emergence of changes to requirements and instead, for example, try to bring stability by postponing changes or freezing requirements, then ironically, the risks of project failure further increase because projects are not meeting the real needs as they continue to emerge in the real world.

If you find that projects are not delivering the results you want, or you suspect they are taking longer than necessary and costing more than needed… the good news is that there are better approaches available.

From Tasks & ‘Busy-ness’ – to Business Improvement
There are alternative approaches which enable business improvement and system projects to be delivered faster, at lower cost, to higher quality, with reduced risk. If you would like to see faster progress with business improvement activities and projects in your own organisation, the simple points outlined in this site may give you some ideas. Alternatively, get in touch and we can take you through how the alternative approaches can be applied to your advantage, to your existing projects.

In response to various requests, we will be publishing our detailed analysis of the shortcomings of the conventional structured project management methods (such as PRINCE2) on this site in the near future.

But if you are already locked into the kind of project management methodology we’ve discussed here, your wisest priorities may be to…

1. preserve the appearance of practicing the established methods
2. understand and work around their underlying flaws
3. quietly incorporate some of the alternative approaches into your projects. You can then begin demonstrating the value of early delivery of practical, commercially/operationally useful business results (and be forgiven for a lower emphasis on compliance with a prescribed project management process!)

And Finally…

Whilst we do not contend that all project problems can be laid at the door of these kind of methodologies, we do contend that it is time to question the faith placed in them, and to acknowledge that there are serious underlying, structural problems to PRINCE2 and related methodologies.

Your views would be very welcome. Please do express your mild agreement, denouncement as arrant nonsense or wherever your views take you, as a comment below.

Prince^® and Prince2^® are registered trade marks of the UK Office of Government Commerce

Copyright © Business Transition Technologies Ltd 2012.  All Rights Reserved.

There are several reasons why this could well be the case for your projects.

The Perils of ‘Best Practice’ project management methods
Firstly, the dominant mainstream methods for running projects (particularly, those described as ‘Best Practice’; a subject for another day) will inescapably…

• increase your project costs
• increase the likelihood of project failure, and…
• will reduce the value of what is delivered to your organisation

This is a result of the shortfalls in the methods used in running projects. So we potentially have immediate scope right there to reduce costs and simultaneously improve the project’s effectiveness.

Secondly, it’s rare that a project is as accurately focused as necessary on what is really going to benefit the organisation. Because this is true for most projects, there is again immediate scope for reducing costs by through improving the focus, and simultaneously gaining greater business benefit from the project investment. Let’s start with this second aspect.

Experience of working with something of the order of 30 client projects – with clients ranging from the world’s largest multi-nationals in the UK, US and mainland Europe, to medium sized companies and small private companies; and also with public sector organisations such as UK Government departments, public sector services and the United Nations, is that they all tend to start with a project idea, rather than explicitly with the business improvement needs of their host organisation.

And that is entirely in line with the approach embedded in ‘Best Practice’ project management methods. Unfortunately, that approach rarely leads to a project that is well-formulated to address the business improvement needs of the organisation paying for the project.

What do I mean by well-formulated?

The Formulation Disconnects
What I mean is that it is quite usual to find significant ‘disconnect’ between the aims of the project manager, and the project outcomes the organisation’s managers say they need.

It is also highly probable that each individual senior manager with an interest in the project outcomes, has a different concept from their peers, of what the project is intended to achieve. A simple check with each manager, individually, will demonstrate the truth of this.

Often, expectations are misaligned to such an extent that even if all the ‘boxes are ticked’ and the project manager declares successful delivery, the organisation itself sees little of the benefit it wanted or expected in return for the time, money and resources it has spent; a case of “the operation was successful, but the patient died” syndrome.

So the immediate opportunity is to verify and tune-up the contribution the project outcomes will make to your organisation. Doing so, will eliminate the costs of working on outcomes your organisation doesn’t need, or are low priority or are peripheral, whilst also achieving a new focus on what is needed as real priorities.

The key to this is surprisingly simple. Yet this simple step is missed at the start of nearly every project.

The Key Question
The key is to ask the question “what do we want to improve?”.

More specifically, the question is “what aspects of business performance do we want to improve and/or costs reduced for our organisation?” And the question can (and should) be extended into asking; “improved by how much, and by when?”

The answers to those questions may be immediately obvious, or may need some thinking about. A hint here is to separate out the business outcomes you want, from the means to achieve those outcomes. A simple example of the separation of those two aspects would be…

• outcomes: you want to increase the sales revenue income of your company. That’s an outcome which depends upon other conditions for it to happen, such as…
• the means: you need to increase the number of units sold, or the number of customers, or the frequency of re-buying those units, or some combination of those

If the project is to make a contribution to the desired outcome of increased revenue, then it needs to make some contribution to the means we’ve just outlined.

A further hint – which limited space doesn’t allow to be expanded upon here, is to focus on the factors which are constraining the current performance of ‘the means’ to achieving the outcomes.

That is, what is the major pinch-point or bottleneck standing between the current performance levels, and where your organisation’s performance levels need to be? Again, for reasons that can’t be explored here, helpfully – there will only be one or two critical pinch-points or bottlenecks at any one time.

The trick is to find those, and focus the project on either making those bottlenecks wider in some way, or eliminating them to get the next step in business performance improvement.

Heresy & ‘Best Practice’
But I made some scurrilous comments earlier about project management ‘Best Practice’.

I asserted that ‘Best Practice’ will: increase project costs, increase the risk of failure and reduce the value of the outcomes your organization receives.

How can supposedly ‘Best Practice’ be the cause of the common project problems when they’re claimed to be the solution?

The short answer is that the effect of the linear, step-by-step (‘waterfall’) structure of the project life-cycle embedded in ‘Best Practice’ project management methods is…

• to extend the elapse time (unnecessarily), from project initiation to delivery of results in the real world – which increases the development costs incurred before any business benefit is received by the organization

• to increase the project risk because the ‘product’ – and ‘Best Practice’ tends to plan in terms of products, is only introduced into the real world, with real users and real challenges after the extended period just mentioned. In a rapidly changing world, it is vital to get real-world feedback as early as possible, on whether what you thought was going to give you the business results you want, is actually going to work as expected, or not?

• the risk of project failure is that due to unclear expectations, the many months elapsed between initiation and delivery, what is eventually delivered no longer – if it ever did, meets the real needs of the organization. How could it? There is typically no shared, clear explicit understanding of either: what was needed, what would get you there, or how the needed results would be achieved

The longer answer, fully explaining why the project management methods taught today as ‘Best Practice’ to many thousands of project managers are fundamentally flawed – and what to do about it, is the subject of an analysis which will be published in the next few months – contact me if you would like early discussion.

The project should have done this; it should have done that. Confronted with the wreckage, it’s all so obvious and clear now.

This seems to apply to business change projects, computerisation (eg. the UK’s National Health IT programme), system development projects… the list goes on.

But why wasn’t this new-found clarity available at the start of the project? Why did no one insist on clarity in what would constitute success; and even, what would constitute failure?

• everyone in the early days, assumes it’s obvious what success would be – and everyone shares that view

• perhaps the precise form success must take is something that has to be discovered en route; it’s just too hard to know beforehand

• and have you noticed how much easier it is to talk about activity; of what projects must do, rather than what they must achieve?

Maybe, it’s a combination of all of those?

Or the unthinkable: maybe corporations, businesses and public sector organisations find it so onerous and uncomfortable to define project objectives with clarity, they simply prefer to go ahead and explain away the failures (a 60-80% risk according to some) as…

due again to unforeseeable circumstances… to speak the “we must learn the lessons” line again… to swallow the ballooned costs of the mis-investment, and airbrush the entire sorry episode out of history, again.

Does it have to be that way? No.

The answers are available, but they involve insisting on a shared clarity in project objectives. Are managers ready to insist on that clarity? Or in a choice between “clarity” and “mis- investment”, is mis-investment the lesser of two evils?

Over the next few months (June 2011 onwards), we’ll be adding quirky, pithy commentary the world never knew it needed.