Phase 2 - Developing a Minimum Viable Product

After a Discovery phase we develop a 'minimum viable product'. This needs to do just enough to be able to test our key hypotheses and/or to understand whether we can overcome key project risks, without doing so much that it's too expensive or takes too long to develop. This phase is important because sometimes projects move the more complex parts to the end of a project - such as integration between systems or discovering whether users will adopt a new technology. Developing an MVP enables us to understand how to deliver a solution and whether it will work through real-life testing before we commit further resources to the solution. In Hackney, we talk about building a Minimum Viable Product rather an Alpha phase to emphasise the importance of getting working code in users' hands quickly, and so we avoid making technical investments that we have to jettison before building a beta. We can use this method even when we've decided to re-use or buy software rather than build it. Our 'MVP' might be a small number of internal users, or using the software for a small number of cases.

Team and skills

During this phase, it is particularly important to work with a team that can share the understanding of what users need and continue to support the project in the next phase of work. You would normally expect to be working in a team of 3 and potentially a team as large as 8. Much larger than this and the team may be too big to be cohesive. The team will contain:
  • A project sponsor
  • A Product Owner
  • A delivery manager
  • A developer(potentially a front-end and back-end developer)
  • A service designer
  • A user researcher
  • A subject matter expert
You will also need to draw on the skills of:
  • a Technical Architect for advice on the hosting and infrastructure - including security
  • A data expert for advice on the data that will be stored and exchanged
  • Suppliers of existing solutions
  • Master Data Officers
  • Information Governance Officers

Governance

The Product Owner will make the day-to-day decisions in response to the insights gathered from users. The key moments for decision-making will be in the activities to estimate the size of the user stories, the prioritisation and the sprint planning workshops. Beyond the sprint team, the Product Owner will need to explain these decisions to the project sponsor, head of service and possible the Cabinet Member - depending on the prominence of the work. Getting this input in the prototyping phase helps avoid later changes of direction in subsequent phases of work. We have developed a role description to help Heads of Service and Product Owners understand the commitment. During this phase, you should be sharing weeknotes and holding a show & tell at least every fortnight. We have created a guide to holding a great show & tell. At the end of the phase, the team will need to commission an assessment of the work against the Service Standard, consistent with previous phases. This should involve the infrastructure teams and applications management so that they are sighted on the scope of the project and prepared for any change requests when the project later delivers working solutions into the production environment.

Tools

The key tools during an MVP phase will be: You may also want to check back to some of your key outputs from the discovery phase. For example, it can be useful to check back to the personas and have a group discussion about whether the MVP would meet the needs of each of the people in the personas (which is why it's useful to give them a name and face, so the conversation isn't abstract).

Timing

This phase should take between 6 and 12 weeks, depending on the technical complexity of the service. A project involving simple web-based interfaces or off-the-shelf software should take nearer 6 whilst a 12 week phase enables the team to test the development of APIs. The phase could be designed to tackle the biggest risks to the project first, which can then inform the overall length of the phase.

For inspiration

Outcomes

At the end of the prototyping phase the team will have:
  • Tested the MVP with users to validate or redefine the user stories
  • Identified the biggest risks to the project and reduced these through its work
  • Identified which parts of the business process need to change, and how
  • Defined the most important user stories
  • An understanding of the relative complexity of building the key user stories and the importance of each to the project
  • Developed KPIs for the measurement of the service in the next phase and a clearer sense
  • The solution architecture, hosting and security of the service
  • A clear budget and business case for the remaining phases of work
  • An understanding of the open standards and how these will be adhered to, existing solutions any common government platforms and whether or not they’ll be used

End of phase checklist

We have:
  • Evidence of what our users need, and we can justify key features and design decisions based on this evidence
  • A team with a shared understanding of what needs to be done in the next phase reporting to an empowered Product Owner with sufficient time to make in-flight decisions
  • A solution architecture, including the plan for hosting, infrastructure and application support and data security
  • A take-up plan and plan for what to do if the service is unavailable
  • Realistic targets for the performance of the service
  • Developed a clear product roadmap which has the support of senior stakeholders
Team and skills
Governance
Tools
Timing
Outcomes
End of phase




Last updated on 25/06/2018