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.
Stakeholder Engagement in My Projects
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:
Irrespective of any project scope, the following elicitation methods, hold the weight while engaging with any group of stakeholders:
Stakeholders List, Map, and Persona
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.
Other Business Analysis Techniques
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.
My Interactions with Relevant Stakeholders
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:
Project Manager Role
IT Managers Role
Domain and Implementation Subject Matter Expert (SME)
SMEs – CRM Developers
Business Analyst (BA) – IT Role
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.
Business Analyst – Process and Requirements Discovery
Process analysis and requirements discovery are my current projects. I work with domain and implementation SMEs and plan to deliver clarification documents to discover user requirements.
For process and program management, simplistic as-is documentation for requirements discovery starts with current standard operating procedures. I then complete clarification, recommendations, and gap analysis documentation of AS-IS process (SIPOC) documents covering insights gathered during process walk-through.
For current projects, I focus on short iterations for producing documents, and the key roles are domain and implementation SMEs from Accounting and Financial Systems domain for Work Day implementation.
Conclusion
To conclude, determining the stakeholders of the project early on and engaging effectively with them determines the success of the project. If they feel ignored or overlooked, it can affect the project negatively. BABOK outlines elicitation and collaboration tasks across knowledge areas in much greater detail than I mentioned here. This article talks about my experiences in the last few years. Finally, it’s important to always keep yourself updated by reading and researching online and finding that coveted information liked by your stakeholders!
Project Terms Used in the Article
Technical terms have a much deeper meaning and scope, so much so that it encompasses the need for advanced knowledge and practical experience. I acknowledge the following are project specific technical terms only: Data Cleansing, Record Deduplication, SSAS components, SSAS data flows, Excel fuzzy add-in, SSIS components.
How to manage negative stakeholders?
How to handle aggressive stakeholders
Stakeholder Management