Project Cards Explained

A project card is designed to hold relevant and useful information for the community to be able to support prioritisation discussions and recommendations.

When a potential project is submitted for review and inclusion to the backlog we will ask that this information is provided, or an explanation as to why it cannot be.

On the following 'Potential Roadmap projects' page you will see one of these card for each potential technical roadmap project. Below is a explanation of what is requested to be included in each project card.

---

Example Project Card

Project Title - title of the potential roadmap project

Abstract

Description: An introductory description of the project and what it is about.

Problem Statement: What problems this project looks to resolve.

Benefit: Anticipated likely project benefits.

Project Details

Project sponsor: The group or individual proposing and advocating for this project, should usually be considered the technical subject matter expert. They are not necessarily the supplier, as the project will go through a tender & procurement process.

Product goal: The high level, product committee, goal this project supports.

Dependencies/risks: Key dependencies which may block or partially restrain prioritisation. Any known risks likely to impact deliverables.

Next deliverable(s): The likely next deliverable should this project be prioritized and funded.

Estimated effort: Based on likely full-time-employee and/or team effort for the deliverable(s) above. Please note this is indicative, subject to change during procurement and does not include resource(s) such as scrum masters, or CI/CD integration etc. - it is designed to show indicative sizing to help evaluate effort vs benefit.

Readiness (Current > Target): The software readiness level (SRL) reflects how close a project is to being development-ready without the need for further research, validation, or technical specification creation. The current SRL and the target level by the end of 2025 provided by the project sponsor is represented on a scale of 1-9. This is designed to show the community what is expected to be achieved.

Further reading: Links to supporting documentation, CIPs, CPSs whitepapers etc. where applicable.

Video

Video Introduction: all project sponsors have been asked to create a short 3 minuet video explaining the project, its key details and desired outcomes.

Project Card Key

Not Provided - Information has been requested but not yet provided by the project sponsor

TBC - Information has been provided but is currently being reviewed and/or confirmed by the CIR, TSC or other reviewing body

Software Readiness Level - explained!

Defining a robust and repeatable process will ensure the progression of solution development can be thoroughly validated before going into production. The software readiness levels (SRLs) provide a mechanism for this.

Research to proof of concept – demonstration of hardware/software concepts that may or may not be incorporated into the following development:

• SRL 1: basic principles observed and reported

• SRL 2: technology concept or application formulated

• SRL 3: analytical and/or experimental critical function or characteristic proof of concept

Technology development – progression from demonstrating functionality to prototyping software built for validation up to a breaking point:

• SRL 4: component or breadboard validation in the laboratory

• SRL 5: component or breadboard validation in a relevant environment

• SRL 6: system/subsystem model or prototype demonstration in a relevant environment

Technology delivery – software has been successfully operated in an operational environment of the same scale:

• SRL 7: system prototype demonstration in the target environment

• SRL 8: actual system completed and qualified through testing and demonstration

• SRL 9: actual system proven through successful deployment/operations.

(These levels will be assigned by the reviewing group or committee)