Item 2 is an evidence-taking session on progress with the development of the i6 programme.
It is my pleasure to welcome: Deputy Chief Constable Neil Richardson, who is designated deputy for the chief constable; Chief Superintendent Hamish Macpherson, who is programme manager for i6; and, last but not least, Tom McMahon, who is director of strategy and performance at the Scottish Police Authority.
We have received a comprehensive report from Police Scotland, which includes the most recent update on the programme, so we will go straight to questions from members.
Good afternoon. I have a question about the scope of i6, which is perhaps for Mr Richardson.
I understand that the project covers 80 per cent of current police operational activity. In your letter to us, Mr Richardson, you say that recent examples of improvement
“are the inclusion of a national vehicle accidence management solution and ‘ewarrants’.”
Are those additional to the 80 per cent or would they have been in the programme anyway? What is the 20 per cent?
Those two examples are in addition to the initial scope of the programme.
Throughout the entire journey, I have been cautious to guard the programme’s scope. I described it previously to the committee and discussed the importance of ensuring that we do not allow mission creep to distract from delivery. However, the passage of time between the concept and delivery is a number of years and the world moves on. It is important that we keep up with dynamic arrangements in policing, and both of the additions reflect that.
The inclusion of e-warrants is a really good example of the start of the genuine digital exchange of documents—which currently takes place within Police Scotland—beyond the boundaries of Police Scotland and into the justice arena. It almost serves as a testing ground for further development in that space. Beyond the benefits that it brings, it opens our thinking and opportunities for more such activity.
The road collisions element directly fits into the spirit of, and the benefits that flow from, i6. It was originally outwith the programme’s scope but, as we moved forward, it became apparent that the two would run in parallel. In discussing the various changes that were happening just by due process, an opportunity arose to incorporate the road collisions element into the programme. Therefore, with the agreement of Accenture, it has now been included.
I should say that both additions have taken place without further cost to Police Scotland. They are included within the initial contract.
That is very reassuring.
You are right that there is a wider future agenda in relation to e-warrants. Can you give every assurance that the system is compatible with your criminal justice partners such as the Crown Office and Procurator Fiscal Service? We have heard previously—although perhaps at the Justice Committee rather than this sub-committee—about the unique nature of communicating reports electronically. Is it all compatible?
The simple answer to that is yes, but I will invite Hamish Macpherson to provide a little more technical detail. As I think I have previously mentioned, we now have a cross-disciplinary group through which colleagues and partners from a number of disciplines are actively consulted and involved in the development. The e-warrants element is being done with the full visibility of that group.
I ask Hamish Macpherson to expand on that.
The e-warrants functionality that we are putting in is entirely to do with compliance. For the integration of the Scottish criminal justice information systems, data standards have been set with all the partner bodies in that criminal justice group. The e-warrants functionality is purely us reflecting that in the i6 application.
As I think that Mr Hippman and the deputy chief constable said when the sub-committee discussed the issue previously, i6 has always been described as an extensible application, so that we can extend it as years go by. The e-warrants element came up as an opportunity, and the Crown Office was keen to move towards it. We are keen on it, too, as it involves huge labour saving. Currently, we have an archaic paper system for warrants. A paper warrant is sent to a station and is manually routed to an officer who then deals with it. When the electronic system comes in, warrants will be routed automatically by the application and a log of all the activity for the warrant will be held in the application, which, in due course, will be available to our criminal justice colleagues.
Just to confirm, would that include, for instance, the Scottish Prison Service?
The Scottish Prison Service is part of the criminal justice group. As it stands, i6 will be rolled out for police officers initially, but the intention has always been to involve partner organisations. Apart from anything else, there is a saving for Police Scotland in that. For instance, when a warrant is executed or cannot be executed and the Crown Office asks for an update on all the activity that has taken place, at the moment we manually produce that update. Under i6, the Crown Office will simply be able to view the log that is held against the warrant.
Mr Richardson, you said that the issue came up in the course of the project and that you initially wanted to contain the project specification. Is there anything else on the horizon that is likely to come up, including matters that are outwith your control and could perhaps emanate from this building?
In effect, we are in the delivery stage; the design phase is now complete, so we are beyond the point at which adjustments to scope can be made. That said, there is potential for subsequent after-roll-out addition. There is a great deal of scope to deal with things that are currently done in a remote or independent fashion and to incorporate them into i6 or something that is compatible with i6. Those will be subsequent conversations.
The trick is to ensure that we stay focused on the delivery of i6 as a distinct entity while we develop strategic plans on information and communication technology requirements, and then consider at every stage how those are brought together. That is all on-going work.
I have one overall question, which is a small question but also a very big one. Is it still the position that, if a milestone is not reached, no payment is made?
That has been the principle all the way through. The situation became a little more complicated with the last milestone, on which, for convenience to an extent, I breached that principle and retained some money but made the bulk of the payment. That was for a number of reasons, but it was largely because, from our perspective, some elements sat more in our space than in the supplier’s space. However, there has now been full delivery and the payment has been made. In essence, it was just a slight breach of the principle. I revert to my original position, which is that, unless something is completely delivered, there will be no payments.
Thank you—that is reassuring.
I have been very remiss in not acknowledging the attendance of Hugh Henry MSP, Labour’s justice spokesman. Welcome to the sub-committee, Mr Henry.
DCC Richardson, in your letter to the sub-committee, you state clearly that there have been no additional costs as a result of the contract variation. Is that correct?
Yes, that is correct, in terms of the contract arrangements.
We discussed the contract variation in some depth the last time you were here to give evidence on i6. What changes have been made to the timetable for complete delivery of the i6 system?
The stand-out fact that I am keen to stress is that the date for the final roll-out has remained what it was originally. After the contract variation, we expect to have a complete national system rolled out fully in September 2016. That has remained the case.
There has been some adjustment and change, but the changes have not altered the end point. In essence, there has been a delay to enable us to ensure that the design is absolutely accurate and that we are completely content that what we are asking to be built is exactly what is required. I still believe that that is necessary. If we do not get that right, we will pay a heavy price later if something is built that does not do exactly what we want it to do. That will come out during testing. To avoid that, we negotiated a period in which we allowed more time.
The changes did not compromise the roll-out date, for a couple of reasons. As the delivery and detail of the construction of something moves forward, things become clear that were perhaps not clear when it was initially procured or bid for. Once we got right into the detail, we became clearer about what was required. As a consequence, we adjusted the way that the product was going to be built. For example, we had made a significant time provision for one element around the back-loading of data. I could go into the technical details, but I suspect that you do not have much of a head to hear that technical description.
I do have an interest. You are saying that the contract variation that was put in place after your initial difficulties with the supplier has led to no additional cost and that the system will still be delivered on time. Yet, at the same time, you are saying that time changes have been built in to ensure delivery by September 2016. I am interested in how there can be changes in that timescale from the original contract but you can still meet the operational deadline of September 2016. If you could explain that, it would be extremely useful.
There are two principal areas related to the one that I have just clumsily mentioned, which is data migration.
The original plan was quite complicated. As a consequence of things coming to light and our acquiring a better understanding of the requirement, an alternative approach around a data store—which Hamish Macpherson is largely the architect of—was put forward as a better option. Pursuing that option and just taking a different approach allowed us to save around three months without any detriment.
Secondly—
Could you explain that different approach? Does having a data store mean that the data does not go into the i6 system initially? It would be helpful for us to know, in layman’s terms, what you mean by that.
I shall endeavour to explain it in layman’s terms.
In the original application, the roll-out was predicated on each legacy force having the data from its legacy system migrated at the time of going live. We have moved that forward. Some months ago, we started migrating the data into a thing called the operational data store. All the data within i6 will end up in the operational data store—it is, if you like, a data warehouse for all information that is held by Police Scotland. That information is available to all i6 users through a legacy search button that has been introduced as part of the functionality.
We believe that that is a much better and stronger way of presenting legacy data because it will make that data available not only to i6 users but to the 20 per cent of operational activity that is not covered by i6—for instance, command and control systems. It is not about not doing something; it is about doing it in what we believe is a much stronger and better way.
That sounds a lot more logical than your original proposal. Why was it not decided to move in that direction during the initial stages?
I can answer that swiftly. It is just a matter of timing. When i6 was first contracted for, it was as a national solution for the eight legacy forces. We now have one national force, so it makes much more sense to rationalise all the legacy data into one national data store. That is the reason.
13:30
Thank you for that. We have previously taken an interest in the milestones that you have set out, and again we have some indication of them in the information that we have in front of us today. I note from your letter to the committee, DCC Richardson, talk of “milestone 5B”. As I have said to you guys before, I have some experience of major IT projects, and when numbers start having letters added to them, which usually means new milestones, it has previously indicated to me that there may be some difficulties.
Was there previously no milestone 5B? What is 5B? What was 5A? I take it that there will have been a 5A. Are we likely to see changes to the other milestones, too?
I alluded to the answer to that in my previous answer. The principle so far has been that, unless the milestones are met in their entirety, no payment is made. The milestones usually contain a number of component parts, and this was an example of that. As a programme board, we were faced with a situation where about 80 per cent of the milestone had been completed to a good standard and on time but a small element of it had not.
As I said, elements of that were within our area to resolve. In that single instance, it seemed appropriate—for that and some other reasons—to allow payment for the elements that were complete and a slightly extended time period for the finalisation of the last element. That was agreed and progressed and the final element of the milestone was delivered on time, on message and to a high quality.
In essence, that was a slight diversion from the principle, but the rationale and reasoning were sensible and we were able to address a number of interests by taking that approach rather than a very robust one to, in effect, financially penalise the supplier, which had completed the vast majority of the milestone.
It would be helpful if you could put some timeframes on that. There has been a slight slippage. You are talking about the milestones as well as the content, and it would help the committee if you could put that in context with the dates.
It would also be useful for us to know what those elements were. It is always useful for us to get things into context. What were the difficulties?
Sure. Hamish Macpherson has the details in front of him, so I will invite him—
It would be milestone 4, would it not, where the first slippage was?
No. Milestone 4 stood alone as the training mobilisation plan. Milestone 5 consisted of two main elements. The first was the functional design being complete and the second was the detailed implementation plan.
As Mr Richardson has attested to, the work for the functional design was complete and we were completely happy with it, so we were happy to sign against it, but we still felt at that point that we had some work to do with the detailed implementation plan for Police Scotland in order to feel confident about the testing programme and ensure that we got a robust product when we went live with it, so the decision was to separate the two.
With regard to the date, the initial date of the functional design being complete under the contract variation agreement was 8 August 2014 and it was signed off on 16 October 2014. One month later, at the next board, we were happy to sign off against the detailed implementation plan—that was on 28 November 2014. That was the timing.
As I said, there were two stand-alone elements. They just happened initially to be wrapped up within the same milestone.
Okay. Finally, do you foresee difficulties that might lead to further contract variation or changes to the milestones before i6 goes live and the system becomes operational?
First, let me say that I am very pleased with where we are at the moment. We have managed to complete the design to our satisfaction, which is a major milestone in its own right. The design is directly in line with the principles of retaining the functions and with the terms of the contract, meeting our requirements. That has been completed.
However, the reality is that, for any major programme that runs for a number of years and has the complexities that the i6 programme has, delivery never follows a linear path.
I can tell you that our principles have remained consistent, that we have an end date that has not altered since the contract variation, that our costs remain constant and that the functionality that we expect to be delivered and which was in the business case is exactly what has been designed.
That said, there have been variations along the route, as members know. There has been some slippage and some things have changed in nature. That is the reality of programme delivery.
Now that the design is complete and elements of the engine—to use a mechanical metaphor—have been constructed, we are at the stage of putting those elements together to see whether the engine runs smoothly.
In any such process, there will be issues that we did not expect and adjustments will require to be made. I can say with confidence that I will continue to hold true to the principles to which I have held up to now. However, in all probability there will be things to which we need to adapt and adjust.
I have no reason to think that that will be problematic or will lead to another contract variation, but it would be wrong to give you a sense that, now that we have reached this point, everything will be plain sailing all the way through. That is not the case. This is an incredibly difficult and challenging programme, and I imagine that it will continue to be so. However, at the moment we are in a good place.
I would never expect anyone who is dealing with an information technology contract to tell us that it is plain sailing. I have dealt with a number of IT contracts, and they are never plain sailing.
However, the committee is concerned about further contract variation. There was a contract variation quite early in the programme. It did not cost the public purse any more money—thank God for that. I am keen to know, as I think other members are, whether there is likely to be another contract variation.
I am always rather perplexed that the original tenders in IT contracts sometimes do not seem to allow for the flexibility that is likely to be needed during the construction of the programme.
Do you foresee any contract variation in the near future?
I am not planning for that and I do not envisage an imminent contract variation.
What you said is right. This was an incredibly difficult part of the delivery, and we have rehearsed some of the detail around that, so I will not do so again. It is reasonable to say that the working arrangements with the supplier are in a far better place today than they were earlier.
It is also fair to say that Accenture has been working purposefully with our team to overcome some fairly significant challenges. Indications from the testing phase, even at this early point, are that there are slightly more niggles—however we describe them—than we might have planned for. However, a high number of those issues have been resolved more rapidly than we would have planned for. That underlines that the working relationship between us and the supplier is in a pretty good place.
As you know, I am always guarded about making predictions for the future. These things are incredibly difficult. However, as we stand here right now, I think that we are in a reasonable place and I do not anticipate changes that will lead to contract variation.
You do not have a crystal ball, but I hope that the scrutiny that the committee undertook when you were having problems and the interest that we took in the matter helped to foster those good relations. It is clear that the full business requirements have been built in through a process of working together, so I hope that, if an issue arose in the future, the same arrangements would apply and the same relationship would materialise.
Good afternoon, DCC Richardson. You said that you have successfully designed and built the system and that you have entered the six-month testing phase, which will be followed by a user acceptance testing phase before you go live. Will you give us a bit more detail about exactly what those two phases—particularly the user acceptance testing phase—entail? Do you intend to have parallel running or will a pilot group use the system?
I will hand over to the technical expert to give you more detail. It is an area in which there has been a slight change.
I will try not to get technical.
Testing has gone on for some time. As soon as we started building the product, it immediately went into testing. Most of the early test phases sit with the supplier. The process begins with unit testing, which is the testing of individual components. Those components are then assembled and assembly testing is carried out. We have got through most parts of the assembly testing process.
That is followed by product testing, which again sits with the supplier. It consists of an end-to-end test of the application by the supplier. The change that we have made is that we will be fully involved in the product testing. I will not get technical, but the product testing is broken down into several tranches and we will be heavily involved in what we describe as type 3 product testing, which involves doing end-to-end scenario testing across the product. The reason for our being involved earlier in the process is so that, by the time we get to user acceptance testing, we should have already dealt with most of the bugs in the system. There will be bugs in any system at that stage.
At that point, the user acceptance testing begins. That is a customer activity, so it is carried out by us. For the past number of months, we have been devising various scenarios that are based on real-life policing—scenarios that involve missing people, vulnerable people and various crime and custody events. When we come to do the user acceptance testing, we will simply run those through over the piece. As a result of that process, we hope to have a completely robust product by the time we go live with it. Given the time that we have set aside for the testing, I am absolutely confident that that will be the case.
So the user acceptance tests involve the use of fake scenarios. They will not involve police on the ground using the system.
No. User acceptance testing is always done with dummy data. It will be done in a mirror of the live environment but not with live data.
We will then go to our pilot area. That is when we will start rolling the system out across Scotland. The first roll-out will involve a longer period than the roll-out for the rest of the divisions. It will be carried out in a pilot area to ensure that we have no problems—by that time, we should have very few problems.
Obviously, training needs will be significant. Will you tell us a little bit more about the training strategy and the training needs analysis that you have done?
The training strategy has been developed over a significant period alongside Accenture. Again, it is scenario based, so rather than giving training on the functionality of the application, we approach the training from the point of view of a day in the life of a police officer. Officers will come in and deal with the application as if they were using it on the ground.
A training needs analysis has been done for each of the legacy forces, because there are different IT infrastructures in place and each person has a different knowledge of IT systems. Some had some corporate systems already and some had standalone systems. The training will be tailored to people’s individual needs. There will be bespoke training for police officers and police supervisors and expert training for people who work in areas such as custody, crime management and case management.
13:45
So the people who are testing the system, even at the user testing stage, are very familiar with it. They are the people who designed the system, and your project team who have worked with it. Surely the risky area is when it goes live and real officers start to use it. What contingency is there if the real users identify problems in the system?
I am sorry; I probably failed to articulate that properly. The product testing will absolutely involve the design and work leads for the system. We are testing what the people who designed the system tested. When we get to user acceptance testing, those people are absolutely not involved. Subject matter experts from across each of the areas will test. Therefore, when we test custody, custody officers will do a live custody job, and when we test criminal justice, people who work in a criminal justice scenario will be involved. User acceptance testing involves dummy data, but the real subject matter experts do the testing.
That is helpful. Thank you.
I would like to add to that.
We have talked before about i6 and its significance, but in truth, it really is transformational change in action. Once people have moved beyond the training environment and how to use a new computer system, that changes the way in which they do their business. Our investment around that capability and ensuring that people understand how they need to operate in the new environment is absolutely key.
The process is based on three days’ classroom training. There is pre-course and post-course work, and there will be on-going support for officers. It is a big commitment. There will be a major impact on the organisation—there is no getting away from that—but the system is fundamentally important if we are going to transition to a new way of working with all the benefits that we know that that will deliver.
I would like to clarify something. On page 2 of your letter, you say:
“Milestone 7 which details the approach to the build phase and wider technical architecture was approved … on December 10th. A six month detailed product test phase has commenced and this will be followed by a rigorous user acceptance test”.
In your paper, which is more detailed, you say in paragraph 7:
“There now follows eight months of detailed and diligent testing by both Accenture and Police Scotland”
for milestone 7. Am I reading that properly? Is that a discrepancy?
Can I pick that up, convener? That is the difference between unit testing, assembly testing, product testing and user acceptance testing. The first test relates specifically to product testing; the other relates to the cycle, if that makes sense.
So they are different tests.
Yes. There are all sorts of product testing, but product testing itself is a specific activity.
They are both in milestone 7, but there are just different testing times.
Basically, there is a cycle. The process goes through unit testing into assembly testing and product testing. Milestone 7 is the successful conclusion of product testing, if that makes sense.
That is very helpful.
Governance has clearly been a huge issue with other public sector ICT contracts. I ask you for a general update on governance going forward. It seems that you overcame quite a significant problem quite successfully, and we would not want the eye to be off the ball in any way.
I am happy to give an update.
In essence, I am not sure that we were ever in an atrociously weak position with governance, but it is true that we went through a major change to policing arrangements midway through the delivery of i6. That is the reality. We asked a brand new police authority, which had been newly appointed, to get its head round not just the policing environment, but the technical complexity of a business case that was, it is fair to say, not an easy read. Therefore, there were some challenges.
In my view, the programme governance arrangements were very robust. We have initiated gateway health checks all the way through the process. The comfort around those governance arrangements was articulated very clearly in the reports that we received.
Around the time that we were developing the arrangements with the Scottish Police Authority—Tom McMahon might perhaps comment on this—we initiated a specific, almost thematic, gateway to look at governance. That fed back recommendations that we were able to consider to make the arrangements more robust.
Where we currently stand is significantly in advance of where we were and is right for the stage of the programme that we are at. We have a programme board that involves a number of interested parties, including a number of executive colleagues from Police Scotland and a representative of the Scottish Government who has specialist knowledge. Tom McMahon now sits on the board; prior to that, the accountable officer, John Foley, sat on the board.
The Scottish Police Authority invites papers and we provide updates in a number of areas, including for the finance and investment committee. Tom McMahon might wish to comment on the other areas involved.
Collectively, we have a fairly robust opportunity to deal with detailed programme elements and ensure that they are fed up. We deal with the more strategic issues and decisions through the SPA, which includes regular input provided by me to the SPA on a quarterly basis.
You have mentioned in-house experience, but if a key person were to leave or be unavailable for any reason, is there a contingency plan to ensure that that would not be a real problem or obstacle for governance and timeframes?
Absolutely. Clearly, as you would expect, occasionally individuals are not available. I have a point to make about delivery. Previously, the director of human resources was not a routine member of the board. However, because of the development of the training requirement and the change activities that will necessarily be involved in the delivery of the next stage of the programme, John Gillies became a member towards the tail-end of last year and is now very active on the board in assisting us.
If somebody is not available, their deputy can sit on the board. I am not uncomfortable at all about our resilience from that point of view.
Do you have anything to add, Mr McMahon?
I endorse what the DCC said. I sit on the programme board, so we are well integrated in terms of the internal governance of Police Scotland. Each meeting of our finance and investment committee receives a report on the i6 spend profile. The audit and risk committee monitors the risks and the full board receives updates on i6-related risks. Most recently, we have developed our information and communication technology governance and scrutiny forum, which is chaired by the chief executive of the SPA and involves DCC Richardson, members of his team and the chairs of the finance and audit committees.
That is very reassuring. I thank the panellists for coming. I think that we have had a much better and more upbeat session today than we did when we met previously, and I hope that that is how we will continue in the future.
13:52 Meeting continued in private until 13:54.