Business Transition Technologies Ltd

Insanity: doing the same thing over and over again and expecting different results. While there’s some dispute over who said it, Benjamin Franklin or Albert Einstein, it seems to ring true.

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.

[click to continue…]

If you have a number of projects running, with potentially some linkages between them and with some sharing of resources – even if, for example, the shared resource is only limited funding, the interactions between the projects and their resources leads to management control complexities which can result in undependable deadline performance.

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… [click to continue…]

The notes below were prompted by a post on Companies are struggling with change management in the LinkedIn forum Business Improvement, Change Management & Performance.

Based on 30 or so client projects/programs 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’ is 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.

I’m literally asserting here, 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, contact us.

PRINCE2® is a registered trade mark of the AXELOS Limited.

The phrase ‘Business Change’ is well established and common parlance these days in the world of medium to large sized organisations. In a sense, there is a business change ‘industry’.

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 a 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, that is, business performance improvement.

Importantly, we now have the notion of direction; a positive direction, improvement.
[click to continue…]

Do your major projects have a structure similar to the model sketched below? That is, several stages (perhaps each of several or more months), separated by some kind of review meeting. If so, you are probably following a conventional ‘waterfall-style’ project management approach.

Conventional ‘Waterfall’ Project Structure Model 

PRINCE2® projects are usually structured structured in this way. 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.

Let’s take a look at why the failure rate for projects following this approach is so dismally high… [click to continue…]

Introduction
With business projects in mind such as; business change, business process design/redesign and IT system implementations, the pressure to reduce project costs can – perhaps perversely it may appear, also be the opportunity to improve the results from the project – and all at lower cost.

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…

[click to continue…]

Interesting isn’t it, how what would have been success for the project, only becomes clear to us as we survey the wreckage of its failure.

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, but probably much higher)…

[click to continue…]

The Btt web site has been “off the air” for a year or two. It’s on the way back – gradually!

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