Two More Examples of Business Analysis

I have two new Business Analysis stories to share. The first is a common pattern in recognizing that your business analysis approach is lacking. The second is a success story where I applied a lesson I learned from a previous BA class. Both are based on true stories though the names have been withheld to protect the author from frivolous lawsuits.

How did we miss that?
After a feature in a software application goes live, a support issue comes up and the development team lead and one of the developers are discussing it. The issue is one of functional deficiency; the feature works but is not accounting for some lower percentage edge cases. This deficiency is now costing the company more money than it realizes:

• The user raising the issue is unable to depend on the system to complete work
• The development team lead and the developer are both expensive resources now having to spend time fixing something rather than moving on to a newer and perhaps more strategically valuable enhancement.
• The infrastructure team has to add this to the list of items in the next scheduled release.
• The costs of having dealt with this in the software development phase would have been less expensive than it is now. Now, it incurs the additional costs of regression testing, additional documentation, redundant testing and more.

The team lead mutters out loud, "That's a missed gap. How did we miss that?" If this is happening regularly in your shop, it's a good bet your BAs could use a little more training and need to understand the value an analyst's effort provides. Even if you did not have time to develop for all the feature's edge cases, by paying some attention to them, you could have at least had a contingency plan in place (manual work around, system work around, alternative business process) to deal with the issue. Instead you now have to throw it over the wall to IT, where enough of these types of issues will cost you more than you spent on that project manager who got it done on time and on budget, but not necessarily on target.

Challenge the User (and the importance of understanding the domain)
Here's a more positive story. In my BA class in 2008, I noted that I loved one key line in particular: "BAs are not order takers." That statement proved valuable in a development effort I witnessed.

The request being addressed is to automate a process that users must manually perform. Ok, sounds good, that's always something IT is good for. But the analyst on the case originally performed as an order taker. Word for word, the user's request was put into a requirements specification. Now, that's already a far sight better than situations when the developers are given a single verbal sentence for a requirements document.

But the original request in this case says the automated process should not run on weekends, and should a scheduled day fall on a weekend, the process should know to run on the next business day instead. That's a request that is a perfect example of something that seems obvious to humans but can be tricky for computers: understanding when to delay the scheduled process adds complexity. The routine must now take into account what defines a business day, what defines a weekend, and whose calendar is defining holidays. Moreover, you cannot simply ask the routine to run on Monday if the regularly scheduled time lands on a Saturday because what if Monday is a holiday? The logic has to know how to handle various date collisions.

Our story has a happy ending, however, because the analyst involved in the requirements definition looked more closely at the user's needs and realised that the date concerns would have no effect on the routine. The requirement that the process run only on business days was not a meaningful business requirement at all, but a process quirk of the way humans did things. In actuality, there was no new business data being generated on the weekends or holidays, so asking the computer to run the process on the set day versus the next business day would not make a difference; you would get the same data regardless.

The analyst conferred with the user and was able to eliminate the date logic, which simplified the routine and the requirements. Cost savings: fewer database tables, simpler logic and fewer lines of code to read and maintain.

Question everything!