Health Education England’s (HEE) Learning Solution is being developed following the Government Digital Service (GDS).
The GDS have a standard, a proven and effective way of designing, developing and producing online services that has been seen time and again through the Government’s own sites, and we’ve adopted that approach.
You can read more about that standard of delivery in the GDS Service Manual if you wish. The manual details how services should be designed and delivered using Agile development, how success should be measured, how the process should be heavily user led through extensive user research and who in a team is required to deliver the project.
That’s the Service Team. That’s the team who is now working on developing the Learning Solution.
The roles required in a Service Team change depending on which phase of development you’re in, so having progressed from our Alpha and Discovery phases, which you can read more about in other posts on this blog, we’ve also moved the team on.
Here are a few slides from the first meeting of our Service Team. The first shows a standard team taken from the GDS Service Manual, the second shows the team we’ve assembled.
That’s our Service Team. We come from a range of roles and have a broad experience between us, from commercial and public sectors, delivering systems small and large. Many come from HEE e-Learning for Healthcare (e-LfH) and have been involved in or responsible for the design and development of the existing e-LfH Hub.
Let me quickly explain the roles shown in the diagram above so you can understand a little about each. The explanations are mixture of the guidelines from the GDS Service Manual section about Teams and have what works with our team, their experience and skills, as well as the project requirements.
Service Owner:
Responsible for developing, operating and continually improving the overall service, using all the systems and products available. They look after the project level approvals, risks and issues, and encourage the use of the service and systems.
Product Owner:
Responsible for defining the future goal of the product, or what’s called the Product Vision. Ensures the product meets the needs of its users, current and future. Comments on and approves the solutions put forward by the team for the technical, content and design of the product, both before and after user research.
Delivery Manager
Makes sure the agile environment the team needs is in place, thus ensuring the team can run the design, development and delivery process effectively. Helps to remove blockers that stop the work from continuing, and in getting the necessary sign-offs. Helps the Service Team work better and more autonomously. Also makes sure that the user and accessibility are focused on throughout the project.
Stakeholder Manager
Identifies and engages with any group that has connections with the product and its usage. In the case of the Learning Solution these could be existing content providers, existing user of the e-LfH Hub, to potential new organisations of users or existing systems wishing to link their content offerings. The stakeholder manager ensures that the relationships are strong and that all their requirements are gathered and fed into the Service Team. They will also ensure that the stakeholders are considered and involved at the relevant phases of the project.
Communications Manager
Responsible for all the internal and external communications from the project, they always ensure that the Service Team and the project, convey the correct messages. They will ensure that communications reflect the progress of a project, and the correct information is disseminated through the correct communication channels including emails and blogs to third party channels and industry conferences. They will define a communications strategy to help team engagement, raise the profile of the product and help engage more groups in the product and service.
User Researcher
They will help the team understand who will be using the product, and how they will be using it. This is an important role in an agile project as the focus is always on the user and what works for them. Almost all the front end of the product and the functionality will need to be put to the users to understand their needs. This includes those with specific accessibility requirements. The user researcher will involve the team in this work, feed back to them, analyse the findings and present them back to the Service Team, and get involved in show and tell sessions to update wider groups involved in the project.
UI/UX Designer
This role is often thought to be just about how the system looks, but it’s much more. It’s about how the user moves between screens, how they interact with components, what works best for engagement and understanding, and again, empowering the users’ needs and requirements in the system.
Technical Architect
Leads in the decision making for all the infrastructure and systems behind the screens. They are responsible for all the technical aspects of the system and provide technical approval. What comes from user research and UI/UX design will always have to be reviewed by the Technical Architect to ensure it is technically feasible. They are also there to ensure that the team of developers follow similar and modern, high quality coding practices.
Data Architect
Much as the technical architect looks after all the technical responsibilities, this person looks after all the data requirements of the system. They are responsible for what and how data is gathered and used, how it is reported back to the users and administrators, and what we call the Data Warehouse. The Data Warehouse is a system that gathers all the data from multiple systems and sources behind the Learning Solution to create one source of data, one source of reporting.
Business Analyst / Development
A dual role that manages the development team and works between them and the business to ensure requirements are understandable by the developers, meet their and the technical architect’s needs and are, importantly, user focussed.
Developers
This team build the actual system, creating it to the requirements provided. They write, adapt, maintain and support the to create the product. However, they don’t just code what they’re given, they are involved in the service team meetings to discuss the requirements, advise on the technical feasibility of designs and assist in the resolution of technical problems during development and support.
Web Operations / Support
Leading the Web Operations and Support teams, this role is responsible for making sure the Service Team don’t miss out on the wealth of experience and knowledge of running the existing products and systems, focussing on the existing users. The lead will not only ensure that the current products and services continue to operate efficiently and are effectively supported but will also ensure the Web Operations and Support team are engaged with the new product, provide advice on the current users and carry out acceptance testing where required.
Taxonomy/LRS
This role is unique to this project and is responsible for two products that integrate into the Learning Solution behind the scenes. They are the Taxonomy system that analyses and connects content and terms providing some of the key browse and search functionality. As well as the Learning Record Store which allows informal and non-Learning Solution learning to be recorded, learning such as meetings, events, conferences, etc.
For more information about the Learning Solution visit www.hee.nhs.uk/tel and follow us on Twitter: @HEE_TEL.