Problem Statement
The GPIT Futures programme aims to replace the existing GPSoC programme and provide a framework to supply IT systems and services to GP practices and associated organisations. The GPIT Futures programme focuses around a Digital Buying Catalogue, whereby suppliers advertise their solutions and Clinical Commissioning Groups and GP Practices can purchase them. In order for a solution to be able to feature on the Buying Catalogue it must map to at least one Capability and that Capability's associated Standard. A Capability is made up of a series of Acceptance Criteria relating to specific functionality. A supplier must evidence that it's solution has the specific functionality in order for it to be advertised under that Capability.
Whilst working on this programme I was involved in tackling a number of key problem statements including:
How do we assess against the Capabilites?
How do we provide Suppliers with the information they need about Capabilities and Standards?
How does the assessment process work?
And how do we manage the various aspects of the programme within our current tooling systems?
Role
The GPIT Futures programme aims to replace the existing GPSoC programme and provide a framework to supply IT systems and services to GP practices and associated organisations. The GPIT Futures programme focuses around a Digital Buying Catalogue, whereby suppliers advertise their solutions and Clinical Commissioning Groups and GP Practices can purchase them. In order for a solution to be able to feature on the Buying Catalogue it must map to at least one Capability and that Capability's associated Standard. A Capability is made up of a series of Acceptance Criteria relating to specific functionality. A supplier must evidence that it's solution has the specific functionality in order for it to be advertised under that Capability.
Whilst working on this programme I was involved in tackling a number of key problem statements including:
How do we assess against the Capabilites?
How do we provide Suppliers with the information they need about Capabilities and Standards?
How does the assessment process work?
And how do we manage the various aspects of the programme within our current tooling systems?
Role
Business and UX Analyst
My Key Contributions
1) Representation of the capabilities on the Buying Catalogue
2) Requirements Management Tooling - analysis and design
2) Requirements Management Tooling - analysis and design
Representation of the capabilities on the Buying Catalogue
Goals
Represent the capabilities on the Buying Catalogue in a way that is understandable to buyers.
Represent the productivity submissions* on the Buying Catalogue.
*The productivity submissions are functionality that a supplier has submitted to the Buying Catalogue that do not fit within our existing Capabilities. i.e. niche or unique functionality.
*The productivity submissions are functionality that a supplier has submitted to the Buying Catalogue that do not fit within our existing Capabilities. i.e. niche or unique functionality.
Requirements Management Tooling - analysis and design
Goals
Determine whether our current tooling solution will be able to support the framework moving forwards.
Identify alternative Requirement Management Tools than the one being used presently.
Research Methods
Research Methods
User Needs
1) Understand what functionality each Capability represents.
2) Understand the difference between the Productivity Submissions and the Capabilities.
3) Find the types of solutions they are looking for via an easy and understandable search functionality.
User Needs
1) A tool that acts as a single source of truth, replacing multiple different sources.
2) A tool that reduces manual process via the use of integration with existing tooling.
3) A tooling with a good visual interface, that is intuitive and easy to learn, and that meets the current requirements of the programme (i.e. functions at least as well as the existing tool).
Key Outputs
Analysis (kumu):
Key Outputs
User Needs Map:
Capabilities Grouped by Categories
Productivity Submissions Grouped by Themes
Buyer friendly design to be taken to usability testing
Productivity Submissions Grouped by Themes
Buyer friendly design to be taken to usability testing
Personas
Backlog of requirements
List of potential tools
Backlog of requirements
List of potential tools
Lessons Learnt
Define the scope as early as possible.
Where scope has been predefined, ensure it is fully defined before conducting user interviews as what a user says is greatly influenced by the pre-defined scope of a project.
Where scope has been predefined, ensure it is fully defined before conducting user interviews as what a user says is greatly influenced by the pre-defined scope of a project.
Sometimes your users will have conflicting opinions.
In the case of the Requirements Management Tool our users had different requirements because they utilised the tool for different functions. In this case, it would have been best to take these conflicting opinions to someone with a wider understanding of the programme to prioritise them, rather than trying to allow the users to prioritise them themselves.
In the case of the Requirements Management Tool our users had different requirements because they utilised the tool for different functions. In this case, it would have been best to take these conflicting opinions to someone with a wider understanding of the programme to prioritise them, rather than trying to allow the users to prioritise them themselves.
Lessons Learnt
Conduct User Research as early on in the process as possible.
This would have made representing the Capabilities in a way that was intuitive to buyers much easier, as we potentially never would have ended up with ambiguously named capabilities.
This would have made representing the Capabilities in a way that was intuitive to buyers much easier, as we potentially never would have ended up with ambiguously named capabilities.
Don't be afraid to iterative.
The Productivity Submissions were meant to only catch edge cases and niche submissions. Because of the way the Capabilities were written, they ended up catching a lot more functionality than was first expected, making it difficult to represent in the Catalogue. This could have been prevented had we stopped and produced another iteration of the Capabilities when we realised this issue was arising.
The Productivity Submissions were meant to only catch edge cases and niche submissions. Because of the way the Capabilities were written, they ended up catching a lot more functionality than was first expected, making it difficult to represent in the Catalogue. This could have been prevented had we stopped and produced another iteration of the Capabilities when we realised this issue was arising.
