Kicking off a new project can be a daunting task. With a seemingly never-ending list of changing requirements flowing in from all areas of the business, it can be difficult to know what the priorities are and what’s just noise.
This can make even the simplest questions tough to answer, often leading to delays in decision making, money wasted on low-value features/functionality, and the enemy of all projects – scope creep.
This is what a discovery project is here to eliminate.
It’s a pre-cursor to any new initiative or wider project to prove the purpose, value proposition, and expectations of an idea before investing any money into it.
Discovery is about learning what you have, what you want, and what you need and helps you choose the right solution to invest in.
Questions a Discovery Project should answer
A discovery project occurs before anything is built and typically runs for up to 8 weeks.
However, this can vary depending on how many people are involved, how complicated the requirements are and how well defined the project has been beforehand.
It’s important that as many stakeholders as possible are involved, not just a project owner and a tech lead. The more information you can get from the people who will use or feel the benefit of a solution, the better.
What is the problem we’re trying to solve?
Quite often companies will define an objective by describing the solution i.e., “we want to move our data infrastructure to AWS” rather than “we want to improve our data infrastructure capabilities”.
While there’s nothing inherently wrong with having a clearly defined goal before discovery, it increases the possibility of missing out on a more suitable solution by being tied to one pre-defined fixed outcome.
This is where running a discovery project really pays dividends. Spending time to understand not only the problem but the root cause of the issue will allow for a solution designed to solve that specific problem, rather than meeting some abstract (and likely ever shifting) end goal.
How can we de-risk our delivery?
Once the wheels of delivery start turning, it can be difficult to shift direction. By uncovering as many of the unknowns prior to kicking off a delivery phase minimises the risk an organisation is exposed to.
Bad.Tools has the Cone of Uncertainty which visualises the uncertainty variance throughout a project across time/cost/quality elements. Early phase projects have a high degree of variance as there’s still a high degree of unknowns.
To put this in perspective a project with a £100k estimate pre-discovery could be as high as £400k or as little as £25k – but there’s no way to know this due to the number of unknowns about the project and its requirements.
If you were to dive straight into delivery of the initial idea with no discovery, there is a much higher likelihood of going way over budget and losing focus of the initial objective.
How much appetite for risk do we have?
Any new initiative will carry some form of risk, whether that be financially or operational.
Some organisations with a low-risk appetite may be happy to fund a proof of concept build in the discovery phase to prove out some of their ideas. Even if this ultimately gets thrown away, the lessons learned are far more valuable than the output as they now know what they don’t want.
On the flip side, higher risk organisations may be more willing to dive straight into building a minimum viable product (MVP) off the back of initial discovery, which while higher risk, can reduce the time to delivery and overall cost (if it all goes to plan!).
Can we trust this vendor to deliver?
More often than not, organisations engage with a third parties who have specialist skills to deliver a project. As with any new relationship, there’s an element of uncertainty on their ability to deliver on their promises.
They may have a really engaging, intelligent, smooth new business team, but then service level and quality outputs slip once it gets into actual delivery. The last thing you want is to commit to a £500k 9-month project only to realise 3 weeks in that the partner you’ve chosen isn’t up to the job.
Running a much shorter, lower value delivery project before any larger engagements allows for you to get to know the people who could be the ones implementing transformational change in your organisation, with the ability to walk away at the end of it if it’s not working out.
Typical outputs of Discovery
While each discovery project will vary greatly depending on the individual needs, the general outputs are usually the same. Some outputs may be:
Path/roadmap for next steps: a clear technical or non-technical plan for next steps in delivering a project.
Clear definition of project delivery outcomes: the purpose or outcome of a project may change throughout discovery as more requirements are defined – these will all be thoroughly understood aligning all stakeholders to run a successful delivery.
Pre-project requirements: a list of dependencies that must be addressed prior to delivery kick-off to ensure that the desired outcome can be met.
Improvement opportunities: any areas of the project which may have been overlooked in the initial scoping which, if included, would be complementary to the desired outcome.
Lessons learnt: all elements of discovery should be treated as a learning exercise which can be used to inform decisions on future project, strategies, and other business requirements.
A Discovery Project in action
It’s important to point out that not all projects are the same meaning not all discovery phases are alike.
The above information is what you would typically see in a discovery phase.
At Hippo Data, we run a discovery phase on as many of our projects as possible – it allows us to get a real feel for the company we’re working with, their requirements, and an understanding of the tech stack we’d be working with.
An example of a successful delivery we ran off the back of a discovery phase was for Ecology Building Society.
We ran a 3-week discovery where we engaged stakeholders to uncover compliance and reporting requirements.
This resulted in a series of options for delivery, including a finance and management reporting suite, which were presented to the board to decide on the best route for them. From this we went on to run a 3-month delivery project to implement the chosen option.
Always factor in Discovery
Running a discovery project may seem like an extra step for those on a strict budget or tight timescale, but diving headfirst into a large project before taking the time to fully understand what you’re aiming to achieve is only going to cause more pain, delays, and expense in the future.
For any new project you’re looking to kick off, you should always factor in some time and budget for discovery to give you direction and answers to fundamental questions before committing to the wider project.
Doing so will ultimately provide you with a more robust foundation for success.
