In 2013, Police Scotland took the brave position to not ‘make do’ with an off-the-shelf system, but to build their own that would support “new standardised national policing processes and daily policing operations and investigations”. The i6 project was conceived to bring together over 120 IT and paper-based systems into a single transformational solution for the force to use to improve efficiencies. And outsourcing giant Accenture was instructed to develop the new system.
Challenges emerge…
However, three years on, in July 2016, a statement from the Scottish Police Authority (SPA) states: “The decision has, therefore, been taken to end the contract and reconsider options for securing a sustainable IT solution for policing”, announced the end of i6, which reportedly, was still far from complete.
With the project estimated to cost between £40m and £60m, questions are being asked about what led the pair to this point and whether there was anything that could have been done to achieve a different outcome.
Fundamental to the issues that led to the decision to end the i6 project seems to have been the defects that are reported to have existed in the system when it reached its user acceptability testing phase in June 2015. Apparently, 76 critical errors and defects were found, far more than Police Scotland thought there should be at that stage in the process. The reason for these defects and Police Scotland’s response to their discovery seem to be key to why this project was unable to reach a successful conclusion, so this is what our review will focus on.
In February 2016, current affairs magazine Holyrood reported that Martin Leven, the Director of ICT at Police Scotland, had claimed the contract award to Accenture followed “one of the most thorough procurement processes ever”. But it was also reported that in July 2013, “differences emerged between Police Scotland and Accenture on exactly what the i6 contract required the supplier to deliver”. As this was just months after the inception of the project it is surprising that such misalignment should already exist, especially if the procurement process had been so thorough.
Other clues to what may have gone wrong can be found in the statements made at various times by those within the relationship:
-
As reported in Holyrood magazine and the Herald Scotland newspaper, an Accenture spokesman said: “This is a very complex project. The complexity of the solution, which has been driven by the client, has increased significantly over the last two years.” It is vital for any complex IT project to start with a thorough scoping exercise to determine clear and quantifiable outcomes required to validate the effort all parties will need to put in. Long-term projects are susceptible to the potential of change requests, but the more detailed the pre-contract analysis by provider and client, and the more widespread the stakeholder involvement, the fewer or small scale these changes will be, putting less strain on the relationship.
-
The same media reported that subcommittee convener, SNP MSP Christine Grahame, revealed that commercial trust had become significantly strained by saying: “Crumbs, I wouldn’t let them fix my pipes and radiators at this rate. They would tell me that they were alright and they would still have leaks.”
-
And STV and Holyrood reported that Martin Leven, Director of ICT at Police Scotland told the subcommittee it was his “honest opinion… that the senior managers in Accenture, the ones that we face up against, probably were not aware of the issues until such time as we highlighted them to them”.
So at the beginning of July 2016 the SPA issued a statement that read: “Despite the best efforts of the SPA, Police Scotland and Accenture, it was clear that the technical solution cannot be delivered within expected timeframes and budget. The decision has, therefore, been taken to end the contract and reconsider options for securing a sustainable IT solution for policing.”
The statement concluded: “As with any programme of this nature or size, an independent review to ensure the SPA and Police Scotland learn lessons from this project will be initiated.”
While we wait for this analysis, here are five take-aways that you can implement within your own complex IT and outsourcing partnerships.
Five speculative lessons from i6
1. Early establishment of your ICF team
Many public and private sector organisations develop bespoke teams with specialist project knowledge and adequate resources and authority to help mitigate risks and steer a project to more productive ends. This is the Intelligent Client Function (ICF) team, often comprising operational, legal, technical, project, procurement and stakeholder management expertise. The temptation, though, is to wait until procurement is completed and the ‘project proper’ has begun before establishing such a team. Our advice is to involve them from project inception. Your ICF team should be the foundation from pre-contract analysis to implementation/handover. Their consistency could avoid the misunderstandings and misalignments that often occur when procurement teams hand over to operational teams, and the relationships they build with suppliers and providers can build commercial trust between the parties.
2. Define what good looks like
At the core of your project should be a complete understanding of ‘what good looks like’. Your thorough pre-contractual due diligence should identify this for you, and it is paramount that once you know what end results you are aiming to achieve, you build in the right KPIs to guide your outsourced partner to your expected ends. Equally important then is the incorporation of what good looks like into your contract, and both the clear communication of your goals and expectations to your provider and confirmation that they fully understand what is being asked of them. Statements made by i6 project members cited earlier seem to show some misalignment from the outset, and the mention of ‘complexities’ due to changes in requirements along the way adds to the assumption that there may have been gaps in the definition of what good looked like for this project.
3. Thorough pre-contract due diligence
It is essential on any project to sense-check the commercial viability of any bids within the procurement phase to ensure that there are no ‘gremlins in the woodwork’. Clarity of intention and capacity are imperative. Do you know what you are looking to achieve? Have you asked the right stakeholders to gain a clear enough view of this? Do you know what outcomes you wish to realise and can you quantify the benefits you hope to gain as a result? Can your provider deliver on your expectations? And, is it worth the extra expense of a scoping exercise to ensure that the supplier has a documented and informed understanding that will see you receive a solution that is fit for purpose. Tick all the boxes, because any cutting of corners could result in a very costly mistake down the line.
4. Contract clarity is a must
The i6 Programme Director, Chief Superintendent Hamish MacPherson, reportedly said that an “initial plan of action put forward by the supplier to remedy the problems asked for additional finance”. Our advice is that if your requirements and outcomes are clear, the cost of any necessary remedial action should be borne by the supplier, and that this should be detailed within the contract. Contract clarity therefore is crucial. It’s important to understand what is legally documented so your contract should be written in a way that both parties can plainly understand. It is also important to avoid any ambiguity, because any opportunity for misunderstanding is a chance for an expensive mistake to be made. One area requiring crystal clarity is who is responsible for what, and the process to be applied should things go wrong. If the vendor on the i6 project was asking for additional funds to resolve problems uncovered during testing this could imply that there was some lack of clarity in the agreement, or that the contract could have/should have been more favourably weighted towards the client.
5. Manage, measure and realign
From what has been so far reported on the i6 project, it seems as though the schedule and budget started to slip, and when issues arose they were not resolved in a manner that satisfied Scotland Police. One of the fundamental aims of any ICF team is to be the early warning system of a project, leveraging their relationship with the provider-side teams to identify any strains or risks and reporting up the line. Ensure that your ICF teams have the skills and capacity to develop such relationships, then give them every opportunity, at regular review meetings, to share their learnings so that you can recognise when and where realignment is required.
Conclusion
The development and implementation of a large IT system is a complex undertaking, fraught with ‘unknown’ unknowns. Yet there are measures that you can put in place to mitigate the risks they pose. Lay the groundwork for the right behaviours, contractual and communication clarity, highlight expert responsibilities, and never miss an opportunity to double-check project viability and your provider’s understanding of your objectives. Time and budget sensibly spent at the outset of a project will pay significant dividends in years to come and any cracks identified at this point are far better off handled right away, rather than being left undiscovered until they have grown into a beast that’s more difficult to deal with.
