The dismal success rate of business change/transformation programmes and IT projects in both the private and public sectors, across the world and in a variety of industries [noted elsewhere on this website], do share something in common.
What they have in common is that when senior managers gave ‘go ahead’Â approval for those programmes, they evidently failed to ask the incisive questions and/or, didnâ€™t insist on the meaningful answers that would have revealed the fundamental flaws in the proposals they reviewedâ€¦ and blessed!
As weâ€™ve pointed out elsewhere on this site, the dreadful failure rate is primarily due to the design of programmes rather than in failures of execution (although that can of course also happen).
The fundamental and fatal flaws in the approach taken to business and IT programmes by most large organisations, can only survive because senior managers either donâ€™t ask, or donâ€™t know the critically important questions to ask.
These notes are intended to help managers raise those questions â€“ and to help them insist on meaningful answers. This thought-process or mindset,Â applies when evaluating programme proposals or in consideringÂ the continuation of programmes already underway but which escaped serious scrutiny â€“ as the vast majority do escape, at their original approval stage.
We will set out a set of questions you can use as your toolkit for quickly assessing the robustness of programme and project proposals.
But first, letâ€™s start with the basics…
The Basic Question
In some way or other, every programme or project an organization undertakes must be intended to result in some improvement. Otherwise, why undertake it?
The improvement may be in, for example, cost efficiency, effectiveness, quality, compliance with say regulatory requirements, reputation/image, whatever. The basic question to ask of any programme isâ€¦
- â€œwhat is the improvement to be delivered in return for this investment of money, time, resources?â€ and then…
- â€œspecifically, how much improvement and by when?â€
The â€œimprovementâ€ question is fundamental.
But the vital next step is to prepare for answers which donâ€™t address the question but which instead, respond with what is going to be done, or what â€˜stuffâ€™ is going to be put in place (the new IT systems, redesigned business processes, changed organisation structures and new ways of working).
Most programmes involve lots of busy activity and deliver lots of stuff, but those things alone do not guarantee business improvement â€“ as the dismal success rates attest.
In terms of return on investment, what actual business improvement will be achieved? By how much and by when in return for the expenditure, time spent, resources committed and the disruption to business-as-usual?
Often, programme proponents will claim â€œBest Practiceâ€ or other vague phrases as justification for their proposed â€˜solutionsâ€™. So you need to be prepared to unpack and challenge vague assertions. Weâ€™ll come back to that in the questions themselves.
And a word of caution; do not rely on the programmeâ€™s business case.
Hereâ€™s the solution; whatâ€™s the problem?
The business case is typically written and shaped to cost-justify a solution or project that has already been decided as favoured, but which now needs funding and approval for go-ahead. In other words, the business case is retrospectively seeking to identify the advantages to solving the â€˜problemâ€™ that the favoured solution might provide.
So, accepting â€“ just for this moment, or particularly because of – the â€˜backwards-nessâ€™ of most business cases and the benefits they propose, incisive questions must be asked of the business case.
So what are these incisive questions? More to comeâ€¦