I was recently talking with a project manager who insisted every BA must be a business domain expert. I disagreed, suggesting a strong BA can learn the business by asking the right questions and studying the work. As we discussed this further, he agreed the BA should learn the specifics of the business and doesn’t necessarily need to be hired with industry knowledge. We realized our disagreement was really over WHEN the BA learns the business. For the project manager, he expects the BA to come to the project with the knowledge already in hand. He expects business requirements are already understood and the collecting of requirements (PMBOK® task) will be very straightforward. He does not have money or time in his project budget for the BA to learn the business. He wants the BA to immediately begin the Product or Solution scope and functional requirements.

At another company BAs are also expected to learn the business before their project work begins but when I asked if they are given time outside a project to perform this analysis the answer was no. All of a BA’s time must be allocated to a project. They expect BAs to learn the business in their spare time or on their own time.

I believe these attitudes reflect a lack of understanding of the complexity of our business domains. When an IT manager thinks a BA can learn a business area in his or her spare time, the manager assumes the business processes are simple or straightforward. Very few are. As BAs we need to constantly be educating our management (supervisory and project managers) about the sophistication of our business users and their work. We need to help the IT organization appreciate both the complexity of the business areas and the importance of capturing this complexity in business models. Only our deep understanding of the business will assure our projects deliver true business value.

Learning the business and representing it in business models and requirements is a critical success factor for every project. Business models are reusable, increasing productivity on future projects. They also need to be updated as the business changes. I would recommend an IT cost center for BAs to spend time learning business domains outside projects rather than within the context of a specific project. BAs who spend time with the business people on a regular basis also see opportunities for improvements and may suggest new projects.

When are you given time to learn your business?

A very simple of example would be a business process which notifies a customer regarding their current order status. A customer may be contacted through email, phone, fax, an IVR solution, or directly via some other software like a CRM application etc. How the process is accomplished does not matter during business requirements but understanding why there is a need to make customer contact is important and additionally the information or data that needs to be communicated to the customer is also important.  The mechanism to be used to accomplish this communication is not yet necessary and if determined too early limits the solution options.

Most people agree that Business Requirements include high level statements such as the project mission statement, business objectives, scope, out of scope items, any assumptions and the constraints in a project. I would add that a crucial part of the business requirements are details about the affected core business processes, the data needed by those processes, the business rules, and the external entities that will interface with the business system under investigation. Until we have a detailed understanding of the business processes and interfaces we will continue to be challenged in defining the right solutions. Without understanding the “why” and “what”, sometimes we fix what’s not broken. Other times in solving one problem others are created.  As in the worn out phrase…”the devil is in the details” this really holds true in the BA’s world. A business analyst cannot be expected to enhance the levels of efficiency and effectiveness in business operations if he or she does not understand specifically where there are bottlenecks, redundancies, defects, and other inefficiencies that affect service, quality, timeliness or cost.