Guest Blog by Jon Pugh, Business Analyst Manager at DataBank IMX
So far, we’ve reviewed:
- The differences between the Sales discovery and the Services discovery
- How to prepare for an onsite discovery
- How to budget effectively and get the most out of your discovery hours
- What it means to “design at the table” and why we try to avoid it
In this final installment of the DataBank discovery blog series, we’re going to take a look at what the week of discovery actually looks like.
Essential Documentation
The onsite team, which usually consists of a process expert and a solution expert, should arrive with a couple of key items in-hand: an in-flight solution design document and the beginnings of a configuration matrix (sometimes called a solution inventory.)
The solution design document:
- Contains pre-loaded details from the sales survey
- Lists existing system specifications
- Includes any samples or diagrams provided by your team ahead of time
The configuration matrix:
- Features information about proposed or purchased software
- Displays how that software will be configured (think of things like keywords, document types, modules, etc.)
In preparing these items, the onsite discovery team will have identified gaps in understanding parts of your process or where the software fits into the future state. These gaps will form the basis of the discovery agenda, which you should receive well ahead of the visit.
Discovery: Phase 1
Having a pre-loaded SDD allows the team to initiate discovery by white-boarding the overall future state with the business stakeholders and SMEs and circling the specific areas where questions still exist.
As the team pursues answers to these questions, the business analyst will direct the conversation through the major steps in your process, looking for specific rules and activities for which the solution must account. Meanwhile, the solution expert listens for specifics (again, think keywords, document types, user groups, etc.) and updates the configuration matrix as the conversation continues. Where required, you can also expect the solution expert to ask probing questions that will determine software settings and variables.
It’s common for questions to surface that don’t have immediate answers. These items will go in a daily parking lot and assigned to a stakeholder or SME at the end of the day. The agenda should allow plenty of time at the conclusion of each day for the client to follow up internally on the open items while the discovery team meets to update both the SDD and the configuration matrix. Each morning, as the entire team reconvenes, everyone should expect to review and verify both the requirements captured on the previous day, as well as the answers to the parking lot items. This typically serves as the ideal recap and icebreaker to get things moving each day.
Discovery: Phase 2
At some point during the week, usually at the end of day one or the beginning of day two, plan on a shadowing session where the discovery team can watch the process in action and connect their notes to their observations. This includes spending half a day or more with system administrators to analyze the existing configuration. This will go a long way towards clarifying anything that doesn’t make complete sense during a conversation.
Also, plan on one or two sessions near the end of the visit where the business analyst projects the SDD draft, walks the team through the future state process diagram and reviews the complete list of captured MVP (minimum viable product) requirements. While there may be time to go through every requirement one by one, the MVP list helps guarantee that the core elements of the configuration matrix are approved and the development team can begin working that very next week.
Final Stages of Discovery
As the engineering team works on building the solution, the business analyst puts the finishing touches on the first draft of the SDD (which will include both process and technical details that go beyond the core MVP requirements.)
Before wrapping up this series, I would like to make a couple of closing comments. Discovery is an iterative process in many cases. The goal is to have everything recorded in full detail at the close of the onsite visit. However, during development and over the course of demonstrations, the scope may change or priorities may change. SMEs may introduce user experience requirements that were not available at the time of the onsite visit and cause us to revisit certain elements of the solution. This is completely normal, so the project team should work together to accommodate a reliable procedure for revisiting and confirming solution behavior as needed within the discovery budget.
Finally, and above all else, discovery is a PARTNERSHIP of the highest order when it comes to a software rollout. We depend on each other to communicate clear needs and expectations and deliver on everything we agree to do. In many ways, it builds or rebuilds the core of a great relationship between DataBank and its clients.
The Road to Discovery | A Team-Oriented Approach | Get the Most out of Discovery| Designing at the Table | What to Expect When You’re Expecting (Discovery)
