Medidas de Liquidez utilizadas en éste Estudio

Our study was designed to evaluate the following hypothesis: ‘structural- intentional responsibility analysis enables the identification of stakeholder

and their interactions. Secondly we were able to make specific recommendations to ameliorate the deployment.

7.5.1 Recommendations

The recommendations we made comprised a six-step plan to address the vicious circles identified. Each individual recommendation can be described as codified commonsense. The value of the plan came from the fact that the combination of recommendations we made was tailored to the specific dynamics of the deployment environment.

We proposed that our recommendations could be implemented in the following manner:

1. -Identify a minimal set of practices for EDM use that programme

management and engineering management have firm grounds to believe are valuable to Company A (taking into account short term vs. long term tradeoffs).

-Assign ownership of domestication to a high level manager(s) within Company A

2. -Create a network of EDM evangelists with members from each discipline / functional unit

-Create a EDM steering committee with members representing the interests of programme management, engineering management, IT and other legitimate stakeholders.

3. -Support the EDM evangelists to create role specific resources that can be used to facilitate the use of EDM according to the set of practices intended by management

-Actively inform end-user of EDM steering committee and its role in improving the tool

4. -Actively inform end-users of the strategic value of EDM and the mandatory practices

-Actively inform end-users of the role specific feature of EDM and how the mandatory practices will change there existing work practices 5. -Roll out mandatory practices

6. -Audit practices in use to ensure they are in accordance with mandatory practices

These recommendations were derived from identifying approaches for dealing with each of the issues identified by structural-intentional responsibility analysis. For instance to break the culture of programmes exempting themselves from EDM usage, the use of EDM should be made mandatory for specific practices that programme management and engineering management have identified, on a firm basis, as valuable to Company A. These practices should be clearly prescribed, perhaps as a set of programme data management practices, and audited for compliance to signal that exemption from these is not a cultural norm. We believe that the implementation of this change should be coordinated with the programme

management community in order to minimise the potential for conflict due to possible tactical/strategic differences in priorities.

To address the domestication issue we suggested that management should take on ownership of the responsibility for EDM’s domestication and in doing so create appropriate institutional structures and resources to support its occurrence.

1. Staff should be activelyinformed of the value-adding features of EDM for their specific work activity.

Staff should be shown what previous practices/tools EDM replaces and what new practices/responsibilities it creates and how it contributes value to Company A. This should not be mistaken for merely informing user of the system’s functionality. Staff should also be informed on an ongoing basis rather than as one off training to reinforce the importance of the systems use. Sending email reminders, creating posters, distributing ‘cheat sheets’ are all appropriate means of enacting an ongoing basis.

2. Institutional structures should be created to enable the coordinated

adaptation of EDM.

A formal structure should be in place for staff to raise usability issues and have the case considered for a possible adaptation to EDM. The creation of an EDM steering group that represents the interests of EDM users and other stakeholders across the site could enable this. A typical steering group would have representatives from a broad range of functional units including users, managers and IT representatives, and would have the authority to make change requests with respect to EDM on behalf of the site.

3. Institutional structures should be created to nurture/support an EDM community of practice so that best practices and advice can be shared. Specially selected members of each discipline, or functional unit, should be empowered by giving them ownership of the task of evangelising their local community to follow EDM best practice. The EDM evangelist’s role would be to a) share/nurture/support best practice and b) learn from the experiences of their colleagues from across disciplines/functional units. This network of EDM evangelists could be supported by the creation a homepage/wiki containing resources to support their task by providing role specific ‘cheat sheets’, how-to guides, and best practice guidelines.

To address the issue of salience of features effort should be put into fostering a shared view of tool features. To achieve this we suggested that staff should be actively informed, or reminded, of the strategic organisational need for capabilities that EDM offers. This can be implemented by top down managerial communication and reinforced by a network of local EDM evangelists.

To address the practice culture we suggested that exemptions from standard practices should be very carefully controlled to ensure that: i) they are necessary; ii) process improvement can take place to ensure that over time exemptions become the exception rather than the norm. This can be implemented by auditing the use of EDM, enforcing standard practice where appropriate, and highlighting opportunities for process improvement to appropriate parties e.g. process improvements or EDM steering group.

7.5.2 Reflections on the Use of Structural-Intentional Responsibility Modelling

Structural-intentional responsibility models provided an appropriate means of understanding the relationships between responsibilities, objectives and outcomes. Responsibility models provided an important means of concisely representing the insights gathered using issue maps of interview transcriptions. Their most important contribution is to bring to the foreground the relationships between issues so that their interconnections may be understood. A limitation of this approach was however observed. When the number of entities (responsibilities, objectives, outcomes) or relations became large the diagrams became cluttered and were no longer as helpful in articulating the situation. This limitation is addressed in the next chapter via means of representing the models as a directed graph and using a large-scale network analysis and visualisation package (Gephi.org) to represent the graph in a user-friendly manner.

In comparison to a task centred analysis approaches (such as I*) we believe that, despite the above-described limitations, structural-intentional responsibility analysis offers a number of useful tradeoffs. Firstly data collection can be of a shorter duration as a detailed understanding of tasks is not required and thus avoids time-consuming ethnography or process mapping. Secondly, the scale of the deployment under analysis can be much larger as data collection is rapid and data analysis can be supported through the use of off-the-shelf digraph visualisation and analysis tools that support large datasets. It remains an open research question if task centric approaches such as I* models can scale up to analyse large-scale systems (E. Yu et al., 2011).

The disadvantages of a structural-intentional approach, in contrast to a task centric approach, is that it will not deliver insights with respect to the subtleties of task level interactions within a work environment e.g. distributed coordination, awareness, spatial and temporal organisation and so on. Nor does structural- intentional analysis enable modelling at the task level so it does not represent how actors and resources are configured at a task level.

Despite these shortcomings, we believe that this trade-off is desirable as it makes structural-intentional analysis complementary to established task/activity centric analyses that inform information systems development. For example when time permits ethnography, we expect structural-intentional analysis to provide complementary findings.