Integrating Stakeholders and 

Users into the Geography 

Discipline’s Research Process 

By Caroline M. Hermans and Richard Taketa 

2006 

Open File Report 2006-1344 

U.S. Department of the Interior 

U.S. Geological Survey 
ii

U.S. Department of the Interior 

DIRK KEMPTHORNE, Secretary 

U.S. Geological Survey 

Mark D. Myers, Director 

U.S. Geological Survey, Reston, Virginia 2006 

For product and ordering information: 

World Wide Web: http://www.usgs.gov/pubprod

Telephone: 1-888-ASK-USGS 

For more information on the USGS—the Federal source for science about the Earth, 

its natural and living resources, natural hazards, and the environment: 

World Wide Web: http://www.usgs.gov

Telephone: 1-888-ASK-USGS 

Suggested citation: 

Hermans, C.M., and Taketa, Richard, 2006, Integrating Stakeholders and Users into the Geography 

Discipline’s Research Process: U.S. Geological Survey Open File Report 2006-1344 [available on the World 

Wide Web at URL http://pubs.usgs.gov/of/2006/1344/ ]. 

Any use of trade, product, or firm names is for descriptive purposes only and does not imply 

endorsement by the U.S. Government. 

Although this report is in the public domain, permission must be secured from the individual 

copyright owners to reproduce any copyrighted material contained within this report. 
iii

Contents 

Section 1: Introduction ......................................................................................................................................................1

Research in Geography: Clarifying our Purpose.......................................................................................................1

Report Overview .............................................................................................................................................................2

Section 2: Stakeholders and Geography’s Research Process ..................................................................................2

A little scenario ...............................................................................................................................................................2

Research, Users, and Stakeholders............................................................................................................................3

Section 3: Stakeholder Analysis ......................................................................................................................................6

Identifying the Stakeholders.........................................................................................................................................7

Templates for organizing stakeholder information...................................................................................................7

1. Stakeholder Identification Checklist ...................................................................................................................7

2. Stakeholder Importance Matrix ...........................................................................................................................9

3. Stakeholder Influence and Importance Matrix...............................................................................................11

4. Matrix of Stakeholder Perspectives, Stakes/Interests, and Objectives.....................................................12

5. Stakeholder Roles Matrix....................................................................................................................................13

Stakeholder Analysis Summary .................................................................................................................................14

Section 4. User-needs assessment and usability.......................................................................................................16

Tools for User-needs Assessment ............................................................................................................................18

1. Interviewing and Questioning.............................................................................................................................19

2. Workshops, Focus Groups, and Surveys..........................................................................................................23

3. User Activity Matrix..............................................................................................................................................24

4. Prototyping.............................................................................................................................................................24

5. Prioritizing Your Users—Streamlining Your Product .....................................................................................25

Section 5. Conclusion ......................................................................................................................................................26

Scenario Revisited........................................................................................................................................................26

Communicate Your Strengths, Understand Their Needs ......................................................................................26

References.........................................................................................................................................................................28

Appendix A. Additional Resources................................................................................................................................29

Stakeholder Analysis Resources...............................................................................................................................29

User-needs Resources ................................................................................................................................................30

Project Management Resources...............................................................................................................................31
iv

Figures 

Figure 1. Stakeholder relationships and connections—stakeholders represented on a hypothetical river 

management team and the roles they have on the team............................................................................................8

Figure 2. Stakeholder relationships and connections. This schematic shows the connections between 

water managers, users, and providers in an urban water district............................................................................9

Figure 3. Influence and Importance Matrix. In this matrix, for example, towns have high influence and 

importance, river users, on the other hand, have little influence and are not central to the issue. .................12

Figure 4. The ideal research product originates from collaboration between researchers and users...........17

Figure 5. User-needs assessment (UNA) within the stakeholder assessment process.....................................19

Tables 

Table 1. Stakeholder-based research protocol............................................................................................................4

Table 2. Stakeholder terms...............................................................................................................................................5

Table 3. Four “I’s” of stakeholder involvement (adapted from Justice and Jamieson, 1999)............................10

Table 4. An example of a Stakeholder Importance Matrix.......................................................................................10

Table 5. Stakeholders perspectives, stakes and objectives in a hypothetical river management problem. ..13

Table 6. Sample Stakeholder Roles Matrix..................................................................................................................15

Table 7. User’s context of use........................................................................................................................................20

Table 8. Open-ended questions.....................................................................................................................................22
Integrating Users and Stakeholders into the 

Geography Discipline’s Research Process 

1 By Caroline M. Hermans and Richard Taketa

Section 1: Introduction 

Applied collaborative research is about working with stakeholders, not on them. 

Research in Geography: Clarifying our Purpose 

Future research priorities of Geography emphasize the discipline’s leadership role in the 

U.S. Geological Survey (USGS) in multidisciplinary and integrated research on human 

and environmental systems and how these systems are interrelated and respond to change 

(McMahon et al., 2005). 

Geography’s research priorities also emphasize providing science that is usable to 

society and creating decision support products applicable to given customer problems. To 

achieve these goals, we must understand the relationship between our research and our 

customer, and how to integrate the customer into the research process.

2

This report details the elements of the research process that help achieve the 

degree of stakeholder involvement necessary to ensure a successful end-product. It offers 

suggestions that can help researchers better understand stakeholders and customers and 

involve them in the research process more effectively, while preserving the integrity of 

the science. Its aim is to help researchers understand the problems and challenges faced 

by our customers and communicate the ways in which Geography can help address their 

problems. 

Adopting these guidelines can improve the efficiency of the research process and 

lead to higher quality output. We will be able to conduct better research because we will 

have an improved understanding of the research problem and the stakeholders involved. 

 

1

 Caroline Hermans, U.S. Geological Survey, 345 Middlefield Road, MS 531, Menlo Park, CA 94025, 

(650) 329-4225, chermans@usgs.gov; Richard Taketa, U.S. Geological Survey, MS 531, Menlo Park, CA 

94025, (650) 329-4231. 

2

Note: USGS defines “customer” as the “users of our information” (USGS, 2000) and “research” implies 

applied collaborative research that involves a high degree of customer input. 

1 
Report Overview 

This report covers a broad range of topics, from identifying and communicating 

with stakeholders and users, to the use of language, to how to effectively present 

scientific information to the user. It does not offer a “one size fits all” method. Instead, 

perhaps only specific sections are suitable for a given project and customers, depending 

on project scope and needs. This report is based on the objectives of Geography’s 

strategic plan (McMahon et al., 2005), U. S. Geological Survey’s strategic plan (USGS, 

2000), and Department of Interior’s strategic plan (DOI, 2003). 

Section 2 of these guidelines describes the purpose of the research process in 

Geography and the need for better user involvement in the process. Section 3 explains 

how to conduct a stakeholder analysis. Section 4 explains how to conduct a user-needs 

assessment. 

Section 2: Stakeholders and Geography’s Research Process 

“Consultation, cooperation, and communication all in the service of conservation” 

(DOI Strategic Plan, 2003) 

A little scenario 

Eric is developing a decision support product that will help the customer (Jane) 

make informed decisions about conserving wide buffers adjacent to a river. Eric and Jane 

are having a conversation early in the process to scope out the project requirements. 

Eric: In your day-to-day work, what are your main concerns about the areas you 

are dealing with? 

Jane: I am concerned about the effects of pollution on the river, as well as the 

effects of recreation and riparian development. 

They agree on the development of a tool that will allow Jane to understand the effects on 

the river of these three variables. Eric and his research team develop a decision-support 

tool. Eric comes back 6 months later to present the work. After the presentation: 

Jane: This is not helpful to me. I am not interested in pollution as it relates to the 

entire river; I am interested in how it relates to specific species and their 

microhabitats, namely river bottom dwellers. I didn’t really want to look at 

the cumulative effects of pollution, development, and recreation; I wanted 

to look at these impacts on specific areas of the river. I am interested in the 

impact of development on specific riparian buffers-not on the river itself. 

Recreation is not as bad a problem as development and pollution, yet it 

seems this model considers it so. 

Eric: But you said you were interested in the effects of pollution, recreation, and 

development on the river! So that is what we did. Did you change your 

mind? 

2 
Jane: [growing irritated] I was talking about specific areas, not modeling the 

entire river – I am not even involved with what goes on miles downstream 

from here! So this is not useful at all! 

Eric: [increasingly frustrated] But you said you were interested in the three 

impacts on the whole river. 

Jane: Why would I say that if we already have a river-wide model that looks at 

the three factors as a whole, what am I going to do with 2 models that do 

the same thing? I want to know about the impacts on specific areas, that’s 

what I said! 

And on it goes. 

The issue demonstrated by this example is the making of and acting on 

assumptions. Whatever you do, be careful about operating on assumptions. Through your 

conversations with the user, you want to either verify assumptions or throw them out. In 

reading this, the actions to take to ensure we do not end up here are obvious; it all comes 

down to communication. Unfortunately, there are no magic models that guarantee 

successful communication, but there are tools and skills that will help you in your 

communications with stakeholders and users. 

So how do we ensure our research products are usable and useful to the user? 

First we must understand our users’ needs by conducting a user-needs assessment. 

Secondly, we must communicate with the user during the project to ensure that their 

requirements are being met as the research product develops. Thirdly, as the research 

product is used, we must measure the usability of the product by looking at its 

effectiveness, efficiency, and the satisfaction of the user. The research products we 

design are used in complex social and institutional environments, and in order to ensure 

our research will be implemented, it is essential to understand these environments. As 

researchers in Geography involved with stakeholders, we are being asked to go beyond 

the science to design products that implement science in a useful way for the customer 

and other stakeholders. 

Research, Users, and Stakeholders 

The Department of Interior’s Strategic Plan stresses the use of science and 

partnerships in order to serve communities by “advanc(ing) knowledge through scientific 

leadership and inform(ing) decisions through the applications of science” (DOI, 2003, p. 

8). DOI’s management approach suggests that “all of our activities will be customeroriented, designed to add value for citizens, partners, public-land users, and other 

agencies” (DOI, 2003, p. 21). 

How can Geography Discipline’s research process and products effectively reflect 

Geography, USGS, and DOI strategic objectives to serve communities, inform decisions, 

and orient research towards the customer? In traditional scientific research the initial 

starting point is the hypothesis to be tested, and customer involvement is not emphasized. 

A model is developed, data is collected and analyses are run. Under this framework, a 

customer is not necessarily identified to receive the research. Applied, collaborative 

geographic research has a different initial starting point. The focus is the customer and 

his problem. The research process begins with and is developed around the identified 

3 
problem. Once the customer and problem are well defined, then the hypothesis, model 

development, data collection and analysis can happen. 

A stakeholder-based research protocol can bring the customer into the research 

process, from the proposal phase through development and execution. The procedures in 

this protocol represent a shift in making collaborative and useful research an explicit part 

of a project. Table 1 details the steps in conducting stakeholder-based research. 

Table 1. Stakeholder-based research protocol. 

Step 1 Departure point is the stakeholder problem or issue and the project proposal makes explicit 

the needs and goals of the customer (problem), how the customer is integrated into the 

research process (customer engagement), and how the research product meets the needs of 

the customer (responsive products/services). The research hypothesis is developed around 

the stakeholder problem. 

Step 2 Conduct stakeholder analysis. 

Define stakeholders’ roles, needs and priorities. 

Evaluate potential of project success prior to embarking on project (based on stakeholder 

analysis and consultation with customer). 

Step 3 Develop and define research question/hypothesis, conceptualize research product based on 

problem formulation with customer input and assessment of their needs and priorities. 

Step 4 Product development: develop research product to target needs and priorities of the 

customer. Continued customer interaction during research process to assure product meets 

potentially changing customer needs. 

Step 5 Application of product to customer problem. 

*Note: For more information on aspects of project management, such as team management, project 

execution, time, quality and cost management, see the Resources section at the end. 

The terms stakeholders, users, customer, and client, mean different things to 

different people. Below, these terms are defined as they are used in this paper. Each 

project is unique and, depending on project specifics, you may want to define these terms 

differently—just make sure that everyone on your research team is using these terms in 

the same way to avoid misunderstandings. Table 2 lists the most common stakeholder 

terms. 

Stakeholders are broadly defined to include everyone with a vested interest or 

who is affected by your project. The term is also defined as “individuals or organizations 

who stand to gain or lose from the success or failure of a system” (Nuseibeh and 

Easterbrook, 2000); or “...any person, group, or institution that has an interest in (the 

project). This definition includes intended beneficiaries and intermediates, winners and 

losers, and those involved or excluded from the decision-making process” (EDIAS, 

2001). The term “stakeholder” also includes customers, clients, users, and others 

involved in or affected by the project (table 2). 

4 
Table 2. Stakeholder terms.

Stakeholder Definition 

Sponsor Approves project. May fund project. 

Customer, Client, User The direct users of our research product or service. 

Primary Stakeholder Directly impacted by the project. 

Directly involved in implementation. 

Buy-in is needed for project to succeed. 

Secondary Stakeholder Impacted by project, but in an indirect way. 

Experts Have critical information or data. 

Have content knowledge specific aspects of the issue. 

Develop data inputs, define political/social environment. 

May be scientists, researchers in USGS, and from universities and local 

organizations. 

Decision-maker May or may not be a stakeholder. May or may not be a user. 

Buy-in from decision-maker(s) may be necessary for project to succeed. 

Audience Receivers of results of research from customer, they can be also be stakeholders 

and/or decision-makers and/or secondary users. 

Primary user The customer (although in some cases, the customer might be different from the 

primary user). 

May or may not be a decision-maker. If not decision-maker, will probably have 

role influencing decision-maker. 

Secondary user Also uses research product, but is not main user. 

Big picture user Concerned with output/results of research product and its impact on targeted 

stakeholders. 

Technical user Concerned with usability, interface, and output capabilities of product from 

technical standpoint. 

Data providers Similar to experts, provide data inputs to research. 

(Adapted from Justice and Jamieson, 1999.) 

Analyzing stakeholder and user-needs are two different processes. A stakeholder 

analysis accomplishes multiple goals. It identifies the primary and secondary users of the 

research product. It identifies other parties who have a stake or can influence the project 

directly or indirectly. It also characterizes the political, socioeconomic, and cultural 

environment of the stakeholders and the degree of conflict or collaboration that might 

exist. Finally, it characterizes the relationships between the parties and how they interact. 

Stakeholder analysis differs from user-needs assessment by focusing on 

identifying the project’s key players, assessing their interests, and the ways in which 

those interests affect project risk and viability (Allen and Kilvington, 2001). “A 

stakeholder analysis aims to identify the characteristics of key stakeholders, assess the 

manner in which they might affect or be affected by the project, understand relationships 

between stakeholders (including potential conflicts of interest and expectations), and 

5 
capacity to participate” (Gavin and Pinder, 2001, p. 2). In contrast, user-needs assessment 

focuses on the specific project features necessary to meet the requirements of those users. 

Stakeholder analysis “contributes to project design by identifying the goals and roles of 

different groups, and by helping to formulate appropriate forms of engagement with these 

groups” (Allen and Kilvington, 2001). 

Why is stakeholder analysis important? Going straight to the user of your product 

and not spending time and other resources on analyzing stakeholders is tempting. As one 

consultant puts it, “user-centered design professionals pay special emphasis to one type 

of stakeholder—the users of the system—arguing that user experience needs to be 

carefully crafted to satisfy user-needs. While understanding user-needs and goals is 

certainly necessary, it is often not sufficient for producing a successful design. “Design 

needs to incorporate the goals and perspective of other stakeholders in order to get their 

buy-in and be considered a success...” (Boutelle, 2004). 

Although conducting a stakeholder analysis sounds straightforward and relatively 

easy, the breakdown of stakeholders’ roles can be complicated and messy. Often, 

stakeholders play multiple roles in a problem, with complex relationships among 

different players. The primary users are not always obvious, and without a stakeholder 

analysis the project may be well underway before it becomes apparent that the wrong 

users have been targeted. 

Stakeholder analysis helps the researcher understand the political, economic, 

institutional, and social climate of the user, because this can have a tremendous influence 

on the impact of a project. For example, a project may be conducted very differently if it 

is understood that the users do not have the decision-making power necessary to 

implement the project with their stakeholders. The research being developed might be 

used for different purposes in different situations, and in some situations the chances of 

the research being useful might be greater than in others. Understanding stakeholders 

through an analysis would have told you who the true decision-makers are. Your 

stakeholder analysis may also tell you that they are not ready to make use of your 

science. In this case, you will need to redirect your project to ensure that the research 

product is usable. 

A stakeholder analysis is especially important if the customer is planning to use 

your product in consultation with their stakeholders (secondary users). Do not assume 

they have conducted a stakeholder analysis. Instead, make sure you understand who their 

stakeholders and users are and how your product is to be used. For example, the partner 

organization says that their stakeholders are interested in the effect of a natural hazard in 

a given area. If this is not a result of a stakeholder assessment, but an assumption, then 

time and resources could be wasted if the secondary user is actually interested in a 

different hazard in a different area. Assuming you know who all the players are and what 

they need from you is all too easy, but you will be operating blindly unless you conduct 

the appropriate analyses. 

Section 3: Stakeholder Analysis 

The scope of the stakeholder analysis is different for each project. Sorting out all 

the different players will be more difficult for some projects than others, and there is no 

6 
one “correct” way to conduct an analysis. Basically, your analysis will consist of talking 

to people involved in the project and determining their interests, goals, and relationships 

to others involved. The way in which you communicate with stakeholders as a USGS 

researcher is so important that this guide contains a section on communication (see 

Section 4). 

One of the simplest ways to keep track of your stakeholders is to put them in a 

matrix and categorize them according to a set of criteria. You can categorize your 

stakeholders in a number of ways; the templates on the following pages offer some 

examples. The stakeholder analysis should be based on information from the stakeholders 

and not your assumptions or the opinions of other experts outside the scope of the 

problem. 

Identifying the Stakeholders 

Identifying the stakeholders is probably the most difficult task of the stakeholder 

analysis. There is no easy way to know who all the stakeholders are, especially in 

complex, large-scale environmental problems. The first step is to talk to the stakeholders 

you know are involved. Through the course of your conversations with them, other 

interested parties will be identified. You will want to talk to these parties as well. You 

will want to ask each contact to identify other parties involved in this issue. As you talk 

to contacts, your understanding of the stakeholders involved in the issue and their roles 

and importance will mature. There will come a point that you will have a fairly complete 

initial picture of relevant stakeholders and their role in the issue (although it will probably 

change as the project progresses). The following templates can help clarify the roles, 

relationships, priorities, and importance of the stakeholders identified. 

Templates for organizing stakeholder information 

You can organize information collected during a stakeholder analysis in a variety 

of ways. Several tools are described below, but this is by no means an exhaustive list. For 

more stakeholder tools, please see the Additional Resources section at the end of this 

report. The tools used will depend on the preferences of your research team for 

organizing information. Although these tools might seem simple and perhaps busy work, 

they can be very valuable in fostering a common understanding amongst research team 

members and promoting a deeper understanding of the parties involved. 

1. Stakeholder Identification Checklist 

One of the simplest techniques is to create a simple stakeholder checklist or 

matrix to help you define the different stakeholders involved in your project. The steps 

involved in creating a stakeholder identification matrix are: 

(1) List known and potential stakeholders 

(2) Differentiate and group stakeholders 

• Primary and secondary stakeholders 

• Others 

7 
(3) Brainstorm to determine who are the key stakeholders and ask known 

stakeholders to identify other potential stakeholders. 

• Define role 

• Assign importance 

• List potential interests 

(adapted from Groot, 2001; Overseas Development Agency, 1994) 

A schematic is another simple way to define the stakeholders, as shown in figure 

2. It is a simple diagram that charts out the relationships and connections among 

stakeholders. Using schematics can promote understanding among project researchers 

and facilitate communication about the project. 

Figure 1. Stakeholder relationships and connections—stakeholders represented on a 

hypothetical river management team and the roles they have on the team. 

Town of 

Hancock 

River 

Management 

Team – makes 

decisions

State Department of 

Environmental 

Conservation 

Farmers

Town of 

Granville 

Town of 

Rochester 

Property 

Owners 

River 

Users 

disagreement 

agreement 

strong influence 

no influence/ 

high interest

funding 

Watershed Partnership 

data 

8 
Figure 2. Stakeholder relationships and connections. This schematic shows the 

connections between water managers, users, and providers in an urban water district. 

Metropolitan Water

District 

MWD

West Coast Basin

Utilities

Ground Water Pumpers

Central Coast 

Utilities

Residential commerical

and indusrial water

users

Water Replenishment

District

WRD

Enduser-concerned about water quality, 

reliability and price, Endusers can get water 

from only ground water, only imported water, or 

a combination, depending on location

WRD manages ground water resources, 

concerned with long-term sustainability 

of aquifers, regulates pumping, 

purchases water from MWD for artifical 

recharge

Ground water pumpers provide ground 

water to users in the two basins in the 

region, concerned with water rights, 

pumping limits

MWD provides imported water

to WRD and Utilities, concerned 

with water availability from 

Colorado River and aqueducts, as 

as quality issues. 

Utilities concerned with water 

availability from imported and 

ground water sources, water 

treatment and water users needs

2. Stakeholder Importance Matrix 

Another, more detailed way to organize stakeholders is by their involvement in 

the project through a Stakeholder Importance Matrix. Justice and Jamieson (1999) group 

stakeholders in the “four I’s” of involvement, as summarized in table 3: 

9 
Table 3. Four “I’s” of stakeholder involvement (adapted from Justice and Jamieson, 1999). 

Involvement Definition Example 

Influence Those with influence to block decisions Primary stakeholders 

Decision makers 

Client 

Interest Those with demonstrated interests in the work of the group Primary stakeholders 

Decision makers 

Client 

Impacted Those who will be affected by decisions Stakeholders 

Intelligence Those who possess data needed to contribute to an intelligent 

database 

Expert partners 

This basic importance matrix can be expanded to include the role of each 

stakeholder and any significant relationships among stakeholders. This includes both 

their informal and indirect relationships. Explicitly defining stakeholder relationships and 

degree of importance can be important in politically charged situations. 

Table 4 offers an example of a stakeholder importance matrix used to rate the 

importance of each party/participant based on the Four-I’s (on a scale of 1-5, 1 = low, 5 = 

high). The stakeholders with the highest totals are the most central to the project. Note 

that the attributes are equally weighted in this case. In reality, attributes deemed more 

important could be weighted to allow for prioritization of the attributes. 

Table 4. An example of a Stakeholder Importance Matrix. Intelligence Influence Interest Impact Total 

Stakeholder Stakeholder Role Significant Relationship 

Resource 

Managers 

Customer/ 2 5 5 5 17 Communicate directly to 

development board User 

Developers Primary Stakeholder 4 1 5 2 12 Vocal and at odds with resource 

managers 

Community 

Members 

Primary Stakeholder 3 4 5 2 14 Some are developers, influence 

decisions through communication 

with county development board 

County 

Development 

Board 

Secondary 

stakeholder and 

major decision 

maker 

5 5 4 4 18 Advises water management board 

Department of 

Interior 

Sponsoring agency 3 5 2 1 11 Employ park managers 

10 
3. Stakeholder Influence and Importance Matrix 

Groot’s (2001) Stakeholder Importance and Influence Matrix is similar to the 

Stakeholder Importance Matrix (above). Stakeholders are plotted based on their 

importance and influence, as in figure 2 above. This displays stakeholder influence and 

importance in a more graphical form. 

The influence of a stakeholder is evaluated by the following determinants (these 

determinants can be modified based on the needs of the project): 

• Administrative or legal hierarchy 

• Authority of leadership 

• Control of strategic resources for the project 

• Possession of specialist knowledge 

• Negotiation position 

The importance of a stakeholder in the process refers to “the importance given to 

satisfy stakeholders’ needs and interests.” Two questions can be asked to decide how 

important a stakeholder is (1) “Which stakeholders do we regard as priority, in terms of 

meeting their needs, interests, and expectations?” and (2) “Which stakeholders’ interests 

converge most closely with the sponsor’s objectives?” (Groot, 2001). Note that the 

Influence and Importance Matrix, as with any of these templates, can be completed not 

only by the researchers but by the stakeholders as well. Having the stakeholders 

complete these templates will give the researcher a lot of information about individual 

stakeholder’s perspective on their role/influence/importance in respect to the 

roles/influence/importance of other stakeholders. 

11 
Figure 3. Influence and Importance Matrix. In this matrix, for example, towns have high 

influence and importance, river users, on the other hand, have little influence and are not 

central to the issue. 

High Importance 

Low Influence 

High Importance 

High Influence 

Low Importance 

Low Influence 

Low Importance 

High Influence 

4. Matrix of Stakeholder Perspectives, Stakes/Interests, and Objectives

Another way to analyze stakeholders is to understand the perspectives 

stakeholders hold about the problem as well as the stake they have in the problem. This 

extends analyzing relationships to include their perceptions of the problem and their 

desired objectives. If applicable, conflicting and shared perspectives among stakeholders 

should be analyzed. 

Perspectives and objectives can be organized together through the development of 

an objectives-perspectives matrix. This will provide researchers with a clearer idea of 

where stakeholders agree and disagree, as well as what their respective goals are. In table 

5 below, the matrix combines perspectives, objectives, and what stakeholders have at 

stake for a hypothetical river management issue. 

High Importance 

Low Influence 

 

Low 

Influence

Im ortance 

p

Influence

Im

Watershed Towns 

Partnership 

ortance 

p

River 

Users 

Property 

Owners 

Farmers 

12 
Table 5. Stakeholders perspectives, stakes and objectives in a hypothetical river 

management problem. 

Perspective on 

reasons for 

problem 

Perspectives 

on solutions for 

Stakeholder problem Stake Objectives 

Conflict / 

opposing 

perspective 

With 

environmentalists 

Riparian 

landowner 

Nature causes 

problems (for 

example, 

flooding) 

State needs to 

ensure private 

property is 

protected 

Own riparian 

land 

Keep land 

productive 

with no 

erosion, no 

loss of land 

to the river 

With local 

governments, 

riparian 

stakeholders 

Department of 

Environmental 

Conservation 

Channelization 

of river by 

state, poor 

understanding 

of river system 

dynamics 

Education of 

river users, land 

owners – allow 

river to return 

to natural state; 

establish 

buffers, 

meanders 

Pay for river 

management 

(flood costs, 

erosion/ 

sedimentation 

control) 

Decrease 

flood 

mitigation 

costs, long 

term river 

system 

health 

Tries to represent 

all interests 

Watershed 

Partnership 

Channelization Education, 

allow river to 

return to natural 

state 

Concern for 

river health, 

private 

economic 

interests, 

community 

river needs 

Balance 

river and 

community 

needs 

State/Watershed 

Partnership 

Local towns State needs to 

riprap and 

remove gravel 

more 

extensively 

State needs to 

riprap and 

remove gravel; 

continue 

channelization 

Flooding 

problems 

Increase 

developable 

land 

(Adapted from Groot, 2001) 

5. Stakeholder Roles Matrix 

Finally, a stakeholder roles matrix is an effective way of clarifying stakeholder 

relationships. It requires more effort than the techniques described above, but it “assists 

understanding of who does what in relation to the ‘system of interest’ so that gaps and 

overlaps in roles can be identified and acted upon. Looking at stakeholder roles assists in 

identifying weaknesses due to duplication of effort, competition, or just poor task 

performance” (Groot, 2001). This can also be completed for research roles as a part of the 

project work plan if there are many parties involved to identify gaps and overlaps in 

research roles. 

The steps in developing a stakeholder role matrix are (1) identify relevant 

individual stakeholders (see Defining Stakeholder section above) and define the roles and 

13 
tasks involved and (2) Assess roles by scoring each stakeholder’s role in terms of 

function and importance. The matrix can take different forms, depending on the project 

needs. An example of a roles matrix for stakeholders is presented in table 6. 

Stakeholder Analysis Summary 

The level of detail needed for a stakeholder analysis will vary with the situation. 

In some cases, you will have an established set of stakeholders, and the process involves 

simply verifying that the situation has not changed. In others, you may have a complex 

set of primary, secondary, and indirect stakeholders, and the analysis will involve a 

detailed investigation of their interests and relationships. The templates provided here are 

tools you can adapt to your specific research project. All of these templates can be 

customized to suit the needs of the project and your research team. 

14 
Table 6. Sample Stakeholder Roles Matrix. 

Stakeholder Roles in Project Refuge Name Organization Title Role Specific contribution Data/ Primary 

Stakeholder 

Pro

Us

Expert 

R. Jones State Government Sponsor Funding/guidance P. Higgins State Government Main point of 

contact 

Liaison, knows all the players +++ +

Drs. Jones and Hayward 

State Wildlife Refuge 

Managers USER Will use our research in 

decision-making process involving refuge boundaries and extent 

+++ ++

M. Ivy Neighborhood 

Association, 50 members 

Head Primary 

Stakeholder 

Communicates concerns of neighboring community regarding refuge impacts 

++ 

N. Nage Local government Town 

Planner 

Stakeholder Development planning of town, 

helps look at possible impacts on refuge 

++ 

Drs. Mitchell, Olhan 

USGS Biologists Provide data Refuge data +++ 

H. Abe Local 

environmental group 

Head Provide input, 

stakeholder 

Concerned about health of refuge 

+ + 

 +++ Critical/fully involved  ++ Important  + Secondary/partially involved  ? Unknown  ?+++ Potentially critical, no communication yet 

15
Section 4. User-needs assessment and usability 

User-needs assessment (UNA) is the process of understanding the requirements, objectives, 

and priorities of the user to help ensure that a research product addresses the needs of the users. It is 

not a one time analysis, but continues over the life of the project. Tied in with UNA is usability, 

defined by the International Standards Organization (ISO) standards as, “the degree to which a 

product can be used by specific users to reach specific goals with efficiency, effectiveness, and 

satisfaction in a given use context” (Alva, 2003). Bevan (1995) states that usability is synonymous 

with ‘quality of use’ and that it is difficult to operationalize usability as an objective of a product. 

Usability implies that the purpose of a product is to help the user achieve particular goals, therefore, 

to measure usability, we need to understand these goals through a UNA.

UNA is an exchange of information intended to find the common interests of the user and 

the researcher. Users bring their understanding of the Earth science problem to the discussion. We, 

as researchers, help the user understand our research capabilities. All too often, users may not 

understand and be able to articulate their own needs. So, in addition to explaining our research 

capabilities, we must assist the user in specifying the problem and understanding their priorities. If 

done well, this exchange between researcher and user leads to a clear identification of user’s needs 

that the researcher can address (fig. 4). 

16
Figure 4. The ideal research product originates from collaboration between researchers and users. 

Bevan (1995) sees two approaches to usability, bottom up, where usability is synonymous 

with ease of use and a broader, top down approach, where usability is “the ability to use a product 

for its intended purpose.” The broader approach captures the possibility that a research product can 

be “usable but not useful,” or useful but not usable, and seeks to capture user perceptions. This is 

subjective usability and it is where the user and usability interact. A correctly executed user-needs 

assessment captures these user perceptions and dictates the kind of usability required. 

The usability consultancy, Information and Design (ID) states the following in regard to the 

importance of conducting a user-needs assessment and addressing usability concerns: 

“Designers, who don’t understand their users, frequently develop products that are difficult to 

use and understand, do not meet real-world requirements, or provide irrelevant 

functionality...The world of users is messy. Once we start to ask questions like, ‘How does our 

user make decisions currently?’ or, ‘Why doesn’t our user consider x, y, or z?’ we enter a 

murky world with multiple answers that are not easy to obtain...Often, developers simply 

extrapolate from their own experience. Given the huge gap in technical expertise between 

developers and users, the resulting product is likely to be less than ideal. This is a pity, because 

getting good quality, useful information about users is not terribly difficult. (Developing) in the 

17
dark rarely allows developers to meet the needs of users of a given application. To do that, you 

have to get to know your users” (Gaffney, 2004). 

When we enter the realm of user-needs assessment, we begin addressing the relationship, 

not among different stakeholders, but between the customer and the actual product. The stakeholder 

analysis informs the user-needs assessment in that product development (user-needs) takes into 

consideration the specifics of the given decision problem and the people involved (stakeholder 

analysis). The user-needs assessment focuses on developing a hypothesis-driven research product 

that conforms to the priorities and objectives of the customer. Given the technological nature of our 

research products, we rely heavily on software development and Web-design fields for examples on 

how to conduct a user-needs assessment. 

Foremost, our needs assessment relies on the relationship we develop with our user. There 

is no canned way to develop user relationships. Communication skills, such as effective listening 

and asking the right questions are the most important ingredients of a successful user-researcher 

relationship. The section on how to ask questions, below, may be helpful for those that do not know 

how to start talking to your users or are uncomfortable with user interactions. 

You want to talk to users about their needs and objectives. In most cases this should be done 

in the proposal stage, as early as possible in the research process. Ideally, you will meet users in 

person, via site visits. The benefits of visiting the user onsite, including reduced costs down the 

line, more than compensates for this initial cost (Houser, 2005). You can often coordinate the UNA 

with the stakeholder analysis. 

The needs of different users (primary, secondary, and indirect) will differ. The stakeholder 

analysis will identify these different levels of users, and the needs of each group will be evaluated 

during the needs assessment. Users’ needs and political and economic climates, as well as who the 

stakeholders are might change during the life of the project and you will benefit from awareness of 

these changes and adapting the research product if necessary. 

Tools for User-needs Assessment 

UNA tools offer ways to think about the needs of the users and break down the components 

of the needs of the user. Remember that user-needs assessment is a qualitative, not quantitative 

exercise. Many of the tools below may also be applicable to conducting a stakeholder analysis. 

Figure 5 illustrates the interrelated steps necessary to understanding your clients. The broad 

stakeholder analysis comes first; this step identifies the key stakeholders and is described in the 

first part of this report. Then comes the user-needs assessment, embedded within the stakeholder 

analysis, consisting of (1) understanding your client’s context of use and (2) understanding their 

specific requirements of your research product. 

18
Figure 5. User-needs assessment (UNA) within the stakeholder assessment process. 

Wider stakeholder 

analysis 

Environment in which 

product will be used 

(part of UNA) 

Client requirements – product 

specific (part of UNA) 

These “tools” come in the form of ways to think about the needs of your users, breaking 

down the components of the tasks of the user, questions to ask about the needs of the user, and 

other issues. 

1. Interviewing and Questioning 

A. Context of Use. What is the world within which the user operates? 

The researcher must understand the environment within which the client will use the 

product to develop a research product that is useful to the client. This environment is the client’s 

“context of use.” If you can understand the different contexts presented in table 7, you are well on 

the way to understanding the user’s context of use. 

19
Table 7. User’s context of use. 

1. Primary (immediate) application areas of the research product: 

• user expectations 

• benefits of product to user 

2. Future potential application areas of research product 

3. Perceived/anticipated task breakdown, dependencies and output: 

• tasks of the user that pertain to the research product 

• data inputs needed by the user 

• outputs required by user 

4. Intended audience and/or secondary user that will use the research product: 

• capabilities of audience 

• extent of their knowledge pertaining to the research area 

5. Interests/priorities of the user that might conflict with the project 

(Adapted from MUSiC Breakdown of Context, in Bevan, 1995; Overseas Development Agency, 1995) 

Understanding the user’s context of use means communicating with them extensively; there 

are no shortcuts to reach this understanding. Remember, stakeholders and users are not simple 

objects of study. They will only be understood through your communication with them. 

A. Semistructured interview 

The semistructured interview is one of a variety of techniques you can use to understand 

your user’s perspective. Structured processes are efficient but require training to perform. 

Conversely, unstructured conversations without any predetermined questions or agenda can be 

interesting, but inefficient. Semistructured interviews fall in between, structuring conversations 

within a topic boundary, but without having detailed questions formulated ahead of time (Food and 

Agriculture Organization (FAO), 1990). 

The semistructured interview is a directed conversation covering more general 

topics/questions, moving to more specific issues as the interview progresses. Several questions may 

be predetermined to begin and lead the conversation. Relevant topics and issues are defined early 

on and more specific questions are based on these topics and issues. Questions become more 

specific as the conversation progresses, and these questions are created during the interview. The 

advantages of the semistructured interview are that it is less intrusive than a formal interview, 

encourages two-way conversation, and provides “not just answers, but the reasons for the answers” 

(FAO, 1990). 

You will probably have a great many questions to ask and the challenge will be to avoid 

overburdening the user at your first meeting. Instead, group and prioritize all your questions under 

topics. Pick specific topics for the first meeting. Remember, you will be having many more 

conversations with the user. 

The process for conducting semistructured interviews is as follows (adapted from FAO, 

1990; Houser, 2005): 

(1) Brainstorm potential topics and initial questions before interview. 

20
(2) Use broad, open-ended questions. Give the user time to respond and use your voice and 

body language to encourage them to talk. Remain flexible and follow the most promising 

trail. 

(3) During the interview, allow users to tell their story. Really listen to the user, record only 

brief notes, and elaborate on notes after the interview. 

(4) Remember, the first meeting(s) is not the time for you to remedy the situation. Do not offer 

advice or focus the interview on your research. This is a key point that researchers often 

forget! Instead, encourage users to think aloud and allow them to do most the talking. 

(5) Clarify—summarize what the user says to clarify your and their understanding. 

(6) Listen for nonverbal clues—subtle criticisms, suggestions, and innuendos. 

(7) Analyze results of interview and summarize your understanding. Separate facts and 

problems from your own opinions, ideas, or solutions. 

(8) Talk to interviewee to clarify if necessary. 

Pitfalls to avoid when using semistructured interviews are asking leading questions, getting 

too much information, straying off track, and, in the case of group interviews, having users 

interrupt or not speak up (FAO, 1990). Table 8 contains a list of open-ended questions that will 

help you get started in your interviews. 

21
Table 8. Open-ended questions. 

• How do you perform task x (that is, evaluate which areas to mitigate)? 

◊ Gets at task-subtask structure, can then ask about each subtask. This is very important 

in understanding what components the user may want in your model. 

• Why do you perform task x? 

• Under what conditions do you perform task x? 

• What do you do before you perform....? 

• What information do you need to...? 

• Whom do you need to communicate with ...? 

• What do you use to ...? 

• What happens after you ....? 

• What is the result or consequence of ....? 

• What is the result or consequence of NOT...? 

• Please show me how you currently do task x. 

• Why do it this way rather than some other way? 

◊ Attempts to get user to explain method so you can assess importance of the particular 

way of doing task. 

• What are the current problems with task x, currently? 

• What else should I have asked you? 

• Encourage DIGRESSIONS, ask for ELABORATIONS 

• Ask for examples 

◊ What is an example of the impact of x? 

• What are some typical problems you encounter? 

• If you could change one thing about how you currently do it, what would it be? 

Here are some more specific questions you might want to have answered: 

• What are the specific inputs to your decision making? 

 What inputs are critical? 

 What inputs are missing? 

• What are your current outputs? 

 What is missing? 

 What potential additional outputs would make your task easier? 

• What happens to the output? 

• What is this task dependent on? 

• What is the availability of information? 

(Adapted from Foley, 2005) 

C. Communicating the skills of your research team and research abilities 

When you have had your initial interaction(s) with users and better understand their needs 

and priorities, you will talk to them about how your research project and goals can address their 

needs. Here are a few basic points to remember: 

• This takes time! Plan for several conversations to clarify the needs of the user and to 

communicate your research abilities. 

22
• Do not tell the user how they can benefit from your research; instead ask them how they see 

your research fitting their needs. Your research project will automatically be sold when you 

listen to the user and use your project to address his needs. Once you have explained your 

project, ask the users to think of all the ways it might go right or wrong. 

• Ask them to list what is most important/salient to them in terms of issues the research 

product could address and have them prioritize this list (Boutelle, 2004). 

• Ask them to talk about the ways they have addressed their issues/challenges in the past and 

what worked or did not work. 

• Ask the user to talk about his ideal world in terms of the issues the project is going to 

address. You want to help the user really think about how his problem and your potential 

solutions can work together. 

Note: Just because a user says something in a certain way, it doesn’t mean it is that way. You may 

misunderstand what the user is saying; the user may be saying one thing, but meaning something 

else. Make sure you AND the user achieve a clear, common understanding. This may take time. 

As you and the user talk, not only are you clarifying your ideas, but the user is also 

clarifying his ideas. You should allow the user to formulate his ideas and requirements, knowing 

that where you end up might not be where you started. The user may not like your initial ideas, and 

you need to be prepared for this. Use this as a way to get at what the user really wants by asking, 

for example, “If you do not want to look at soil samples, what would you like to consider? Can you 

list the different indicators you do think are important?” Strive to understand the fit between the 

user’s concerns and your research ideas. 

“Issues provide opportunities if you can address them in your design, but they become pitfalls 

if you’re unaware of them, and fail to allow for their effects on users.” (Gaffney, 2004) 

2. Workshops, Focus Groups, and Surveys 

Conducting workshops or focus groups for potential users is a good way to gather 

information as to their needs, priorities, and objectives. For example, in a project involving ground 

water and hazards in southern California, a workshop was held early in the project to better 

understand how ground-water managers and communities in two ground-water basins were 

preparing for potential natural hazard events. The workshop elicited much information on a wide 

range of topics in a short amount of time from many people and was a valuable initial step to better 

understanding what stakeholders needed in terms of modeling the impacts of natural hazards on 

ground water. The workshop also served as an opportunity to identify potential long-term users of 

the research model. A second workshop is planned to present a prototype for further evaluation. 

Workshops take time to prepare. Skilled facilitators must be used and the workshop should 

be highly interactive. Plan on taking up to three to four months to plan your workshop. Logistical 

details include where to hold it, who to invite, workshop structure and agenda, food, transportation, 

invitations, and follow-up calls. Workshop content development is time-consuming, and it is 

important to involve the facilitator and all researchers on the project in designing and testing the 

workshop content. You should identify the major objective(s) of the workshop and plan workshop 

sessions around these objectives. Using a skilled facilitator is key to developing a strong 

workshop. 

Surveys are another way to find out the needs and priorities of a wide range of potential 

users. For more information and government guidelines on conducting surveys, see 

23
http://www.whitehouse.gov/omb/inforeg/pmc_survey_guidance_2006.pdf. Federal guidelines 

require that surveys be approved by the Office of Management and Budget. For planning purposes, 

plan for a 6-month survey approval process. This is in addition to survey development time, pretesting, and peer review. 

3. User Activity Matrix 

Users may not be involved in all stages of your research. Organizing their input in an 

activity matrix, based on the stages of the research process, will help identify when and how users 

will be involved (table 9). Depending on the project, users will be involved more in some stages 

than others. 

Table 9. User Activity Matrix. 

Planning Analysis Design Evaluation

Primary User Involve user in 

planning process, 

visit user on-site 

Consult with user on 

monthly basis, 

depending on data 

needs 

Present user with 

prototype for input 

after initial modeling 

phase 

User formally or 

informally evaluates 

research product for 

future use, gives 

input for 

modifications 

Secondary User Not involved Not involved After input from 

primary user, 

prototype is 

introduced to 

secondary users for 

input 

May or may not be 

consulted to evaluate 

final product 

For example, some researchers involve users in the modeling process on a regular basis. 

The users are part of the modeling team and have input, along with the researchers, on how the 

model is developed. In other projects, users participate in weekly conference calls to provide input. 

In some projects, users may be involved in initial project development, but not in any of the 

analysis or design. Consult with your users early in the project to define the level of involvement 

that is appropriate to both you and the user. 

4. Prototyping 

A prototype is a sufficiently complete representation of the research product (and the 

process into which the product will fit) that can serve as the basis for discussion with a user. It 

identifies the inputs (available data, control parameters, and others), the outputs (maps, graphs, 

reports, data types—numeric, categorical, textual—and the precision and accuracy of the results), 

and the processes that transform the data. 

A prototype is like an outline of the research. It need not be fully functional; some of the 

steps might be simulated or “canned.” In fact, the prototype could be developed and presented 

entirely on paper, like a storyboard. The idea behind building a prototype is to help both you and 

the user visualize the research product and the user’s process. 

24
Prototypes fall into several categories. Horizontal prototypes broadly cover the process 

steps, but without details on individual steps. Vertical prototypes focus on specific process steps, 

capturing the details of those steps. Revolutionary prototypes are rough representations intended to 

be discarded, whereas evolutionary prototypes are more complete representations intended to be 

developed into the final product. Any prototype may be a combination of these types. For example, 

the prototype might be primarily horizontal, with some vertical elements. This might occur when 

the research project will focus primarily on one process step, such as understanding the impact of 

an environmental policy. The horizontal process steps will provide the context within which the 

research will take place, showing how the research results will connect to the rest of the user’s 

process. The vertical portion of the prototype will give details on how the impacts will be 

determined. You may select any combination of these approaches to fit your research situation. 

Treat prototyping as a trial-and-error process. Early prototypes may miss the target, so don’t 

invest too much effort in details. However, each successive prototype should be closer to the target. 

This suggests that your early prototypes should be revolutionary—throwaway—rather than 

evolutionary, and more likely to be horizontal than vertical. The prototypes will be developed more 

fully as the research progresses, until you have a fairly complete picture of the steps in the process, 

and how your research will fit into that process. Use the prototyping process to help solidify your 

thinking, and as a way to communicate your thinking to your user. 

5. Prioritizing Your Users—Streamlining Your Product 

You may have identified several potential users with various needs who can benefit from 

your research product. Unless you have unlimited funding and time, you should target your 

product to specific user groups and applications. You will, generally, want to develop research 

products that are adaptable to different situations, transparent, and can accept additional capabilities 

easily. Rating potential applications of your product according to several criteria can help you 

prioritize your user applications (table 10). Rating or ranking potential applications of your research 

product can help you clarify and anticipate the direction of your research development. 

Table 10. Rating potential applications on a scale of 1 to 5, with 5 being most difficult. 

Potential Application of 

product 

Development 

ease 

Multiple 

conflicting 

uses 

Adaptions to 

current 

design 

Data needs/ 

availability 

Future 

funding 

Potential 

Evaluate hazards for 

individual neighborhoods 

5 5 5 5 5 

Evaluate hazards at 

community level 

4 4 5 4 5 

Evaluate hazards at 

regional level 

2 2 3 4 3 

25
Section 5. Conclusion 

Scenario Revisited 

If we replay our original scenario, incorporating some of the techniques from stakeholder 

analysis, it might look something like this: 

Eric is developing a research product that will help Jane make decisions about conserving 

areas of land adjacent to a National Park. They are having a conversation early in the process to 

scope out project requirements. 

Eric: In your day-to-day work, what are your main concerns about the areas you are 

dealing with? 

Jane: I am concerned about the effect of pollution on the river, as well as the effects of 

tourism and development. 

Eric: So your main concerns center around the effects of pollution and development and 

recreation on the river? 

Jane: No. I am talking about three separate issues. I mean that I want to focus on certain 

species and how they are affected by pollution. That really doesn’t have to do with 

recreation. 

Eric: Really, how come? 

Jane: Well, recreation is an issue, but a secondary issue, the impact is not as bad as for 

development and pollution. 

Eric: Can you talk some more about the species that are impacted by pollution? 

Jane: Well... 

Later... 

Eric: You know, earlier you talked about development. Could you expand on that, what in 

particular interests you about this issue? 

Jane: I am talking about fragile riparian areas and how development impacts them. 

Eric: [probing further] What aspects of development concern you most? 

And so on it goes. 

Communicate Your Strengths, Understand Their Needs 

Each project should (1) complete a stakeholder analysis in the early stages of project 

development, (2) ensure that researchers communicate with users throughout the process, and (3) a 

complete a user-needs assessment in conjunction with the stakeholder analysis. This report is an 

initial effort to describe how these tasks can be accomplished. 

The two main messages of this report are (1) we are challenged as researchers to understand 

the needs of our clients, and (2) we may be even more challenged to effectively communicate to 

customers and stakeholders our research products and how they can fulfill their needs. This is an 

26
integral part of the relationship—asking the right questions of our customers but also telling them 

about our strengths. 

Often the customer may not understand what they need, and often the customer does not 

understand what we can do. Entire conversations can take place between the researcher and 

customer where they think they are talking about the same thing, but are discussing two different 

things entirely. They may share the same vocabulary but give different meanings to the same 

words. Think about the words “risk” and “vulnerability”—chances are they do not mean the same 

thing to the scientist and the user. 

Both the scientist and customer may be seeing the issue from only their individual 

perspectives. The customer may not understand the science behind their problem adequately, and 

the researcher may not understand the preferences of the customer. Also, the customer may have 

difficulty in communicating to the researcher what they need—they may not have the language and 

the knowledge base. Often it seems like scientists and laypeople speak two different languages, and 

the key is to get them on the same page so they can understand each other. Part of our challenge is 

in applying our research products to help stakeholders understand why and how our research can 

help them. The tools described in this report and the sources listed in the appendix can facilitate this 

communicative process. 

In the end, this is about communication, not tools or methods. Subscribe to the following: 

• Put aside your “researcher” side and talk to your stakeholders as people (not as 

experimental objects). 

• Make the effort to understand their point of view. 

• Use language common to your stakeholders and customers. 

• Listen, listen, listen. 

• Clarify, clarify, clarify. 

• Don’t assume—check out your assumptions! And then check again. 

• Communicate your strengths and know that it takes time. 

Good luck and have fun!!! 

27
References 

Allen, W., and Kilvington, M., 2001, Stakeholder analysis: 

[http://www.landcareresearch.co.nz/research/social/stakeholder.asp. (accessed November 

2005)] 

Alva, M. E., Martinez Prieto, A.B., Cueva Lovelle, J.M., Sagastegui, T.H., and Lopez, B., 2003, 

Comparison of methods and existing tools for the measurement of usability in the web: In 

Web Engineering, v. 2722/2003: Heidelberg, Springer Berlin, p. 386-389. 

Bevan, N., 1995, Measuring usability as quality of use: Software Quality Journal, v.4, p. 115-150. 

Boutelle, J.,2004, Understanding organizational stakeholders for design success. 

[http://www.boxesandarrows.com/archives/understanding_organizational_stakeholders_for

_design_success.php. (accessed November 2005)]. 

Enterprise Development Impact Assessment Information Service (EDIAS), 2001, Toolbox: 

Stakeholder Analysis. [http://www.enterpriseimpact.org.uk/informationresources/toolbox/stakeholderanalysis.shtml. (accessed 

September 2005)] 

Food and Agricultural Organization (FAO), 1990, The community's toolbox: the idea, methods, 

and tools for participatory assessment, monitoring and evaluation in community forestry. 

Community Forestry Field Manual 2. Rome, Food and Agriculture Organization of the 

United Nations. 

Foley, J., 2005, Requirements gathering - know the user, Web lecture, Georgia Institute of 

Technology: Human Centered Computing. 

Gaffney, G.,2004, Contextual enquiry - a primer. [http://www.sitepoint.com/article/contextualenquiry-primer. (accessed November 2005)]. 

Gavin, T., and Pinder, C., 2001, Impact assessment and stakeholder analysis. 

[http://www.enterpriseimpact.org.uk/informationresources/toolbox/stakeholderanalysis.shtml. (accessed December 

2005)] 

Groot, A. M., 2001, Stakeholder matrices: guidelines. [http://www.icraedu.org/objects/anglolearn/ACFegJqyr.pdf. (accessed October 2005)] 

Houser, R., 2005, Asking the right questions during a site visit interview: Society for Technical 

Communication International Conference. Seattle, WA. 

Justice, T., and Jamieson, D.W., 1999, The facilitator's fieldbook: New York, AMACOM. 

McMahon, G., Benjamin, S.P., Clarke, K., Findley, J.E., Fisher, R.N., Graf, W.L., Gundersen, L.C., 

Jones. J.W., Loveland, T.R., Roth K.S., Usery, E.L., and Wood, N.J., 2005, Geography for a 

changing world: A science strategy for the geographic research of the U.S. Geological 

Survey, 2005-2015: U.S. Geological Survey, Circular 1281. 

Nuseibeh, B., and Easterbrook, S., 2000, Requirements engineering: a roadmap: In A.C.W. 

Finkelstein (ed), Future of Software Engineering: New York, ICSE, p.147-160. 

Overseas Development Administration (ODA), 1994, Guidance note on how to do stakeholder 

analysis of AID projects and programmes. [http://www.euforic.org/gb/stake1.htm. (accessed 

November 2005)] 

U.S. Department of the Interior, 2003, U.S. Department of the Interior: Strategic Plan FY 2003-

2008: U.S. Department of the Interior. 

U.S. Geological Survey, 2000, Strategic Plan, 2000-2005: U.S. Geological Survey. 

28
Appendix A. Additional Resources 

Some Great Web Sites and Books on Stakeholder Analysis 

and User-Needs Assessment 

Stakeholder Analysis Resources 

Often, development organizations’ Web Sites have a lot of information on how to conduct 

projects with similar issues to Geography’s and can be a valuable resource. 

• New Zealand’s, Manaaki Whenua Landcare Research is involved in sustainable 

development and has a brief overview on the stakeholder process with definitions, reasons for 

conducting a stakeholder analysis, and how to conduct one (http://www.landcareresearch.co.nz/ 

research/social/stakeholder.asp). 

• International Centre for development oriented Research in Agriculture—ICRA has a 

development approach they call Agricultural Research for Development (ARD). ICRA founded 

in 1981 by European members of the Consultative Group on International Agricultural 

Research (CGIAR), a consortium of donor agencies. ICRA has a very well thought-out 

‘learning resource’ on stakeholder analysis (http://www.icraedu.org/page.cfm?pageid=anglolearnstakeholders). For the complete ARD procedure, see 

http://www.icra-edu.org/objects/anglo/ARD-complete1.pdf. (This document also provides 

invaluable information on organizing your research team and project plan.) 

For: 

o Key stakeholder concepts: http://www.icra-edu.org/objects/anglolearn/StakeholdersKey_Concepts.pdf

o Stakeholder approaches: http://www.icra-edu.org/objects/anglolearn/StakeholdersApproaches1.pdf

o Stakeholder matrices: http://www.icraedu.org/objects/anglolearn/ACFegJqyr.pdf

o Information on topics from interviews and surveys to cost benefit analysis to systems 

thinking to visualization see http://www.icra-edu.org/page.cfm?pageid=anglores

• United Kingdom Department of International Development’s Overseas Development 

Administration (ODA)—for guidance on how to do stakeholder analysis from the 

(http://www.euforic.org/gb/stake1.htm) 

• MSP Resource Portal: Building Your Capacity to Facilitate Multi-Stakeholder Processes and 

Social Learning (http://www.iac.wur.nl/msp/). The MSP Resource Portal has practical 

information on how to facilitate participatory learning processes with various stakeholders. It 

provides theoretical foundations, methods and tools to create learning processes, facilitation 

tips, examples, literature and links. For the section on stakeholder analysis and interviews, 

focus groups, brainstorming see http://www.iac.wur.nl/msp/index.php?Stakeholder_analysis.

29
• Australian Government’s Overseas Aid Program—a very nice website on project 

management that contains a section on stakeholder analysis 

(http://www.ausaid.gov.au/ausguide/). 

• Enterprise Development Impact Assessment Information Service—EDIAIS was established 

in 2001. The focus may be on rural development, but the resources on this site are highly 

applicable to our research process. There is extensive information on the following: 

o Stakeholder analysis: http://www.enterpriseimpact.org.uk/informationresources/toolbox/stakeholderanalysis.shtml

o Impact assessment: http://www.enterprise-impact.org.uk/overview/index.shtml

o Project management, quantitative and qualitative methods in analysis, and 

information collection (see the toolbox resource section at http://www.enterpriseimpact.org.uk/informationresources/toolbox.shtml). 

• World Bank Group—Social Analysis Sourcebook has relatively short notes on strategic 

approaches to stakeholder analysis and social assessments in projects. 

(http://www.worldbank.org/socialanalysissourcebook/5elements3.htm). 

• Food and Agriculture Organization—FAO’s web site is a good place to get information 

about all the different tools you can use in stakeholder analysis and user needs. 

(http://www.fao.org/docrep/x5307e/x5307e00.HTM) 

User-needs Resources 

• Boxes and Arrows is a peer-written journal about usability. For information on user-needs and 

stakeholder analysis, and why we need both see 

http://www.boxesandarrows.com/archives/understanding_organizational_stakeholders_for_desi

gn_success.php. For case studies on usability see 

http://www.boxesandarrows.com/story/index/date/1. There are case studies from 

egreetings, Yahoo!, MSWeb, PeopleSoft, Razorfish, Blogger, and others. Some studies are 

more applicable to Geography’s research process than others, but there are fascinating studies 

about others’ experiences in usability. 

• University of Maryland’s Usability Testing site—Although, primarily for software 

engineering and web design the web site has good links to other usability sites 

(http://www.otal.umd.edu/guse/testing.html) 

• For a great case study on usability involving LOTUS for windows see 

(http://sigchi.org/sigchi/chi96/proceedings/desbrief/Ashlund/sla1txt.htm)

• Georgia Tech’s Human Centered Computing Education website has terrific sources on 

user-needs: http://hcc.cc.gatech.edu/index.php.

• Institute of Museum and Library Services completed a UNA titled—Assessment of EndUser-needs in IMLS-Funded Digitization Projects. This document contains great information 

on a UNA and the findings are very relevant to our research (pgs. 2-6 contain a good summary) 

(http://www.imls.gov/pdf/userneedsassessment.pdf). 

• University of California, Berkeley’s Electronic Environmental Library Project is a user-needs 

assessment and evaluation that reports the preliminary results. There is a nice bibliography at 

the end of the report. (http://csdl.tamu.edu/DL95/papers/vanhouse/vanhouse.html). 

30
• USOR, A collection of User Oriented Methods: This site has a great collection of user 

methods – constructive interaction to thinking aloud. It also has methods grouped by activities, 

user involvement, and goals. (http://www.nada.kth.se/cid/usor/) 

• Nielsen, Jakob, 1993, Usability Engineering: Boston, AP Professional, Boston, MA. 

• Beyer, H. and Holtzblatt, K, 1998, Contextual Design: Defining Customer-Centered Systems: 

San Francisco, Morgan Kaufmann. Written for software developers, this book contains 

information on how to relate effectively to your stakeholders, customers. See Chapter 3: 

Principles of Contextual Inquiry – especially the information on the Master-Apprentice Model 

and Partnership. 

Project Management Resources 

• GIO Project Management Office has a project management methodology that is very good. 

Their website is http://internal.usgs.gov/gio/pmo.html, and the link to their guide is 

http://internal.usgs.gov/gio/pmo/pmmgiofinal.pdf

• Project Management Institute, 2004, A Guide to the Project Management Body of Knowledge: 

Newtown Square, Pennsylvania, Project Management Institute. Comprehensive guide on 

project management (basis for GIO PM methodology). See Chapter 3 for the PM processes, 

Chapter 5 for project scope issues and breaking down the project into executable parts. 

• Berkun, Scott, 2005, The Art of Project Management: Sebastopol, California, O’Reilly Media. 

Topics include: where ideas come from, Hitting moving targets. A fun book that confronts 

project management pitfalls head on. Berkun comes from a software development background 

and a lot of the information in this book is applicable to the research process we go through in 

the Geography Discipline. 

31