Develop RAM Project Engagement Prioritisation Framework (RAM Matrix)

[f-rower]

Summary

RAM Matrix development and discussion

Detail

This issue will keep track of RAM Matrix development based on applications, iterations, and discussions

Intended Output

Finalised RAM Matrix for RAM engagement prioritisation

Who can help

all RAMs

[f-rower]

Some reflections from @dingaaling and @f-rower following a first attempt at using the RAM matrix as a tool for RAM engagement prioritisation and obtaining programme buy-in on top 2-3 project engagement recommendations:

@dingaaling's thoughts:

• Adam doubled down on the feedback we received from Simon to make "alignment to Turing GCs" as the Create list of mailing lists/comms channels/Slack Groups with relevant events #1 dimension for prioritisation
• He also suggested the other dimensions (e.g. RAM readiness, interest, project status) could be like a checklist to determine when a project is ready at all for RAM engagement
• Fran was able to use this deck to get programme director/manager buy-in for the top 2-3 projects he will embed within in the next few months
• For one these projects (OpenLIMB), we identified a potential link to scivision. Tagging
  @aldenc
  to explore further!
• A major theme was thinking on how to align this RAM resource with our close collaborators: RCMs, Partnerships, PMU and for DCE a starting point will be co-creating a prioritised stakeholder list

@f-rower's thoughts:

• First, the structure followed for prioritising and reporting was helpful for guiding the discussion and keeping it focused. Do any other RAMs think this is something they could use for their particular programmes and/or engagements? What would you add/change/remove?
• RAM project engagement prioritisation should be preceded by project prioritisation at programme and Turing level. This was made evident by Adam's comments about alignment with GC being the most important dimension, and the first question that Simon and the Exec team would ask. Therefore, a necessary condition for RAM prioritisation is that we first understand the priorities of our respective programmes. (this echoes Jen's comment)
• The current set of dimensions act more as a prioritisation aid, rather than providing a direct output on what the top project for prioritisation is. This is because the dimensions currently capture aspects of projects that are relevant to the decision-making process for prioritising RAM engagement, but the relevance of each is dependent on the specific context of the programme.
• Putting together this report was a pretty time-consuming process, since it involved interviewing a lot of people, extracting the information from each project, filling dimension information for each project, and then dedicating time to thinking about which ones to prioritise. Now that we have a set of dimensions to use, a more time-efficient method to completing this report would be to ask the PI of each project to fill in the dimensions for prioritisation themselves?
• As a next step, as suggested by Adam Sobey (DCE programme director), a great addition to the report could be the incorporation of a diagram showing each project's "impact readiness" (for example, a RAM adaptation of the TRL scale, such as Figure 4 here)
• The current set of dimensions are geared towards project engagement. Prioritisation of engagement at programme-level and cross-programme level is still a work in progress! When discussing programme-level engagement, most of the engagements (except for the external stakeholder prioritisation framework) were perceived positively, but more as accessory activities, rather than must-haves. What is our view on RAM engagement at programme and cross-programme level vs project level?

[f-rower]

Following a first attempt at using the RAM Matrix as a tool for RAM engagement prioritisation and obtaining programme buy-in, this is the current set of proposed dimensions for RAM project engagement prioritisation (tested in DCE context):

Dimension	Description
Alignment with Turing Grand Challenges	Does the project align well with Turing Grand Challenges? (Environment and Sustainability, Healthcare, Defence)
Alignment with programme objectives and priorities	Does the project align well with the programme objectives, priorities and themes?
Project Status	Is the project in an exploratory phase, ongoing, finalised and in need of further impact exploration?
Opportunities for RAM engagement	What is there for a RAM to do in the project? The opportunities for engagement can be further examined in terms of RAM expertise, interest, whether the activities can be conducted by others...
Readiness for RAM engagement	Can the RAM be involved straight away? in the near future? far future?
Interest in RAM engagement	How much interest is there in the project team for a RAM to be engaged? Has the RAM role been mentioned? Is there resistance towards RAM engagement? Has RAM engagement been considered?
Programme leadership buy-in	Does programme leadership endorse RAM engagement in the project?

[f-rower]

Discussion between Hari and I:

• Fran will create a template for RAM Prioritisation Reporting. Add in the structure and steps that need to be followed for filling in the template.
• Add RAG rating for prioritisation dimensions
• Opportunities for RAM engagement dimension RAG rating considerations: add list of items to think about when giving RAG rating (e.g. nature of the engagement (secretarial = red, user testing = amber, cross-programme collaborations = red), seniority level required (green = newbie RAM, amber = "normal" RAM, red = TPS senior researcher RAM)
• Time needed to do: explain the value in doing this, but give guidance in case the RAM doesn't have time to do as thoroughly
• Figure to show programme impact landscape per project: open a new issue and develop this separately to the prioritisation framework
• RAM prioritisation of activities depends on programme lifecycle stage: starting no strategy, strategy set but still starting, strategy set and projects already running. Assessment of programme lifecycle will need to be a preceding step to RAM activity/engagement prioritisation

[harisood]

@f-rower is this accurate?

Then:

• Phase 1: I have stuff on that (strategy work)
• Phase 2 we don't know yet but @kallewesterling, @S-Laher & @aranas may have ideas from their cross-programme work
• Phase 3 is your stuff covered in Develop RAM Engagement Prioritisation Template #67
• Phase 4 is more traditional RAM work (do we even need this Phase)

[aranas]

phase 1 activities:

• drafting ways of working document, including best practices for open & reproducibility into ways of working.
• facilitate creation of theory of change map

Phase 2 activities

• just pointing out that stakeholder mapping task will overlap with RCMs (as it has in TRIC-DT)
• representing programme across different communities (turing-external talks)

I think Phase 1 & Phase 2 could be merged, in practice they are not as neatly separated I'd say

[harisood]

in practice they are not as neatly separated I'd say

I think kind of yes, but also having a fully formulated phase 1 can influence phase 2 in new ways, than how you would do phase 2 w/o phase 1... lets talk on Monday!

[dingaaling]

The way I read Phase 1 is more "these are the activities needed to set up/fund a new programme" whereas Phase 2 is more "these are the activities that support the ongoing delivery/strategy of a programme"

For example, @aldenc and I have been involved with Phase 1 for setting up E&S GC and she is also getting actively involved with Phase 1 for setting up Health GC, which feels distinct to me compared to the work Sophie/Kalle are doing for TRIC, Fran for DCE, and myself for UA.

Many of these activities are incredibly overlapping with roles like RCMs, PMU, Partnerships, so I wonder if the key thing we can really add to this is a clarity on what the RAM role works towards/focuses on in these processes?

For example, maybe RCMs owns the "ways of working document" task and Chris Charlton Matthews owns the "ToC" task, but RAMs offer content on things like:

• Choosing the right repo template based on the project type
• Creating new touch points for users to feed into the repo or project roadmap
• Capturing the stakeholder perspective to feed into the ToC

[f-rower]

#66 (comment)

@harisood I think this is a great starting point. I would maybe suggest combining stages 3 and 4 into a single "project delivery" programme lifecycle stage? and then maybe add a 4th stage called programme wrap-up or sth like that, to reflect programmes that are finishing and wrapping up?

[harisood]

This is all good stuff, some thoughts:
@dingaaling @aranas

what the RAM role works towards/focuses on in these processes?

Agree

RCMs owns the "ways of working document"

Think I agree with this too

Chris Charlton Matthews owns the "ToC" task

imo Chris owns this at the Institute level, we would be responsible for including and implementing it at the project/programme level

Choosing the right repo template based on the project type
Creating new touch points for users to feed into the repo or project roadmap
Capturing the stakeholder perspective to feed into the ToC

I think this is the kind of thinking we need to focus on! But not sure about these three (1 seems mb too specific, 2/3 seem mb a little vague). But this is where iterating wording comes in!

@f-rower

I would maybe suggest combining stages 3 and 4 into a single "project delivery" programme lifecycle stage?

On the fence - to what extent do you see the work you've done so far with project prioritisation being the same/separate from the work you would do with specific projects? Is it distinct enough to separate, or should they be combined? Tbh maybe a 'phase' approach is the wrong way to think about it, as you'd probs be doing all phases (esp 2,3,4) concurrently (reflecting convos I had last week with you and @dingaaling)

and then maybe add a 4th stage called programme wrap-up or sth like that, to reflect programmes that are finishing and wrapping up?

I think this would be cool.

---

I also think the big thing (as discussed with @dingaaling) is to make sure this builds on, and doesn't sit separate to the RAM matrix - otherwise we'll end up with loads of random competing models for how we work 😅 will think about how to combine

[f-rower]

Discussion and actions from RAM meeting 27/11/2023:

• @aranas We could aim for documents that address very specific questions/remits, instead of a large catch-all framework? Largely agreed.
• @f-rower reword the two issues we currently have into the very specific questions that they answer (RAM Project Engagement Prioritisation and RAM Programme Engagement Prioritisation)