V1: How do we approach analysis when a project is funded?

Roles Key:

A: Analyst
E: Engineer
U: UI/UX Designer
LM: Lab Manager
PM: Project Manager
S: Sysadmin
R: Research team (PL, project partners)

When no other roles are mentioned, the assumption is that actions are on the Analyst

1. Notification grant was successful

1. Once notified that grant application was successful at minimum notify - LM, PM
2. Ensure that project is recorded as moving from Submitted to funder space to Foundations or Evolutionary Development as appropriate by PM
   1. Ensure requirements, rates, time estimates, and team/assignees are added (if known) by PM and review as needed
3. Set up desired shared spaces (e.g. SharePoint folder, shared Miro board, dedicated Slack channel)
4. Organise kick-off meeting
   1. Update default Project Review Record - ensure research team is able to access and give access to partners as needed
   2. Set up kick-off meeting agenda

2. Kick off meeting

1. Chair the meeting following the default agenda
   1. Intro and welcome
   2. KDL Process
      1. Team roles (introduce sub-team and main responsibilities; clarifies analyst is the first point of contact for anything in relation to the project)
      2. Tasks, documentation and comms channel
      3. Software Development Life Cycle (PM can cover this at kick off)
      4. Point to an FAQ document, if applicable (KDL FAQ page for reference)
      5. [Team name]'s approach (e.g. design-led approach - explain what it is at high level)
   3. Project requirements overview/discussion (review table from Product Quote and/or Statement of Work as applicable)
      1. Check whether any of the requirements since the partners' received and signed off on the Product Quote/Statement of Work have changed and also whether any new requirements have emerged
      2. Check if prioritisation defined during feasibility still relevant
         1. Provide reminder of how MoSCoW prioritisation is intended to work, noting especially that a change to the priority of one requirement will very likely involve a change to the priorities of other requirements. This is particularly important if the partners come to kick-off with new requirements.
      3. Definition of increment 1 (agree with partners what to focus on as first increment; discuss and agree delivery date of any data and/or information required for increment 1)
   4. Date for first review meeting (schedule dates of first review meeting with partners and ideally set series e.g. monthly for projects lasting 3-5 years; always invite domain experts/research team and [Team name] sub-team; PM can be invited if needed at important milestones or moments when escalation is needed)
   5. Ask partners for known significant events/dates during the funded period and how (ideally) project progress would relate to them. Examples of significant events/dates include conferences, advisory board meetings, public exhibitions, and scheduled reports to funders
2. Record agreed actions (e.g. tasks, dates, etc. to refer to at next review meeting)
3. Add project information to [team name]'s website ideally when project starts (this can happen automatically via project management tool metadata extraction but analyst might need to review/integrate prior to publication)

3. Evolutionary development (increments spread over one or more timeboxes)

Iterate over:

1. Set up internal to RSE sub-team review meeting in advance of review meeting with partners
   1. Ensure design review meeting (either integrated with the above or not) is set up
   2. Record any decisions/points for discussion in the Project Review Record relevant increment section so they can be brought back to review meeting with partners (e.g. as part of delivered solution or as point for discussion/where feedback is needed etc.)
   3. Record any actions in the Project Review Record so you can monitor progress at the next internal review and / or review with partners as applicable
   4. Check with sub-teams if actions are clear and they can create own sub-tasks or whether you need to do it based on recorded actions
   5. Review with sub-team what will be discussed at meeting with partners if unsure
2. Prepare and set up partners/overall research team review meeting
   1. Set up meeting agenda in Project Review Record (remember to update status on % budget spent)
   2. Double check if tasks in progress need to be reviewed, functionalities tested etc. as needed with sub-team in preparation for the meeting (note when feasible the analyst is usually the first tester prior to research team as this helps identify bugs early)
   3. Double check there is something to review at the next meeting with partners or propose to postpone as needed
3. Host research team review meeting (note ideally PL or WP leader should always attend unless others were delegated with decisions on budget and objectives of the project)
   1. Chair the meeting
   2. Involve sub-team in review of delivered solution and assist with any new functionality and/or design demonstrations if needed
   3. Record feedback
      1. Discuss and agree actions in relation to current increment for next increment
      2. Negotiate delivery dates as needed; if uncertain convey to partners that you will get back to them after having discussed with PM at Timebox (TB) or Quarter Planning (QP) meetings as applicable
   4. Discuss and agree any changes to / new requirements (including MoSCoW changes; variations of estimates, allocation of resources etc.) to be worked on in the next increment
   5. Schedule next project meeting if not already scheduled via series
   6. (after the meeting, usually via Slack) Check with sub-teams if actions are clear and they can create own tasks or whether you need to do it based on recorded actions
      
4. Undertake any analysis work assigned to you within requirements and set up extra meetings as needed (e.g. design workshops to support initial user research); record progress in tasks assigned to you and anything you'd like to discuss at internal or research review meetings; review estimates and amend due dates as needed
5. Contribute to project technical documentation as needed (e.g. project technical overview on project website, github or on readthedocs)
6. Monitor requirements and associated increments making sure they are scheduled within timeboxes (TB meeting) and quarter plans as needed (QP meetings) paying attention to priorities, estimates, progress and any criticality (e.g. lack of resources and/or time; confusion over requirements to be delivered), discuss with sub-team (at internal review meetings and/or via slack project channel and escalate to PM if needed (ideally using TB and QP meetings).
   1. Act as first point of contact with partners/research team noting any feedback/issues in relevant tasks or creating new task/s as needed, acting as first tester when applicable, copying everyone in the sub-team by default unless otherwise agreed
   2. Alert PM about any major changes in project as per project change request process and provide information for the Project Change Request form if needed
7. If publicly available site is launched during funded period, check that web stats recording is in place and tell partners how to access them.
8. Mid-project updates and celebrations
   1. Review information on KDL website if needed
   2. Add any relevant news (releases, innovative elements etc.) to social media slack channel for publicity and/or PP agenda and/or other Faculty/College reporting as needed

4. Change freeze

1. Alert of 80% budget spent (PM notifies sub-team at TB or QP meetings)
   1. Liaise with PM on any pre-change freeze communication (part of release process which is responsibility of PM - PM will notify project partner/s of when change freeze is expected to kick in but they need to check with the analyst about timing and wording)
   2. Note requirements that are still to be met and their prioritisations; pay attention to any criticality (e.g. lack resources and/or time; confusion over requirements to be delivered) and escalate to PM if needed (via TB and QP meetings); use the project review meetings to agree with partners what will be left out
   3. At next project review meeting, discuss remaining requirements, whether they need reprioritisation, what requirements may be realistically begun prior to change freeze
      1. Agree on final requirement/s that may be started / abandoned prior to change freeze
      2. Re-iterate that no other requirements will be begun from this point (depending on when project meeting takes place)
2. (Note it is the PM responsibility to notify project partners when change freeze does kick in)
3. Facilitate and undertake analysis work as needed to support requirement completion
   1. Undertake testing, facilitate user testing if applicable
   2. Record acceptance in project review record and/or via email as needed
4. Review information about the project on KDL website and make/assign any updates if needed

5. Project launch / final release

1. Assist with / review data deposit if applicable and if not already undertaken during evolutionary development
2. Assist with SLA drafting (LM initiates this 6 months prior to project end date for projects lasting 3-5 years)
3. Confirm date/time of final release at project review meetings, any launch events
   1. Circulate information to LS and SysAdmin
4. Liaise between SDT and research team for final work/testing to be completed
5. Launch project (final release)
   1. Attend any launch events scheduled

6. Post-project

Post project responsibilities can include:

1. Contribute to project review (usually initiated by PM)
2. Review renewal SLA draft (initiated by LM)
3. Facilitate any post-project communication that may come in via the project and LM to appropriate people
4. Take part in discussions around decommission when appropriate
5. Review decommissioning documentation (LM creates task - draft done by Decom Analyst) and creating a static SLA when appropriate