One view on how to tackle government IT-related failures

Sarah Burnett of the Bulter Group has some worthy views on how to tackle government IT-related failures, even if her coinage of “proof-win” threatens to burden the IT industry with more jargon.


She says in essence that, at the proof of concept stage, fully-functioning systems should be tried out in the departments that are going to be affected by the change.

She argues that proofs of concept should be scaled up and extended “only when the business case and, flexibility and scalability, are proven and key stakeholders are won over”.

“Only when success is proven should attempts be made to extend the rollout to other anisations. By then, there will be a compelling business case to support the extended rollout, to help win over even the biggest sceptics,” she says.

This costs more money and time. But it’s better to understand the potential problems in the early stages of the project than try to fix misunderstandings later about how end-users work.

She says:

“The fundamentals of Proof-Win are not new; piloting projects to test concepts on a small manageable scale are common. It is in the detail that Proof-Win differs from general pilots. Although this approach would be slower than others, it is far more likely to succeed and will be less expensive in the long run.

“The public sector consists of a diverse group of organisations with complex structures and reporting lines. Take the case of the National Health Service’s (NHS) National Programme for IT (NPfIT). The programme applies to GP surgeries, and yet GPs are contractors to the NHS, and are not governed in the same way as a business unit would be in a private sector company.

“Another example is the police force and local authorities that work closely with each other, but answer to different Government departments; the Home Office and the Department of Communities and Local Government respectively.

“Therefore, delivering multi-agency projects, where there are no direct lines of reporting within the organisation of the project, cannot follow traditional project management routes. An example of this in the private sector would be in a conglomerate where staff involved in a project report to different managers in diverse subsidiaries.

“Traditional methodologies such as Prince 2, which developed out of the public sector, can only be applied if key stakeholders are represented on the project board. That is impossible to achieve if change is mandated centrally and dialogue is held after the initial ideas have been formulated.

“This may be the case for example, if change is necessitated as a result of Government’s long term needs and plans at a national level. In such cases it would be difficult for users, at a local level, to specify requirements, visualise the end product, and how it might help improve their business processes. Even when stakeholders are involved in the project from an early stage and support it, getting consensus of opinion on a national scale is never easy.

“Another issue is that skilled resources are scarce and are required to deliver the main services that they are contracted to do. This often leads to a shortage of staff to provide input to the project requirements.

“The Proof-Win approach is totally the opposite of a big bang deployment. It hinges on successful proofs of concept to win support from key stakeholders.

“Put simply, there are three main principles to Proof-Win:

– user requirement management,

– full functionality trials that are repeated to take into account issues that arise out of extending the project, and

– measurement of outcomes.

“To manage user requirement, IT resources must sit in the departments that are going to be affected by the change, to shadow users, and observe and learn the daily processes of the department.

“They must also measure throughput and efficiency before the deployment to compare with measurements after. Having consulted the users and learnt their daily routines, the IT staff can then define the user specifications, and have them checked and agreed by the users.

“The full functionality trial is about delivering the complete IT functionality that is required, no matter how small the scale of the exercise. This means neither cutting corners, nor making do with inferior functionality to what would be deployed in the extended roll out otherwise the proof of concept will be unrepresentative of the wider solution.

“Scaling up is done by degrees with new issues and lessons learnt included in the proof of concept at the next stage.

“During the development phase, there must be regular updated mock-ups, screenshots, and simulations of the final solution to show to users to ensure that the project remains on track.

“When the trial is successfully deployed, it must run for at least one year to allow time to resolve teething problems, and for the new system to get into a steady state of operation. This period must be used to prove resilience, flexibility and scalability.

“IT staff must then return to work with users to get their feedback, observe and note the effects of change on service delivery and productivity, and compare measures of throughput and efficiency. Unexpected results and lessons learnt must be fed into the next stage.

“Only when success is proven, should attempts be made to extend the rollout to other organisations. By then, there will be a compelling business case to support the extended rollout, to help win over even the biggest sceptics.”

**

Sarah Burnett is a Senior Research Analyst with Butler Group where her focus is on business intelligence, and the public sector. She was the Smart Card Programme Manager for Buckinghamshire local authorities, and e-Government programme manager for Aylesbury Vale District Council.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close