In recent years, and especially in custom software development, we have seen a pattern where more and more companies kick off their digital initiatives with a deep dive into the subject area and specifics of the business problem that they set out to solve.
Sometimes, however, the problem is even not yet fully defined, so the companies start by collecting all the relevant data, defining alternative paths, and running proof-of-concept and pilot projects before they sign off on bigger, full-scale digital initiatives.
Business Analysts, Product Owners and other industry professionals call this deep dive – Requirements Discovery phase of the project, or simply – Discovery.
Photo by Ketut Subiyanto
In my more than 17 years of experience in running and participating in digital projects, naturally, I’ve been involved in multiple discovery initiatives. As it happens, different companies have different approaches to how they handle their discovery efforts - some focus more on user research, service design, and defining new business capabilities, while some start with data flows, defining as-is processes and related pain points.
With all that, however, certain common things happen all (or almost all) of the time during requirements Discovery. In this post, I’d like to summarize some fundamental principles that I hope will help you be prepared and successfully plan, run and complete Discovery engagements for your digital initiatives.
So What Is It Again?
First, let’s explore where Discovery sits in the overall project lifecycle, this will help us better understand what happens before and after Discovery, what is its focus and duration, compared with other project stages.
On a very high level, almost every custom software development project has at least 4 distinct stages - Presale, Discovery, Delivery, and Hypercare.
The goal of the Presale stage is to grasp and understand the business opportunity, develop the business case and get preliminary approval from the senior stakeholders.
Discovery - is where we go deep dive into the customer's subject matter, understand their business processes, use various requirements elicitation techniques, run the interviews, and workshops and collect all relevant data.
After we launch the product, we'll need to reserve resources to operate and maintain the system. We call this Hyper care.
As a result of the discovery, business analysts capture and set expectations for the Minimum Viable Product (MVP) and related business, functional, and user requirements. Based on these requirements, project leaders define implementation estimates, timelines, and resource plans required to build the new solution.
Artifacts, produced as a result of Discovery should be sufficient to start the Build phase and guide the team through the implementation and acceptance of the software development project.
Discovery Stages
In custom software development, almost every Discovery typically consists of the Preparation, Execution, and Analysis&Transition phases.
We'll look at all these steps in separate articles, but here’s in a nutshell:
During the Preparation, business analysts collect all the information that is already known from the presales or open sources and create agenda for the workshops and the interviews. BAs also define what exact requirements elicitation techniques they will use during the discovery workshops, along with related questionnaires, and other materials.
After that, BAs and other team members Execute discovery workshops using interviews, show-and-tell, and other types of meetings. In the post-pandemic era, we see a prevailing hybrid execution model with the usage of both onsite and remote meetings.
During the Analysis and Transition stage, business analysis and other team members prepare the resulting outcomes: features lists, user experience wireframes, high-level user stories, and project plans and smoothly transition the project to the Build phase, also often called the Delivery phase.
What's Next?
In the next articles, we'll talk about assembling a discovery team, preparing for the discovery, planning, building an agenda, scheduling, leading discovery meetings and workshops, capturing results, and sharing the outcomes with the delivery team and the client.
Learn More
Interested in learning more? Check out my Discovery crash course on Udemy, where I teach business analysts and product owners all the fundamentals of requirements discovery (typical stages, team structure, meeting types, outcomes, and common mistakes) within less than one hour!
Comments