Projects (outside of onboarding)

Home > Onboarding > Projects (outside of onboarding)

Submitting an idea for development

1. Ideas for developments / releases and change requests should be logged using the Aha portal. Anyone can submit new ideas as well as vote and comment on existing ones. The aim is to encourage a community of collaboration and to ensure we are focussed on a user centric design approach.

2. The Interweave Website Ideas Portal – Interweave provides the ability to navigate to relevant workspaces where ideas can be submitted.

3. Once an idea has been submitted this is reviewed by the Product Owner.

4. These ideas are then discussed as part of a weekly Interweave Care Portal workshop with partners where they can be reviewed, and a decision made collectively to promote an idea to the backlog.

5. When prioritising ideas, partners put idea into one of four buckets.

Do now, which is typically smaller changes that we can achieve quickly.
Make a project, which requires User Centred Design (UCD).
Do it if we have time, which is smaller but less important changes.
Forget for now, which is low value, high effort changes.

Ideas will then be submitted to the roadmap for further development.

Initiation

1. Any projects committed to the roadmap should be submitted to the Interweave Project Management Office (PMO) via email to hnf-tr.interweave@nhs.net for registering the project.

2. An email from the Interweave Product Owner confirming their approval for this request to proceed should also be submitted and attached to the project.

3. Interweave PMO will register the request and create a project. This record can then be used as the central repository for related documents and information relating to the project or release such as due dates and interdependencies.

4. Interweave PMO will review the project ticket and submit request to the Interweave Management Team for approval. A Project Initiation Document detailing the development, stakeholders and timeframes for the development should be completed and attached.

5. If there is a need to discuss next steps the Interweave PMO will schedule a project session with key stakeholders alongside the Interweave Product Owner. The purpose of this meeting is to agree any next steps around the approach and implementation.

Operation considerations include – Information Governance, Data Assurance, Clinical Safety, Cyber Assurance etc. Do any Standard Operating Procedures need updating or creating to support this development? Do any user guides need implementing and approving, and do we need to issue any further communications relating to this? The cadence of meetings where appropriate will also be agreed.

6. Stakeholders will be signposted to supporting documentation when available on the Interweave website and the development should be added to the Interweave release schedule along with a date of release.

7. Interweave PMO will notify the Service Desk of any approvals, so any communications can be scheduled according to the release or development.

Assurance

(this will be undertaken as part of the cross functional meetings)

1. Information Governance – it is advisable to complete these activities shortly after approval, in the initiation stage, as approval can take time.

a. If required, an Information Sharing Agreement will need creating and approved by the Interweave Information Governance Team and Humber Foundation Trust who hosts Interweave.

b. Similarly, the above steps should be carried out for the Data Protection Agreement as appropriate.

c. A Data Protection Impact Assessment in relation to the project, development or release may also be required. The Information Governance Team at Interweave / Humber Teaching can provide advice and guidance (project dependent).

Implementation

1. The project ticket (listed above) should be maintained and updated during the lifecycle of the project.

2. Commencement on the work required will then take place. The development team and/or Interweave PMO collectively will update the project ticket when appropriate detailing what has been achieved, where dependencies are and update any due dates along the process as some developments may require more time than others.

The release schedule can also be updated to reflect these changes.

3. Once the development work has been completed any testing prior to changes becoming live can then begin. This could include Clinical Safety, Data Assurance, Cyber (if required) Information Governance as well as traditional development testing (project dependent).

4. The Interweave Product Owner will then raise a Request for Change within the project and the change request will be linked by the PMO to the relevant project ticket.

5. The Interweave Testing Manager will review the testing undertaken and document findings in the project, identifying if further assurances need to be received to approve.

6. The Interweave Product Owner will submit a request to CAB to advise them of the release for change. If the objection date passes with no objections being raised the Interweave Product Owner will mark change request raised above as approved.

9. The project will then be updated and linked to the Request for Change by the Interweave Product Owner.

10. Any final preparations should now be completed prior to the release going Live. This should include the development of user documentation such as user guides and standard operating procedures as agreed. It is the responsibility of the Interweave Product Owner to ensure that these are in place and made available before the release takes place.

11. Documents developed during step 10 of implementation (as above) should be made available prior to release and will be submitted following the steps of the document review process by the Interweave Product Owner. It is advisable to develop these documents and submit for review during the implementation phase of the project to avoid any unnecessary delay in releasing the development.

12. Once approved, the supporting documents will be uploaded to the Interweave Website in advance of any release being made by the Interweave PMO.

13. An agreed Go Live / Release date should be registered within the project ticket and the release updated so the project can close.

14. Finally, Interweave PMO will notify the Service Desk so any final communications can be scheduled according to the release or development. This request should be also stored within the project ticket.

15. Project close. The release is made live in accordance with the steps above.