I attended BA World – Atlanta a few weeks back, and attended a wonderful presentation by Paul Mulvey, “Why Should a Business Analyst Care About Essential Processes?” Paul started off his session with a story about his daughter, and how she asked for a new iPhone. His first question was “why?” Why did she need a new iPhone? Well, she needed to upgrade her operating system. Why could she not upgrade her operating system? The phone did not have enough memory. Why did her phone not have enough memory? Because most of the phone’s memory was being used by photos. Could she delete some of the photos? Yup, considering most of them were selfies. Thus, after some quick analysis, Paul found that by deleting most of the selfies his daughter had taken of herself, her phone had enough space to upgrade to the latest operating system. Problem solved, and it did not involve having to spend hundreds of dollars buying a new iPhone.
It seems so easy when we are dealing with our children, to ask “why”. But why do we not do this with our business counterparts? Why is it that when the business asks for something, or even better, they hand us a solution, our typical responses is “OK”. And then we make it happen. We rarely question whether or not the request is feasible, needed, or would actually help the business solve a problem. We just fulfill the request.
Business Analysts really should not do that. What value to the organization does that add?
At ArgonDigital, one of the first things that we do on a project is to understand the business problem that we are trying to solve. We use a number of different Objective Models to help us understand:
- The Business Objective Model (BOM) is created to document a project’s value for the company creating it. The elements of a Business Objective Model are business problem/objective pairs that culminate in product concept to solve the business problem. Success metrics are also included, which state the goals the project will be measured against.
- The Objective Chain begins first with the business objective at the top of the chain, eventually linking to features. Between the business objectives and features are qualitative statements describing how the level adds value to the objective above it.
- The Requirements Mapping Matrix (RMM) aids in the mapping of models information to business rules. Common mappings to include in a RMM are process flows to requirements to business objectives. Features, code and test cases can also be included in an RMM. Ultimately, the goal of the RMM is to add traceability between requirements models and requirements, themselves.
- Feature Trees are high-level models organizing features into feature groups, capturing the entire scope of a project into a single model. Features are listed into three separate levels of detail. The highest level features are shown on Level 1 (L1), mid-level features are shown on Level 2 (L2), and low-level features are shown on Level 3 (L3).
Using these models really helps us understand the business problems, and ask the “why” question. Understanding the problems helps us steer the organization to the correct solution, which may, or may not, be software. There are even times that it’s best not to undertake the project. The business value is just not there.
If more business analysts asked the “why” question, imagine the value that we can provide the organization!
