NOTAS. FIRMAS DE CONVENIOS DE COOPERACIÓN

5.3.1 Timeline

5.3.2 Overview

Phase 3 covers a relatively short period of time but represents a crucial moment in the development of Hublink. This phase stretches from just after deployment into the production environment and the final tests as described in the previous section, to the moment that Hublink is put fully into production, that is, when consortium partners are expected to use it to record all of their work. The beginning of this phase corresponds to the launch of the consortium on 1 October 2013, and ends with the end of the calendar year 2013. During this phase, staff at Real

Figure 33: Timeline, phase 3

and the consortium partners were asked to start inputting records to Hublink, but also to keep their old system in place. Both the development team and the Real staff thought that a 'soft launch' period would be beneficial to the project. It was important that the application should be used by at least some people as if it was integrated into their everyday work practice but without the pressure of it being the single repository of records. This soft launch can therefore be seen as a 'transition phase' between development and production, in which the application is thoroughly tested, any bugs and serious usage problems ironed out, and generally made ready for its final conditions of use. The term transition phase is here borrowed from the Unified Process model of software development (Kruchten & Philippe 1998) as it accurately describes the work required to move from development to production, including making the application available in its production environment and preparing end users. However in our case there is a major difference, as in this project it is not the last phase of development. In our flexible and and participatory model this phase is not the end of development, but transition into design in use with different patterns of development.

This phase was divided roughly in two. During October and most of November the project was still in test phase, using placeholder content. On 28th _{November all test content was deleted and} all consortium partners were invited to start record keeping on Hublink. In this busy and sometimes stressful phase, the knowledge and trust that had been built up through the PD process became an important resource, enabling the team to identify issues clearly and problem- solve together. Notably, evidence shows that the design work we did together in earlier phases facilitated the Real team in taking full ownership and responsibility for the training and documentation for the other community partners. Indeed one of the most remarkable features of this phase was the emergence of the consortium's project co-ordinator as a leading user who

Figure 34: Issues open during the transition phase

increasingly took on a role of mediating and requesting changes and refinements from her own knowledge and from her team, and carrying out the adoption tasks – training and documentation – needed to get ready for Hublink's launch as the consortium's main infrastructure. (Textbox 21). The project co-ordinators emerging role resembles the 'gardener' role described by Nardi (Gantt & Nardi 1992), especially in the way that she emerged as a specialist from her role as a domain expert rather than through any special recruitment process or plan. I have referred to her as a leading user to distinguish from Von Hippel's notion of a 'lead user' (Hippel 1988) in which lead users are identified and instrumentalised to drive innovation. In contrast, the gardener role can be more emergent and focussed toward facilitating the needs of peers in everyday work. This therefore better describes our situation.

5.3.3 Refinement

The design and testing phase had built up a small number of users who were already familiar with Hublink and also knew the developers. These were an ideal group to be the core users in this soft launch phase. On one hand they would be likely to know the expected behaviour of the system and on the other, through the previous face to face contact with developers, there was a good relationship in place that would help communication. Individuals from this group also had a key role in mediating questions from the consortium partners who gradually started to enter their data on Hublink. They therefore could be said to be forming the beginning of a community of practice (Wenger 1998), based on the experiential learning (Kolb 1939- 1984), gained through the PD process (Bratteteig et al. 2012).

I feel that Cathie has had the most input, and the most input in making it real for people who are going to use it. We are very conceptual and I think Cathie has made it what people can actually get on with and use and understand.

Karen Linnane 13 mar 2014

Textbox 21: Reflection on leading user role in the transition phase

Though this was a busy stage, the minority of development work was on new features. Most of the work was on refining the features that were in place to make them fully fit for purpose. This included refinements in the infrastructure and security features such as mandatory password complexity and rotation and automated logout. The workflow and group allocation features were also double-checked and refined where necessary. A number of usability improvements were needed, including quite a number of tweaks to tools that are heavily used by frontline workers such as the dashboard (see Textbox 22 for an example on how this developed at this stage) and the client search facility. An expanded amount of error handling to encompass more error conditions was also included.

In a work-based application such as this visual design plays just one part of many in making the application usable. As Neilsen (1997) points out, text elements such as field and button labels are key to making an application navigable and learnable by users. By this transition phase, the emerging leading user, the project co-ordinator of the consortium based at Real, began to take on this kind of work herself; instead of asking developers to to these tasks, she began to ask how she could do them herself. Drupal, with its web-based configuration is able to facilitate this kind of customisation via its web front-end (For example, Figure 35 ). As discussed in more detail later, evidence shows that her ability and willingness to do these tasks was a direct result of the PD process.

Hi Lisa,

You asked me to let you know what I need to see on the dashboard. Karen and Mike, please feel free to add your comments/additions. As discussed, filters would be needed to manage this. The primary filter needs to be the

organisation with the following secondary filters in date order (most recent first):

-number of open enquiries / projects

-unallocated referrals (by internal service for Real i.e. IAA or ILS)

-allocated referrals

-whether casework has commenced on an allocated referral

-key dates and critical dates -referral follow-up dates

Thank you for yesterday, it was really helpful. It's great to see the database evolving.

Best wishes and enjoy your holiday.

Textbox 22: email about the dashboard from the project coordinator during transition phase

Figure 35: Documentation on how to change the input form for projects. Other content types configuration are similar