Exceptional Discovery
In 2013, I won an engagement to customize an event registration solution for a major sponsor of the Olympics and FIFA World Cup. The team leader emphasized their number-one rule:
We're all about exceptions.
I wondered what she meant by that, and found their biggest exception soon enough. The company needed to register a guest twice for the same event! For example, a guest comes to the Olympic Games for the opening ceremonies. Then, the guest leaves and returns later for the medal games and closing ceremonies. An off-the-shelf registration system assumes that a guest registers for an event only once.
The customer laid the groundwork for dealing with this exception. They sold event packages to groups within the company. Each package included tickets to games, a hotel room, and on-site transportation. The groups purchased packages for their invited guests.
We decided in the discovery process to register guests to event packages rather than the entire event. For example, a guest could register for an "Opening Ceremonies" package, then register for a "Medal / Closing Ceremonies" package within the same Olympics.
We then uncovered other exceptions, such as guests arriving before the starting date of their package, or departing after the end date of their package. They called these exceptions “special requests,” which turned out to be an integral part of the solution.
Discovery typically focuses on the "happy path," where a process works as expected. For example, a guest registering once for an event follows the happy path. Discovery should anticipate exceptions that veer off the happy path, such as registering a guest twice for the same event. Too often, discovery overlooks exceptions and how to deal with them. Karl Wiegers and Joy Beatty discuss overlooked exceptions in their book, Software Requirements :
Overlooked exceptions are a common source of missing requirements. Specifying exception conditions during requirements elicitation helps teams build robust products.
Alternatively, you may decide an exception happens so rarely, you’ll work around it operationally. For example, our registration solution assumes that a guest could bring a companion on a double-occupancy package. Yet, what happens if a guest brings two companions, like their spouse and child? We captured the need for multiple companions and implemented a solution for it after meeting higher-priority needs.
How do you discover exceptions? They occur in a process when it depends on one or more conditions to be true, but one of those conditions is false. For example, the registration process assumes that the guest arrives on the start date of their package. An exception occurs if the guest arrives before the package start date. They could need an unscheduled ride from the airport and additional nights in their hotel room.
You can discover exceptions by examining each step of a business process and looking at the assumption(s) required for the successful completion of the step. If an assumption can be false, you have an exception.
Once you discover an exception, you should determine a way to handle it. Ideally, you could redesign the process to prevent the exception. In our case, guest registration requires a package for the guest. If the guest’s group has no packages available, we disable registration.
If you cannot prevent the exception, you could create an alternate path to remedy the exception. Mapping out this path may require additional discovery. For example, our solution validates arrival and departure flight information when registering a guest. If the arrival or departure time from flight validation differs from the time the user entered, the solution shows the validated time and offers to replace the entered time with the validated time.
You may only need to inform a user of an exception, suggesting a remedy they could take. For example, our registration form has a color-coded heading for each section.
A green heading means the section has all information required for registration.
A gold heading means the section does not have all of the information required for registration.
A red heading indicates that the section has invalid information.
To paraphrase the team leader, we were all about discovering exceptions. We dealt with those exceptions to deliver a robust solution.
Discovery that deals with as many exception cases as possible leads to a more robust solution.
Learn more about business analysis and project management from Karl Wiegers at Process Impact.
This is the fifth in a series of posts about unknowns in the discovery process.