A good discovery will set a project up for success, whilst a bad discovery will do the opposite. In this article I’m going to explain what I think makes a discovery successful. This applies whether you are a providing the discovery service or are an end user of it.
Rule 1: Understand The Audience
With any discovery, the first thing I need to understand is who the intended audience is and what are their needs. This will fundamentally change the level of information I need to capture and how that information is presented.
Typically, management require a very different level of information relative to the development team. This is because management are often primarily concerned with assessing scope, timescales and cost, whilst the development team are primarily concerned with what the solution must do and need an actionable level of detail.
Not only does this fundamentally change the content of the discovery pack, but also it’s presentation. Management are usually drawn to high level conceptualisations, whilst the development team need to work in the long grass of the detail in order to build the solution.
The first rule of discovery is therefore you should always be clear who your audience is, and the discoveries intended purpose.
Rule 2: Understand The Discovery Outputs
And this brings me to rule 2 which is to fully understand the intended outputs of discovery. A good discovery isn’t just about understanding the requirements.
I’ll go into the actual requirements capture element in later sections, here I want to highlight Other [MH1] outputs that are often overlooked.
Is the Juice worth the squeeze?
One of the most important outputs of discovery is to determine if the project offers enough business value to offset likely costs and make it worthwhile to pursue, in other words, is the juice worth the squeeze? This can save millions of pounds in development costs.
There is often an unconscious decision that the project will proceed, which can be a mistake, and nowhere is this more evident than when the development and test team are brought in during early discovery.
Determine the Right Technology Choice
Another key output of discovery is to determine a suitable technology choice. Understandably, not all technologies suit all situations.
Again, bringing in developers early often indicates a subconscious choice. Typically, developers have specialist skills and so in selecting your team early, you are often selecting your technology.
Organisational Readiness
When conducting a discovery and thinking about a solution, I am also assessing the organisations readiness to implement it. This could be down to stakeholder sentiment, the organisation not having a clear business operating model, or when recommending a low-code platform, is the organisation willing to accept the compromises this brings in order to realise it’s value?
Organisational readiness has a huge impact on the success of the project and so it should never be assumed or glossed over.
Rule 3: Avoid The Morecambe & Wise Paradox
When you sit back and approach discovery logically, there is a logical sequence to events.
1. You need to understand the problem first, the ‘As is’.
2. You need to understand the desired state, the ‘To be’.
3. You need to understand the high-level solution that gets you from the ‘As is’ to the ‘To be’.
4. You need to understand the detail of the problem and the solution.
5. You can then use that knowledge to estimate how much effort is required.
6. You can then plug that effort into a cost model to provide a time and cost estimate.
In practice, it rarely happens so cleanly. Organisations often need to know the solution, timings and costs before we know what the problem is. This in order to justify releasing the funds to do the discovery properly and understand the problem space.[MH2]
I call this the Morecambe & Wise Paradox in reference to a classic sketch from the Morecambe & Wise show in 1971. Legendary music conductor Andre Preven complains that Eric Morecambe is playing all the wrong notes on the piano, to which he replies, “I’m playing all the right notes, but not necessarily, in the right order”. This is often how it is in discovery.
The lesson to take away from this is that discovery is never ‘complete’ as there is always more detail to learn, detailed planning should not begin until we have a ‘sufficient’ level of understanding and a clear picture of what it is we need to build. Without this, any estimates are uninformed.
Rule 4: Get the Team Size and Composition Right
Another key element to success is the team, size, and composition, and in my experience, it is usually better to be slightly under resourced than over resourced during the discovery phase. Generally, a ‘long and thin’ and approach to discovery works well, where few, even singular resources gather requirements over a longer period of time rather than trying to complete a rapid discovery with a larger team. This is for a number of reasons which have proven universal across many discoveries.
Limited PO and SME Availability
A key argument for limiting the size of the discovery team is that during discovery the biggest limiting factor is usually the availability of the PO and SME team for engagement, and this can lead to an underutilisation of discovery resources.
Burn Rate and Pressure to Start
Another is the larger the team, the greater the monthly cost of running it, known as the ‘burn rate’. A high burn rate often puts a pressure on the management team to just start building, to build anything in order to demonstrate value and this often sets the project up for failure. This is particularly true where developers and testers have been brought on to the team early.
Rule 5: Start at a High-Level and Work Down
When it comes to actually gathering requirements, a key practice I employ on all of my discoveries is to start at a high level of detail, typically a swim lane diagram, and then work downwards. This has a number of advantages I’ll describe below.
1. By starting with a high-level diagram, it is easier to grasp the overall problem and what the organisation currently does and what we need to build without getting lost in the detail.
2. It can be used to quickly define the overall scope of the project, which stages of the process are in scope, and which are not.
3. It serves to frame discovery sessions so that we can work through the business process from start to end, keeping the group focused on that process.
4. It provides a map with a clear indication as to where we are in the discovery, with stages completed and stages left to discover.
5. It can help to drive out requirements by asking what is required at each stage of the process.
6. It helps to organise and categorise the information discovered so that it becomes meaningful, and I can understand how it is relevant.
In my experience, where the organisation insists on going straight to the detail, it often takes a lot longer to fully understand what we are trying to achieve, causing the discovery to ‘drift’ without a clear direction, and so I see this practice as instrumental to a successful discovery.[MH3]
Rule 6: Make Your Requirements Traceable
Related to the high-level business process and what enables the benefits highlighted earlier, is maintaining a clear traceability between each requirement and the stage in the business process to which it relates. This can be achieved in a number of ways.One simple method I use is to number each stage in the business process, and then simply prefix each user story with the stage it relates to.
By doing so, we build a very clear understanding of which stories relate to which stage, which is incredibly powerful, particularly with large and complex backlogs which evolve over time.
It allows me to view all of the stories relating to a particular business process stage next to each other, which can either drive out contradictions or very quickly identify gaps in understanding.
This direct mapping of stories to process is also incredibly useful when it comes to tracking and reporting progress. It is very easy to see how many stories on each stage are left to do and on completion of the business process diagram, stages can be colour coded to indicate status to provide a visual representation of progress.
This approach is particularly useful where the scope of the project is in flux, perhaps due to budgetary constraints or an evolving business operating model. As the operating model changes, affected stories can quickly be identified and the impact on stories relating to neighbouring stages assessed.
Rule 7: Secure User Engagement
One of the most important deciding factors affecting the success of a discovery is the amount of engagement from the end customer’s Product Owner (PO) and their Subject Matter Experts (SME’s). Essentially without regular engagement the BA or FC is guessing the business needs.
Getting engagement at the right level and quantity is more challenging than it sounds due to a number of factors:
The first is availability, particularly when it comes to the PO. A good PO has detailed business knowledge and operates at the level where they are given the authority to make decisions on prioritisation and project spend. An individual with these qualities who also just happens to have sufficient free time can be like finding the proverbial Unicorn!
One method around the PO’s time constraints is to devolve specific authorities to a named individuals within an SME team. However, try to avoid more general devolvement of authority to a group of SME’s as it can result in disagreements without a clear escalation path as to whom has ultimately authorised a piece of work.
A useful technique to secure PO and SME time is to setup a regular cadence of meetings. This blocks out the time in their diary and allows you to get ahead of the business-as-usual demands on their time.
In my experience failure to secure sufficient PO or SME time should always be called out as a risk and actively managed. For example, it may be necessary to scale down a discovery and team in order to fit with availability by going ‘long and thin’.
Rule 8: Define Entry and Exit Criteria
Discovery is uniquely difficult to project plan because it is fundamentally aimed at uncovering what is unknown and that makes it difficult to accurately estimate. We simply don’t know what complexities or issues will arise until we get into it. In practice, discovery is also never complete, instead we simply develop an ever-clearer picture over time.
Add to the constraints around PO and SME availability and it becomes clear that managing to a project timeline is imperfect at best. Whilst attempting to fit within an overall project is necessary to try and fit with wider project orchestration and planning, we also need some objective measures of progress, and this is where defining entry and exit criteria can really help.
Entry Criteria
Entry criteria define those things that need to be in place before discovery should even start. There are many you could use; some common criteria I would look at include;
1. Stable Business Operating Model — Any solution I develop is designed to support a Business Operating Model. Every feature, function or assumption is based upon it. Trying to discover requirements without a stable operating model is like trying to build on shifting sands, there is simply no foundation on which to base it.
2. Identification and securing of a PO and named SME’s — without SME engagement, I can only guess what is required.
Exit Criteria
Exit criteria are those things required to officially exit the discovery phase and begin development, or to move between various stages of discovery. For example, when operating within the GDS framework on public sector projects.
Whilst this list is not exhaustive, some common exit criteria I would define before beginning development include:
1. A problem statement — which defines the problem we are trying to solve
2. Project Scope — what does the project encompass?
3. Constraints — These could be legislative, contractual, technology based, process or human.
4. ‘To Be’ process map
5. Volumetrics[MH4]
6. Entity diagram
7. High level design
8. Initial effort estimate
9. Business value assessment
10. Success measures
11. High level project plan
12. Organisational owner sponsorship
13. Ways of working
14. Backlog of requirements
15. Stakeholder map
16. Risks, assumptions, issues, dependencies and opportunities (RAIDO)
Rule 9: Use Appropriate Methodology
Another factor affecting discovery are the methodologies used. Whilst I won’t run through an exhaustive list, these are some of the methods I find most useful. The key lesson to take away from this section is that if you only rely on workshops, you are missing out on important tools that you should have in your armoury.
Workshops
A workshop is a structured, collaborative meeting, and for many, the only method they are aware of. A workshop is a great option when there is a need to build consensus amongst different parties. I will often use workshops when there is a need to agree a way forward, to update a group of people or to build stakeholder buy-in.
As useful as the workshop is, it isn’t always the most efficient way to elicit detailed knowledge. Without careful planning and facilitation, workshops can float adrift, pulled by the ebb and flow of competing opinions and interests.
The key to making a workshop effective is understanding it’s purpose and to carefully select attendees. This itself is an art form and beyond the scope of this article.
Interviews
A one-to-one interview is exactly as it sounds and is possibly the most efficient of all methods to elicit requirements.
It comes into its own when there is a need to understand a specialised business process or need that is clearly defined rather than where a consensus may be required.
Interviews are incredibly efficient because they allow a highly focussed discussion without the interruption and distractions of a group discussion. They are also very respectful of an SME’s time, requiring them to be present only when they are directly contributing, where a workshop often requires them to sit through conversations in which they are not involved.
Interviews are often much easier to facilitate too, through only needing to find an available slot in one person’s calendar and can easily be carried out online.
Observation
Observation involves observing people do their work and is the only way of uncovering important details that those being observed are not aware of themselves, and so would not think to tell you about at a workshop or interview.
For example, I once reduced the lead time of producing steel bars by 10 working days, simply by observing an order pass through from sales to production. During observation I noticed that an order was passed from one person’s in-tray to another’s without any action required. This was repeated several times down a chain of people until it got to where it needed to be. It had always been done that way, and nobody knew what each person did with it. By identifying this I was able to re-route the order directly from the originator to the final recipient.
Observation can be an incredibly insightful technique to use, particularly when looking at application interfaces and user experience.
Artefact Analysis
Artefact analysis is another unsung hero when it comes to eliciting requirements. It can be a great way to uncover policy, rules and regulations, particularly when it is not well understood by the SME’s, which can sometimes be the case.
Artefact analysis is also my go-to method when it comes to uncovering detail around data integration and capture. By analysing existing paper-based forms or database tables, I can get to the required level of detail far faster than I could during a workshop.
Surveys and Questionnaires
Surveys and Questionnaires are a useful tool when it comes to gathering targeted metrics and other quantifiable information. They can also be used to gather qualitive information from a wide audience, for example if you are looking for product feedback.
Anonymous surveys can be incredibly useful in organisations where stakeholders do not feel they can speak out without negative consequences.
Rule 10. Command and Control
During discovery it is normal to uncover requirements from SME’s that the PO does not want to pursue. Likewise, end users will sometimes talk directly to the development team to sneak requirements in through the ‘back door’. As a result, the PO sometimes feel like they are losing control of the project which can lead to a number of unwanted behaviours.
One way to avoid this situation is to proactively define the ways of working and command and control mechanisms to ensure that only the user stories that the PO has prioritised and approved are put forward for consideration. This can take many forms, from prioritisation sessions to a stand-alone activity by the PO with their team of SME’s.
The key take-away is that this process is agreed in advance in order to reassure the PO that they retain full control of their backlog and that developers do not do ‘favours’ which can redirect effort from the PO’s priorities.
Rule 11. Build Credibility
Another key factor in discovery is whether the BA or FC is able to build credibility with the PO, SME’s and wider stakeholders. This goes beyond doing a ‘good job’ by demonstrating you understand the organisation’s processes and needs, and extends into learning how to build trust and relationships with a wide range of people.
For example, when conducting a discovery with floor workers in a manufacturing facility I will lean into my working-class background, and when talking to White Collar professionals I will lean into my current situation. It’s partly to do with identifying a particular group’s pain points and showing empathy towards them, but it’s also about demonstrating that I understand people’s processes, constraints, and terminology to help create the conditions for open discussion.
One way of achieving this is by mirroring their language and organisational lexicon. For example, when undertaking a discovery for the military I have been known to use robust language and terms that I would not feel comfortable using in a non-military work setting.
Another is by always being honest and using clear language. There is sometimes a tendency in professional circles to try to reduce the negative consequence of bad news by using words that leave the message open to interpretation. In my experience by using clear and direct language without trying to obfuscate the message, it becomes easier to build trust and credibility.
Remember, updates are neither good nor bad, they are simply updates.
Rule 12. Include the Workforce
Sometimes, to maintain control, it can be temping for a PO to keep the discovery team away from those who carry out the work, often because they may have different opinions on the problems they face and what the likely solution looks like. It is for this very reason that they should be included.
In my experience those doing the work are rarely “wrong”, they are simply closer to the problem and therefore have a different perspective. This is not to say that the PO or management are “wrong” either, the reality is both groups often have a valid opinion based on their individual perspectives.
One of the main reasons it is so important to include the workforce is to secure stakeholder buy-in. It is important that the workforce feels the system is something that is done with them and for them, rather than ‘to’ them. Without stakeholder buy-in, it can negatively impact user satisfaction and adoption and in extreme cases even lead to sabotage.
Another factor is that whilst managers undeniably play an important role, it is the workers who carry out the bulk of the organisational activities and so productivity gains for the workers often have a relatively larger impact.
Rule 13. Discovery Specialists Should Lead
Hopefully it’s become clear over the article that there is a lot more to discovery than running a number of workshops. This is why in my experience they are best run by a specialist BA or FC as they are highly specialised roles that carry distinct skillsets rather than a general or project manager.
Most people who don’t write code understand why it would be ill-advised to open up the source code repository and start changing the code, but not so when it comes to discovery. Often non-specialists feel empowered to muddle through as the skillset is more nuanced and feels more accessible.
Technically I can plaster my own walls, but a specialist plasterer will always do a better job.
This issue of ‘muddling through’ is compounded by the fact that discoveries are rarely deemed to have failed. Whilst the root cause may be in the discovery itself, the symptoms only manifest in the ensuing project, and it is here the problem is usually attributed. For example, delays may be blamed on requirement churn or user training rather than not fully understanding requirements and securing stakeholder buy-in during discovery.
Why Bad Discoveries Happen
The process of running a good discovery is more nuanced than many realise. There are different flavours. For example whether the approach is user led, or designed to maximise the value from implementation of a product such as Dynamics 365. There are also different levels, for example I would collect a lot more detail in a waterfall-based project than I would agile.
It’s in that lack of understanding that I’ve seen projects fail, and often predictably so.
There is also a real risk that discovery quality could decline as AI allows people to carry out tasks more quickly and with less thought. If somebody does not understand the nuance of running a good discovery manually, how can they possibly instruct the AI?
AI absolutely does have a place in discovery, and I have developed several agents to assist. The danger I am beginning to see is where AI is used by people who do not understand its nuances and claim to have completed it ‘in hours’, perhaps by summarising a transcript of a meeting. If the nuance is not understood, and the various points are not discussed, no matter how good the AI is, it will never be able to extract it from a meeting transcript.
Summary
Discoveries make or break a project; it is not something you want to shortcut. An investment in Discovery now can save millions of pounds in development costs later and I have worked on several where I have saved the organisation lots of money by quantifying why a project wouldn’t provide the value they initially thought it would.
Despite this, discoveries are rarely defined as having failed as whilst the cause may often lie with poor discovery, the symptoms usually manifest in the ensuing project where blame is assigned.
Discoveries are something of an artform, best left to a specialist who fully understands them. But despite that nuance, there are definite rules and practices as outlined above which can significantly impact the success or failure of that discovery and its related implementation project.
If you want to learn more about the Microsoft Team here at Capgemini, take a look at our open roles and consider joining the team!
13 Rules for Good Discovery was originally published in Capgemini Microsoft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.