The “Four Core” of Business Analysis
by Kathy Martucci, PMP
It’s crunch time. User Acceptance Testing, the task that finally rallies all the functional resources (come on, you know it’s mostly true), is underway. The team is now reacting furiously to all the “defects” that have been identified. I have enclosed the word in quotes because most of the items in the defect log do not reflect a process in the software that does not work as designed, specified and built. Rather, the process isn’t working the way the customers explained all those many weeks ago; and they have no reason to expect anything different.
Is this project among the 50% of projects that fail due to poorly defined requirements?1
What is the root cause of poor definition? If we were to dig deeply enough, would it be due to the skills and knowledge of the business analyst (BA), or would it be the knowledge and ability of the subject matter expert to translate a business process into something meaningful that can be taken through design and development to the functionality required to successfully operate the business? Certainly we have highly competent people in both roles.
Or do we?
Most subject matter experts, regardless of their experience and expertise, have never participated in the implementation of a software application that will define their daily work life. Even the most senior staff and/or seasoned “power users” may be at a loss when finely dissecting business processes and communicating objectives, especially if those processes are being reengineered into a new system to take advantage of off-the-shelf functionality.
It is based on this that I maintain that it is the business analyst who has the primary responsibility for clearly defining and documenting requirements and ensuring project success. Therefore, it is imperative that the organization recognizes the role of the analyst on the project and actively seeks the following four critical competencies. They are not in any particular order.
1. Developing and maintaining relationships. The BA must build rapport – that highly sought-after but often elusive condition born of active listening, demonstrating understanding, setting clear expectations and utilizing the staff’s time efficiently. By establishing and maintaining rapport, the team benefits from the trust and respect of its stakeholders, time and again.
2. Understanding the business process. The BA clearly understands that it is someone else’s job to define the technical approach to a business solution. Rather, it is truly a deep and total understanding of the inputs, business actions and outputs of a business process that form the basis for every piece of functionality.
3. Employing business knowledge. The BA is not a random choice for defining requirements of your business. Just because Mary is organized and friendly does not mean she will be able to effectively understand, document and communicate the requirements of the payroll department.
4. Translating and supporting requirements to the development team. The BA must educate developers on a project’s business context. To do this effectively is an art and science which involves (again) building rapport, being knowledgeable about the technical aspects of the software and knowing how to bridge the gap that may exist between functional and technical specifications.
A good Business Analyst will have these core competencies and will be equipped to act as a guide to lead the business through unmapped territory to get it to its desired destination. This leads to realization of benefits, avoidance of cost, identification of new opportunities, understanding of required capabilities and ultimately improving the way organizations do business.
Is this how your organization views the role of the business analyst? Would your project run more smoothly if it was?
1ESI International survey of 2,000 business professionals, 2005.
Full Course: Power Requirements: From Process Map to Requirements Documents (1 day)
Click here for our full list of available courses!
