What It Means To Be Stakeholder Centered

 

The management of a software project is really an art; it’s a trick that’s difficult to master.  The difficulty lies in 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.  

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 (part of the) organization.

It’s 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.'

In this respect, the role of the project manager becomes that of a negotiator. The customer always wants to have it all for free, the user wants to have the greatest functionality, and the programmer doesn’t want to document anything but wants to use the coolest compilers.  The software project manager has to make them all happy.

The entire process of software project management is strongly stakeholder-driven.  It’s their wishes, fears, dreams—their stakes—that determine the course of the project.  

Time schedules, financial projections, and software goals may be abstractions, but it’s 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.  Issuing the best procedures doesn’t mean that people will live by them.  

I know that this socio/psycho stuff is not the favorite cup of tea among technocrats, but being unknown shouldn’t make something scary.  In essence, it’s even easy to understand.  You are part of it.  If you are human, you can practice on yourself and try things out on your spouse  and kids.  Look around your office and try to think about how the situation there is different from the one at home with your
kids.

First of all, your children are more transparent than the people at work.  They  communicate directly what they want, and if they try some power trip on you, you immediately recognize it for what it is.  “I want ice cream right now” is pretty clear.  If they don’t get this very nice cold snack, kids can use crying as a means to get their way. And you may cave in, perhaps just to stop the annoying sound and, of course, the embarrassment of walking through the mall with your yodeling kid.

Let’s start to focus on project management.

Your boss or your employees will not be this explicit and predictable.  They may try some mind games to manipulate you or (let’s avoid being negative) they will have the best intentions, ones you haven’t figured out yet.

But in essence, they have the same mechanisms as you and your children.  People do what they do to realize their dreams or to avoid having their nightmares come true; in other words, to achieve their wishes or to escape their fears.  Within the context of projects, people are the stakeholders.

What people (and stakeholders) really want are what can be termed their interests. With fears there is a stake to lose, and with wishes there is something to gain.

In general these interests are hardly ever communicated.  It’s pure mind stuff, all inside the head of the owner. 

If no one will tell you anything, what is the point?  

People will tell you something if you ask them. Their expectations.

Expectations are a one-sided communication. Requirements on the other hand 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.

Requirements are always clearly defined and describe a state that is desired.  This is in contrast to expectations, which are generally vague and abstractly formulated.

Here’s an oversimplified example: an interest of a programmer is “to be involved in way cool new technologies like my brother-in-law is” (let’s say Java).  The corresponding expectation could be, “The system can only be programmed in Java.”  The expectation can be stated along other technical arguments, but it’s only the interest mentioned
that caused it to appear.  If everyone agrees on this “fact,” then “programmed in Java” can become a requirement.

So the project manager has this project, surrounded by requirements that must be met.  But remind yourself: they are
not the stakes, they are not the crown jewels that may not be touched.  So you can mess with the requirements, can’t you?

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.  

As mentioned earlier, 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!  Right?

Now let’s take it one step back.  

A stakeholder formulates an expectation for the software project; for example, senior management states, “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’s a software project, so the deadline 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’s 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.