Discovery: Going Where No Person Has Gone Before
Typically, at the beginning of a project, we begin by collecting requirements from the business. We might spend a month or more gathering requirements. If we are using a more Agile approach, we may spend a few weeks gathering requirements for the first few iterations in the form of stories.
Every once in a while, I find myself starting a project where for every step forward we seem to be taking two steps backwards (or at least sideways). Let me explain: As soon as the development team starts to code, literally within the first week or two of coding, the change-requests start. Does this mean the business is already changing their mind? We are just beginning to code!
So how is it that the business is changing their needs within weeks of starting a project? I can see change requests occurring once they see some initial software delivered. But why do we regularly see projects with change requests before the business even sees a deliverable?
We might assume that we had the wrong stakeholders in the room. Another potential cause could be that we didn’t do a great job collecting requirements. Certainly, there are projects where one or both of these problems exist.
But what I often find is that the project is suffering from a case of “Discovery”. More specifically, the business is stuck in Discovery and is not ready for Definition.
Discovery vs. Definition
Let me contrast the difference between Discovery and Definition. Put simply:
Discovery is the phase where the business identifies what problem to solve as well as a description of the end-state or goal of the project.
If Discovery defines what problem to solve, then Definition defines the path to the solution. In other words, the Definition phase focuses on how we are going to achieve the end goal.
An Example:
A small company is in growth mode, doing very well. At a recent Board-of-Directors meeting, the company’s management team was asked how they can continue their revenue growth over the next two or three years.
They currently develop advanced Word Processing solutions for Android products. Their solutions are customized to that platform and to take advantage of all the Google Android features, giving a rich experience on a mobile platform.
To increase revenue, they can choose to develop a complimentary Spreadsheet tool for the Android platform, providing the same, rich user experience and Google feature integration. On the other hand, they can choose to create an identical Word Processor and user experience on other mobile platforms such as iPhone and Blackberry mobile devices.
There are probably other paths as well, all providing a path to their continuous revenue growth. At this point, we are “Taking a single goal and generating multiple ideas.”
Moving from Discovery to Definition
After much research and due-diligence, you conclude that the best direction would be to offer your current Word Processor and all of it’s rich user experiences on the iPhone and Blackberry platforms, solidifying your brand as “The Mobile Word Processor. Period.”
At this point, we have completed the Discovery phase because a decision was made on the overall goal. Now, it’s time for Definition.
In Definition, we begin to define the path to that goal. We start to define the key features that MUST be in the iPhone version and how we will replace Google Android features within the Apple iPhone environment.
Clearly identifying this feature list is what is called Definition.
So Why Should We Care?
If you are trying to define the requirements for a solution, but your business stakeholders are still discovering what they call success, then you are destined for rework! And this will show up as:
- A proliferation of change requests early and often
- Slipped schedules, since they didn’t anticipate these discovery changing goals
- Budgets being blown since they didn’t anticipate the increased costs associated with rework
Because they are still in Discovery, we can’t be sure of the right direction. Any step we take could cause rework that translates into budget and schedule variances.
My guess is that you could think of a project or two right now where the business stakeholders were probably not ready to define their system. And, most likely, this “re-thinking” of their projects goals created a great deal of pain for everyone involved.
So What To Do?
When you are collecting requirements, or engaging with the business, if you believe they are not ready to define how the system will work, you need to “pop-a-level”. I use this term when I want folks to take a step back, and take a different view.
So if you suspect you are being setup for a great deal of rework, then pop-a-level and ask your business team:
- Do you have the right Subject Matter Experts who are knowledgeable and empowered to help define your needs?
- Are you still in Discovery? Are you unsure of what a clear definition of success is?
In either case, try to create transparency around the issue, highlighting the potential costs of continuing to move forward when the wrong stakeholders are involved or the goals are fuzzy.
Realizing your project is in Discovery is half the battle. No matter what’s ahead, this realization will enable to you stay on course and manage the project more effectively.
Have you experienced Discovery? Please share your experiences in the comment area below.
Category: Business-IT Alignment, Defining Success, Requirements Definition