By John Little
It’s a significant and neglected challenge for service leaders: distinguishing problems they actually have to solve from those they think they have or have been persuaded by others to believe they have.
The push to digitise services has been encouraged by government and large IT outsourcers, often in a Whitehall partnership. They promote the notion that digitising services also makes them cheaper, faster and better. Not so. Many outsourced IT providers have little knowledge of what good IT support looks like to meet individual organisations’ operational needs, and frankly often don’t care. They just want a sale.
When implemented, dysfunctional IT architecture and software effectively dictates what service staff can and can’t do to meet a user’s needs. Senior leaders often deny this happens… unless and until they go into the work to see for themselves, at which point, ‘This isn’t what I thought we had bought. It needs to be changed,’ is a frequently heard lament. ‘The vendor said it was “configurable”, so I guess we just need to reconfigure it’.
Few large organisations now write or maintain their own IT software. Like service work in general, IT development has been outsourced to software houses with their own standardised product offerings and profit-focused sales agenda. Very often the only things retained in the IT department are the minor technical assistance function, contract management and a few peripheral activities. They have thus voluntarily down-skilled themselves into product administrators – a self-inflicted helplessness often compounded by effective ‘capture’ of IT support departments by vendors and their products. The effect is to lock in inflexible and wasteful systems sometimes for a decade or more.
As for configuration: whatever vendors promise in sales negotiations, the reality is that after implementation, off-the-shelf software is almost impossible to reconfigure except at a cost that most organisations will not want or be able to afford. Reconfiguring a ‘vanilla’ product often entails persuading other purchasers, whom you don’t know and who don’t know or care about your business, to agree to software changes that will affect all users. Not surprisingly, this doesn’t usually end well.
How to do it wrong
A housing organisation, let’s call it AB Housing, was looking to upgrade its IT in support of a newly completed business improvement project.
AB Housing hired an expert in PRINCE II project management on a ‘temporary’ basis to help it source and implement appropriate software. The project manager supposedly knew about the PRINCE II framework but not very much about IT itself, nor about AB’s IT requirements. He struggled to comprehend the business needs as the work progressed but couldn’t let that show. He was an expert, after all, who needed to work with other clients after this project ended.
The PRINCE II approach to software development appears systematic and orderly. It is based on seven principles, seven themes and seven processes – what could be more reassuring? Just to be sure and to comply with best-practice, the project manager insisted on a risk register which was duly drawn up, with a list of imagined/made-up risks, all categorised, named and given a risk number. Needless to say, when the IT project collapsed, none of the things that caused it to fail figured on the risk register. The reason was that the project leaders, who understood neither the work nor the staff who did, were themselves the source of most of the risk.
The temporary ‘expert’ now believed everything was in place for full project control.
The project launched with a project board, senior responsible owner, project manager, steering committee of potential users (no one spotted the irony here – why not start with actual users?), and a senior external IT expert available on call.
Although no one on the project board had been involved with the business improvement project, its members were expected to sign off on staged implementation proposals on the basis of what they were told the IT would do to deliver the improvement. This brought their individual biases and opinions into play and triggered much debate. The senior responsible owner had not taken part in the business improvement project, being considered too busy and senior, so a second external IT expert was drafted in for another opinion. Benchmarking trips to see systems of other clients were arranged, but no actual users of the system were included.
In parallel, the project management expert was ensuring that the PRINCE II documentation of ‘milestone review meetings’ was being properly recorded. What could possibly go wrong?
I know you want a happy ending to this story. You will be glad to know there was one.
The matter was resolved by terminating the services of the PRINCE II and external IT experts. Having adopted a Vanguard Method approach, the senior leadership realised that the initial business improvement project and findings were flawed. They were flawed because they were based on customer focus groups, asking managers what they thought, staff workshops and ‘away days’.
So leaders went back to first principles and established what was actually happening on the ground and why. They then learned what they could do to meet service users’ needs in the most effective, efficient and consequently economical manner. The supporting software-writing expertise and solution were then ‘pulled’ to the real future solution within the organisation. The solution was what is known as a Rapid Application Development (RAD) approach. It is hated by off-the-shelf IT snake-oil salespeople.
The staff who carried out a rapid ‘check’ and were therefore aware of just how bad the existing IT systems were now had knowledge to take forward into a redesign. After two weeks of prototyping the redesign team decided they needed software code-writers to work alongside them to learn what an effective IT system should look like and be able to support them with. Coders then worked iteratively with the team to create software that followed the logic and flow of the work.
Understanding the need for measures relating to purpose, the code-writers ensured that the data required for capability charts was available as a matter of course rather than as an afterthought.
When it was rolled-In to the workforce the EDIPing of staff was so much easier because the work-flow-focused IT had been designed in support of the work. Staff could get the measures they needed when they needed them. Because AB Housing owned and controlled the code it was as cheap as chips to make any amendments that were necessary.
How to do it right
This example describes how Norwich-based Flagship Housing Group built its own bespoke IT system to ensure seamless interaction across the interlinked systems in its repairs and maintenance service. To do so, it decided to bring the service under direct control through its own specially created subsidiary, RFT Services.
This came about because Flagship’s chief executive and two directors took the time to participate, along with a cross section of staff, directly in the ‘check’ or understand phase. It was a professionally life-changing experience for all of them. What they discovered by seeing it for themselves was that performance was very different from what they had been led to believe. With real knowledge of the ‘what and why of performance’, they could see that there was a great opportunity to provide services in a much more effective and efficient manner.
Much of the underperformance established in ‘check’ was caused by the standardised, off-the-shelf, so-called best-practice IT in use by Flagship and its outsourced contractors. There was a compelling case for a complete rethink of the delivery model and specifically the IT systems for repairs and maintenance. This included a significantly greater understanding of the grim state of the logistics support to tradespeople in outsourced contractors.
As the ‘redesign’ phase progressed, the directors realised that having the right IT to support and integrate their requirements in terms of leadership, logistics, operations and tradespeople was absolutely pivotal to achieving their goals of as near as possible perfect service delivery.
Nothing on the market met their specific software requirements. Like many other organisations, Flagship realised that its own internal software writing abilities had been eroded over the years. It had bought the line chorused by many senior IT managers that writing your own software is too expensive. The answer to that of course is, ‘compared to what?’ They have no idea of the waste and associated costs driven in by buying standardised systems. Initially, Flagship needed help from an outside IT supplier to build a system to its specific need. Concurrently the company began to rebuild its internal IT capability to ensure self-sufficiency and sustainability in the longer term – a smart and counterintuitive move.
At the end of it, Flagship had in place a bespoke IT system that was a key enabler of its ability to deliver service right first time. The system is still being developed in an emergent manner and that will continue. This is all at a fraction of the cost of traditional dysfunctional IT maintenance systems available on the market. There are none of the requirements to take unwanted software updates that make off-the-shelf IT providers such huge undeserved profits.
What does the new IT look like?
When a repair is reported, it is recorded and visible on the system which is then fed into the workload management facility.
This makes it accessible to those who need it, in the format they need and at the time they need it to deploy resources. It enables them to understand and plan organisational capacity against what tenants actually demand. The tradesperson attends at the time the specified by the tenant, not the housing organisation. Resource controllers have full visibility on where tradespeople are and what demands still have to be met, enabling frontline leaders to deploy effectively in their support.
Meanwhile, materials used in the repair are recorded on the system. The visibility on usage of materials by trade and location and building archetype allows the Flagship logistics centres to replenish van stocks in a timely manner. As with initial coding, early logistics learning work was supported by an outside company called Perfect Flow. However, the Flagship logistics staffs are now self-supporting. Crucially, their element of the Flagship IT system is fully integrated with the rest of the business, allowing the cost of the repair to be calculated when the job is closed. This is fed directly into the logistics element of the IT system so that business intelligence is acquired, in emergent fashion, on product usage and performance, in turn feeding into more effective and economical purchasing and supplier selection.
The prospects for IT in service organisations is bright – so long as it is approached in a user-oriented, purpose-focused manner. The future should not be to line the pockets of outsourcing providers, nor to sustain the UK as a centre of incompetence in IT project management. It should be to ensure IT serves the public and staff in the most effective and economical fashion.
It is essentials to know what problem(s) you are actually trying to solve with IT; indeed, if you have one at all. Because there is something new and shiny in the marketplace doesn’t mean your organisation has to have it. IT must be fit for purpose – your purpose – not some compromise that ends up cutting you off from customers.
As at Flagship, senior leaders must be actively involved in the entire ‘understand, improve and implement’ cycle. This ensures those with authority can make properly formulated and informed choices regarding what fit-for-purpose IT consists of for their organisation.
Service staff must not be captured and constrained in how they serve customers by the IT system. Standardised IT-based transactions always cost more, in our experience, driving in failure, waste and unanticipated overall cost. Cheap is usually dear. Yet having useful and useable IT is both achievable and necessary. Bespoke can deliver what you need when you need it how you need it. As in the case of Flagship, well designed, purpose-focused IT is a significant part of that bright future – provided you do it your way.
John Little
