At Principle One, many of our customer engagements begin with a Discovery phase. This is often before there is a clear understanding of how we might solve the customer problem, or even what that problem is. On occasion we have been asked to start designing a proof of concept, only to find that the customer hasn't yet defined the concept they are actually seeking to prove. During a Discovery phase, our challenge is not only to help understand the problem but to paint a vision of the art-of-the-possible as well as what the solution could involve. Even without clear requirements, there is a place for rapid development of prototypes and elaboration of throwaway solutions to help understand and test what the solution concept could be. In many cases, it’s not the technology that we are seeking to prove; many of our engagements simply involve the deployment of mature technology solutions that are already on the market, even when the customer requirements themselves have a high degree of complexity. Proving the concept should therefore be more centred around how new business processes or new ways of working can help the customer solve their business problem or address a critical risk, as much proving a specific technology can do the job it was designed for.
Even once the outcome is understood, it can still be challenging to fully understand the breadth and depth of the aspects around how we reach that outcome. This is particularly true when there are multiple internal and external stakeholders who may not have a holistic understanding of the problem or the outcome that is being sought and may not buy into the drivers for change.
As a result, before we can begin looking at how we might prove the concept, we firstly need to understand the motivations and goals for both the customer and those wider stakeholders. We create an initial set of key artefacts including an overarching problem statement and a motivation model to help us map out the drivers and constraints around the problem to enable us to work closely with our developers with a clear perspective on who we are building for and why, from the outset.
We recently undertook a proof-of-concept commission for a government agency to design, prototype, and de-risk a potential solution to support transition from paper processes to a digital solution which would give greater control and auditability over a potentially sensitive process.
Over just eight weeks, our challenge was to help the customer fully understand the scale of change required to address the risks they had identified in their current processes. We balanced painting a picture of what a solution could deliver, with the development of a roadmap of how the customer could move to a future solution and new ways of working.
We began with mapping out as-is scenarios to enable us to understand the key business process flows and interactions. These illustrated the pain points that they experience today, and considered the wider system of interest, security considerations and delivery de-risk. This provided a strong foundation of requirements and constraints to consider in terms of defining the concepts that a future solution would need to prove.
Given the need to work at pace, we onboarded the development team while business analysis was still ongoing. We followed an iterative, agile approach of short sprints with analysts and developers working closely together to create prototypes to be quickly demonstrated to stakeholders. This enabled feedback to be incorporated into the next sprint, and flexibility to make any changes required as the understanding of the scope of the solution evolved. This let the customer quickly evaluate whether there was anything missing and refine how the digital solution could be delivered.
To ensure effective working, communication was key, and the split of roles between analyst and developer became less clear cut. We combined wireframes created in Balsamiq, which could quickly show the customer how the system could look, with Microsoft PowerApps to bring them to life against the revised set of business processes as we developed them. By using tools that required limited custom coding, we were able to move rapidly into building something tangible with the flexibility to amend the solution as we began to tease out more requirements and refine our understanding.
Regular communication with our customer product owner and stakeholders was just as important as communication within the team. By sharing the visual prototypes quickly as part of our requirements validation process, we could crystallise what the customer did and didn’t want to see in a digital system far quicker than reviewing a written requirements set.
By prototyping in this way, the team were able to identify some of the challenges with systems integration, implementation, and delivery risks far earlier in the process, and identify the technical de-risk activities that should come next. While there is always a risk that the leap from prototype to production is underestimated, by being clear about why we were prototyping and that our goals were both to reduce ambiguity and support an understanding of what change could mean, this was mitigated from the outset.
The short timeframe and initial lack of structured requirements made this a challenging project, and one which really pushed us to get as many innovative ideas as we could on the table as quickly as possible, recognising that some may be thrown away just as fast. Integrating ongoing business analysis and requirement gathering with the work of our developers needed almost constant communication, whether working remotely or together on our in-office days, this was only possible with flexibility on all sides and a buy-in to the process from the customer from day one.
Through this iterative approach to development, the team rapidly progressed from simple visualisations to a coherent prototype that demonstrated key services and processes including a case management system for all applications and stakeholders’ communications, helping inform the next stage and the preparation of a business case and plan for delivery.
When embarking on a proof of concept, we shouldn’t forget that proving the concept is as much about testing out what’s possible as it is demonstrating proof that the solution will meet requirements. The rapid prototyping described here may not by itself prove the concept; much of what is delivered at pace may be throwaway, but it should inform and accelerate the understanding of the challenges faced and enable rapid progression into the next phase of work. Working in this way is only possible with a high level of trust between all parties involved, which creates a foundation of successful delivery at pace – from concept through to reality.
Comments