Is It Too Hard To Improve?
There is a famous case in Australia where the Chairman of a large company rejected out-of-hand a takeover offer of $27 per share when those shares twelve months later were trading at under $10. This Chairman’s ‘protection’ of his company was hugely detrimental to his shareholders.
Likewise with the project fraternity, and with project improvement opportunities, project and portfolio managers too often protest, “Oh, THEY won’t adopt any of this” or “We (as an organization) are not mature enough (to improve).”
The Dangers Of Protection
In one case the project manager dismissed the TOP approach to identifying and simplifying the business requirements as “Just too hard to do in this organization.” His project then went on to double its original cost and then fail altogether due to, you’ve guessed it, inadequate business requirements! I’m sure his Sponsor was delighted to have this project waste having been protected from a workable and lower cost solution.
There is a common but fallacious belief that ‘more mature’ processes (as they are called) are more difficult and more work. In some cases this may be so; but with TOP we’ve designed it to remove many of the redundant steps and render other steps unnecessary. The overall project workload goes down.
If you take an 18-step process and redesign it to be a 5-step process or reduce 375 processes down to 23 options – the design, configuration, testing, training, operating effort and associated project costs all go down. But most organizations are ‘protected’ from this level of improvement by, for example, project teams’ (and the business') use of packaged software as the definition of requirements.
If you take the opportunity to implement change progressively throughout the project thereby realizing early all benefits that are not systems dependent, the net cost of the project goes down while belief in and commitment to the potential success and value of the project goes up. But most projects are ‘protected’ from this continuous realization bonus by the dogged use of the systems development lifecycle.
When the Board of a major bank complained yet again about the poor results obtained from projects; the bank's executives focused on filling the gaps in the bank's current project delivery methodology rather than identifying the root causes of the problem. “We’re not mature enough for anything else” was the justification. That Board was ‘protected’ from improving the organization’s capital investment and value delivery processes and results.
Because the project fraternity has often failed to improve project performance by using ‘better’ project management tools and techniques they are reluctant to try again. “It doesn’t work; they just won’t change.”
I don’t think “protecting my organization from improvement” is in anyone’s job description; but many seem to want to make it their personal accountability.
