After iterations – groups and content visibility

The end of the iterative design cycles were by no means the end of engagement between the development team and Real. If anything, engagement and communication accelerated in the period following the final iteration and ending with the deployment of the system into

production. This work was particularly focussed on refining workflow, groups and permissions. This work needed to be informed by detail on how a case progresses through the stages of initial

Figure 27: Workers' dashboard showing action dates

referral, allocation to a caseworker, action and closure. This process may occur within a single organisation, but in consortium working a case may also be referred between organisations. Dovetailing with these workflow rules (see Figure 28), mechanisms also needed to be established that would determine the visibility of personal data within and between organisations. It was thought not to be appropriate to rely on individual workers applying workflow state and visibility rules as this would be onerous and error-prone. Instead, our aim was that these should be allocated by the system programmatically according to well specified criteria and rules.

The clarification of these criteria was my next task. The problem was well expressed in our preliminary discussions around the need for different teams at Real for advice and advocacy, even though they are in the same organisation. This need was described to us by staff at Real as a need for an 'ethical wall', and was given detail by invoking a scenario. In this scenario, an advocate, whose job it is to support people with disabilities to express their views, may be helping a client challenge the work of a Support worker who also worked for Real, but in a different team in the organisation. Through this simple scenario the need for control over the visibility of data between groups in the consortium was made clear.

One of the biggest challenges in the move to consortium working is the extension of the issue illustrated by this scenario to information sharing between organisations. The system needed to both facilitate the desired degree of joined up working between organisations, while still giving choices to both organisations and individuals about how data is shared.

Figure 28: workflow summary for iteration 3

This discussion around data sharing went to a new, higher level of detail than the previous iterations. Though unlike the earlier stages, they took place through informal means; emails and telephone calls and some smaller meetings. The discussion was difficult especially as, as has already been noted, the consortium had not yet started meeting or working together. Several different methods to analyse the needs and turn them into rules were tried out by Real and the development team. I made several attempts at using visual means to approach this task and in the meantime, quite independently, staff at Real were also working creatively as a group to understand and tackle the problem. Figure 29 is a diagram produced by Real staff at their own meeting to express and systematise their thinking around visibility of records between groups, in which once again they used scenarios and visual communication, but in this case

independently of the development team.

After much discussion and testing, the Drupal suite of modules 'Organic Groups' was found to be able to meet the requirements adequately. As shown later in the project, this set of tools proved extremely valuable to the project later because of their reconfigurability. This reconfigurability meant that later on, the application was able to incorporate changes as a greater depth of understanding of differences between the organisations was reached as they came more engaged with the consortium. The Organic groups module was complemented by a custom module that interacted with the workflow to automatically assign a new project or enquiry to the appropriate group. This technique uses the full potential of the extensibility and generativity in the architecture of many FLOSS projects (Alspaugh & Scacchi 2013; Capiluppi et al. 2012).

Figure 29: Permissions diagram produced by Real team

A key organisational milestone occurred near the end of this phase with a meeting, on 13th September, when Hublink was presented to all of the consortium partners for the first time. The whole development team: Paula, Kate and myself were invited to attend. As well as make a short presentation I adapted some of the scripts to allow the partners to try the application for themselves. This was a key moment in the acceptance of Hublink by both Real and the partner organisations as their shared infrastructure.

On October 17th _{a technical milestone was reached when I installed the application onto the} production server. This marked the end of the main development phase and transitioned the project into its “soft launch”. Hublink's permanent home was to be on a server managed by a commercial company who are a strong user and supporter of Open Source solutions. This company were to be responsible for backups, server level security and ongoing server maintenance. The contract with Bytemark was with Real and Fossbox, as manager of the project from the technical side, was keen that they should take ownership of this relationship. To that end, I did the installation work on-site at Real together with the Operations Manager who was to take charge of this relationship. Doing this work together was motivated by our priority to transfer ownership and control to the community partner, as emphasised by researchers in CI, for instance Merkel et al. (2005) and Gurstein (1997). Meanwhile the capacity to do so illustrates the point by Burt and Taylor (2001) that effective deployment of IT systems in VSO's is highly dependent on the presence of staff with the correct expertise. Compliance with data protection legislation was specified and overseen by the Operations Manager and included features such as forced password rotation for users, forced logout, a strong firewall and encrypted connection with the server (SSL). This part of the process also surfaces the important point that even if a solution is based on FLOSS, it is not ever free of cost as there always needs to be infrastructure in place to run the system.

Figure 30: Project view in iteration 3

With the resolution of the groups and workflow issues and the acceptance of the system, at least in broad terms, by the project partners, , the main body of the design and development process was concluded. However, in our case, this was by no means the actual end of design. After the reflections on this phase, we move on to phase 3 in which the system transitioned from design into use.