And it’s just as true in the world of the projects that commercial and public sector organisations undertake to move themselves forward in some way, such as; business change programmes, cost reduction programmes, business process redesign, ERP Enterprise Resource Planning system implementations or complex IT projects.

We tend to go about them in the same way over and over again. We organise and carry out our projects in ways declared “Best Practice”. We train our staff in “Best Practice” methods and the consulting firms we engage, tout their “Best Practice” credentials.

And the results according to sources such as industry analysts, is that 60 to 80% of these projects are doomed to fail. That is, the business benefits expected by the organizations paying for the projects, will not materialize.

My own observation of 30 or so client projects within some of the world’s largest corporations – and not so large private and public sector organisations, is firstly, that the private sector is no more successful than the public sector in this regard, and secondly, the real failure rates are probably higher than the those reported by the analysts. And there is I will suggest, good reason for that disturbing state of affairs.

But first let’s remember what those project failures mean for the organisations involved.

The most obvious is the financial millions in wasted funding. Plus there is the disruption to business, and the time and cost of the ensuing damage limitation and rectification work. Then, there is the human cost in terms of wasted time and talent, the frustrations, the disillusionment with management leadership and consequent distrust of future improvement initiatives.

That’s not to forget the delays and lost opportunities in putting in place the performance improvements, costs reductions or increased competitiveness the organization wanted in the first place.

After declaring that we will “learn the lessons” from these failed projects, the odd thing is, that we then set about the next round using exactly the same “Best Practice” methods as before, but armed with the earnest hope that “this time – for some reason, it will all be different!”

Many authorities on projects and programmes list 10 to 12 factors they say lead to the high failure rates. Their lists range across factors such as: poor project management, lack of senior management support, failure to identify requirements, poor communication, and so on.

Certainly, those factors can be involved and be important. But a conclusion I’ve arrived at is that they are not fundamental to the failures.

We are all guilty
This is where I have to confess to being a sinner myself.  I am by no means an innocent observer. My own rude awakening was as a Project Manager of an ERP system implementation some years ago.

At the time, I happened to read a column in the Computer Weekly newspaper. The columnist pithily asserted “any project manager who refuses to quantify their objectives, is either incompetent, a charlatan or just plain stupid”.

Being a project manager who had not quantified my objectives, I somewhat took exception to this assault upon my affectionately held personal qualities.

‘What could this idiot mean?” I raged. “Why did I need to quantify my objectives? My objective was clear – implement the new system. One or maybe two, new systems. There, quantified! Job done!”

I should have noticed that being enraged meant a nerve had been touched. It took me a few weeks to realize that I was the idiot; not the columnist. The point being made was… why are we as a business, implementing a new system?

What are we trying to achieve? What do we expect to get out of the expense, the technical work, the new ways of working, the staff training, the disruption and all the other paraphernalia of a large system implementation?

Okay, so I’m a slow thinker
After a bit more pondering – which admittedly took me several years, I realized that the whole point… [drum role]… is, to improve the business; to improve the performance/ capabilities/costs of the business. There is no other purpose.

It’s not about delivering “stuff”; the “stuff” is simply a means to an end. It’s not enough to hope that delivering “stuff” will somehow make the organisation better. It’s about business results. The project objectives are about some form of improved business performance.

Now, that columnist’s point made sense. In fact, it made vital, crucial sense.

The real question was – how much improvement did we expect or want the project to make to the business? From what existing level of performance, to what improved level of performance – and by when was it to be achieved?

Which aspects of performance did we want to improve – and how would we specify, quantify and measure those improvements? What numeric scales of measurement would we use? That gives a level of clarity rarely seen in project objectives.

As the project manager, I could try claiming (as so many project managers do), “my job is to implement the new system. It’s not my job to improve the performance of the business”. But that’s exactly what the business is really paying for. That’s the purpose of the project. This is where we come back to ‘Best Practice’.

Many corporations and organisations internally promote and follow a ‘Best Practice’ approach to business and IT projects. It’s based on what is called a ‘waterfall’ model.

If your organization is mid-to-large sized, it is probable you are following a waterfall model. In the UK, the dominant project management method in the private and public sectors is PRINCE2^®. PRINCE2 is based on the waterfall model and is positioned as ‘Best Practice’ by the UK Government Cabinet Office.

The ‘waterfall’ model has a structure in which typically – an idea for a project is proposed, a business case is written to justify funding, and the project planned and structured as a series of stages. Stages such as analysis and design work are planned and carried out, followed by development work and maybe procurement, a pilot implementation and then full implementation. Given the failure rates, it’s tempting to add ‘Post Mortem’ at the end, although that’s not yet an officially recognized stage.

Between the stages – each of which can take several months, there is usually a management review in which managers typically review documents produced by the project team.

It’s called ‘waterfall’ because each stage follows on from the previous, in a step-by-step, linear, downhill manner; water not being noted for naturally travelling back uphill. Eventually, something – some form of deliverable or “stuff” emerges at the end of the process.

Mr Royce tried to warn us
The waterfall model is a conceptually simple and logical process. Unfortunately, in all but the simplest of projects it usually doesn’t work in real life. Mr Winston Royce, credited with originating the waterfall model, did warn about this characteristic; but to no avail.

Real life tends not to cooperate with step-by-step linear processes. It would be like driving from London to Edinburgh and determined to do so in a straight line. Try explaining that to the traffic police!

Real life – including driving from London to Edinburgh and staying on the road, demands sensing and responding to changing circumstances as they happen. It’s a learning process in which we are learning continually in the real world, about what works and what doesn’t; building on what does and correcting what doesn’t.

The management reviews of paperwork in the waterfall model can’t and don’t substitute for validating the project’s basic assumptions and actual effectiveness in the real world.

The waterfall structure is such that the “stuff” being delivered only gets its first exposure to the organisation’s real world realities towards the end of the project – when it’s too late to change course.

On knowing all the answers at the start
It’s also worth recalling that business change and large IT projects in complex organisations are themselves are far too complex for it to be humanly possible to foretell with precision at the start, exactly how the project requirements and the business environment will evolve during the course of the project. Although the waterfall model assumes the exact opposite.

Back to fundamentals
I’m suggesting that rather than the 10 to 12 or so reasons for the distressingly high rate of project failures, there are really two fundamental mistakes, namely:

Mistake 1: we plan to deliver “stuff” rather than quantified levels of business improvement. And we usually compound that basic error by proposing the solution ‘stuff’ before we’ve gained a clear understanding of the real problems or obstacles to performance improvement

And then…

Mistake 2: we follow a ‘waterfall’ project management model which does not provide for testing every few weeks or months that the project is either actually addressing the real problems, or even capable of making business improvement in the real world. We rely instead on untested assumptions and expectations.

 So what can we do?
While there isn’t space in this article to explain all the practical details – that’s for another article, here are the key principles, starting with the launch of a project…

 ”Here’s the solution; now, what’s the problem?”
Most organisations decide the favoured solution first, and then set about justifying it.

Instead, let’s ask the critical question “what business improvements do we want to make for our organization?” This means deciding the improvement objectives before deciding what the solution will be.

That’s a key mindset change in itself.

And then further, ask “expressed in terms of numbers, what level of improvement do we need? By how much and by when?”

What would be the minimum acceptable level of improvement? That is, what level of improvement must we attain in order to have succeeded?

What would be the target level? What level above the acceptable minimum, do we plan to achieve?

Now we have a clearer idea of what improvements we want to achieve, we can get a clearer idea of what the obstacles are between where we are, and where we want to be.

We can gather potential ideas (solutions) for achieving the improvement aims, and meaningfully start evaluating those candidates in relation to their costs and their likely benefit contribution to achieving our improvement aims.

It can take some hard thinking to answer those questions. It’s so much easier to think in terms of delivering “stuff” – but as we’ve seen, avoiding the hard questions is costing organisations immensely in financial, business and human terms.

As a test, ask the following question about a proposed or ‘inflight’ project in your own organization. But please do so with caution. The answers will be illuminating but can discomfit those who are wedded to their favourite solutions, and would prefer the question to remain unasked!

The question is: “what performance improvement do we expect this project to make, and by how much (in numbers) do we expect that improvement to be?”

Even if you go no further, simply asking that question, will immediately give you penetrating insights into the rationale of a project, and its likely success. But you can go further.

Designing the project…
Structure the project to deliver – within a few weeks of starting, some useful and real improvements to the business,  and then onwards, in regular delivery cycles of say, every 4 weeks.

Measure how well what was put in place actually worked compared to what you expected, and use what you learn to improve the next delivery cycles to the organization. Rinse and repeat!

That is, structure the project as an iterative process of improvement cycles. Measure the actual improvement made in each cycle, and use that feedback to adjust the next delivery cycles to keep the project on track to delivering the overall needed levels of improvement.  That way you enjoy early business results, and receive early warning of risks, new emerging objectives or faulty expectations before any serious damage or project failure.

And there may be some schooled in ‘Best Practice’ who will protest that it’s not possible to deliver projects this way. The question for them is “are they saying it can’t be done, or are they simply saying they don’t know how?”

Or, we can keep doing the same thing over and over again – and just hope that unlike the last time, this time – for some reason, it will be different!

_________________

PS: to help you and your organisation introduce a business improvement-led projects approach – the simplicity of which, I admit took me several years to grasp, there are various explanations of the techniques elsewhere on this site. Or to discuss via email, contact us

For high levels of management control across a portfolio of projects or programs, the factors below need to be brought into the equation.

The big challenge is, that those factors need to be considered simultaneously.

For each of those factors…

Task dependencies within projects – is conceptually the easy bit and will be familiar to all project managers.

It’s the identification of those tasks which really are reliant upon the completion (usually) of an earlier task (usually!) before they can begin. Yes, there are variants on that sequential ‘Finish-to-Start’ theme. Those variants include: Start-to-Start, Finish-to-Finish and so on. Although this is the easiest part, many project plans are longer than necessary because sequential dependencies between tasks have been assumed, whereas in reality, tasks can often be concurrent.

Task dependencies between projects – where activities in one project are dependent, in the same way as above, but upon tasks in a separate project. Which means, that slippage in one project can cause delays in other projects where they are awaiting completion of that task. On the subject of slippage, we should bring in the wider subject of variability in the times it can take to complete a task.

Resource dependencies between projects – is where it starts getting challenging for many organisations.

This is where some type of resource is needed across more than one project (or task) at the same time… and there ain’t enough of that resource to ‘go round’.

Effectively managing this situation entails… firstly foreseeing it, secondly, prioritising the use of that resource. If you have unlimited resources, you won’t need to prioritise their use.

However, in the real world where resources within a given time period are often limited, prioritisation of resources is an important mechanism but by no means the only one.  And then thirdly, sequencing and synchronising the tasks and projects around how that shared/scarce resource is actually going to be used, leads on to…

Resource Availability & Allocation – another aspect of resource dependencies. It involves monitoring the current and planned commitments of a resource, and making decisions on how best to allocate it according to criteria such as… what your organisation is trying to achieve.

Resource Constraints and Overloads – it may already have struck you; resource constraints, which could also be called bottlenecks, are created rather than god-given.

They are created as direct consequences of our objectives. That is, we decide we want to achieve a certain aim. We then realise we will need certain resources to achieve that aim.

If we had no aims; we would need no resources. As soon as we have aims to achieve in finite time scales, we start to encounter resource limitations… that’s unless we’re lucky enough to be well resourced, or have very modest aims!

If we want close control over project delivery dependability, then we need to foresee those resource constraints and plan with them in mind. Foreseeing the overloading of a resource, is foreseeing that the current plan is unrealistic. An overloaded resource is the signal that at least one of the projects trying to use that resource is in trouble!

Rework Elimination/Defect Avoidance – why is this here? This subject is not usually mentioned in project or program management discussions. But it is closely linked to resource dependencies, to resource constraints and to the unnecessary consumption of resources.

For example, if you are running projects and you need to make use of a key resource that is regarded as in limited or constrained supply, the last thing you would want is for that constrained resource to be burning-up time in working on putting some other job right (rework) because defects have arisen which now need to be corrected.

Rework – that is, correcting a piece of work in order to make it satisfactory – wastes resources, which reduces productivity and causes disruptive delays. It is also surprisingly common.

In business processes within multinational corporations, I have measured the losses to productivity caused by rework as greater than 50%. That is, 50% of the productive resources are lost to rework activities. For management control of project delivery reliability, rework elimination is a very powerful mechanism.

Based on 30 or so client projects with some of the world’s largest corporations… and some of the not so large, I’ve come to a slightly different view.

There’s a lot of talk about culture change and its challenges. And yes, there are doubtless challenges around that, but I would suggest – based on 15 years of analysis, research and testing, that many of those challenges are avoidable and are in fact generated by the approach most organisations take to ‘business change’ programs.

(‘Business change’ itself being an interestingly nebulous and directionless phrase. Change for the better, change for the worse or even, change for change’s sake? [Here's a 'take' on this subject])

My evidence and conclusion is that what is often promoted as project ‘Best Practice’ – frequently some form of project management process based on the ‘waterfall’ model… which because of its flawed structure and flawed assumptions, is actually at the root of business change problems; rather than the solution it purports to be.

This is literally asserting, that the linear structure of ‘waterfall’ process-based ‘Best Practice’ project management methods such as PRINCE2, will increase the difficulties in change management initiatives.

Has anyone else come to a similar, scurrilous conclusion?
————————————————————-
For more information on how ‘Best Practice’ project management methods lead to business change and IT project failures, please contact us.

PRINCE2® is a registered trade mark of the Cabinet Office.
(UK Government)

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.

PRINCE2® is a registered trade mark of the Cabinet Office.
(UK Government)

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 us 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.