Top page background

Planning & Prototyping

Software project projects can be delivered faster and better results by introducing a discovery phase upfront.

The Discovery Phase

Before committing to building a service, it is imperative to understand the problem that needs to be solved.

  • Identify your users and what they’re trying to achieve
  • Identify any constraints you’d face making changes to how the service is run – (e.g. legal or technology related)
  • Identify opportunities to innovate or improve things

The knowledge, solutions and flows you accumulate during the discovery phase should help you work out whether you want to move forward to the implementation phase. Continuing to implementation phase means that you’ve decided that the benefits of looking further into the problem outweigh the cost.

Asa a general rule, we will not start building your service in discovery phase.

How long will Discovery phase take?

It depends on the project, but generally anything from 2 to 6 weeks is a reasonable amount of time to allocate to the discovery phase. However, if your project involves problems which have not been researched before, it may need a longer period of discovery.

Defining the problems

At the start of the discovery, it is useful to define the goals and the problems, as well as break down assumptions. Reframing the problem also includes agreeing what is not part of the problem.

For example, a problem is not: “We need to build an interactive map to show people where our contact centres are”. It’s probably something like: “How can we make it easier for people to find their nearest contact centre if they need to book a face-to-face appointment?”

What to focus on during the Discovery phase?

Once you’ve set a goal for your discovery and understand the problem you’re looking into, you’re ready to start research.

1. Understanding users and their context

Start by learning about your users and their context. This means understanding what the user’s trying to achieve and how they go about doing it, then developing a picture of what that wider journey looks like.

2. Understanding constrains

You’ll need to understand any constraints you’re likely to come up against if you were to move on to the implementation phase. This includes constraints due to things like:

  • legislation
  • contracts, licenses
  • legacy technology
  • existing processes and systems

Some constraints are soft constraints, though. For instance, if existing processes (whether in digital, call centre or paper-based teams) are preventing you from delivering the best version of your service, you’ll need to work to change those processes – do not just work around them.

If there’s a hard constraint which means you are not able to improve on the solution that’s currently available, it might be worth stopping at the end of discovery.

Known constraints can help you prioritise your risky assumptions if you do continue onto implementation phase. For example, if a service will only be viable if you can change an existing process or structure, you’d want to focus on ways of doing that during the implementation phase.

3. Identify opportunities to innovate or improve things

One of the benefits of understanding the user’s wider journey and who’s involved in delivering it is that you can spot things that could be improved. You could take these improvements on to later development phases.

What to skills are needed for Discovery phase?

During the discovery phase you’ll need a team with the skills to:

  • research and understand the user need for your proposed service
  • be aware of other services that exist and their development plans
  • start planning what your initial prototypes will explore

This means you should have the following roles:

  • a business analyst
  • a user researcher
  • a designer (UI/UX/Content, depending on the case)
  • a developer

The outputs

The discovery outputs are important documents which will be used during the implementation phase. Here is a list of the outputs which Atomate will usually produce

  • Project Requirements Specification Documentation – describing the project, features, solutions, flows and requirements. It also usually includes so-called User Stories, ready for the developers to use during implementation.
  • Architectural notes – describing suggested technical stack, architecture overview and implementation notes for developers and notes on testing strategy for QA analysts.
  • Preliminary UX Prototype – allowing you to understand and change the the user flows early
  • Development plan – a detailed development timeline and budget

Grow faster with Atomate

Connect with us

Explore more

Development & Integration

Read more >

Maintenance & support

Read more >