Philip Virgo has an excellent piece (HT: Pete Thomson) in CapGemini's magazine Transformation (hidden behind a lengthy sign up and PDF only. Sigh). It's about IT but you could substitute Web and it works just as well.
His main points are:
Why do big systems fail?Choice quotes:
The nominal causes of failure are listed in many reports. The usual top six, in order, are:
Analysis of business needs, missing or wrong: failure to undertake a proper needs analysis. Failure to consult those in the front line of delivery, or in receipt of services, is endemic among those planning new policy initiatives or changes to existing systems.
Needs change before implementation: the churn of ministers and political priorities is significantly faster than that of technology. It has been suggested that suppliers commonly bid low on the original specification to get the opportunity to make profits on the subsequent changes.
Over-ambition: about what is achievable in practice, given the people, time and budgets available, as opposed to in theory – with the people, time and budgets that are not.
Delay: particularly in agreeing priorities between conflicting objectives, leading to delay in planning and procurement (compounded by staff rotation) before the project gets under way.
Lack of top customer management involvement: and lack of high-level skills, training or experience in planning, procurement or implementation. This lack of training and experience on the part of the customer causes and compounds the previous four problems and should, therefore, come first – but rarely does so in most reports.
Supplier project or team management: usually because the ‘B’ team is trying to salvage an already doomed system, after the ‘A’ team has moved on to the next bid.
‘Technology problems’ rarely appear in the top six. Complex and untested mixes of semi-incompatible software may result in slow, unreliable or unusable systems but, if so, the fault is not the technology but the failure of the customer to require the use of tried and tested products and services and to check claims of inter-operability or performance as part of the procurement process. Blaming consultants and suppliers for competing to reinvent new wheels at taxpayers’ expense is like blaming fox hounds for tearing apart a tame cat.
Once a proposal has been said to have ministerial support, it acquires a mystical status – to be justified and defended at almost any cost, until such time as a new minister can announce that ‘technologies have changed’ and thus justify a new approach.
A practical difference is that in motivation and skills. Those working in the public sector commonly joined for a life of service and security. If they had wanted to be risk-taking, bonus-motivated entrepreneurs, they would have gone into the private sector. There is also the poor provision of opportunities for project implementation experience (let alone training) in the public sector. This is particularly serious when one adds the common expectation that officials can perform roles outside their experience or supervise contractors to do so.
@PubSecBloggers
Can't argue with any of those points... but extrapolating them, the proposed solution seems to be an even greater focus on pre-project specification.
ReplyDeleteI'm afraid, in my own experience, the 'mythical status' of Requirements Documents are just as big a problem as ministerial endorsement. If not bigger.
er, yep. he does have some ideas at the end. maybe I'll add those in. pity this isn't just on a webpage!
ReplyDelete