Discovery: How well do you know your business?

According to the Forbes Technology Council, "not understanding the needs of the business’, ‘not starting with the end customer’ and ‘unclear requirements" are some of the most common reasons that technology projects fail.

Discovery (which in this context has nothing to do with treasure maps or uncharted desert islands!) is a collaborative process that helps to reduce risk by researching, documenting and analysing business information. The goal is to get a profound understanding of a large, complex project or problem before embarking on a larger, unknown project.

Or, to use a non-business metaphor, it's a bit like finding out where the gold is hidden before you start digging.

In this blog, Alexandra Koyfman, one of our Senior Business Analysts, provides a straightforward summary of what a Discovery phase entails and why it could be beneficial to your project and business.

What is Discovery? 

Although “If I had asked people what they wanted, they would have said faster horses” is a somewhat overused quote in product and design circles, it is (probably incorrectly) attributed to Henry Ford.

Whilst the former does support the case for ground-breaking ideas of individual genius, something Ford is known to have said is, "If there is any one secret of success, it lies in the ability to get the other person’s point of view and see things from that angle as well as your own." - and this is exactly what Discovery is designed to do.

Discovery is structured process of research and analysis, which arose primarily from digital product development. It’s a relatively short, intense period during which customer needs, staff needs and needs of other stakeholders such as partners and suppliers are collected and reviewed, alongside business goals, competition, sustainability, technology and commercial viability and other considerations.

There is no ‘one size fits all’ recipe for Discovery. However, there is a consistent set of tools and techniques that can be employed: the constants are that information is gathered using a several well-established research methods, which we’ll outline later, and that information is analysed and documented in business communications style de jour – typically presentations, reports, spreadsheets, diagrams.

With the research and documentation in place, a ‘weighing up’ can happen; the presentation of a clear, tested hypothesis for a new product, service or transformation, or the exploration of various solutions to a business problem.

When talking to clients about a relatively large software development, digital transformation project, or solving a problem with tech, we often propose starting with Discovery.

Why Discovery? 

1. Understanding your business context

If you work in the public sector, you may have seen this description in the UK Government Service Manual: "Before you commit to building a service, you need to understand the problem that needs to be solved."

Within government, Discovery forms part of the Service Manual because it is a way to ensure citizen-centric services, as well as sensible use of taxpayers’ money before embarking on costly development projects.

In the commercial world, Discovery helps to reduce the eventual total cost and timelines for new products: according to McKinsey, projects with a well-executed Discovery can reduce time to market by 20-30% while Standish Group’s Chaos Report suggests projects with a defined Discovery phase have a 28% higher success rate.

Our experience at PDMS supports this, and we have used Discovery in a variety of contexts such as:

• Determining the feasibility of a project to manage Biodiversity Net Gains for Natural England;
• Investigating how we might combine multiple, legacy solutions into a unified service to bring about better staff communication and improved customer service at Stanley Black and Decker; 
• Exploring how technology can aid parents through the admissions process for statutory entitlement to early learning and childcare for West Lothian Council, as part of a CivTech Scotland challenge. 

There is no one answer to the question of ‘Why do Discovery’, but we recommend it for most ‘from scratch’ or transformation projects over a certain budget.

There are contexts where it may not be appropriate: for existing software that needs changes it may not be necessary, or when some form of requirements or research has been previously carried out, or for small or start-up projects, full discovery may not be needed or viable.

Discovery reduces the chance of making strategic mistakes based on false assumptions or biasing a product towards one or more influential individuals’ valuable, but potentially subjective, opinions.

It also helps just to ‘get everyone singing from the same hymn sheet’ as documentation and findings from Discovery can be shared or adapted, and communicated across teams and departments, even if they are geographically distant.

2. Addressing the actual business problem 

Organisations generally approach us to help solve specific problems. They might even have a particular technology in mind that they are dead set on using.

 However, we generally advocate fully understanding the problem before formulating solutions as it is too easy to ‘solutionise’ and assume that the first solution that springs to mind is the correct one.

Sometimes we find a deeper or hidden problem that needs addressing first, and the initial problem was only a symptom. Other times, we realise we just need more information to unearth the full extent and causes of the problem.

3. Focusing on user needs 

Users are central to the potential value of any software, whether a complex business system used by your staff or a public-facing website used by your customers or members of the public. They are the people who regularly use the system, and their experience determines whether your service or system is a success.

We want to understand who your key stakeholders are (especially system users), their goals and how they can achieve them within their day-to-day environment.

In short, our goal is to make their lives better and easier.

4. Achieving cost savings 

A Discovery phase is usually short (weeks not months), but intense, with a small, focused team typically made up of business analysts, designers and solution architects. Other specialists can be brought in as needed.

In contrast, the large software development projects we work on can last from six months to two years and involve a significantly larger team.

Research from McKinsey suggests ‘large IT projects often run 45% over budget and 7% over time’.

Without a discovery phase, your investment may be spent on a solution that either doesn’t fully meet the needs of your business, fails due to insufficient research, or simply costs much more than anticipated due to unclear scope or lack of detail.

What happens during Discovery?

While there is no standard recipe for Discovery, most projects broadly include the following stages. One important consideration is that time from your key people (and ideally some customers) is vital to ensure you get the most out of it in the few short weeks of a typical Discovery. We bring in an experienced, multi-disciplinary team consisting of business analysts, user experience (UX) designers, and technical experts to look at the problem from all angles.

Onboarding 

Initial meetings with the client are essential to get a clear picture of stakeholder groups, as well as dispelling any concerns over the purpose and reach of discovery. Exploratory workshops and interviews can help to establish organisation structure, reporting lines, processes, culture and approach to customer service.

Planning 

During the planning stage, we explore what success looks like.

By setting clear objectives and goals for Discovery, we’re able to set the scope for upcoming analysis activity and agree on deliverables needed, all to get the most value out of the time spent.

For example:

• If there is an unclear problem to be solved, we may work in the problem space to expose more of the problem.
• If there is a clear problem to be solved, we agree on how solutions will be ideated and selected.
• If there is a product or service to be designed, we agree on the scope, process and tools for delivering a prototype.

Research 

We use proven tools and techniques to gather perspectives and data from representative groups and individuals within the organisation. Sometimes the best insights come from the people you’d least expect!

User research techniques are well established and can include workshops, interviews, observation (for example observing someone doing their job), surveys, mind mapping and analytics.

Alongside user research, we review existing business documents available to us and we may employ more traditional business analysis practices to map processes, gather business requirements, assess the tech stack and document day-to-day operations.

The initial phase is all about ‘taking stock’ to get a clear, high-level view of the organisation and any problems that are pre-existing, or uncovered during research.

Analysis 

During this stage, material that has been collected is reviewed and evaluated and can be used to inform the creation of other documents or artifacts. Many types of artefacts may be utilised. Some of these could include:

• Journey maps: How customers may feel about your services now, and in the future
• Clickable prototype: working model of software or app to obtain user feedback
• Roadmap: Timelines and goals for a service or product
• Project or delivery plan: timeline, phases and estimated cost for software delivery
• Technical architecture: document how a solution will be built
• Testing strategy: describe how software will be rigorously tested and fixed
• Requirements or User Stories: list of features and functions that the solution must or could have
• Investigative report or feasibility study: document to assess how viable a project is, could include aspects such as market research, sustainability, commercial model, human resources, business recommendations and more.

Findings and deliverables

By the end of a discovery phase, we will have a much deeper understanding of your business, its people, its challenges and opportunities.

This knowledge allows us to summarise our findings, potential solutions or products in a way that best suits the context, as well as to present you with recommended ways to move forward based on fact rather than assumption. We often do this via a board or Senior Management level presentation, and several more specific presentations with stakeholder groups such as product teams, sales and marketing and customer service.

Armed with this firm foundation for a successful future project, clients can have more confidence in choosing the optimal path for success.

Conclusion 

The Discovery phase is often an essential first step in many projects, especially in Agile delivery, a popular approach to software development. Agile ensures technology is built in a way that adapts to the needs of the business in an ever-changing and increasingly competitive landscape.

Ultimately, an effectively managed Discovery can be the difference between project success and failure.

To find out more, visit our Discovery page