Stakeholder engagement is vital for successful requirements gathering and eventually successful project delivery. Engaged stakeholders cares about the project and understands the work you do as a business analyst, you will need not to work hard to discover the right requirements.
This article outlines some top tips we have gathered from various accomplished business analysts in the industry that can be of help to you during the business requirements gathering phase with stakeholders who are not as engaged. Use these tips as an idea generator.
My top tip is to set up meetings with Stakeholders and make them productive.
This means you will have to prepare well before the meeting and create clear agenda and assign takeaways near the end of the meeting. When your stakeholders realize your meetings are important and productive, they will be more willing to attend and contribute.
As a business analyst, I’ve faced this issue when the stakeholders are reluctant to participate, and as per my experience, I’ve taken the approach of understanding their perspective – One of the biggest reason for stakeholder participation reluctance is their inertia to change, and for that understanding their perspective and their concerns and making them understand the benefits of the change shows the stakeholders that their opinion is valued.
Ideally with the help of Project manager stakeholders with proper RACI approval should be engaged from the initiation phase itself. However, if stakeholders have not been engaged in advance, you can use the simple steps below to do your ground-work while working on identifying and engaging stakeholders.
In my experience, the top tip for solving the problem “stakeholders being not engaged” is to find out the reason why they are not engaged, rather than just try to force them to be engaged. It is important to understand that different reasons behind the ‘not being engaged’ would lead to different solutions. When the right solution is developed, that will be the most effective way to ultimately solve the issue. The reasons I have experience in practise includes:
The above reasons for “being not engaged” are very different. Therefore, in my point of view there is no one simple unified/standard solution to solve them all. We need to identify the right reasons, sometimes are hidden thus hard to be identified, then find a right solution to solve this issue.
Learn as much as possible about the business requirements by using their existing systems and researching the Internet on compliance legislation. Be a subject matter expert on their project in all phases of the SDLC to earn their confidence and trust. Deliver a POC (Proof Of Concept) and prototype early on, as a picture is worth a thousand words. These will engage them as everybody wants to be on a winning team. Action and results speak louder than words and documentation. After all, we are in the software and not the paper business.
My number one tip for motivating a stakeholder that is not as engaged is to first identify where this blocker may be. Is it due to resistance to change management? Are there other internal or external factors leading to the resistance? Remember as humans we all want to align with something that directly benefits us or has some positive impact(s) related to our careers. A good reference point would be the stakeholder power and influence grid to determine positions within the organization.
Business requirements can be gathered in a number of ways including by first understanding the current process or model of the organization’s way of doing business. The current process is important because it serves as the basic foundation and provides insights to the ability of the business to deliver economic value to its constituent customers or stakeholders. (A Business Analyst must know who these constituent stakeholders are, what value we deliver to them and how we deliver!). Most of the information can be obtained from the company websites, ask the people around you, read up on the regulatory framework that impacts the business, business case for the initiative, company’s financial statements – these internal documents are very useful too. You don’t need a stakeholder to understand this if you thoroughly understand the business model of the company or organization.
Second but very important as well is any new changes in current process or business model as a result of internal, regulatory requirements, micro or macro economic environments, or even technological obsolescence that could have an impact on the current process for example a new government requirement regarding data storage and security, access management, new data warehousing needs, new calculation metrics (as a result of market, government or regulatory requirements).
A business analyst can avail him/herself of these needs or changes by first going through the necessary readings or get familiar with these regulatory frameworks (these I call the necessary ammunition) with or without the impacted stakeholder and simply socialize the findings with the stakeholder(s) when engaged for agreement before making the necessary business changes.
Before you can determine how to extract requirements from stakeholders who are less engaged in the initiative or project you need to find out why are they not engaged, prime reasons are they are not motivated enough or they do not see any value or any incentive in the project.
So in order to engage them we need to motivate them by showing them all the positive differences this new initiative will bring to the organization and to their lives. For example: the initiative may decrease the time required to perform certain activities hence saving the stakeholders time and money; or automation of certain process may eliminate manual work for end user.
Other tip is to give these stakeholders importance, ask for their help for their advice. For example: john you have been with this organization for many years can be explain this process to us. Or john i need to meet X person you know him can you introduce me to him.
Taped Python and the Secret to Stakeholder Engagement
You could tape a python to the ceiling of the meeting room where project discussions are held, and no one would look. Not that I am encouraging you to do so, but in several years of being a business analyst, I realized that stakeholders have too many distractions during project discussions. Either it’s a phone call, a message, or a mail that needs to be answered right away. Stakeholders focus more on business/ production issues and putting out fires for the day. While stakeholders do know that engaging in the project activity is important, its not the priority and often business analyst who conducts the discussions doesn’t induce the sense of emergency and excitement either.
While doing the necessary preparation like having clear objective, agenda, visual and factual documents
might help, its often much more than that. When things go right, stake holders really engage, you can
feel the electricity in the discussion, and everyone will leave the room with renewed sense of
responsibility on what needs to be done.
So, here is my secret to engaging stakeholders, Empathize! As Covey has put it eloquently “Seek first to understand, then to be understood”. Its important to get an understanding of: What drives the stakeholder? what are his/her aspirations? What excites or what scares the bejesus out of him/her? Take genuine interest. Listen, let the story be told.
I never really set to become a business analyst, it happened to me. It happened not because I worked
for a small organisation where everyone wore different hats to get things done, it happened because it
was in my very nature to empathize with people. Ability to put myself in someone else’s shoe has
helped to gather not just the spoken but also the unsaid needs of the stakeholders. Empathy is perhaps
the most important quality for a business analyst. Empathy breeds to engagement. Engagement
encourages the stakeholders to share their ideas, knowledge and harmonizes everyone’s objective to
common goals of the undertaking.
Business requirements gathering without the intervention of business stakeholders requires a progressive elaboration approach. This process could be initiated in several consecutive steps starting from collect information through brainstorming and interviews with various sources, including software vendors, professional end-users and developers and then dividing requirements on functional and non-functional. The next step is to explicitly describe in BRD (business requirements document) the key attributes of the product, current software system status (if it is not an initial build), clearly state the scope of the project and to identify anticipated project’s phases. Business requirements should be accompany with detailed process map containing links to incoming source files, data elements and idyllically logical model or/and physical database schema. To accomplish business requirements gathering the high and detailed levels of traceability matrix should be created to ensure the testability of business requirements.
We hope you gained some insights after reading some accomplished Business Analysts share their expert opinions on what to do when stakeholders are not engaged on a project. Contact ProViso Consulting to share your experience with us now. Feel free to view our open IT jobs now and apply.