The Community Blog for Business Analysts

A few years ago, I had shifted with bag and baggage to the US. I thought that the upcoming project would consume me for at least a couple of years. Alas, that was not the case. I returned home in five months. Well, I don't even want to begin to think about the financial and emotional set back that my family and I had to endure!

Why did this happen? The easy answer is always, "Oh! you know, the customer was totally ill-prepared. They did not even have the business case for the project and they had already spent $1M+. Can you believe that? Ultimately the CEO found out that there was no business case and revoked funding." But this was only one of the reasons. There were several others. Among the others, one of the reasons was, well, me! I might have been the reason for the project getting scrapped!

You see, like in every project, there were two critical stakeholder roles for this project - the Sponsor and the Solution Owner. The sponsor was the head of IT. He controlled the budget. The solution owner was a director of a business division and he controlled the solution's features. In most projects, these two roles are played by the same individual. But in this project, these two roles were played by two different individuals.

The PM, the Solution Architect and I were clear - go to the sponsor for budget, estimate approval, release plan and timeline. "Please the sponsor" was our motto. We went to the solution owner only for requirements sign off and kept him out of the loop for discussions on release planning. Here lies the problem!

These two individuals acted based on completely different set of motivations - having just got out of the debacle of a long drawn, several times over budget project, the sponsor wanted to show quick wins by having shorter release cycles, which meant that the budget per release was very limited and thus the features we could accommodate in a release was limited. The solution owner, on the other hand, maintained that each release should be of value to the end users. There is no point in releasing something which the end users would find unexciting. For him, the definition of quick win was not just to make a release, rather to make a release that would win accolades from the end users.

You may imagine what happened next - the sponsor and the solution owner never saw eye-to-eye. That they belonged in two different organizational units and did not have to regularly communicate with each other only exacerbated the situation. I would work with the PM on developing a release plan, estimates and project plan. We would then take it to the sponsor. He would look at it and instruct us to reduce the number of features and hence the estimates. We would do that. He would then approve the release plan. I would then go to the solution owner, who would look at the release plan and literally go ballistic. I would plead helplessness and indicate that I was at the mercy of the sponsor. He would care for none of that.

Eventually, I raised both my hands. I said, you guys work with each other and resolve your differences. Well, I'll tell you something. They did resolve their differences. They had the project scrapped!

Was it my problem that the sponsor and solution owner did not get along? Is there anything that I could have done better? For both questions the answer is a resounding "Most certainly!" If only I had anticipated this tussle between stakeholders! If only I took a more proactive and a hands on approach to diffuse the tension between these two stakeholders. If only, if only...now do you get how I was one of the reasons for the project getting scrapped?

What could I do better? Stakeholder Analysis is a best practice that every BA must have mastery over. Alas, I studied this concept only after I returned from the US feeling like a hapless victim.

The purpose of stakeholder analysis is to analyze the interest and influence of each stakeholder and customize our collaboration strategy with each stakeholder with the sole intention of minimizing the adverse impact on the delivery of the solution. Stakeholder Analysis enables the BA to deal with stakeholders as a matter of choice rather than chance!

So, let's talk about stakeholder management:

Who is a stakeholder?

Stakeholder is anyone who is directly/indirectly, positively/negatively impacted by the problem and/or its solution. It is possible that someone is 'positively' impacted by the problem, in fact they might thrive and flourish inside the problem.

What is Stakeholder Management?

Stakeholder Management is about customizing collaboration strategies to suit the temperament and background of each stakeholder with an intention to "minimize the any adverse impact on the progress of a project" that could caused by a stakeholder.

Step 1: Stakeholder Identification

The first step in Stakeholder Management is obviously identification of all stakeholders. This activity begins as soon as the business needs are identified.

It is important, well, to make sure that all relevant stakeholders' views have been considered in building the solution. The BABOK lists various stakeholder roles that can be used to identify stakeholders. But this is easier said than done. For e.g.

1. Consider the stakeholder role 'Regulator'. Most of us assume this to be the macro regulatory bodies like SEC, SEBI, FDA, TRAI, IRDA, FSA, etc. But somehow we forget that PMO of an organization is also a regulator - they regulate what, how and when project deliverables need to be produced.
2. Consider Enterprise Security team. They regulate access to all 'Applications' in the enterprise, including the one that you are defining requirements for. Not only that, they also dictate security related requirements.
3. Consider Sponsor - the one with the money is the sponsor. We all know that. We assume that the sponsor needs to be pleased all the time. Well, this is not true always. It is not JUST the sponsor that needs pleasing...there are other stakeholders. One of the most critical stakeholders that need to be closely managed is who I call "Business Owner" a.k.a Solution owner. (The BABOK does not call out a separate stakeholder role called solution owner. I assume they include this in their Domain SME.) The Solution Owner decides what features and functionality should the solution provide and also has a say in release planning (i.e. when does which feature become available in the solution. Fair, right?) Normally, there is one individual that sits in the roles of both Sponsor and Solution Owner. This is the best case scenario. The troublesome scenario is when these two roles are played by two different individuals, like in my case (described earlier).

Step 2: Stakeholder Analysis

The second step is stakeholder analysis. This comprises of two parts - understanding a stakeholders 'interest' and understanding a stakeholder 'influence'. Let me dwell on these two points:

1. Stakeholder Interest

It is important to understand stakeholder's interests because it gives us some indication on how much would the stakeholder care about exercising whatever influence s/he might have. Interest is a function of two factors - change appetite of the stakeholder and impact of the solution over the stakeholder.

• Change Appetite is the disposition of the stakeholder towards the change. In other words, to what extent is the stakeholder willing to change.
• Impact of the solution is to what extent will the solution force the stakeholder to change

Stakeholder Interest is determined as follows:

Notice that if the Change Appetite is Low and Impact of Solution is High, the stakeholder will have a NEGATIVE interest in the project, which means that the stakeholder will not hesitate to scuttle the progress of the project or even kill it, provided s/he has adequate influence.

2. Stakeholder Influence

Stakeholder Influence is very simple. It is the degree to which the stakeholder can sway decisions to his/her line of thinking and impact the outcome of the project.

Step 3: Stakeholder Map

The third step in Stakeholder Management is to develop a visual model of stakeholder's interest and influence, which is called a stakeholder map. It looks like this:

Each stakeholder gets assigned a quadrant, with the relative location in the quadrant indicating the extent of influence / interest of the stakeholder compared to other stakeholders. The RED circles indicate the stakeholders who have a negative interest.

"Okay...this is great", I hear you saying. "Now what do I do? What significance do these quadrants hold? What is this about one stakeholder Bob moving from one quadrant to the other?"

A stakeholder map is the four quadrant Interest vs. Influence map. All the stakeholders fall into one of these four quadrants.

What do these quadrants represent? 

The I Quadrant (top right) carries the most significance because the stakeholders who are high on both Interest and Influence are bracketed here.

But, mind you, the folk with negative Interest (the RED circles) can appear in the I and IV quadrants only...guess why?

What do I do with this map?

The stakeholder map essentially helps the BA figure out how the collaboration with the stakeholders should be.

I Quadrant - Manage Closely

High Influence & High (Positive) Interest

1. Work in Collaboration/ Partnership and keep on board.
2. Manage them closely and maintain support
3. Refine communications to align with project goals.
4. Leverage stakeholder influence.
5. Use in project teams to deliver change.
6. Reward their support.
7. Use an interactive communication method - do not use a dictatorial tone with them. Make them feel that every idea is theirs

High Influence & High (Negative) Interest / Resistance

1. Build Relationships when possible. Take time to know them.
2. Understand the underlying reasons for resistance. Paint a picture of the future if things continue as is.
3. Acknowledge their concerns.
4. Compromise on strategy where it is possible - give and take negotiation
5. Stand firm on principles and the need for change
6. Involve other influencing people who are more positive in influencing them
7. Use an interactive communication method - do not use a dictatorial tone with them. Make them feel that every idea is theirs

II Quadrant - Keep Satisfied 
High Influence and Low Interest 

1. Keep them satisfied.
2. Send regular information about project but not constant involvement.
3. Ensure that they support the project.
4. Target communications to align with project goals.
5. Provide information to help them become supporters
6. Enthuse about change and sell the benefits.
7. Use an push communication method.
8. Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence

III Quadrant - Keep Informed
Low Influence and Low Interest

1. Manage relationship passively - not necessary to seek them out. Be courteous and genuine when they pass by the hallway or in the cafeteria
2. Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
3. Use a push communication method - no interaction unless asked for.

IV Quadrant - Monitor
Low Influence and High Interest

1. Consult or have a dialog
2. Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
3. Empower them and protect their interests
4. Consider their advice and opinions...no need to bend backwards to accommodate, unless they are really important to the project
5. Remain in constant communication to ensure that no major issues are arising

Coming back to my situation

So, had I known the above stakeholder management method, rather, had I known its real significance, I would have realized that both my warring stakeholders - sponsor and business owner - fall under the I Quadrant. In hindsight, what could have saved the project is the following collaboration strategies:

1. Involve both the sponsor and the business owner in all status review meetings (I used to involve only the sponsor)
2. Facilitate communication between these two stakeholders to ensure that both of them truly understand each other's worlds and both realize that neither is acting with any vested interest, rather, both want the best from the project
3. Arrive at the Release Plan together, such that both stakeholders' interests are optimally taken care of and that both understand what they are giving up, if at all, and why
4. Create an atmosphere of trust that neither stakeholder give you any guidance/direction without the knowledge of the other.

Well...better late than never, right? I might have been partially responsible for losing the project, but I did learn a lesson from that.

Let me know what you think...leave a comment!