Guest blog by Jon Pugh
The absolute number one question on my clients’ minds is, “How do I get the biggest bang for my buck!?” This is the third installment of the Road to Discovery series and it’s all been building around a certain theme: getting the most value from your paid discovery (remember: a problem well-defined is half-solved.)
Essentially, we invest in discovery to nail down a moving target so we can hit it in one shot. The alternative is doing just enough to identify the target, but wasting efforts chasing it as it maneuvers around the landscape of the project. We put our full weight into discovery because loose requirements and undocumented end-user expectations introduce more risk to a project than any other factor. You’ll see this risk manifest as (among others):
- Late start to development
- Longer testing cycles
- Low user adoption
Sound familiar? Challenges like these add more time and cost to projects and really become a project management nightmare because they diminish one’s ability to effectively plan for the current project, let alone other projects that may depend on the same resources.
A lot of work goes into a successful discovery and what’s great is that the business unit can drive much of this effort before we ever even sign an agreement.
Here are ways you can get the most out of discovery:
1. Meet internally.
to create consensus about the current-state process and future-state objective. Flowcharting helps things along a great deal!
2. Define the business problem.
or mission statement of the project beforehand.
3. Prepare sample documents.
or data containers that the solution will need to manage.
4. Schedule discovery participants that represent every aspect of the process.
Don’t forget technical experts who know the third party applications involved.
5. Schedule the ideal room for the discovery meetings.
Preferably, one with windows (remember, these are long days!) Rooms with a whiteboard or a projector work great.
6. Make sure you automate “worthy” processes.
When automation is tacked on to a bad process, it can actually enable it to produce more mistakes. If the discovery effort unearths a faulty process, we’re going to spend time together fixing that issue before we can actually get started defining software requirements. Before you automate the process, make sure it’s the one you want to invest in.
With all of these things in place, our job becomes much simpler: create a comprehensive list of requirements and objectives, then work with the stakeholders to prioritize that list. With few or none of these things in place, we often double our efforts and burn through the discovery budget before we have anything to show for it.