All Business Analysis Initiatives require some level of interaction with people in the organization. A large part of the business analyst's work involves engagement to gather data about their stakeholders' issues and needs. Projects are about people, and success is about creating value for those people.
Very often, as a BA, I have to anticipate stakeholder expectations such that requirements elicitation covers a maximum number of deliverable. Microsoft Flow and SharePoint are a good example where 'no code' drives the way business user interacts with the system. Sometimes high-end code development is not necessary. Providing results as part of elicitation can win new projects as long as project expenditures are well under budget and within schedule.
If I prioritize the wrong stakeholders and don't estimate their power and level of interest, I stand to lose out on essential/crucial opinions. So, time and again, I go back to concepts. BABOK explains this stakeholder engagement concept as illustrated above, which is to keep people with high power higher levels of interest closest to all business analysis activities. A crucial part of stakeholder analysis for a business analyst is identifying the project stakeholders and the level of influence they have over the project.
Through this article, I'll be narrating my personal experience dealing with multiple roles that evaluated my elicitation outcomes and how I engaged with those roles/stakeholders effectively.
My interaction with stakeholder roles, during the last few years, have primarily been during system integration for Workday, Destiny LOS, and Microsoft Dynamics CRM. I not only play the role of a Business Analyst, but also that of VBA functional/technical programmer, IT contractor, and consultant. Some of my recent projects, elicitation deliverable, had the following scope:
During the new system integrations as an external contractor/consultant, it is essential to plan stakeholder engagement to adhere to the client's current state description and change strategy.
Business analysts understand the scope of the system and data spread across customers, business end-users, project managers, developers, and supplier stakeholder groups through active interaction and collaboration. Stakeholder lists are a well-known BA technique for consulting assignments as well as other projects.
For new project deliverable, stakeholders depend on me for techno-functional business analysis and process management documentation. On the data front, I use data models, research, descriptive data mining, brainstorming, business rules analysis, lessons learned, data modeling, document analysis, workshops, and interface analysis. However, process model/analysis, and walk through are non-technical methods. I will explain what I mean by both techno-functional and non-technical elicitation.
Firstly by 'techno-functional,' I mean wearing the hat of VBA coder for Excel and Access data and looking for 'no code' efficacies in document analysis using research. I create data flow automation using Microsoft Flow, SSIS components for SQL Server and then assemble my research and data documents as business analysis information for further IT integration. I bring an automation request up to speed so that developers, SharePoint, and System Administrator IT roles refer to this information for proposed requirement analysis and solution analysis.
Secondly, as part of process management, I typically complete elicitation using Visio process models and process analysis.
Below, I have highlighted the importance of stakeholder engagement by tying all the roles that I interacted with as a Business Analyst (BA), who were enablers to effective solution implementation and requirement analysis across multiple elicitation and collaboration efforts. Let's see what these roles did:
I played the role of an IT BA for a consulting project that concluded about a year back. The conclusion mentioned herewith are for all tasks that was in the past.
I completed data flows and provided technical specifications translating data analysis into requirements through elicitation outputs. Elicitation documents gave two scenarios for both mass merge and system-wide organizational hierarchy.
After project close, users realized requirements validity when indexed search became available – this feature was inaccessible before record deduplication. Users received near similarity entity vendor records through data analysis.
For IT developers, I provided data layout to enable similarly or misspelled phrase mass merge. Fuzzy add-in Excel report was useful for vendor names comprising two or more words. I provided research for a system-wide upgrade for use in the organization hierarchy. IT offered a glimpse to business users on the next version implementation - cloud and address verification services in addition to organization hierarchy in SharePoint documents.
Excel fuzzy add-in, SSIS components.