How effective are performance improvement projects?

There cannot be many sizeable organizations that have not subjected some, at least, of their core and non-core functions to a range of cost-cutting and performance improvement projects over the last 15 years or so. In many cases, two or all three of the elements described above – management techniques, packaged systems, management consultants – will have been part of the project mix. Certainly, very few projects are completed without dipping into scarce resources to purchase the latest hardware and software technology available or in fashion.

It is impossible to know how many such projects the originating project sponsor considered successful and in any case, that will depend, to some extent, on the targets that were originally set and how long the technology chosen remained desirable. Anybody studying a large sample of CVs submitted by project managers would naturally surmise that all projects are successful and delivered on time and to budget. On the other hand, the reports of research companies that check out after implementation projects using packaged software, would suggest that results don’t often match expectations.

It may be that some managers are badly advised, fail to adequately manage the project, or just don’t understand what is involved. In many cases, however, a failure to improve performance after one of these projects can be directly attributed to a desire to avoid the trauma of major change and the resulting redundancies. Too often the failures are associated with management reluctance to make difficult decisions. In other words the parameters necessary to obtain the desired results were either fudged or ignored.

This problem was illustrated very well during the 1970s craze for centralizing and decentralizing. Almost every time a highly decentralised organization approached a management consultancy and asked ’Would we make savings by centralizing?’ the consultancy proved that it could. However, almost every time a highly centralized organization asked if savings were possible from decentralizing, the result again turned out to be positive. Management consultancies took a lot of criticism for their role in this matter but much of it was unjustified. Usually the client organizations were well aware that the savings were resulting from releasing people and processes that were no longer essential to running the business, and that they would not have always achieved such savings if major relocation issues were not present to provide an excuse.

Clearly, in a rapidly changing business world the needs of customers must be constantly changing. Why then should anyone assume that the way the function or process was carried out in, say, 1970 is necessarily still the right way. Obviously, every responsible manager will accept this need to adapt, but apparently a significant number of them do so ’half heartedly’. This was apparent in the 1970s when the centralize/decentralize saga was in progress and it is clearly still happening today.

Whatever the causes, it is generally accepted that projects fail too often to meet a reasonable amount of the targets set for them. For a number of reasons it will always be difficult to label projects as simply successes or failures. For one thing, the parameters for judging success and failure are rarely adequately laid down prior to the commencement of projects, and for another it is not easy admitting that you have been associated with a failure. However, questions aimed at project sponsors such as ’With hindsight, if you had to do it again, what changes would you make?’ almost always produce responses that suggest at least a degree of failure.