Timescales

The construct of timescales was fed back in two ways. First the unforeseen benefit of the information sharing system in saving time. One partner in particular identified the system as saving them as much as two hours a day in writing emails to partner agencies. Secondly the time taken to implement the project and reach decisions. Overly long implementation timelines meant that at times work was obsolete or had minimal benefit by the time it was implemented. For example at two agencies interfaces were still not live when the feedback was gathered. In the absence of interfaces the agencies had found workarounds to negate the issue of missing data on the system. As such they felt by the time the interfaces were delivered they would have little benefit to their agency, though benefit could potentially be gained for partner agencies on the system having wider access to information.

7.2.1.3 Co-location

The biggest factor which respondents felt was missing from the framework was the aspect of colocation. In addition to Sentinel as a technical solution some councils had implemented co-location of officers at least on a part time basis. Two councils had built new premises during the time of implementing Sentinel. Whilst designing the new buildings the councils designed areas where partners could come to work. These areas were designed to be used at any time for partners not just when partners were required to visit the council. This had the benefit of increasing interactions between police and council officers. This is backed by the literature which highlights the importance of relationships and social interactions for information sharing. Areas which implemented colocation felt this had benefited partnership working more so than any other initiative taken to improve partnership working. Areas which had not yet implemented any co-location seeing the success of co-location are now looking at ways to implement co-location.

7.2.1.4 Standardised Processes

The construct of partnership-wide standardised processes was reported in feedback from partners in conflicting ways. Some partners felt the partnership was too prescriptive, telling agencies exactly what and how they should be recording on Sentinel. The agencies who felt the partnership were overly prescriptive

also fell in to the category of agencies which displayed fewer characteristics of being bought in to the project. As such these comments were included with the construct of buy in and decision making.

Others agencies felt that a lack of consistency in recording processes meant it was difficult to accurately understand information. This had been a consideration in earlier development of the framework. It was not included due to the researcher feeling standardised processes were appropriately covered in other constructs. For example if all partners are equally bought in to the aim of the information sharing project; in this project the need to record 100% of ASB information on a single system standardised processes will be achieved through the need to achieve the project’s goal. In addition sufficient communication between the partners can negate misunderstandings due to differences in processes. For example the definition of an ASB incident does vary slightly between the partners. By communicating and discussing the various partners definitions other partners are able to understand what incidents are classed as ASB at other partner agencies. 7.2.1.5 Transparency/Responsibilities

The construct of resourcing was already present in the model but this was further highlighted in the feedback summarised in one particular statement “there were a lot of meetings and time required to implement the project especially compared to other work we had on” (Sentinel Project Partner, 2014). Further discussion highlighted that on initiating the project most of the partners were unaware of the level of resources they would need to commit in order to implement the system. On a similar theme another partner felt that in early stages of the project they were unaware what their role and responsibilities were towards the project. They were provided with “strategic goals rather than practical details” (Sentinel Project Partner B, 2014). The partners at times felt ill equipped to make decisions which would impact the project due to a lack of understanding their responsibilities. For example the project members were asked to input into processes regarding the administration process without having seen or experienced the technical details of administering the system. The public sector are pushing for greater transparency to the public, but this seems to sum up the requirement for transparency to the project around resourcing and responsibilities for each partner.

7.2.2 Validated Constructs

The feedback gathered suggested some strong agreements with particular constructs. These are detailed below.

7.2.2.1 Security Restrictions

Feedback highlighted how security restrictions put in place early in the project impacted the partner’s ability to share information. One partner in particular felt that the security procedures “put the focus on not sharing

reason not to” (Sentinel Partner C, 2014). The security construct in the framework presented to the partners highlights the need for security. It is key that partners with a low risk appetite do not cause the information sharing system to become so restricted that benefits are not gained as appropriate information is not shared. Utilising bureaucratic processes such as sharing agreements and proper research of the legislation can help negate these issues.

7.2.2.2 Communication

Some of the partners felt that the information sharing had “promised a lot, but hasn’t delivered” (Sentinel Partner D, 2014). This helps to validate the communication construct. Communication helps manage expectations of those in the project. This is key as when expectations are not met trust can be lost. Trust is a key requirement for sharing information between partners. It is visible in multiple constructs in the framework e.g. Reputation Management, Security and Relationships.