How does this tech team achieve so much for so little?
By Tony Collins
Laura Slatcher dreams of forms – reducing the number of them.
She works with a small IM&T team at Trafford General Hospital that is trying to standardise and reduce the number of paper forms doctors and nurses use in the care and treatment of patients.
As is typical for a hospital of its size there are up to 70 – mostly different – paper forms on every ward. Slatcher is working with clinicians to define ways of switching from paper to electronic records – which they are doing with alacrity.
“We have to standardise here,” says Steve Parsons, Head of IM&T at Trafford Healthcare NHS Trust in Manchester. “The doctors and nurses welcome that. They want to work better and more efficiently because they are under pressure themselves to do that.”
Clinical support
Trafford General bought its main systems outside of the £11.4bn the National Programme for IT [NPfIT]. The hospital, though, is one of the most technologically-advanced in the UK says Peter Large, Trafford Healthcare NHS Trust’s Director of Planning.
There has been no risky “Big Bang” implementation of a Whitehall-bought patient administration system. Rather, Parsons’s approach has been step by step progress over 10 years: implementing systems, learning from what went well and not so well, and integrating hardware and software from a range of suppliers. This strategy could help to explain why the clinical staff we spoke to at Trafford hold the small IM&T team in high regard.
In 2000 the hospital had rudimentary technology – isolated systems in some departments. Now the IM&T team is able to give clinicians what they have asked for; and at Trafford it’s the doctors and nurses who say what they want. Systems are not imposed on them. Here the technologists are in the background, not centre-stage as in the NPfIT.
Trafford and the NPfIT
Says Large: “We found ourselves in the position of being ahead of the game. When we were asked to commit to the National Programme we held back because we needed to know we would be committing to a better solution than was already available to us.”
Parsons adds: “Some trusts didn’t really have anything at all so were desperate to be in the first wave. From their perspective the national programme was a brilliant step forward. But the right products never arrived.”
Integrated systems
One reason for Trafford’s success is the integration of the hospital main and departmental systems. Before electronic patient records, patients could come into hospital without their paper notes being available. Now doctors across the hospital’s departments and clinics can access at the hospital’s XML-based electronic patient records at any time, day or night – and from home if they have remote access.
Doctors can view x-rays and assessments of them from the patient record; and from system alerts and patient tracking, operational managers can see how well individual doctors and nurses are coping with the numbers of patients on their daily lists.
No black-box technology
The hospital’s three main systems are an electronic patient record from Graphnet, software to schedule and manage appointments from Ultragenda, owned by iSoft (now acquired by CSC), and the “Ensemble” integration engine from InterSystems.
What sets these and the hospital’s other systems apart is that they are not black boxes, impenetrable to Trafford’s technologists. Parsons insists that Trafford’s suppliers make their software transparent so that it can be understood by the hospital’s IM&T staff and integrated with other systems, at database “field” level if necessary. That way Parsons can produce any report clinicians need and usually in real-time.
When a supplier keeps its software opaque for reasons of proprietary and commercial confidentiality, Parsons is restricted in the type of medical and administrative reports he can ask the company to supply – and may have to wait hours or a day to get them. He wants none of that.
It’s this level of control that Parsons believes he has a right to expect – and he seems a little surprised that CIOs don’t always require openness from their software suppliers.
How does this tech team achieve so much on so little money? (2)
How does this tech team achieve so much on so little money [final part]
**
The following Agile Development Case Studies have been reproduced from the Institute for Government report, ‘System Error’.
The case studies reviewed for the report come from a range of different industries dealing with highly complex issues, different regulatory requirements and a changing technology landscape. In several cases, the organisations have used multi-supplier arrangements with some using external developers.
This review demonstrates several points. First, agile development can produce significant gains, improving delivery performance, in terms of cost, quality and speed, by a factor of 20.
Second, agile is often rolled out with the support of a broader structural change and requires a cultural change within the organisation for the benefits to fully take hold. Within the private sector, for example, a more sophisticated charging mechanism was used to incentivise business units to focus on their priorities more closely, which was itself aided by an agile approach. In another instance, boards have actively encouraged a culture of empowerment through the use of rapid decision making, often via email.
Third, the use of agile can unravel without leadership and strong central support. For example, centres of excellence can be created to provide support, coaching and training for agile projects. At a large government agency, an investment review process has been adopted that provides seed-funding for smaller scale projects with less specification in order to demonstrate success earlier. Perhaps the most important message coming from these case studies is that the principles of modularity, incremental delivery, experimentation and active user involvement can be applied across virtually any IT-related business problem.
These case studies are based on interviews with senior managers in the organisations. In some cases, the organisations requested anonymity for commercial reasons.
Case Study 1
A large government agency
Case Study 2
Ministry of Defence with General Dynamics
Case Study 3
Department for Work and Pensions
Case Study 1: A large government agency
What the organisation says:
“The approach is radically different to a waterfall based project management methodology. On an individual/team level – The intense and forced ‘closeness’ of an Agile approach quickly forges an effective and motivated team. Self-managing teams increase accountability and the focus moves people past the need to ‘word smith’ and finalise requirements catalogues, moving the project away from long, onerous and valueless signoff loops. From a customer perspective – the customer sees rapid results, and is involved with what the project will deliver. They are part of the team rather than an outsider. Discussions around what will be delivered by when (scope) are much easier to facilitate as they are based on fact. Faith and trust is built between the customer and the delivery team, Agile creates a ‘we are in it together’ attitude rather than the traditional business versus delivery team model that waterfall sometimes promotes.”
Situation
Organisation description:
• An executive agency and non-ministerial department with more than 1000 staff.
Challenges:
• Decision makers were unable to reach agreement on the full set of requirements for a large scale project to create a comprehensive online ordering system. While 80% of the requirements were uncontested, the gateway process required a full set to be agreed prior to development. This process continued (on and off) for a period of four years and cost over £1 million, resulting in little usable outcome.
Objective:
• To demonstrate that it would be possible to deliver all business products online by using an agile development approach.
Transition
Selection of methodology:
• The failure of the traditional waterfall approach provided an impetus for a new methodology with high-level support. With the assistance of an industry expert the organisation carried out workshops to develop familiarity with the new approach and gain enrolment from key stakeholders.
Implementation:
• Initially a seven person team began work on the project and within three months this team doubled in size. The industry expert supported the delivery team throughout the project.
Barriers:
• The major technical challenge has been the infrastructure elements to the project which traditionally have very long lead times on purchasing and implementation (when compared with rapid two week iterations).
• There was significant difficulty in initial iterations with defining ‘user stories’ as there was a strong culture of everything needing to be 100% correct and agreed by everyone before it could be progressed to the next stage. This applied equally to business and technical resource; it took six to seven iterations (about three months) to get over this difficulty as trust was built in the team and the approach.
Impact
• Agile provided a working platform for a total cost of about £650k: less than the cost of the incomplete requirements document in the old process.
• The project has acted as one catalyst for a broader culture change where the business has adopted agile principles such as incrementalism, prioritisation, lean thinking and rapid delivery of flexible products and services. To date, only one project has adopted a fully agile approach, with around one-third of major projects now using some aspects of agile.
• At an organisational level, the agency now has a well formed and capable project team, which can easily adapt and quickly reprioritise and plan much more effectively than in a waterfall based approach. This means the team can take advantage of new opportunities identified or evolve its solutions based on problems encountered or new and emerging business requirements.
• Budgeting and governance processes within the organisation have changed to accommodate and encourage more agile projects in the future – for example through incremental investment approval. The new investment approvals process involves obtaining early permission to fund development immediately without a fully specified business case being approved, although a robust justification must still be provided. The project is given permission to spend at a particular rate over a period of time. The projects will return to the Investment Board at specified intervals for further ongoing approvals and to update on progress.
Case Study 2: Ministry of Defence with General Dynamics
What the organisation says:
“The chief difference between a DSDM (agile) approach and a ‘traditional’ project is the explicit acceptability of failure (fail early) and the flexibility (within clearly defined limits) of what the final outcome will look like. The biggest single mind-set change is the denial of ‘slip’ in delivery dates, preventing the traditional engineer’s mindset of ‘just a little more time will do it.”
Situation
Organisation description:
• The MoD’s Defence Equipment and Support is responsible for spending £14bn annually to acquire and develop equipment and services, including ships, aircraft, vehicles and weapons, information systems and satellite communications.
Challenges:
• The Defence Acquisition Change Programme (DACP) highlighted the fact that threats facing the military require greater agility and responsiveness and that there is an increasing divergence between MoD and commercial technology cycles, resulting in obsolescence and undermining innovation. It was therefore important to reduce the length of acquisition cycles.
Objective:
• To deliver a £3m system to integrate the land, sea and air communications for combat operations through a multi-supplier arrangement.
Transition
Selection of methodology:
• Agile was identified for pilot application by the DACP designed to bring about a radical improvement in acquisition performance.
Implementation:
• The approval of the change programme gave the project the backing of the corporate centre. As project participants had no prior experience with the agile approach, short training courses were undertaken and a facilitator from Keith Richards Consulting provided coaching.
Barriers:
• Establishing a common understanding of the nature of agile was complicated by the involvement of four separate organisations.
• A technologically closely related project was subject to a higher degree of financial and risk scrutiny than the monetary value warranted because of the lack of perceived assurance in the agile methodology. The project involved four separate organisations and the contract specified a limited number of high-level requirements, increasing risk exposure. The MoD ultimately had to rely on developing a high quality, collaborative relationship with suppliers to provide assurance that the contractors would continue to deliver functionality beyond the bare contractual minimum.
Impact
• The project was delivered on time to cost and budget. It demonstrated that agile can be successfully applied to a collaborative, multi-organisational project to deliver a technically complex military capability and required more customer involvement than usual.
• The lead contractor, General Dynamics, now uses agile development techniques for its internal IT capabilities.
Campaign4Change 
Thanks, it’s not clear from the text what system the case study is describing. However, it is Automated Service Delivery (ASD), which was scrapped in Feb 2012 (not 2013 as I originally posted). There are a couple of links about the system below:
Click to access rrep734.pdf
http://www.pcs.org.uk/en/department_for_work_and_pensions_group/dwp-news.cfm/id/80DF8049-858A-42EB-9F2182688938019E
The parallels with Universal Credit are interesting.
LikeLike
Thank you for the links
LikeLike
Case Study 3 – leaves out the facts that this project was scrapped in early 2013 and not a single line of code ever went live. I assume this is because this piece was written in 2011? Anyway, I think it’s best not to write a case study until a system has gone live and the benefits are tangible and have been realised (especially one that seems to be claiming some kind of success). I notice that the study says UC used the same methodology. That’s doesn’t appear to be doing well either.
LikeLike
Thank you for the information which we’ll look into and if necessary remove the case study.
LikeLike