The Role of a Business Analyst on a Dynamics NAV Engagement
I frequently discuss with others in the Microsoft Dynamics NAV community the importance of performing business analysis prior to developing a project scope. At times, discussing business analysis with others can be difficult, because until recently there has not been a standardized definition of business analysis. Often, I find myself engaged in an apple to oranges conversation that ultimately, is extremely unproductive.
In 2003, the IIBA (International Institute of Business Analysis) was founded by 28 members. The mission of the IIBA is “to develop and maintain standards for the practice of business analysis and for the certification of its practitioners”. IIBA defines Business Analysis as “a set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals”.
Checking job listings to see how others are defining the role of the business analyst in the NAV community, I find a listing for a “Senior Business Analyst”. As I frequently find on job boards, the listing describes the position as “to engage in on-going implementation, upgrade, maintenance, support and continuing development of the financial functions of Microsoft Dynamics NAV”. Clearly, the Dynamics business analyst role as defined in the job listing does not parallel the definition of Business Analysis as defined by the IIBA.
What is the role of a business analyst as defined by IIBA? Let’s review five key points that helps define the role of an IIBA business analyst on a Microsoft Dynamics NAV Engagement.
The first point is a business analyst is on a project to act as a stakeholder liaison. Typically, on a Dynamics NAV project there are multiple groups of stakeholders. The Business analyst elicits requirements from individuals and groups of stakeholders, and then confirms the stated requirements with the stakeholders. The business analyst represents the stakeholders.
The second point is the business analyst obtains and maintains consensus among the key stakeholders regarding the overall solution scope and the requirements that will be implemented. The business analyst communicates clear, concise, and accurate stakeholder, solution, or transitional requirements to stakeholder(s) responsible for approving the requirements, and then makes sure they are approved.
The third point is a senior business analyst identifies why an organization needs a business change or new capability, by performing an Enterprise Analysis. The business need, and other business analysis deliverables are included in the project manager's project charter or other project initiation documents.
The fourth point is the work of the business analyst typically starts before a project and finishes after the project completes. The business analyst performs a great deal of work during project preparation. After the project completes the business analyst validates that the solution delivered meets the needs of the client as specified prior to the start of the project.
The last point is the business analyst recommends solutions to stakeholders based upon the solution meeting the needs and requirements of the stakeholders. The business analyst allocates requirements to solution components to ensure that the solution is a good fit before the solution is delivered.
What doesn’t a business analyst do? Let’s cover five key points that tell us what the role of the business analyst is not about during a Microsoft Dynamics NAV engagement.
The first point is the business analyst does not implement or create enhancements in Dynamics NAV. Keep in mind that we are talking about a role. There may be people in both the role of business analyst and Dynamics NAV consultant.
The second point is the business analyst does not need Dynamics NAV knowledge or subject domain expertise. In fact, having Dynamics NAV knowledge or domain expertise may impede the business analyst. Great business analysts pride themselves in their ability to facilitate requirements sessions and drill down on root causes. Having domain knowledge may cause a business analyst to make incorrect assumptions regarding a client’s need.
The third point is a business analyst does not “gather” requirements. Gathering requirements brings out images of someone skipping through a meadow, picking up requirements on the ground, and putting them in a picnic basket. A business analyst elicits requirements; which is much more difficult and takes more time than simply “gathering” requirements.
The fourth point is the business analyst does not test solutions. The business analyst makes available requirements and assists the tester in developing test cases that are used during testing process, but the business analyst does not test solutions.
The last point is the business analyst does not simply meet with stakeholders and listen to their “wants”. The business analyst plans a business analysis engagement much like a project manager would for a project and then executives the plan. The business analyst may include in the business analysis plan to elicit, confirm, validate, verify, approve, and model requirements. The tasks and techniques used are dependent upon the attributes of the specific engagement.
One thing I can tell you for sure is the definition of business analysis is changing, and has been changing for some time now. Just as Bob Dylan sang so many years ago; the times they are a-changin’.