Pragmatic Stakeholder Analysis

Joe JeffreyDept. of Computer Science

Northern Illinois University

Abstract

This paper presents an approach to stakeholder analysis that is both more systematic and pragmatic, than informational. The software project literature indicates that stakeholder analysis, the indispensablefirst step of a project, is frequently omitted or incomplete. The goal of the paper is to provide a comprehensive and practical technique for identifying all the stakeholders and what action is needed by each. The resulting pragmatic stakeholder table and the accompanying checklists provide a method that directly addresses, “How do we identify the stakeholders in this project, what do we need each of them to do, and how to we get them to do it?”

Virtually every text and resource on the management of projects – whether IT or some other kind -- recommends stakeholder analysis as a first step. As usually described, stakeholder analysis includes identifying all the stakeholders, identifying what their stake – their interest or concern – is, and assessing the impact of each stakeholder on the project. In softwareprojects, stakeholder analysis is usually considered part of requirements definition; the stakeholders are those affected directly or indirectly by the system, each group of whom may have varying requirements.

The importance of identifying everyone impacted by a system, and their requirements, at the outset of software project seems beyond argument. Actually carrying out the stakeholder analysis, on the basis of the usual instructions for doing one, can be quite difficult. The difficulty is due, in significant

measure, to two weaknesses in discussions of stakeholder analysis:

1. Virtually always, the first step is specified as “identify all the stakeholders.” The following example of the description of the process of stakeholder analysis is a good illustration:

Who are the key stakeholders? What are the goals, motivations, and

interests of the key stakeholders? What is the power and influence of each key

stakeholder? What is the importance/impact of each key

stakeholder on the project? What are the participation roles of each key

stakeholder on the project1?

(In fact the example above is significantly betterthan most. More common is the one at the beginning of this article: identify the stakeholders; identify their interest or concern; assess the relative impact on the project; figure out how to address each stakeholder’s concern.)

Telling people to start by identifying the stakeholders may seemreasonable at first glance, but in practice this is often the most difficult step of the entire analysis, and the one done poorly or incompletely.Simply telling someone to do it does not help themcarry it out.

Some authors recommend brainstorming to develop a list of stakeholders2. This is a valuable

1 L. Elliott, “Use these two forms to analyze your stakeholders,” http://techrepublic.com.com/5100-10878_11-1027920.html#2 R. Manketow, “Stakeholder Analysis & Stakeholder Management,” http://www.mindtools.com/pages/article/newPPM_07.htm

2

technique, but without the backup of a systematic approach it is subject to error, oversight, etc. It is typically very difficult to arrive at a comprehensive list of stakeholders simply by asking the question, “Whose interests are involvedin some way in this project?” The question is toobroad, especially for a relatively large project. One of the most important characteristics of a stakeholder analysis is completeness – making sureno stakeholder has been inadvertently excluded. As a result, relatively unfocused questions and the lack of systematic approach are particularly likely to result in trouble for the project.

Limiting the analysis to the impact of different stakeholders on system requirements may make the analysis easier, but it has the effect of excluding important stakeholders from consideration, to the detriment of the project. For example, one of the most important and common risks in IT projects is lack of executive involvement3. Executive stakeholders often have no impact on requirements for the system; their “stake” may be financial, marketing, organizational turf, or other factors related to the fact that the project is taking place in an organization. A requirements-focused stakeholder analysis will almost inevitably fail to identify such stakeholders, and when the executive finds his or her concern unaddressed the project is at risk.

2. Even after a list of stakeholders is developed, itis often very difficult to identify the pragmatic implications of a traditional stakeholder analysis, i.e., what exactly is to be done about each stakeholder and his or her concern. This is

3 L. Wallace and M. Kiel, “Software Project Risks and Their Effect on Outcomes,” Communications of the ACM, April 2004, V. 47 No. 4.

3

due primarily to the focus of the initial questions, which are “who is the stakeholder” and“what is his/her interest” – ie.., information-oriented rather than action-oriented. Establishing the link between information and its pragmatic implications is notoriously difficult. It is clear that knowing the goals and motivations, and power and influence, of each stakeholder is valuable, but this knowledge is notvaluable for its own sake; it is valuable only in so far as it relates to what we need each stakeholder to do. Whatever we do is done in order to get the necessary things done for the sake of the project; the actions of the stakeholders are the real question, and other things as they affect those actions.

In contrast to the project management literature, most software engineering and software project management books have comparatively little to say about stakeholder analysis. For example, one of the most widely used software engineering texts includes only one page on the subject, and that is limited to the need for, and difficulties in getting, requirements forstakeholders, who are defined as “any person or group who will be affected by the system, directly or indirectly.4”

To be really useful, we need three things from a stakeholder analysis: it has to be complete; it has to tell us just what we need from each stakeholder; and itideally it should help us figure out how to get the stakeholder to do what is needed. Accordingly, we proceed in two steps. First, we show how to develop a table of stakeholders that has the information we need.Then, we develop a procedure for thinking through the

4 I. Somerville, Software Engineering, Seventh Edition, Pearson-Addison Wesley, Boston, MA, 2004, p. 146.

4

key question: how to we get the stakeholders to do whatis needed, in order for the project to be successful.

THE PRAGMATIC STAKEHOLDER TABLE

We begin with a procedure for building a stakeholder table. This table is somewhat similar to more traditional stakeholder analyses, but with two important differences: the structure of the table, and the entries in it. Specifically, in this table, the rows of the table denote the relationships between the person and the project, of which there are exactly six;the columns denote recognizably distinct positions withinthe organization; and the entries denote not the stakeholder but the action required of the stakeholder.

We do not build the table by first asking for names of stakeholders. Instead, we begin with a series of questions designed to elicit the names of people in specific relationships to the project:

Step 1: Make a list of the following:

Anyone who has to approve or endorse the project– approvers.

Anyone who will be actively involved in implementing the project –implementers.

Anyone who will have to clear the way, or break ground, for the project – ground-breakers

Anyone who could kill the project, or make it difficult, if they decided to – project killers.

Anyone whose work methods, goals, schedules, etc., will be affected by the project – impactees.

Anyone who may see the project as infringing on their “turf”, i.e., their proper organizational responsibility – turf defenders.5

5 The list of six types of stakeholders is due to A. O. Putman.

5

These lists of people specify everyone who has a significant relationship to the system and/or the building of it – that is, a relationship we may have todo something about.

Step 2: Make a list of the distinct “realms” or “worlds” of the organization, and distinct positions within each realm.

Stakeholders are not just undifferentiated members of the organization – a member of an organization is always a particular type of member or, to say it differently, has specific position in it. In addition,organizations consist of several overlapping “realms” or “worlds.” Each of these worlds is a self-contained system, and each contains a version of every aspect of the organization. It is not a new observation that the day-to-day processes, objects and situations of interest, and concerns of “the finance guys” are entirely distinct from those of “the IT guys” and “the marketingguys.” In this step, we begin with the recognition that each of these groups of “guys” is a distinct realmof the organization, with distinct interests and concerns – i.e., stakes.

The distinct worlds of an organization are: Financial Quality Marketing Operations IT Industry-specific technical/scientific – any area

of science or technology that is the basis of the organization’s work: molecular biology, chemical engineering, aeronautical engineering, finance, chemistry, law, medicine, etc.

6

Upper management6,7

In addition, while not universal, in many organizations, particularly large ones, there is an additional realm:

Legal

(By “Legal,” we mean the Department concerned with the organization’s legal issues; a company providing products or services in the field of law may or may nothave a Legal Department. Similarly, an investment company will have its own Financial Department, but theday-to-day work of the organization involves experts inthe field of finance.)

Within their realm of the organization, a particular member will have a specific position. That position may be formal, of the sort that we might find on an organization chart, or might be informal but equally real. An Accounting Manager will have interests different from an auditor, for example. Similarly, theconcern of “the guy who knows how things really work around here” (an all important, immediately recognizable, and informal position) in the Marketing Department will be different from that of a Marketer ora Marketing Manager.

Step 3: Combine the two lists into a Pragmatic Stakeholder Table (PST):

Upper

Fina-

Quality

Market-ing

Ops

IT Technical/

LegalDept.

6 The first four of these, and “upper management,” are also due to A. O.Putman, in a separate communication. 7 Strictly speaking, upper management is not a distinct world. However,it refers to a group of people with perspectives sufficiently similar that it is worthwhile to consider them as a distinct realm, for these purposes.

7

mgmt cial

scientific(legal, medical, chemical,automotive, etc.)

Implemen-tersGround-breakersProject killersImpacteesTurf defenders

(For simplicity of presentation, we have not sub-divided realms into positions within them.)

Step 4: In each cell, enter the specific individuals or groups of individuals in the position indicated by column heading who have relationship to the project indicated by the row: the Finance VP who could kill the project if she decided to; the Marketing Dept. Head who perceived the project as intruding on his turf, the programmers and designers building the system, and so forth.

The value of the two lists, assembled into this tabular form, is that they act as systematic checklists for identifying stakeholders. It is much easier to ask, “Who inFinance is involved in implementing this project,” “Who in

8

Marketing has to break ground for this project,” “Who in IT could kill this project if they had a mind to,” etc., than it is to first try to elicit names and then identify interests, the traditional approach.

The PST, with names of specific individuals or groups of individuals in the cells of the table, is a record of the results of examining the project from several distinct positions. In addition to the actual knowledge of the stakeholders it represents, it forces us to inspect the project from all the significant perspectives in the organization – and record the results of that multi-perspective inspection. As we go down the column listing the relationships to the project, we are examining the organization as a project advocate, looking for all individuals who stand in each kind of relationship to the project: who is carrying it out, whose budgets or schedules will be impacted, whose turf might be impacted, who might kill it if they decided to, etc. The column headings list additional perspectives, that is, positions within the organization from which the project will be seen – by peoplein those positions. As we go across the column headings, weare asking, "Looking at the project from the financial (and then quality, marketing, operations, etc.) perspective, who do we see who is affected in some way?"

The row and column labels provide a series of questions thatsystematically focus on every segment of the organization. As with any checklist, their value is not that they tell us something we don’t know, but that they help ensure nothing is overlooked. (An airliner preflight checklist is a good illustration.) They can be used in any order, and interlaced: “Who in Finance has an interest in this project? Who in Marketing? OK, what is James’ interest here – is he an implementer, an impactee, a ground-breaker, or what? All right, we agree he’s a ground-breaker; who arethe other ground-breakers for this system?” etc. Some person or group may be in more than one cell of the table –

9

a respected software architect who will be both an implementer and a ground-breaker, for example.

Step 5: What we have so far is a picture of the project's position in the organization – each stakeholder's position in the organization and their relationship to the project. The traditional next step would be to identify the concern or interest – the “stake” – of each stakeholder in the table. This move, although seemingly natural, is not the most direct route to what we need. The goal of the stakeholder analysis is to identify what we need to do to address the stakeholder’s concern. What we do depends quiteheavily on exactly what we need the particular stakeholder to do, for different actions on their part will require verydifferent actions on our part. If the Marketing Director isbeing asked to simply give permission to use data they have gathered, that is a very different action than if he is being asked to allocate several people from his Department for three months to help identify patterns of customer complaints, and accordingly the action on our part to bring it about will be quite different.

Therefore, our next step is to move to the question what we need from each stakeholder:

For each entry in the table, specify the action we need this person to take, with respect to this project.

The entries must be actions, not feelings, interests, concerns, attitudes, perspectives, or general statements involving kinds of action or thinking. "Jane publicly states that she favors the project" is a valid entry here, but not, "Jane supports the project." It may not be necessary to specify the physical form or version of the action, but each action must be recognizable as something a person does. For example, "Akil gives permission for the project to proceed" is acceptable, because giving permission(authorizing) is a known practice, a "done thing"; it need

10

not be entered as "Margaret gives permission for the projectto succeed by signing the project authorization memo" – unless that specific form of giving permission is, in this case, necessary.

The entries in the PST are the most distinctive aspect of pragmatic stakeholder analysis, as contrasted to other formulations of the task. The entries in the table are not people or interests; they are actions – actions needed by each stakeholder. (The stake itself is not being dismissed from consideration; we will return to in when we address what is involved in getting each stakeholder to do what we need them to do.)

The PST is now complete. It specifies:1. Everyone in the organization with any direct

relationship to the project, and their position in the organization (i.e., their organizational perspective).

2. What we need each of these people to do, for the success of the system and project.

The completed PST is a complete list of who is involved, howthey are involved, and in each case what action is required.. Now we address the question of what it will taketo get each stakeholder to do what the project needs.

GETTING THE STAKEHOLDERS TO DO WHAT YOU NEED

A great number of books have been written about how to get someone to do what you want, and it does not seem useful to attempt to summarize that large body of literature here. In addition to the apparent impracticality of such an endeavor,our experience is that a generalization or set of “canned” techniques is less useful than an organized, systematic way to think through the specifics of the situation to arrive atanswers tailored to the particular people and circumstances involved.

11

In this section, we develop such a systematic method. The goal is not to reveal “secrets” of manipulating others’ behavior, and some of what will follow may be familiar to some readers. It is, rather, to develop a step-by-step approach to addressing all the issues involving members of the your own or the client organization that might arise in shepherding a software project.

Each entry in the PST specifies a person and an action: “John” is to do A. (In what follows, we use a person’s name, “John,” rather than the more formal, and more abstract, “the person,” for purposes of making the checklistmore concrete.) If we want John to do A, we need to think through two kinds of things: Can he, and will he? (It may seem that “can he do it” is a trivial question, scarcely worth asking. As we will see below, several factors go into John being able to do what we need him to, and often one or more of these factors results in John being unable, even if he is willing.)

We present the analysis in a question-answer format, so thatwhen we are done we will have a checklist that is directly usable.

Can “John” do A?

Typically, “Can he do it?” is taken to mean, “Can he carry out the steps?” Certainly John must be able to do the stepsinvolved in what we need him to, but there is much more to it than that. There are several other factors that must be “in place,” or he will be as unable to do it as if he could not carry out some necessary step. We begin with the steps, and then expand the list of questions that need to be asked:

1. Can John do the steps, or methods, needed to do carry out this action (including knowing what the steps are)?

2. Does John have all the relevant facts and information needed to do A?

3. Does John understand the concepts involved in action A?

12

Example: We want John to approve an Extreme Programming pilot project in our Department. Does heclearly understand what XP is, and how it is different from other methodologies?

4. Is John looking at the situation from the appropriate viewpoint, or perspective, so that he can see and evaluate the facts and situations that may arise in carrying out the action?

Example: If John is the lead systems analyst on this IT project, does John have the perspective of someone focused on the client needs and wants, with the goal of making the client satisfied with the product, or does he, by contrast, looking at this project from a technical point of view, viewing it as on opportunity to build a cool, slick, powerful system?

Everyone is familiar with the fact that there is doing something, and then there is doing it well. It’s “the same thing,” but with important differences. A skilled software architect will create better designs than a less-skilled one; a good programmer will produce better code, faster, than a mediocre one; a good software manager’s group will produce better code, faster, and have happier, more satisfied members, than one managed by a mediocre manager; etc. The difference is usually not what they do, but the way in which they do it. They carry out the same steps, but do so in ways that also accomplish more or different results, in addition to the straightforward outcome of the practice: an elegant, easily extensible architecture exactlysuited to the client needs; tight, efficient, but easily understood code; clients that are comfortable with the analysis team and believe that the team is there to make sure the system builders are really responsive to the clientneeds; etc. Also, we’re all familiar with the fact that the skilled performance isn’t a matter of doing different or

13

extra steps; we call it “skilled” when John is exercising abilities he has learned through practice and experience, but for which we have no breakdown into steps. (We don’t, for example, look for the extra steps that make a good software architect good.)

Often, the skills are a necessary part of doing action A at all, not just a nice “extra.” The following two questions address this.

5. Does John have all the skills needed to do A, i.e., is he able to do all those things needed for this action which are done not by following a procedure but becausethey have had the necessary training and experience?

Example: Does John have the skills needed to make new clients comfortable and get them to see that he and his team actually have the goal of developing a system to meet their real needs, not just a “cool” and powerful computer system?

6. One kind of skill, closely related to the question of whether John understands the concepts involved, is whether he can recognize instances of them.

Examples: John understands OO design patterns and knows many

of them, but can he recognize when a situation callsfor a particular one?

John is the Supervisor of a group of designers and programmers. Can he recognize when a design is cumbersome and difficult to modify, even though it is based on an existing framework?

Since skills are only acquired through practice and experience, we often ask, “Does John have the necessary experience in doing this.” This is the more common way to inquire about John’s skills, but it is less precise. We have found that most of the time the person asking “Does he

14

have the experience” cannot identify exactly what skills areneeded. As a result, there is a greater risk that John willhave experience in the area, but not have one or another necessary skills. It is more effective, although a bit morework, to identify the specific skills and inquire about them, in particular.

Some things need a certain kind of personality. For example, in one company the author saw several projects end in failure because the project manager was so risk-averse that he insisted on measures to avoid the most extreme theoretical risks. In one case, the company had promised todeliver, in 5 days, a copy of an already completed prototypeproduct to a government intelligence agency, for preliminaryevaluation. This manager insisted on taking weeks to attempt to prevent the agency stealing the intellectual property by decompiling Java class files. Several months later, project with that agency was dead, due to delays on the part of the company.

7. Does John have the personality characteristics he needsfor this action – the appropriate attitudes, traits, and style?

Examples: Does he have the risk tolerance needed? Does he have the tolerance for ambiguity

needed? Can he handle the uncertainty in this

situation? Does he have an antipathy toward scientific and

conceptual work, or view it as an unnecessary and destructive waste of time?

Does he consider vigorous discussion of alternatives to be harmful to the team?

Does he treat all technical suggestions from colleagues as challenges to his technical superiority?

15

Does he consider clients a necessary evil, an annoyance to be gotten through in order to get to the “real work” of building the system?

8. Does John have the money, time, and other items or materials involved in the process (the steps of) this action?

9. Does John recognize how this action/project fits into the larger action it is part of, and into the project itself, and thus what he will be doing, by doing this –what we can call its significance?

Example: Cradle To Grave Insurance begins an IT project to support a new liability umbrella policy. The significance of this project as initiated is to provide a new type of insurance product for Monmouth. Part way through the project, CGI’s CEO "repurposes" the project, to cover a serious revenueshortfall, thereby changing the project's significance to, "Disguise the revenue shortfall andmake the CEO look good to the Board."

As software professionals, we are all familiar with thefact that often the constituent steps or a larger process are done differently when they are part of different larger processes, even though the constituentstep is “the same” in both cases. This factor is a reminder that the same holds for actions by people and organizations: action A may be done differently when part of a larger actions, and when it is John will needto know what the larger action is and how A fits into it.

Question 1 refers to the process (P) John must go through; Questions 2, 3, and 4 are all specific kinds of knowledge (K) -- facts, concepts, and perspective; Questions 5 and 6 ask about John’s skills, or know-how (Kh); Question 7 asks about his personality characteristics, or PCs; Question 8 asks whether he has the resources (R) needed; and Question 9

16

asks about the Significance (S). So, we can give a usefullyshort summary of these first questions:

If John is to do A, he needs the P, K, Kh, PC, R, and Sfor A.

If any of these 6 factors is missing or deficient, John willbe unable to do what we need him to do for project. When this is the case, the easier situation is that he will not do A at all. Much more common is the more subtle, and dangerous to the project, case in which John does try to do A, but due to the lack of the necessary knowledge, skills, personality characteristics, resources, or appreciation of the Significance he does a defective or deficient version ofit.

Will “John” do A?

Having established that John is able to do what we need him to, we have to ask whether he will do it. Asking this question is a way of starting with a basic fact: John has alternatives, and we want him to choose A. A person chooseshis action on the basis of reasons to do that action, ratherthan something else8, so we need to understand John’s reasons, in this situation.

Reasons are not “internal” or “emotional” things; they are John’s appraisals of the facts as he sees them. So, to analyze whether John will do A, we need to list three kinds of things:

The circumstances or "bare facts" that John considers relevant.

How John appraises each of the facts, i.e., the reasonseach fact implies.

8 P. G. Ossorio, “Notes on Behavior Description,” in Advances in Descriptive Psychology, Vol. 1, K. E. Davis, ed., JAI Press, Greenwich, Connecticut, 1981.

17

The relative importance or weight John attaches to eachreason.

The circumstances are what matters; the reasons are how theymatter. Each reason is a reason to do A or do something else. A fact or circumstance may give John several distinctreasons to do different things, and there may be several reasons to do one action.

We noted earlier that we would return to the issue of the stake itself. This is where the stake is involved: each stake is a fact or a reason (an appraisal of a fact). If the Database Group Supervisor is impacted because her group will have to do extra work, that’s a reason to oppose the project; if the policy for leasing the new product is new and untried, it’s a fact whose appraisals may or may not be known.

The goal of the stakeholder analysis, ultimately, is of course not just to understand; it is to get John to do what we need him to, for the project. The facts he considers relevant (and whether some have been overlooked or inappropriately included), John’s appraisals of the facts, and the relative importance he considers each reason to have, are potentially the elements that we can address.

There are two quite different cases that we need to examine:the intrinsic and the extrinsic case.

Intrinsic and extrinsic motivation

Someone is intrinsically motivated to do something when it is part of their job, or more technically, when it is a practice they engage in simply because that is their position in the organization. This is the organizational version of the fact that a chess player plays chess whenevershe has an opportunity, as long as she does not have stronger reason not to; she does not need to be “convinced.”The things someone finds satisfying are those that are

18

intrinsic to them; doing things that are intrinsic results in satisfaction. Being intrinsically motivated to do A is a reason to do it; if doing A is John’s job, he has reason enough to do it, and will, unless the reasons not to do it are stronger. Recalling the XP example earlier (Question 3 above), approving methodology pilot projects (when the information to be gained is worth the cost) is straightforwardly an action that is part of John’s job – hisposition as Supervisor. He will approve it, unless he has stronger reason to disapprove it.

Intrinsic motivations are the most powerful. When someone isintrinsically motivated, he or she will do a the task more quickly, more effectively, and generally better than otherwise. (This is why a programmers doing work that “turns them on.” will produce better code, with fewer bugs, and do it faster, than otherwise.) For this reason, it is important to know whether John is intrinsically motivated todo A.

Extrinsic motivations – extrinsic reasons – are reasons thatare not directly part of John’s position or things he already values, any benefit other than those already part ofhis job. Examples include an opportunity to increase his yearly budget or staff, an opportunity to increase his group’s influence in the Department, an opportunity to move the working relationship with someone else in the organization in a direction that John wants, or an opportunity to make a favorable impression on company executives.

We begin this list of question with the intrinsic reasons, and then move to the various extrinsic ones John might have.

1. Is John intrinsically motivated to do A – does he see it as part of his job?

2. Does John see this project as an opportunity to get something he already wants (as a member of the organization, in the position he is in)?

19

3. Is A the kind of thing John finds satisfying and motivating in and of itself?

Examples: Does John find it satisfying to resolve technical

disputes between key members of his group? Does John find solving tricky design problems

satisfying? Or does he find them an annoyance, tobe gotten through so as to get on to the coding?

Does John find it satisfying to work with clients to understand their business in depth? (This action, crucial to developing a system that will actually meet a client’s needs, is one that many analysts find extrinsic, or even an annoyance.)

Does John like testing the system to make sure it meets all the requirements – devising devious setsof inputs that the system should handle?

Coercion and resistance

It is all too easy to give John reason to not do what we want – by trying to force him. It is a fundamental fact of human behavior that coercion produces resistance. If we tryto make John do A, we give him very strong reason to not do it – even if he is already intrinsically motivated to do it or sees it as a chance to get something he wants.

This push-and-push back phenomenon is almost universally recognized, and in all probability few would deliberately try to get John to do A by forcing his hand. However, a number of actions that are routine behavior in organizationsare, in effect, coercive, and result in resistance just as surely as if we intentionally tried to make John do A. Perhaps the most common of these is the ordinary act of “going through the chain of command” in an organization: we want John to do A; we ask our manager to speak to John’s manager about it; John’s manager does so, telling John to dowhat we want.

20

This seemingly innocuous action is coercive because, practically speaking, John has no choice. He can scarcely refuse to do what his boss is telling him to do, and so we have in effect removed his options; he cannot not do what wewant.

When this happens, John will almost invariably resist, in a way that is also responsive to his other reasons. He will do as he is told, but will do as little of A as John can arrange, and it will end as soon as he can arrange it. In the software field there are almost limitless opportunities for excuses to stop doing A, because software problems and surprises are so universally recognized: a piece of code turns out to be harder than expected, so John has to pull the programmer off of A; some new and unexpected problem arises that John’s boss would have to agree has higher priority than A; etc. When these situations arise in IT, itis almost impossible to challenge the need to switch from A to dealing with the new problem.

Therefore our next questions are:

4. Is John, in fact, being coerced into carrying out this action – that is, forced to do it, either by threats ("If you don't sign on, we'll have to look very hard atyour budget") or by inappropriate use of authority?

5. Equally important is John's perception: regardless of the facts, does John see himself as being coerced into this action?

21

Relationship-based reasons

Business is all about relationships. Business people pay a good deal of attention to working relationships: building them, maintaining them, and making sure actions do not violate them. This aspect of the business world is often simply unknown to technical people, and relationships and relationship-building are often dismissed as “schmoozing” – being friendly, but not really doing the work.. Relationships are not about being friendly, or asking after someone’s family. They are the core of doing work together:the relationship defines what each person can and will counton the other to do, and what each person is eligible to do. Inmost cases, relationships are at least as important as results – and both impact and are impacted by results. Theyaffect both how the current work is done and the possibilities for future work. In addition, many who do understand the importance of relationships have relatively little understanding of how relationships are created, maintained, and changed, and the crucial connections betweenactions and relationships.

The logical connection between reasons and relationships is that having a specific R gives John reason to do various A's, and reasons not to do other actions. The formal connection is one of consistency: each action A is consistent or inconsistent each relationship R. The logic works in reverse as well: if John has relationship R1 with Jane, does action A involving Jane, and A is consistent withrelationship R2 but inconsistent with relationship R1, John’s relationship with Jane changes in the direction of R2. 9

While the logic of reasons and relationships is relatively straightforward, identifying which action is consistent with

9 P. G. Ossorio, “Outline of Descriptive Psychology,” in Advances in Descriptive Psychology, Vol. 1, K. E. Davis, ed., JAI Press, Greenwich, Connecticut, 1981.

22

all the relationships between the people involved, or precisely which action will move a relationship in a desireddirection, often requires substantial skill. There is a close analogy with Newton’s laws of motion: the laws themselves are easy to state and easy to verify in simple settings, but applying them in situations in which there area number of forces and motions often requires considerable judgment and skill.

The next group of questions addresses whether and how doing A is or is not in accord with the work relationships John has.

6. Does John have the relationships he needs with the other persons or organizations involved in doing A, in order to do it?

Examples: Does John already have the relationship of

"trusted business advisor" with Miracle Pharmaceuticals – the relationship he needs to have if the CFO of MP is to buy into this project based on what John presents next week?

John and Jane are going to have to collaborate closely on this financial analysis software for this client. Do they "get along well enough professionally" – that is, have the appropriate professional relationship -- to do that?

7. Does John know how to create the relationship he needs with the people involved in these actions?

Example: Does John know how to change his relationship with his clients from one in which he is seen as “the computer guy who wants to install some system” to one in which he is seen as a trustedadvisor whose goal is to help the business by providing IT systems?

23

8. Does John have the sensitivity and judgment to successfully maintain the work relationships with othermembers of the organization, and clients with whom he must deal, in carrying out this action? (“Sensitivity”and “judgment” are skills, as described in the section,“Can John Do A?”)

Example: Can John tell Nancy that she must change the kind of entries in the database, without making her feel coerced or that her turf is being intruded upon?

9. Does John have all the eligibilities he needs to do this – all the organizational permissions and authorizations, both formal and informal?

Examples: Is John our recognized expert in ERP applications?

Does he have the credibility to have his opinions on this project count?

Does John have permission to install these software fixes without filing the correction reports?

Does World Wide Airlines consider John a trusted business advisor, or a guy out to sell computing hardware?

10. Does John have the credibility he needs, with the other people involved in this action, to do it successfully?

Example: When John tells the CEO that the new product won't work because the database doesn't havethe proper technical attributes, will the CEO believe him?

24

Organizational factors

Finally, when John is considering whether to do A, he will consider the “fit” of the project, and action A, in the organization. The fit of an action in an organization has several aspects10,11, but three are the most important for ourpurposes:

Every organization has a mission, which is a single, all-encompassing thing it exists in order to carry out.This holds for the entire company or any sub-organization within it, down to the smallest supervisory unit or team. By “all-encompassing,” we mean that every action, no matter how small or technical, is done as part of accomplishing the organization’s mission. The mission serves as an organization’s compass: if something will contribute toaccomplishing the mission, that is reason to do it, andconversely, if it will not or is perceived as not contributing, it will be seen as a waste of resources.

The focus of an organization is fundamentally external:the goal of the mission is to provide some product or service to clients or customers12. As with the missionitself, this is true of the entire company or any sub-organization within it, no matter how small. Accomplishing the mission means having the clients or customers “buy” the product or service, whether the client is outside the company or, as is the case with in-house IT organizations, is one or more parts of the parent organization.

Every organization, again including sub-organizations, has a set of priorities, principles, and philosophies that govern the choices of its members. Following

10 H. J. Jeffrey, “Addressing the Essential Difficulties of Software Engineering,” Journal of Systems and Software, 32:157-179, 1996. 11 A. O. Putman, “Organizations, ” in Advances in Descriptive Psychology, Vol. 5, K. E. Davis and A. O. Putman, eds., Descriptive Psychology Press, Boulder, Colorado, 1990.12 J. Magretta with N. Stone, What Management Is, The Free Press, New York, NY, 2002.

25

Putman13, we use the term “choice principles” for this collection of principles and priorities. The principles are often stated a slogans and images, and are often overlooked or dismissed, or not taken seriously, by technical people, but they are a real as executable code. In particular, if John sees action A as conflicting with his organization’s choice principles – their philosophies or priorities – he has an extremely strong reason not to do it, and almost always will not.

The next group of four questions therefore addresses the fitof action A in John’s organization:

11. Is action A consistent with the mission of the organization, and does John see that it is?

Example: DZ Search is a search engine company. Its mission is to build a new Web search engine, using aunique theory and technology. A group of technical people in DZ develop a proposal for the company to build a special database to enable the company software to attach “tags” to text documents that arecodes for what kind of event the document is about. The event tags are clearly related conceptually to the new technology but will not help search. Without a clear connection between event coding and DZ’s mission, John will not approve event tagging project, in spite of the conceptual connection, for he will see it as not contributing to the mission, even if it is technically successful.

12. Does doing A violate any of the choice principles ofthe organization – and does John see it that way?

13 A. O. Putman, “Communities,” in Advances in Descriptive Psychology, Vol. 1, K. E. Davis, ed., JAI Press, Greenwich, Connecticut, 1981.

26

Example: ABC Pharmaceuticals exists to invent and market anti-retroviral drugs. It highly values allowing its pharmaceutical researchers to follow their impulses and ideas, whether they can justify them or not. Researchers at ABC, as do all researchers, depend heavily on their intuition and “feel” for the paths that seem likely to pay off in new products. A VP of Operations, noting the lack ofplans and measurable milestones in the Research Department, proposes that a new tracking system be implemented to manage the researchers and their time, to reduce the amount of time wasted in exploring dead ends. The system will maintain research plans for each researcher. Each plan will specify in detail research goal, the steps to be taken, the amount of time to be spent in each step, and the criteria the researcher will use in decidingwhether to continue the project at the end of each step. The criteria must be specific, focused, statements giving estimates of probability of success of the next step and of eventual successful product creation. Will John, the COO, approved the project? Not if he acts in accord with ABC’s choiceprinciple that researchers be allowed to follow their intuitions.

13. Will the project, and therefore action A, provide value to the clients, as defined by the clients, and does John see that it will?

14. Will the client buy (or the other in-house organization adopt) the product, when the project is complete, and does John believe they will?

If "John" is a team – "Can He?" revisited

Often, an entry in the PST will be a group of people, not anindividual: “We need Marketing to buy in to this,” “We need Sales to agree to supply data,” etc.. In this case, the question of whether The Team will do A changes relatively

27

little, but whether a group can do something (effectively and correctly) is a different question than whether an individual can, and different factors are involved in the answer. Fundamentally, whether a group will do action A is the question of whether that group is a well-functioning team and whether they see that A is a legitimate part of their job.

The literature on effective teams includes a great deal of advice and many techniques on how to create one. We can summarize that literature by noting that a well-functioning team has:

A clearly defined mission, that is clear to everyoneon the team.

A set of work practices and methods to accomplish the mission

A set of values/priorities/philosophies – i.e., choice principles -- that govern their choices in carrying out those practices.

A set of well-defined positions for each member on the team (although position assignments may fluid orrigid).

We have seen three of these earlier: mission, practices, andchoice principles are core facets of an organization. The fourth, “positions,” is equally a defining aspect of an organization; the positions, or Statuses, in an organizationdefine the roles the members can take in it. In short, a team is an organization. We can then use the concept of an organization to ask whether The Team in the PST can carry out the action needed: it can do it if the action is, and isseen by the team members as, a proper part of its mission and it has the "structure" to do it: the practices, choice principles, and statuses.

15. Does The Team agree that action A is its new missionor part of it – and that until this mission is completed everything everyone in The Team does is devoted to accomplishing A?

28

16. Do the members of The Team see action A as somethingworth doing – something they find motivating and satisfying?

17. Does The Team consider that it has been appropriately included in the decision to make this action its new mission – or do the members see the imposition of A as coercion? (Or, to use more emotional language, have they “bought in” or are they resentful and skeptical?)

18. Does The Team have the appropriate values, priorities, and philosophies – i.e., choice principles -- for carrying out this mission? (An important complexity here is that "having" the principle means that the members know it is the actual principle, understand it, and are prepared to act on it. Simply telling a team to use a new set of priorities does not create this situation; it's only the first step.)

19. Does The Team have the appropriate set of work practices for carrying out this mission – that is, doesit know specifically what to do, to accomplish A?

20. Has The Team identified the necessary roles, within itself, needed to do A?

21. Does The Team have the necessary relationships with other sub-organizations?

Example: John is the Supervisor of the Software Productivity Group in the IT Division. The DivisionManager has a project: improve the Division's software productivity 15% over the next 6 months. IfJohn’s Group is to succeed at this project it needs to have a specific relationship with the software development groups in the Division: the relationshipcharacterized by trust that the SPG really understands software development in the Division, and is there to make development better. If John’s Group does not have that relationship, the productivity improvement project will fail, as surely as if it had never been initiated at all, although in its failure it will have more negative

29

side-effects in the IT Division than if it had not been initiated.

Checklists and complexity

There are 21 questions in the above checklist; going throughit is a significant amount of work. In addition, each of these 21 items applies to every entry in the PST. As a result, it may seem that this approach to stakeholder analysis involves a great deal of additional work. It’s not the stakeholder analysis that involves work; it’s the project. It should come as no surprise to any practitioner that projects can involve a lot of people, often with surprising relationships to the project, and that getting all these people to do what we need can be time-consuming and difficult. Building the PST and analyzing whether each stakeholder can and will do what the project requires gives us map of the work needed involving the various stakeholders. Certainly building this map requires time and effort, just as designing a complex software system takes time and effort. As with design, the larger and more complexthe project, the greater the importance of a complete, systematic, action-oriented stakeholder analysis.

30