Protecting the project
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, 12 months later, were trading at under $10. This chairman’s ‘protection’ of the company was hugely detrimental to its shareholders.
So it is with the project fraternity and project improvement opportunities: “Oh, they won’t adopt any of this” or “We [as an organisation] are not mature enough to improve.”
In one case the project manager dismissed our approach to identifying and simplifying the business requirements as “just too hard to do in this organisation”. His project then went on to double its original cost and then fail due to, you’ve guessed it, inadequate business requirements! I’m sure the project sponsor was delighted to have been protected from a workable and lower cost solution.
There is a common but fallacious belief that ‘more mature’ (as they are seen) processes are more difficult and more work. In some cases this may be so; but we’ve designed it to remove many of the redundant steps and render other steps unnecessary. The overall 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 and operating effort and associated project costs all go down. But most organisations are ‘protected’ from this level of improvement by project teams’ use of software as the definition of requirements.
If you take the opportunity to implement change progressively throughout the project, realising benefits that are not systems dependent; the net cost of the project goes down while belief in the potential success and value of the project goes up. But most projects are ‘protected’ from this continuous realisation bonus by the dogged use of the systems development lifecycle.
When the Board of a major bank complained yet again at the poor results obtained from projects; the bank focused on filling the gaps in its current 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 its project results.
Because the project fraternity have often failed before to ‘change the business’ in relation to projects, often by trying to get them to use project management tools and techniques, they are reluctant to try again: “It doesn’t work; they just won’t change.”
Organisations need a strategy-based, business-driven approach that assumes the project manager is going to do his or her job effectively, asking the business questions like:
- “What exactly are we trying to do here?”
- “Is this a valid project?”
- “What business changes do we need to make?”
But then we also give them the processes, tools, techniques and templates to answer these questions.
I don’t think ‘protecting my organisation from improvement’ is in anyone’s job description, but many seem to want to make it their personal accountability.
Who is protecting you from improving your project results?
