Quantcast
Channel: Assemblies » SLAP
Viewing all articles
Browse latest Browse all 2

MEAoT at the BRII Assembly

0
0

Introduction

Modular E-Administration of Teaching (MEAoT) is a JISC-funded project in the Institutional Innovation programme, run as a joint venture between the Centre for Applied Research in Educational Technologies (CARET) and the departments of Engineering and Physics, at the University of Cambridge. The BRII project hosted an assembly in Oxford on 9 June 2009 to discuss issues surrounding stakeholder engagement and buy-in.

The development of the TODB module within the MEAoT has had a large stakeholder engagement component, a discussion of which was presented at the assembly by Matthew Jones (CARET/Engineering). The stakeholder engagement (SE) experiences of five other projects from institutions across the UK were also presented, and this made for interesting and informative discussion. Many of the insights and experiences presented were interesting; some of these are more directly relevant to the MEAoT project. It is hoped that some of the techniques described and discussed can be successfully applied for the remainder of this project. A number of themes have been highlighted and are briefly discussed below.

The MEAoT project objectives

The objectives of the MEAoT project involve the development and deployment of two software modules, one for the allocation of teaching tasks (the Teaching Office Database or ‘TODB’) and the other for facilitating more streamlined exam entry. The assembly presentation and discussion was limited to only the TODB, as work on this module has involved stakeholder engagement at several levels and so was considered to be an appropriate choice.

Another objective of the project is to evaluate a software development model that interleaves stakeholder-specific software implementation with stakeholder adoption; that is, early versions of the software are used and ‘broken’ by stakeholders, whose experiences can then underpin and direct ongoing software features. This model obviously requires stakeholder buy-in at an early stage; it may also lead directly to increased levels of adoption, as users have been a part of the software development process.

Prototype software version: TODB

The TODB is a software system for managing teaching duty allocations. SE initially involved meeting people in six departments at the University of Cambridge and discussing how teaching ‘works’ at each of those departments, with a view to developing/customising a software module ideally suited to each department. Each department was presented with an early version of the software (that had been developed specifically for the Engineering department prior to the start of the project). Having this prototype system to engage with and (if necessary) criticise gave a concrete instantiation to what would have been otherwise fairly abstract concepts. This was an enormous help when engaging with stakeholders, to the extent that this is highly recommended as a general software development approach.

In project situations where the development of a ‘complete’ software prototype is impractical prior to ‘real’ stakeholder engagement, this approach can still be used by breaking the complete system into smaller independent units. Each of these can then be developed as a prototype and presented discretely to stakeholders to start an engagement process relating only to that unit. Stakeholders can then engage with the complete system, assembled from these units, at a more mature point in the development/engagement process.

Interleaved approach

Engaging with each department required a series of engagement steps, starting with discussing teaching allocation issues and moving to discussing specific software setup, maintenance, long term adoption, and so on. Rather than approaching all departments at once for each stage of this process, we tried to concentrate on a small number of departments (typically one or two) at a time for a month or so each over a series of stages. Our stakeholder engagement prowess increased, as did our wealth of software features. This has meant that with each subsequent department approached, we can engage more effectively. This appears to be better than working with all stakeholders in parallel, because the first stakeholder is no worse off than in the parallel scenario and all others are better off. This approach may not be applicable to many other projects, however (its effectiveness is subject to the nature of the project).

Planning SE and identifying stakeholders

An insight that emerged from the assembly is that SE is a project aspect that needs to be planned and managed in itself, rather than considered a possibly peripheral part of a more ‘tangible’ project component, such as the development of a piece of software (this was certainly the author’s attitude at the start of the project). A Stakeholder Engagement plan should be developed. Stakeholders themselves should be identified, and their roles clarified. We perceive that having developed ongoing personal relationships with individuals in the departments we have engaged with has been an important contributor to the success of SE thus far; this was echoed to some extent by other projects at the assembly.

Stakeholder personas

The Academic Networking project discussed the idea of deriving stakeholder ‘personas’ from real stakeholders: the opinions, preferences and behaviours of actual stakeholders were condensed into three ‘personas’, representing broad groups of users. Ongoing system development could then be directed through interacting with these stakeholder personas rather than necessarily real stakeholders themselves. It is interesting that, with the fresh perspective offered by this presentation, we can now different stakeholder sub-groups that could be represented as personas for the MEAoT project: in a department, the computer officer, departmental teaching administrator and the director of teaching – in whatever form that they are actually represented in actual departments – could be fairly successfully represented as personas, requiring different engagement approaches and responding in different ways to different cues.

Reminders to improve adoption

The SLAP group described using project-related contributions to frequent institutional newsletters for communicating information on their project developments to the institution at large. This created awareness and interest in the project. Another project talked about the value of a memorable and ‘catchy’ name for a project, that will stick in stakeholders’ (and potential stakeholders’) minds and possibly lead to more effective engagement. The MEAoT team plan to distribute monthly newsletters to all formal project participants (our stakeholders), partly to keep them informed of project developments, but also simply to remind them of the project’s existence and hopefully lead to increased adoption and system use (and hopefully not just annoyance).

Contesting Group

The guest speaker, Susannah Wintersgill, discussed the idea of a ‘contesting group’ of users: stakeholders identified as having a natural prejudice against the project; ‘difficult’ people. By identifying and engaging with these people at an early stage in the project, their concerns and insights can be taken into account at an early stage. The general principle of this is very appropriate to the University context: University people – particularly scientists – are accustomed to being (constructively) critical, and are also accustomed to accepting things that hold up to criticism. Giving such stakeholders the opportunity to criticise, and giving the project the opportunity to respond, will be mutually valuable and could lead to promotion rather than demotion from such stakeholders.

Conclusion

The stakeholder engagement aspect of the MEAoT project began with discussions to find out how to configure the software for departments’ needs. It has since grown to the mechanism by which the entire lifecycle software development, adoption and continued use is defined and directed.

Attending the assembly was particularly helpful in that it forced the project team to seriously consider the stakeholder engagement aspects of the project as a process in itself, rather than a peripheral necessity for developing software. The insights developed were then reinforced and clarified through discussion and seeing the similar experiences of other projects. In addition to this, new insights and approaches were presented which are relevant to this and other CARET projects. While it would be an overstatement to suggest that the experience and outcomes of the assembly will dramatically alter the way this project is being run, it has certainly introduced useful concepts which will help to to ensure that the development and adoption of the MEAoT software modules is as effective as possible.

by Matthew Jones, CARET, University of Cambridge

26 June 2009


Viewing all articles
Browse latest Browse all 2

Latest Images

Trending Articles





Latest Images