Guest blog by Jon Pugh
We hear it a lot in sports: “Trust the process.” It’s usually the theme song of a front office that’s trying to keep its fans patient and faithful while their favorite team rebuilds its roster or brings a star player back from injury. Sometimes, things take longer than fans (or customers) would like. In most cases, the process is moving along just fine, but due to transparency issues, that progress isn’t obvious. In either situation, there’s a tendency to rush the results or to push design elements into the discovery conversations out of eagerness to keep moving ahead. We call this “designing at the table”. There is a time and a place for this approach, but it’s not usually recommended. Trust the process.
What is the discovery process?
Well, it depends. There isn’t one right way to conduct discovery. It’s unique to the combination of several variables, including (but not limited to):
- The style and strengths of the discovery team
- The experience level of the customer
- The business process itself
- The technology involved
- The project methodology
We routinely engage in both waterfall and agile projects and make sure to gather both functional and technical requirements. We spend time with the business SMEs to understand the whats and whys of the business: What do you do when…? Why do you do that? Who is involved? We take those items to the appropriate information technology team members to weigh them against technical limitations and available assets. With that information in hand, we review the comprehensive list of requirements with our engineers and developers to begin fleshing out the elements of design. While it isn’t always a paint-by-numbers experience, this is a great representation of the process: functional requirements from the business, technical requirements from IT, solution elements from the build team.
Asking The Right Design Questions
When the lines blur, we waste a lot of time answering design questions like, “Can the software do X?” or “I assume something like a Y is a possibility here?” when we should be capturing business and data rules. In other words, “Yes, the software can do X, but why do you think you need it to do that? What are YOU trying to do?” More often than not, the answer to whether the software can do X, Y or Z is immaterial by the time we present the actual business need to the engineer or developer. They always know of a better way. Thus, that time spent answering design questions from the Finance director causes the days to run long, or worse – we are left revisiting critical steps in the business process over the phone the following week. Hopefully, everyone is available for thirty minutes here or an hour there…you get the picture.
Trusting the Process
In closing, rest assured that we recognize the excitement that goes into each discovery – people want to skip ahead and start picturing what the solution will look like. And that’s okay! That’s great – we want enthusiasm during discovery because it’s still a long way ahead of a final product. In many ways and for many of the same reasons, we match that enthusiasm. We can go far together if we nurture that feeling. But, I caution stakeholders not to be offended when questions about the technology or the design go into the parking lot. We’ll revisit them when it’s more appropriate. In order to be thorough and to be respectful of each constituent’s time and effort, we move ahead methodically and follow our process. Ask questions, raise concerns, partner with DataBank and trust the process.