Project Sociology: Identifying and Involving the Stakeholders

by Suzanne Robertson

September 2002

Project Sociology

The major factor that affects the success of a project is having the right people involved in the right subjects at the right time. We recognise the need to identify the project’s stakeholders and to find ways of appropriately involving them throughout the life of the project. The stakeholders are all the people who have some kind of interest in the project. This might be because they have an active role in building or using it or it might be because their knowledge is necessary to make it fit into the world. The first step towards discovering all the requirements is to understand who all the stakeholders are, what roles they are expected to play, how much involvement they need to have and how committed they are to the project.

In short we need to understand the project’s sociology.

Traditionally our concerns about the stakeholders have focused on the developers of the product and the users of the product. Several of the participants in our workshops and projects have suggested that, instead of talking about users and developers, we need to look more widely at the people whose knowledge contributes to the project’s success. Figure 1 develops this idea by identifying a number of different types of stakeholders whose participation is potentially necessary for a project’s success.

The stakeholders in the inner circle (Producers) are the people who are assigned to work on the project and deliver some product or mixture of products that satisfy the requirements. The stakeholders in the outer circle are not assigned to work full-time on the project. They have knowledge that is needed by the producers, however they do not necessarily view the success of the project as their primary concern. Each of these different types of stakeholders can provide the producers with feedback about their own particular knowledge and concerns. However, in order to stimulate that feedback the producers need to provide a feedback mechanism that is appropriate for the particular stakeholder. And this means understanding the individual stakeholders and understanding what knowledge the project needs from them, when do they need to be involved, how they relate to each other and how their involvement will affect the success of the project.

This paper discusses how to do a project sociology analysis by understanding and considering how to communicate with the different types of stakeholders.

Figure 1: Different types of stakeholders make different contributions to the project.

Producers

Producers are the people who decide the details of precisely what the product will be and then work together to build it so that it satisfies the requirements within the constraints and is both technically and organisationally correct. In short, producers are actively involved in building a product that fits into the world. The producers are often referred to as the project team. These are typically people like, project manager, developer, business analyst, key business people, marketing specialist, research and development specialist, designer, tester, programmer. Some of the producers will have business/subject matter/domain knowledge and some of them will have technological knowledge. A producer who has participated in similar projects will have a mixture of both types of knowledge. The nature of the product that we are intending to build is a guide to who should be in the team of producers.

Any product is some combination of hardware and/or software and/or procedures running on one or more devices/environments, installed in one or more geographical locations and affecting a variety of people. The products that we build are growing more and more diverse. Software for a payroll system; a new web interface for a library; a vacuum cleaner containing mechanical, electrical and software components; a geographical positioning system for a car; a satellite guidance system; a portable personal organiser with an email interface; an automatic milking system for dairy farms; a new computer operating system, a building that controls its own temperature and lighting…….the list is endless.

The common factor is that the products that we build are involving more and more different types of subject matter knowledge. And every different type of subject matter knowledge indicates the need for some kind of stakeholder involvement. A mistake that we often see is for the producers to be limited to the people who play a technical role in building the product. But, in order to build a relevant product, the business subject matter experts also needs to play the role of producer. Without participation of business subject matter experts the product is likely to be a good technical solution that does not satisfy the needs of the real world. Each of the producers (both business and technical) should be committed to spending an agreed amount of effort on the project; ideally their involvement (or part of it) should be financed by the project budget. Producers should be people who form a gelled team [DeMarco & Lister ‘00] who are collaborating [Highsmith ‘99] to produce a shared product. They should be in close contact with each other, ideally they should be located in the same workspace.

Consumers

Consumers are the people who make a decision to buy the product and/or use the product to do work. Buyers are an important consumer role that each project needs to identify and understand. People who play the role of buyers are those who decide whether or not to buy the product. They might be individuals who decide to buy a new piece of software or a new hi-fi system. They might be people in an organisation who decide to commit part of their department’s budget to buying a new piece of communications software or a new personal organiser for their staff. But money does not necessarily change hands; instead a buyer of the product might be someone who influences whether or not a product will be used by its intended users.

For example suppose you are building a product to help children learn mathematics, even though the childrens’ teachers are not making the decision about whether or not to buy the product (the school boards have already decided that). The teachers are buyers in the sense that they will decide whether to include the product as something that will be used by the pupils in their classes. If the teachers “buy into” the product then it is likely to be more successful in its subject matter market. So, part of understanding your project’s sociology is to identify the people who will affect the success of buying/introducing your product into its intended place in the world and then to discover the factors that the buyers consider most important. An understanding of buyers helps us to discover relevant requirements and to prioritise the requirements when we need to choose between which ones should have priority.

Another important consumer role is that of the people who will have direct contact with your product, the people who will actually use your product to achieve some specific task. These people are normally referred to as Users of the product. Someone who uses a bank machine, an air traffic controller looking at a radar screen, a nurse monitoring heartbeat on a screen and the patient to whom the device is attached, a bank clerk using an on-line interface to make an inter bank transfer, a householder entering his code in a home alarm system, a software designer using a tool that records and evaluates a design. All of these are users of particular products. People playing the role of user will rarely have a wide view of the product. Instead, all of these people have requirements that relate to the way that the product specifically affects them. Some users will tell you about specific requirements; others will not have any idea what their requirements are. In order to be able to discover the users’ requirements we need to have some understanding of the factors that influence those users’ requirements. The sorts of factors we are talking about are things like:

• Subject matter experience
• Technological experience
• Intellectual abilities
• Awareness of the project purpose
• Attitude to job
• Attitude to technology
• Education
• Linguistic skills
• Age – older people have different life experiences to young people, and may not adapt as quickly to completely new concepts. 
• Gender – men and women may have different perceptions
• People with disabilities / blind / deaf / Non-readers
• People who do not speak the home language
• First-time vs. experienced users
• People carrying large parcels or a baby
• People who might be angry, frustrated, or in a hurry

We record our knowledge about the users in drawer 3 of the template. We have separated the users from the other stakeholders for convenience, because information about users will often be used by the producers to decide on the very detailed aspect of the product. For instance, it is impossible to discover appropriate usability requirements without knowledge of the users. Similarly performance requirements require an understanding of why particular people require a particular response time. Knowledge of the users helps us to build a product that fits into those users’ real world.

Sponsors

The sponsors of the project are the people who have the organisational commitment to doing the project. The role of sponsor should be held by someone who has enough influence to make management decisions that affect the organisation. The sponsor must agree to help the project with any problems or decisions that are outside the power of the project manager.

Suppose that a project is having trouble because key stakeholders are not able to devote enough time for their necessary involvement. It is up to the project manager to quantify the problem, then it is the sponsor’s responsibility to decide what should be done about it. We had a project where the producers were scattered around the organisation because there was insufficient office space. The project manager went to the sponsor and explained the huge impact of producers not being able to easily talk to each other, he asked the sponsor for some walls around the team. The sponsor understood the problem and agreed that it had a serious effect on the team’s ability to meet the deadline. The sponsor talked to other managers, found a nissen hut in the organisation’s grounds and fought the necessary battles to have it allocated to the producers. It was pretty basic accommodation but it did the trick. The team was together, they could talk to each other, they could get their work done. This would not have happened without the sponsor’s political power.

The other side of the coin is that the sponsor’s decisions are not always popular with the other stakeholders. The sponsor needs to take the view of the entire organisation whilst the project team is naturally looking at situations from the point of view of their particular project. So the sponsor needs to be a good decision-maker and a good leader - someone whose decisions people have faith in.

A problem on many projects is that the sponsor is too far removed from an understanding of the project. Hence it is very difficult to have a meaningful communication. A solution to this is, at the start of the project, to agree on some components of the project that the sponsor will be able to understand and review. Project goals are a very good starting point. Suppose the sponsor can objectively verify that the project goals conform to the aims of the organisation. Then the producers can agree that they will use the project goals to help them make choices and keep the project on track. In a situation where they cannot come up with a decision that conforms to the project goals then it is an indication that they need to ask the sponsor for some help.

The ideal sponsor is someone who makes it possible for the project to flourish within the organisation and who makes sure that it remains relevant when there are changes within the organisation.

Subject Matter Consultants

Subject matter consultants are people or organisations who are not producers but whose knowledge is necessary or beneficial in order to discover the requirements. We worked on a project for the Polish railways where two of the subject matter consultants were British Rail and SNCF in France. Both of these organisations had experience with similar projects and they agreed to contribute some of their subject matter knowledge to help the Polish project.

You will often find that domain experts will play the role of subject matter consultants. These might, as in the case of the railways, be external organisations. If your organisation has done a number of projects concerned with the same subject matter then you will have some subject matter consultants within your own organisation. If other projects have built business data or business class models then you might be able to use those models as a source of subject matter knowledge.

Technical Consultants

Usually a project has need of technical knowledge additional to that known by the producers. The technical systems architect, the network specialist, an expert in the programming tools, a system software expert, a configuration management expert, a hardware supplier, a usability expert are all examples of technical specialists whose knowledge and skills are needed by the producers at some stage of the project. The greater the understanding of the requirements and constraints the more possible it is to identify the necessary technical consultants. Once we identify a need for a particular sort of technical expertise the project manager investigates when we will need that expertise and how much of it we will need.

Influencers

Who is there in the world, apart from the consumers, who might influence the success or failure of your project? To help us discover all the requirements we need to ask this big question at the beginning of the project. For instance, are there any people or organisations that have rules with which we need to comply? Consider:

• Other organisations within our domain who have some expectation of our product
• Auditors – does your product have to pass any audit checks?
• Lawyers / police – what about the legal aspects?
• Professional Bodies – do professional bodies have any influence on whether or not your product will be accepted?
• Public Opinion / special Interest Groups – what special groups are there whose opinion will affect the acceptance of your product?
• Government – how might the government affect your product?
• Cultural Interests – are there any special cultural influences on your product?
• Adjacent Systems – people or organisations who are adjacent to your study
• Operations / maintenance – people or organisations who expect our product to have particular operational characteristics
• Security / safety / emergency services – is your product expected to meet specific standards?
• Inspectors – are there any organisations who will have the right to approve/disapprove of your product?
• Competition – products in competition with yours influence the success of your product. Do competitive products have characteristics that buyers will expect from your product?

The best way to discover influencers early is to do a brainstorm and list all the different people and organisations that you think might influence your project. The list is usually long because it opens a Pandora’s box – it seems that the whole world might have an influence on your project. However, you will not investigate all of them, you are only doing this so that you can identify the most relevant influencers, the ones that you all agree should be considered to be stakeholders, bearing in mind the goals of your project.

Project Sociology Analysis

We have found that it is a good practice to do a project sociology analysis at the beginning of a project. We do a brainstorm to identify all the different stakeholder roles that we think are relevant to our project along with who we think will represent that role. This usually raises lots of questions about work context (what do we need to investigate) and product scope (what are the boundaries of the product we intend to build) that would not otherwise occur to us until later in the project. To help organise this, we have built a stakeholder analysis template that you can download and tailor to your own stakeholder roles [http://systemsguild.com]

Another reason for doing a project sociology analysis is to negotiate relevant stakeholder involvement. If we can explain to a stakeholder why the project needs his/her particular expertise in order to be successful, we have a much better chance that people will commit to being involved. Even better if we have enough understanding about the project to be able to talk about what sort of involvement, when and how much. People are tired of being tied up in long meetings when they really only need partial involvement. If you can manage the project so that you focus on relevant involvement then you have much more chance of continuing stakeholder involvement. This is all part of good stakeholder relationship management.