Lessonslearnedfinal

WATERLOO REGIONAL POLICE FORCE COMMON INFORMATION MANAGEMENT SYSTEM LESSONS LEARNED

By Domitille Biehlmann, Timothée Bommelaer, Camille Favreau, Caroline Forestell, Alexandra Isabel, Vivian Tsang

TABLE OF CONTENTS LESSONS LEARNED

1.

2.

3.

4.

Purpose of the Lessons Learned Report.....................1 Project Overview............................................................1 Executive Summary........................................................1 Lessons Learned.............................................................5

1. PURPOSE OF THE LESSONS LEARNED REPORT Throughout the CIMS project many challenges were encountered, and as a result many lessons were also learned. This report regroups all the lessons learned as formulated by project team members and stakeholders. As such, the knowledge gathered here will be useful in better planning, implementing, managing and monitoring future projects. For example, this document can benefit future projects by helping teams diagnose the same challenges ahead of time, and hence prevent them from re-occurring. Additionally, it can also be used to give advice on how to identify the root cause of current issues and further apply the learnings of the CIMS team.

2. PROJECT OVERVIEW The Common Information Management Systems (CIMS) project was undertaken by multiple Police Regional Services in the Golden Horseshoe area, in Ontario. Members included the Waterloo, Hamilton-Wentworth, Niagara, Halton, Peel, York and Durham regions. The goal of this project is to provide a fully integrated system accessible from mobile stations, that would support crime analysis procedures for proactive actions by facilitating information sharing between the mentioned regional police services.

The CIMS includes five basic functions: computer aided dispatch (CAD), a records management system (RMS), mapping, mobile workstation environments and the Canadian Police Information Centre (CIPC) module. The work was contracted to Information Technologies Group (ITG), a US-based leading provider of integrated public safety and criminal justice systems.

3. EXECUTIVE SUMMARY This report consists of the project’s main success factors, primary challenges and top recommendations. The main success factors were the project sponsors, diverse project team and experienced vendor. However, as mentioned, the project ran into many issues, the primary challenges being project communication, vendor management, and project planning. We further discussed these primary challenges in the lessons learned in addition to project planning, time management, change control, project communications, and vendor management. These lessons are addressed in terms of problem summary, impact on the project, and recommendations for future projects.

1

3. 1 SUCCESS FACTORS

3.1.1 STRONG PROJECT SPONSORS >

Chief Gravill is the Waterloo Region chief of police and has an excellent academic record and has received several awards for his outstanding work. He is also experienced with IT projects as he led the successful PRIDE computer system project. Given his high authority and strong background he was well positioned to authorize the major decisions that the CIMS project required as well as understand the many complications that arise in IT projects, hence was a very strong sponsor for the project.

3.1.2 DIVERSE PROJECT TEAM >

The CIMS core project team had representatives from all regional police services to ensure that each office was equally represented. Additionally, a year of background work was done with all the involved agencies to establish the overall blueprint for the system. Throughout the project the police offices were well involved and their everyone’s input was strongly considered.

3.1.3 CONTRACTOR WITH EXPERTISE IN POLICE WORK >

2

ITG has worked with the WRPS before, and successfully addressed issues like Canadianization on previous projects. It is a leader in providing integrated public safety and criminal justice systems in the US, describes itself as customercentric and has a global presence and many strategic partnerships that allow it to offer high quality solutions.

3.2 PRIMARY CHALLENGES Project Communication

Lack of communication and trust The communication between the two parties came to a full halt in February 2000. All key stakeholders had to meet for the project to resume, and even after this, issues arose again in the following months. There was still communication between the two parties, but a complete lack of trust.

Vendor Management

Lack of proper vendor alternative evaluation The first Request For Proposal (RFP) outlining the work that had to be done on the project did not succeed in identifying any vendor for the project. Therefore, it had to be reworked entirely and made less stringent. Despite all the work done to loosen the requirements, only one vendor, ITG, felt it was up to the task. The agencies, pressed by time, agreed for ITG to be the contractor Project Planning

Ill-defined scope of work The agencies did not take the time to properly define the scope of work. This led to two problems. The first and major issue is the Canadianization of the software. The second issue was with the specific vocabulary and law-related terms.

Lack of detailed guiding principles in the project charter The guiding principles had not been clearly laid out, and a committee approach to reach consensus between the agencies and ITG was not adopted. Detailed principles on how accountability is enforced were not established. This contributed to the breakdown of communication and lack of trust.

3

3.3 TOP RECOMMENDATIONS

We recommend Chief Gravill to keep the CIMS project alive because its objectives are needed in the police forces for optimal operational efficiency and to improve the Golden Horseshoe’s population’s well being. In the future, for significant and large police information systems project, we suggest the project team to break down the project comprising of multiple components, into smaller projects where each project would tackle one component and follow the lessons learned laid out later in this report. However, the CIMS team is now legally bound by a fixed-contract with ITG, so Chief Gravill must continue with the project and we suggest to add an incentive for the vendor in the contract to complete the project within the agreed upon timeline, if not earlier.

Better requirements enunciation The expectations for the project were not properly formulated. Writing down in detail the specifics and the depth of work required from the vendor will help future projects. In particular, the Canadianization should have been put first in the software, and the scope of ITG’s expected work (hardware and software integration) was much too important to be left out. Future projects should state very clearly what they want the vendor to deliver. Additionally, we recommend dividing up the five scope items of the project into a small project each. This way, each of them can be outsourced to a different vendor. The reduced size means less stringent requirements each time, which translates in more vendor willing to participate, as well as the possibility for CIMS to play the competition off of each other. Finally, not having to rely on a single vendor eliminates the possibility of the project completely failing.

Careful vendor evaluation The first RFP that the CIMS project teams could come up with was too strict, and not a single vendor fit the requirements. So when the second RFP only got an answer from ITG, pressed by time, the CIMS team gave it a go. Realistically, another RFP should have been prepared, to get a choice between at least two different vendors and be able to compare the proposed solutions. This could also have been used to negotiate the price or the terms to CIMS’ advantage.

Relationship-building and constant communication Once the two aforementioned points have been addressed, most of the problems the CIMS project ran into should disappear or settle. However, to ensure the best possible experience and for future projects to be as successful as possible, putting emphasis on building good relations with the vendor. Accenture recommends as a best practice to “Hire a Partner, Not Just a Provider”. In addition to this, ongoing and efficient communication will help cultivate the relationship and ensure all parties have their expectations heard and respected.

4

4. LESSONS LEARNED This part addresses directly the lessons learned during the CIMS project.

The following headings are divided by project management areas and include a description of the problem or success, its effect on the project and recommendations for this project as well as for future similar projects.

PROJECT PLANNING Problem Description The main purpose of project planning is to guide execution however during the project the CIMS team and ITG did not agree on the interpretation of requirements. More specifically, the CIMS team paid $200,000 on Canadianization without ITG understanding what was required.

The major issues lied in the Canadianization of the CIMS systems, the CIMS team did not write specifically on the Request for Proposal (RFP) and Functional Design Specification (FDS) document what the Canadianization entailed in terms of what they wanted to see in the system, because they assumed that ITG already knew this from a past upgrade project in the existing PRIDE system done seven years earlier in 1993/1994 done with the Golden Horseshoe police services.

What was meant by the CIMS team was that the CPIC interface needs to be fully integrated for the system to be Canadianized, meaning the rollover from the RMS into the CPIC database should have been fully integrated -- all software functionality should have been fully integrated to complete this task. But for the vendor, ITG, it only meant only specific hardware integration.

Impact on Project This conflicting interpretation of requirements resulted in 200 issues in dispute regarding the FDS with respect to the CAD module, 60 issues in the RMS, and issues with the entire CPIC. This caused ITG’s stance on Canadianization integration being specifically hardware integration, while the CIMS project intended Canadianization to be both hardware and software integration. These conflicting stances resulted in a project stand still as well as further conflicts with the project.

The scope of the CIMS project was thus unable to meet the individual needs of each region. As a result, Metro Toronto and the OPP pulled out of the project to design and implement systems that better met their needs, making the CIMS project less effective already.

Recommendations for Future Projects In hindsight, this issue could have easily been avoided through a more collaborative and thorough project planning. More specifically, the project team should explicitly state in a detailed manner critical project objectives instead of implicitly implying them. During the aplanning stages of the project both the vendor and team should hold a workshop where each agency’s goals, objectives and deal breakers are clearly outlined hence ensuring that there is a mutual agreement on the project’s requirements.

Specifically, when a system requires Canadianization, the project team should actually write on the Functional Design Specifications (FDS) what they mean (aka specific vocabulary hard-coded into the system or having the integrated rollover from the RMS into the CPIC database to complete the Canadianization requirement).

5

PROJECT COMMUNICATION Problem Description The problem described in the project planning part is similar in project communication. The project plan did not specify in detail what the agencies expected from ITG, and this can be interpreted as a communication failure. The agencies assumed ITG would do the Canadianization work on their own, without thinking about asking the vendor at any moment if they planned on it.

in advance, and clearly state the team’s expectations that the vendor should solely use jargon from this dictionary.

From the very beginning dialogue should be encouraged between the two parties: the project manager and team should set the tone to engage all stakeholders to take part and should accept all communication channels: meetings, emails, texts, etc.

Meetings should be scheduled on a regular basis.

If necessary, the team should reiterate several times during each project phase, Impact on Project and ask the vendor to clearly state their The dispute over what Canadianization understanding and check if there is any meant created tension between project discrepancy between the two and adjust team and supplier, which resulted in a se- accordingly. vere lack of trust between team. It escalated in complete communication breakdown during February 2000, and to the VENDOR MANAGEMENT point where the breakdown lasted until Problem Description July 2000 and the project was nearly fail- Since ITG was the only vendor capable to ing. answer the CIMS team’s second and less These misunderstandings and break- demanding RFP, this puts the police serdowns put the project in jeopardy and re- vices at a disadvantage: they have a lower sulted in additional time, effort and money bargaining power since ITG knows it was spent to turn the project around (by hav- the only one in the market willing to aning the CIMS team meet with ITG in the swer these systems integration requireUnited States, for example), which could ments. have been avoided from the beginning.

Even after getting a payment of $200,000 for the Canadianization, ITG is waiting for the complete commitment with the sign Recommendations for Future Projects off on the FDS before assigning resources Teams should first avoid making assump- to the project and writing code, while the tions on what another party might un- CIMS team wants to make sure that ITG derstand in the dialogue. Instead, project understands exactly what is meant in the managers should be proactive and state FDS by reviewing in detail all the changes explicitly in written form when they are to this document. looking for a specific feature or jargon to Instead of being proactive, the project be used by the vendor. While the FDS was team and ITG were very reactive throughdetailed, teams should leave no room to out the life of the CIMS project. They did ambiguity, because these miscommunica- not work closely enough by having regular tion issues could have been avoided by ex- meetings with the vendor, which created a plicitly being stated them in written form. myriad of disputes over countless issues.

Thus, in the future, since police services The project teams of each region only met are legally bound to use a certain jargon, constantly with the vendor and regional a dictionary should be sent to all suppliers police chiefs after problems have ignited to ensure they have the right information in order to resolve the issues.

6

Impact on Project The latent lack of willingness to collaborate between ITG and the CIMS team has slowed down the project sign-off date and has resulted in unnecessary costs (time involvement of higherups in discussions in the US). This lack of collaboration is most prominent when looking at ITG sending PDF files instead of MS Word files to slow down the CIMS team who wants to compare the changes between FDS documents.

Since there were no regular meetings with the vendor constantly throughout the life of the project, problems kept reoccurring. For instance, there was constant dispute over the key deliverables between the project teams and vendor. Once problems have already arose, it requires a lot more time and effort to resolve the issues, which hinders time management making the project more prone to delays.

Therefore, the project teams should have established regular meetings with the vendor to ensure that both parties understand and agree with the common goal and objectives of the project in order to prevent running into problems that can be avoided, which would be more time-efficient. Because of the significantly poor time management of the project, it created the possibility for Hamilton to pull out of the project if any delays happen, as this police could simply not afford any major phase of the go-live day to be postponed.

Finally, whenever a project requires regional specific adjustments, the project team should ensure to choose a vendor already operating locally or who is familiar enough to provide localization services, and who understands the degree of localization involved to fill the region-specific requirements and explicitly agree to carry out the activities to work towards this adjustment.

CHANGE CONTROL Problem Description Changes are inevitable on most projects so it is important to develop and follow a process to monitor and control them. Yet, at one point in the project, there were 200 issues regarding the FDS with respect to the CAD module, 60 issues with the RMS and all of CPIC was an issue with ITG. The project team and ITG met to solve these issues, and the number dropped to 30 unresolved ones. Thus, there were changes agreed upon between the CIMS team and ITG to decrease the number of issues. However, no change control process had been agreed upon, and the project got stuck again as seen in the communication breakdown between the two parties.

Impact on Project Without having the proper change controls in place, there was no structured process on how to evaluate and approve changes. As a result, modifications to resolve issues and improve Recommendations for Future Projects vendor relations were made without further To avoid such situation, the project team should repercussions being evaluated. A structure on first agree clearly on what the performance how to carry out changes during the project bond (including the requirements and the would allow changes to go more smoothly. completion criteria for approval) will be between the project team and its vendor, in or- Recommendations for Future Projects der to use it as an insurance.

Throughout a project there is constant comIn addition, the project team could have re- munication and negotiation. As a result, quired ITG to create a prototype before pay- teams should plan for change instead of striving the first down-payment before signing off ing to do exactly what was planned. In future to ensure all completion criteria are approved. projects, a change control system should be Further, the project team could also look into made. It is a formal, documented process that vendors willing to work with the agile devel- describes who is authorized to make changes opment framework to ensure the client is in- and how to make them. This will result in a volved in the development and can give feed- more structured way of making changes to back early on before too many disagreements ensure that changes are not overlooked and over requirements arise. well communicated

7

TIME MANAGEMENT Problem Description The project team did not manage the time effectively. They spent a long time comparing versions of FDS documents with previous versions of the same document due to a lack of trust between the project team and the vendor. Hence, a lot of time and efforts have been spent on tasks that did not require as much attention that what they have allocated.

Impact on Project Because the agencies worked very independently yet the project required their joint efforts consistently, the police regions did not understand the goals, objectives and specific needs of one another. Hence, it has been two years since their contract sign-off on August 19, 1999, and yet they are still stuck at the fourth major milestone of the project, namely the approval of functional design specifications for CAD and RMS. As a result of poor schedule management, the project team had to work weekends and evenings to review and turnaround documents in order to meet the predetermined deadlines. Time was thus not managed effectively as this resource could have been allocated to other more significant tasks.

Recommendations for Future Projects Poor time management and the independent delivery approach towards the CIMS project made project management less effective, and led some regional agencies to pull out of the project.

Hence, adopting more realistic timelines could save future projects from this kind of time overrun. What’s more, creating smaller, more frequent milestones at regular intervals will help give a better sense of progress throughout the project, as well as give at any given time a better idea of where the project stands.

8

PEOPLE AND THEIR ROLES Success description The project was spearheaded by a strong project sponsor, Chief Gravill, with experience in similar project and the will to make this project a success. If anything, his personal achievements showed that how much of an outstanding individual he was. What’s more, the project team included numerous members from various regional police services and originally was led by a project manager appointed by the Royal Canadian Mounted Police (RCMP).

Impact on Project Chief Gravill had already led a similar project to success, and having such a driven individual leading the project is probably one of the only reason that despite all the problems encountered on the way, the project was still active and could be saved. Additionally, the early implication of the RCMP showed that the project was supported by the ‘top management’ of the Canadian police, and executive buy-in is paramount to a project’s success.

Finally, the team of workers coming from all the concerned regional police services showed the will of each of the agencies to be actively implicated in the process and to make a success out of the CIMS Recommendations for Future Projects Strong support from both regional and federal police services, an experienced and motivated project sponsor and a diverse team kept the otherwise failing project together. This goes to show the importance of people and selecting the right individuals as a success criteria for a project.

PRIMARY CHALLENGES, AND THE TOP RECOMMENDATIONS Takeaways:

Primary Challenges of the CIMS project:

Lack of communication and trust

Lack of proper vendor alternative evaluation

Ill-defined scope of work Top Recommendations from the CIMS project Lessons Learned:

Better requirements enunciation

Careful vendor evaluation

Relationship-building and constant communication

9