“Discovery” is a term used to describe an introductory phase of a project focused on aligning expectations, exploring assumptions and agreeing on goals and scope. Those in the know often shorten this term to “Disco”, but rest assured they’re not dancing to multicoloured swirling lights – rather, they are collaboratively agreeing on the desired outcomes of the project and then defining the work and delivery plan to achieve those outcomes. Harnessing the power of an Agile approach, discovery is a fundamental element of any project that, crucially, takes everyone’s assumptions, which are often quite different, and aligns them to a shared vision and understanding.
Have you ever been weeks or months into a project and realised there were multiple interpretations of what you were building? Or quickly learned that no one had a clear understanding of their role in the project’s success?
“Discovery” is a term used to describe an introductory phase of a project focused on aligning expectations, exploring assumptions and agreeing on goals and scope. Those in the know often shorten this term to “Disco”, but rest assured they’re not dancing to multicoloured swirling lights – rather, they are collaboratively agreeing on the desired outcomes of the project and then defining the work and delivery plan to achieve those outcomes. Harnessing the power of an Agile approach, discovery is a fundamental element of any project that, crucially, takes everyone’s assumptions, which are often quite different, and aligns them to a shared vision and understanding.
In this article, we look under the hood of what a great Discovery looks like, who should attend, what you should do, and how to get the most out of conducting your disco to ensure your project is set up for success.
Process
Why?
Nearly half of IT projects fail or exceed their original budget. There are a lot of factors to blame for that number, but one way of preventing project failure is having a thoughtful Discovery phase before jumping head first into delivering products or services.
The reason for Discovery is to set up the team(s) for success, gain a shared understanding of the intended business outcomes, Minimum Viable Product (MVP) requirements, and potential obstacles, and enable you to enter the Delivery phase of your project with confidence. While this phase of work doesn’t always produce deliverables pertaining to the project objectives like the Delivery phase, it does deliver a high-level work breakdown or roadmap and a healthy backlog for at least the first sprint. The actual value lies in preventing risks, rework or unhappy stakeholders later down the line – ultimately setting your project up for success.
When? (and how long?)
The Discovery phase will be in between your initial idea and when you start to build/deliver your project – “Delivery Sprint 1”. When planning the schedule of your Discovery, avoid any unnecessary pauses between the conclusion of Discovery and the inception of Delivery. The Discovery period will provide lots of momentum to your team that you won’t want to waste or risk forgetting.
Whilst we are referring to Discovery as a kick-off phase to a project, it’s important to recognise that “discovery” as a concept doesn’t end with the Discovery phase. Teams often unearth additional unknowns during Delivery, requiring an Agile approach in clarifying and addressing these gaps in knowledge in a way that promotes continuous re-integration of new learnings – Continuous Discovery happens throughout the project lifecycle.
As a rule of thumb, the duration of the initial Discovery phase should only be about five percent of the project’s overall time and budget. For example, if the project is estimated to take three Sprints (six weeks) to complete, you’ll want to dedicate about two full days to Discovery. If your project is larger and estimated more toward six months, you’ll benefit from a full 2-week Sprint for Discovery.
Who?
The same team that will deliver the project should also be involved in Discovery, along with other relevant stakeholders. Typically, the Product Owner (PO), Business Analyst/Owner, and Subject Matter Experts (SMEs) will define the “What”, “When” and “Why”, while the Delivery Team will define “How”. SMEs can extend beyond the obvious technological experts. Within the customer domain, the users of the end product often have important insights and feedback to share that could influence the direction of the project.
A Delivery Lead, Scrum Master or Project Manager typically has the responsibility of coordinating Discovery, but could also be a technical leader or other stakeholder depending on the contract, availability or project context.
How?
Discovery comes to fruition through conducting a series of team events, the production of supporting artefacts and just enough analysis & planning to set the team (and project!) up for success. There are tons of resources available on facilitating team events and producing artefacts as described in the Example Discovery Checklist above, so rather than delve into a novel of information here, we will highlight each step, what each step is trying to achieve, and the tools or approach you can use to achieve those things. Note that some steps may or may not be applicable depending on the scope and duration of your project.
Kickoff session
Goals
- Team introductions
- Agree on roles, goals, logistics, and ways of working for the project
Tools/approaches
- Ice breaker
- Vision statement activity
- Role expectation matrix
Design Session(s)*
Goals
- Understand the jobs, needs, wants, and pain points of our end users
- Unpack the current processes and steps a user goes through to identify points for improvement or automation
- Collaborative sketching around how the solution could look like
Tools/approaches
- Personas,
- Journey mapping
- Concept sketching
- Empathy mapping
- Storyboarding
Technical Session(s)*
Goals
- Unpack the technical landscape & understand the target state
- Identify the challenges in bridging the gap between the current and target state
- Set expectations on testing
Tools/approaches
- Walkthrough of technical environment
- Current vs future solution mapping
- Metrics, tables & source system mapping
Feedback Session
Goals
- A chance for the team to showcase the current state of the prototype/MVP and receive feedback from end users. This ensures the team is on the right track and can update any changes necessary before the end of discovery.
Tools/approaches
- Outcomes of previous sessions to be shown & feedback collected upon
Showcase
Goals
- Showcase outcomes for the completed discovery week(s)
- Final alignment/goal/scope to be locked-in
- Discuss next steps for upcoming delivery sprints
- Opportunity to gather feedback from the wider stakeholder group
Tools/approaches
- Recap of the discovery process sessions
- Prioritised backlog
*interchangeable order between the two
Discovery challenges
Authority
| Challenge: | The sponsor or PO is not authorised to make decisions or doesn’t understand the vision of the project. |
| Solution: | Be clear with the client before starting Discovery and explain what their role entails. Ensure the named sponsor/PO has the power of making decisions regarding the project and is accountable. |
Unavailability
| Challenge: | Unavailability of the sponsor, key stakeholders, SMEs and/or PO. |
| Solution: | Reiterate the importance of their participation and input. Work with the individual(s) to create a schedule that works for them. If this is not possible, discuss delegating or replacing that role with someone who is available throughout the entirety of the project, including Discovery. |
| Challenge: | Difficulties organising workshops due to agendas, time constraints and distribution. |
| Solution: | Highlight the time commitments required as early as possible. If possible, obtain a verbal agreement by stakeholders to a preset schedule that works best for everyone. Compromise is key! |
Group Dynamics
| Challenge: | Lack of a competent facilitator. |
| Solution: | First, communicate specific feedback to the facilitator. Provide support and resources for them to grow. If the facilitator continues to lack the skills necessary to produce the intended outcomes of Discovery, course correct and consider a more senior level facilitator, giving the option for the original facilitator to learn from them. |
| Challenge: | Dominant personalities in the group. |
| Solution: | By fostering a culture of psychological safety, ensure there is explicit time and space for those on the team with less dominant communication styles to share their ideas and opinions. |
Timing
| Challenge: | Allowing too much time to pass between Discovery and Delivery, causing Discovery activities to be redone because of requirement or team changes. |
| Solution: | Plan Discovery to be right before Delivery. This can be done once the project commencement date has been locked in. |
