Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban

Using Stakeholder Analysis in Software Project Management

Bas de Baar

Every software professional that has been part of more than one project knows for sure: no two projects are the same. Different circumstances make most software projects unique in several aspects. And with different situations come different approaches to handle project life effectively: there are multiple ways to "do" a project. Different circumstances require different approaches.

Although a project is to a large part defined by the required end results and technology used, the main determining factor of what makes a project different from another is people. The entire process of software project management is strongly stakeholder-driven. It is their wishes, fears, dreams - their stakes - that determine the course of the project. You have to handle a project to really grasp the impact of people on your endeavour. You have to "live" a project to know the force of political games and power trips. You have to lead a team to deliver a project under time pressures to appreciate the constructive power of motivated people or the destructive power of demotivated team members.

In a project, it is the people that are the main cause of problems. Time schedules, financial projections, and software goals may be abstractions, but it is the flesh-and-blood people whose work determines your project's status. It's the programmer that misses a deadline and holds up everyone else, it's the financial manager that goes berserk if you can't produce some good budgetary indications, and it's the key user that doesn't give a darn but didn't tell you about his dismal lack of motivation; these are the folks who can cause serious trouble.

Using Stakeholder Analysis in Software Project Management

Stakeholders and the Software Project Manager's Problem

So, as a software project manager, you should really focus on the stakeholders. You should be guided by their fears and their wishes. A stakeholder can be a project team member, an employee of the user organization, or a senior manager. It can be virtually anyone, as long as that person has something to do with the project.

Here is the central problem the software manager is faced with, appropriately named "the software project manager's problem," as explained by Barry W. Boehm and Rony Ross [1]. They believe that everyone affected by the project, directly or indirectly, has something to say, again directly or indirectly, and will do so. All of them want to get the best from this project for themselves personally or for their organization. It is the job of the software project manager to see that everyone gets what he or she wants, in one way or another. He has to "make everyone a winner."

Of course, this is easier said than done. You have to act like a psychoanalyst and get in touch with everyone's deeper feelings. Most technical project leaders would be running for the door at this moment. To make it less fuzzy, we can attach some project management lingo to it:

"The project manager can use stakeholder analysis to determine the stakes and expectations of the stakeholders, and adopt the project organization and feedback mechanisms according to the desired outcomes."

Expectations, Interests and Requirements

Stakeholder analysis is a technique to identify and analyze the stakeholders surrounding a project. It provides information on stakeholders and their relationships, interests, and expectations. A proper analysis of the stakeholders will help you to construct a project approach suited to the situation and will allow you to negotiate better with the stakeholders.

What people (and therefore your project stakeholders) really, really, really want is what can be termed their interests or, as I sometimes call them, their stakes (hence the name "stakeholder"). With fears there is a stake to lose, and with wishes there is something to gain.

In this context, I consider interests as the aspects that drive people. Before you start drawing your "interest evaluation diagram" or some other tool or technique, be aware that in general these interests are hardly ever communicated. It is pure mind stuff, all inside the head of the owner. A four-year-old boy may share his true interests with you, but the fifty-year-old greying accountant will tell you nothing.

If no one will tell you anything, what is the point? People will tell you something if you ask them. They will tell you they want an ice cream cone, a new hyperspeed Internet uplink, or a new financial software package. In essence, they tell you what they expect. It is a statement created by themselves about a desired situation: their expectations.

If I emphasize that expectations are a one-sided communication, then there must be something else as well; enter requirements. Requirements are a set of statements negotiated among a group of people. They can be the original expectations, if all agree on the statement itself, but more often than not, requirements consist of some consensus of conflicting expectations.

It sounds simple, but getting the expectations is one thing and discovering their corresponding stakes is another. Why bother anyway? What is it worth? A lot. You can't effectively change the stakes, but you can alter the set of requirements as long as the new requirements continue to support the stakes. In this way, there is room to negotiate a set of requirements for the project that poses no conflict, matches the stakes, and thus makes everyone a winner!

Consider this example: a stakeholder formulates an expectation for the software project; for example, senior management states that "The project should be finished before the end of August." The project manager then has to deal with this time frame. When this deadline is no problem, he can rest assured; however, it is a software project, so the deadline typically will be a problem. The way to handle it is to get some information on the stakes that prompted this requirement to be formulated in the first place.

Perhaps it is the old "I don't want to lose face when my projects get delayed" concern. That being the case, the project manager can offer alternatives that don't violate the stake, like keeping the deadline but postponing a subsystem. Chances are good that alternative requirements that keep supporting the stakes will be accepted - maybe not easily, but project managers should do something to earn their money.

So, it seems to be valuable to dig deeper into the souls of your stakeholders. It sounds all very misty and cloudy, but keep remembering why you must do it:

  • Expectations are assessable and can be influenced. However, you should stay true to the interests of people; they will determine the amount of leverage you have to change the expectations without setting a stakeholder on the warpath.
  • Requirements have to stay in line with what people are expecting. If stakeholders find out the requirements don't fit their expectations, you have a major problem.
  • Knowledge about the stakeholders and their expectations and interests helps you shape the project organization (structure, authority, and responsibility).
  • It is a very good risk analysis strategy to see where the potential problems will be.

Stakeholder Analysis

The actual steps for a stakeholder analysis are:

  • Stakeholder identification
  • Stakeholder expectations and interests
  • Stakeholder influence and role in the project

Stakeholder Identification

This first step is concerned with the question "Who are the stakeholders?" For this, you basically draw maps of people or groups and their relationships. You start with two names on a whiteboard and before you know it, you are drawing on the walls.

Stakeholder Expectations and Interests

The more difficult step is this one; here we get the socio-psycho stuff. For expectations it is fairly straightforward: just ask. You can ask in person or via mail or email. Create some variations on the question, so that it is not too obvious what you are trying to find out.

Stakeholder interests are another thing. Trying to elicit their interests is always guesswork, deducting them from other information. For this, there are two types of approaches: (1) using a checklist to assist your thinking about the stakeholder and (2) plotting people in small models that help determine the way to approach them.

For the first type, consider a list with questions like: "Is he satisfied with his current job?", "Is he covering up his own incompetence?" and "Does he want a bigger office?" Thinking about these questions help you build an image of the person's interests. Consider the list at the end of this article as good starting point.

Using small models, the second type, can be easier than it sounds. For this, you have to plot a stakeholder in a dimension, and by doing that, you get an idea of how to approach the stakeholder. Dimensions can include: "How much in favour of the project", "Process or Content-oriented" and "Group or Individual-oriented."

Stakeholder Influence and Role in the Project

The insights about the stakeholders will assist us also to construct the project organization:

  • Do we have to include the stakeholders in the organization?
  • If so, is it wise to grant stakeholders great influence or should we give them positions where they can do no harm?
  • How can we construct stakeholders' job descriptions in such a way that they are as motivated as possible?

What Does This Bring The Project Manager?

In the end, what does all this analyzing and guessing bring to us? That is a good question, and here is the answer:

  1. A list of all the stakeholders
  2. An idea about each stakeholder's relative importance and influence
  3. Insight into what stakeholders want out of the project
  4. Insight into what makes stakeholders tick
  5. An idea about whether stakeholders will work against or for the project

Apart from an improved ability to negotiate better requirements-sets, this information provides the basis for two major project management tools: the project organization (mentioned as the last step of stakeholder analysis) and the feedback mechanisms.

Feedback mechanisms

If stakeholders provide requirements to a project, they are very interested to know what happens to them. Are they going to be met, or will they be ignored? Keeping your stakeholders in the loop, reassuring your stakeholders about what is happening with their stakes/requirements is a smart thing to do.

There are many project management techniques and artifacts available just for the purpose of feedback. Often, it is unclear from the methods that you use what is the purpose of the feedback. In the list below are some artefact samples that are common in most methods, and what kind of feedback each provides. 

Requirements definition

Feedback to the users how their requirements are noted after talking, analyzing and negotiation

Functional design

Feedback to the user how their requirements are translated to a new system

Prototype

Feedback to the user how their requirements are translated to a new system

Schedule

Feedback on constraint "time"

Budget

Feedback on constraint "cost"

Closing

Every improvement you make with the goal of improving your ability to do projects better should involve how to handle the human element more effectively, as this is the area where we can realize the biggest gains.

Stakeholder analysis is one technique that can assist in this. To sharpen your knife you can improve your sensitivity in this area, create your own checklists and read up on the various models available to you. Finally, just being aware of stakes and their effects on your project in itself is a huge benefit to your software project management efforts.

Checklist Stakeholder Interests

Personal

 

Work Orientation versus Family Orientation

Is the person more focused on the work environment or the home front?

Satisfaction with Current Job

Important to know when creating a job description. If not satisfied, perhaps include some new, more exciting content to the job.

Satisfaction with Current Organization

A broader aspect than "satisfaction with job": do you need to be aware of some resentment a person might have against the organization?

Desire to Gain More Skill/Knowledge in a Certain Area

Giving someone the opportunity to improve competency in a certain area is a great motivator.

Sufficient Appreciation

Showing some appreciation can boost a person's performance.

Reduction/Expansion of Workload

Does someone want to do more or less? As a project manager, you don't always have the authority to influence this, but you might give it a shot.

Reduction/Expansion of Responsibility

Actually, comments are the same as above.

Infection by Not-Invented-Here Syndrome

Does someone have a great need to be involved in something to accept it? If yes, and you need the person, then ensure involvement.

Relatedness (Interpersonal/Social)

 

Recognition of Knowledge Among Peers Outside the Organization

If someone has a strong need for recognition among his or her own peers, try to incorporate it into the job.

Recognition of Job Competence within the Organization (Hierarchy)

Does the person feel his or her work goes unnoticed in the organization? Does the person want to keep a higher profile?

Covering Up Own Incompetence (Don't Rock the Boat)

Some people try to maintain a low profile and avoid attracting any attention to themselves to cover up some incompetence.

Boosting Another's Reputation (Sponsorship)

It is nice to get some insight into who is friends with whom and who works to give others a good reputation. Sponsors can work nicely together, but be sceptical about the judgements made about each other.

Undermining Another's Reputation

Actually, the opposite of the above situation: who is trashing whom? Try to avoid putting these antagonists together.

Attempt to Move to Another Job within the Organization

Will not do much about own job or assignment, but can be found meddling in the desired area where he or she has no authority.

Attempt to Build an Empire within the Organization

Very dynamic personality and worth soliciting for maximum influence in the project, if only for sheer number of personal connections.

Attempt to Maintain an Empire within the Organization

Looks the same as person mentioned above, but has a more defensive attitude and will try to avoid as much change as possible.

Attempt to Increase Sphere of Influence within Organization

This person makes assignments bigger than they actually are.

Existence (Material Interests)

 

Desire for More Money

Need I say more?

Desire for More Tools

Any questions?

Desire for a Bigger Office

Look for a real-estate agent.

References

[1] Boehm, Barry W. and Rony Ross. "Theory-W Software Project Management Principles and Examples." IEEE Transactions on Software Engineering. 15.7 (1989): 902-916.

© 2006 Bas de Baar


More Project Management and Agile Knowledge


Click here to view the complete list of archived articles

This article was originally published in the Winter 2006 issue of Methods & Tools

Methods & Tools
is supported by


Testmatick.com

Software Testing
Magazine


The Scrum Expert