Organizations initiate information technology projects for one of two reasons:
- To Solve Business Problems: someone is experiencing problems with the way things work today and expects information technology (IT) to solve these problems.
- To Seize a Business Opportunity: someone has recognized what they think is an opportunity and they need information technology to be able to take advantage of it.
One of the first duties of every good business analyst should be to recognize which of these two situations triggered the project. Without that knowledge, the business analyst could end up applying inappropriate — or at the very least, less effective — techniques to try to figure out what the business community really needs.
Defining Requirements for Projects that Solve Business Problems
If your organization or some significant member thereof, is experiencing pain from a flawed business process or inaccurate information, you need to understand the problem. If you do not investigate the cause of the problem, you can easily develop a solution that you think is spectacular only to discover that you did not solve the problem and your solution actually makes matters worse! In this situation, I would strongly recommend a reasonably detailed analysis of the as-is situation not just to understand the symptoms (which are typically what the business community experiences) but also to uncover the root cause problem. All too often, we deliver a solution that alleviates the symptoms but does not address the real problem.
The simple technique of getting all of the stakeholders involved in the project to write down what they perceive the problems to be is a great starting point for this type of a project. I use the phrase “perceive the problems to be” very consciously in that sentence. It expresses a fundamental truth in my mind, which is what one person perceives as a problem, another perceives as an opportunity. A great example of this is if an ATM machine dispenses more cash than the customer requested but the receipt indicates the requested amount. If I were to ask the customer, “What’s the problem”, I doubt seriously that he or she could see one. From the perspective of the bank that owns the ATM, however, I will get a very different response when they discover the discrepancy.
Defining Requirements for Opportunity-Seizing Projects
For projects that are initiated to take advantage of an opportunity, ask your stakeholders, “What features, functions, facts, or behaviors would the business have to change to take advantage of this opportunity?” Once you have compiled a list, you might want to slip your problem-focused hat on briefly and ask for each item on your list, “What is keeping us from doing this right now?” To improve your odds of successfully implementing a solution that allows your organization to seize the opportunity, you might even consider asking, “Which of these things do we have now that we want to keep or affirm? Which do we have now that we want to eliminate or abolish? Which do we need to acquire? If we change anything, what features/functions/facts/ or behaviors do we want to avoid?”
By taking the time to analyze which changes you really need, you might just avoid the proverbial “OW” that follows the “WOW” when your new business solution throws the organization into disarray. Seizing an opportunity should not preclude allowing your organization’s existing successes to continue to thrive.
