You don’t need to go through a costly Discovery exercise!

AI Generated image of a client asking a delivery manager to save costs by removing the discovery phase.

A bit of tongue in cheek, and provocative, however I have had many clients tell me that they do not need a discovery as either :

• “we already know exactly what we want” or
• “we have been through an internal discovery process, and therefore you do not need to run one.”

Instead of accepting this or dismissing it out of hand, I want to explore what would need to be true for the above statement to be acceptable, i.e. in what circumstances is the client right.

First, let us remind ourselves what the purpose of the discovery phase in a software project is and why it is important.

At the fundamental level, it is there to ensure the success of the program. It does not take a genius to realise that investing a bit of time at the beginning of the program to reduce the chance of expensive failure at the end should be money well spent. Therefore, every program should run and invest properly in a Discovery.

In fact, running a discovery may save you money if after doing one you discover that there is no way that the program will meet your objectives, and you abandon it for something more valuable to the organisation.

A discovery is an initial step where the SI works closely with the client to gather information, understand the business context, and define/scope the project requirements. This latter step is even more important when you decide what you will not do, as everyone will look to the program to fix all the ills of the business.

The discovery phase is essential because it sets the stage for a successful project. Without it, the project may face unforeseen issues, misaligned expectations, and significant risks, leading to increased costs and potential failure.

A discovery is not part of your scope that can be cut. It is a key element of your programme!

In summary, the objectives of a well run discovery are:

• Understand Business Needs — goals, pain points, success measures and constraints. It aligns the technology solution with the broader business strategy.
• Clarify Scope — the boundaries of the project. What is included and more importantly what is excluded. This prevents scope creep and ensures everyone has a shared understanding of the deliverables. It helps avoid assumptions that could derail the project later on.
• Identify Stakeholders — obtain buy in from the inception of the program and identify the decision makers. Key to learning who will provide input or approvals.
• Assess Current Systems and Processes — investigates existing workflows, tools, systems, and technologies to understand what is already in place and how the new solution will fit into this landscape. It helps uncover legacy system constraints, integrations and/or dependencies.
• Define Requirements — gather functional and non-functional requirements. This ensures the program understands exactly what the software needs to do. This includes business rules, user stories, data requirements, and integration needs.
• Risk Identification — identify potential risks early, including technical challenges, business process impacts, or security vulnerabilities. It allows for risk mitigation strategies to be planned ahead of time.
• Determine Technical Feasibility — evaluates whether the goals are achievable with the current technology stack or whether new infrastructure, systems, or integrations will be required.
• Develop High-Level Solution Design — create a high-level architecture or solution blueprint that outlines how the software will work and interact with other systems. Importantly, this is based on the information gathered in the previous steps.
• Cost Estimation and Timeline Planning — based on the gathered information, provide a more accurate estimate of the costs involved and to develop a realistic timeline for delivery.
• Alignment of Expectations — ensures all parties (SI, client stakeholders, technical teams, etc.) have a shared understanding of the project’s goals, scope, and approach, minimizing misunderstandings later in the project.

The above is a lot of crucial work that helps ensure the project’s success.

Can you shortcut some of it? Absolutely!

Will a shortcut to Discovery contribute to the success of the project/program. Absolutely not!

So let us assume that the client has run a comprehensive discovery process. What are the outputs they would need to provide to their delivery partner to help ensure the success of the programme?

• Comprehensive Documentation — A detailed document (often called a Business Requirements Document or BRD) outlining the project’s scope, requirements, business goals, and technical details.
• Clear Project Scope and Requirements — A well-defined scope statement that eliminates ambiguity about what is included and excluded from the project, and a fully elaborated / prioritized list of functional and non-functional requirements.
• Solution Design/Architecture — A high-level technical solution design that shows how the new system or software will be built and how it will integrate with existing systems.
• Risk Assessment and Mitigation Plan — Identification of major risks to the project and plans/costs to mitigate them.
• Project Timeline and Milestones — A realistic timeline for the project, including major phases, dependencies, deliverables, and milestones.
• Cost Estimate — An accurate estimate of the total cost for the project, including development, testing, implementation, and post-launch support.
• Alignment with Stakeholders — Confirmation that all stakeholders are on the same page regarding the goals, timelines, and approach to the project.
• Defined Success Metrics — KPIs and metrics that will be used to measure the success of the project, ensuring alignment on how success is defined and measured.

Also remember that you will need to allocate some time for your SI partner to absorb and process this information, which yes will be less than the time to run a discovery, but is not trivial.

Most significantly, as the client has produced this thinking and owns the outputs, they assume full responsibility for any gaps or misunderstandings that might arise later in the process.

And finally, let's remind ourselves of the benefits of a discovery phase, just in case it is not evident from the above.

• Reduced Risk — understanding the full scope and identifying potential risks early, the project is less likely to face costly delays, rework, or failures.
• Improved Communication — It enables clear communication between the SI and the client, reducing misunderstandings and ensuring alignment.
• Better Project Planning — It leads to more accurate timelines, budgets, and expectations, which is vital for project management and setting internal expectations.

And ultimately, which for me is the key reason everyone is telling you to do a discovery …

Higher Success Rate — Projects with a comprehensive, well executed discovery phase are more likely to succeed, as they are built on a solid foundation of knowledge, requirements, and planning.

Thoughts? Do you think discoveries are just a way to make more money and therefore unnecessary? Do you think that agile discoveries turn agile projects into our much hated waterfall projects?