Modeling Project Stakeholder Influence Using Social Network Analysis

Influence is the power to persuade based on factors such as prestige, wealth, ability or position.  The political behavior of project stakeholders is the process by which individuals or groups acquire and maintain power in order to influence project outcomes according to their interests.  Unfortunately, not all project stakeholders share the same goal for a project.  They may not have the same level of interest in a project or the same ability to influence a project’s outcome.  Project managers need to understand and manage stakeholder influence in order to achieve project goals and objectives.  This means they must engage in the politics of projects.

In this series of articles, we will explore the use of social network analysis (SNA) as a means for project managers to visualize project stakeholder relationships and to assess influence in stakeholder networks. We will start by showing how project stakeholder networks can be represented by graphs.  Second, we will explore how network topology affects the concept of centrality and community in networks.  Third, we will look at how opinions diffuse through stakeholder networks.  Finally, we will discuss influence paths.

For a traditional approach to project politics, see Block (1983) or Pinto (1998).  For a discussion of organizational influence, see DeLuca (1992).  The April/May 2018 issue of the Project Management Journal (PMI, 2018) was dedicated to the use of social network analysis in stakeholder management.  In particular, see Pryke, et. al. (2018).


An anecdotal case study

For the purpose of explaining SNA, a simple anecdotal case study will be used.

Omega, a large service company with 3,000 employees in Orlando, was acquired by a smaller company Iota, with 500 employees in Indianapolis.  To consolidate IT infrastructure, the Network VP of the merged company contracted with the vendor Delta, which serves many Fortune 100 companies from its headquarters in Denver, to provide imaged desktops for the merged organization.  The project has been plagued with the delivery of desktops with incorrect images, to the extent that liquidated damages may be invoked per the contract.  The Network VP has hired a consulting project manager to turn the project around.

The organizational structure of the project is shown in Figure 1.  The formal reporting relationships define the level of organizational power that stakeholders have.  There are several key observations to be drawn from the partial organization chart.  First, the project staff are geographically dispersed across three different locations.  Second, prior reporting relationships at Iota were disrupted as part of the merger, as IT staff was consolidated under the IT Director in Orlando.  The Iota IT Director was retained as an IT Strategist reporting to the Network VP.   And third, the organization chart only shows formal reporting relationships relative to the project.  The procurement officer who wrote the contract reports to an administrative VP outside of the Network VP’s purview.  The vendor staff are external to the merged organization.  The project manager (PM) is a consultant hired by the Network VP.


Figure 1 Partial Org Chart

Figure 1.  Partial organization chart for desktop outsourcing project


Networks are not static.  They change over time.  For this series of articles, three network states will be explored.  The first is the network state prior to the addition of the consulting project manager.  The second is the network state after the PM is introduced.  And, the third is the network state after the PM and vendor Account Manager collaborate to strengthen ties between the three groups of IT staff.  At each stage, stakeholder power and influence will be assessed, along with how that influence changes between the three states.

To start, we will consider only the third state.  The other states will be addressed in future articles.


Visualizing stakeholder networks as graphs

Social networks are represented as graphs comprised of a set of vertices and edges.  The vertices represent individuals or groups within the network.  The edges represent the relationships between the vertices.

Table 1 lists the vertices of the network representing the individuals and groups participating in the desktop outsourcing project defined above.  There are ten vertices and each has a label.  Node attributes will be discussed the next section.


Table 1 Vertices

Table 1.  Vertices in the desktop outsourcing project network.  Organization level (10=high, 1=low).  Opinion (applied influence for=10, against =1).


Table 2 lists the edges in the network.  There are three types of relationships.  The base relationship is a communication channel required for project execution.  Note that these can cross the organization’s functional boundaries.  There are strict hierarchical reporting relationships, as shown in the partial organization chart (Figure 1).    A formal reporting relationship implies there is a communication channel.  And, there may be strong personal relationships between the participants.  Personal relationships may or may not involve a reporting relationship, but personal relationships do imply a communication channel.

Four personal relationships are included in the case study.  The IT Strategist is the protégé of the Executive VP.  They have worked together for over ten years.  The IT Strategist, as the former IT Director for Iota, has close ties to the former Iota IT staff in Indianapolis.  The Network VP worked with the consulting PM at another company.  He observed and trusts the project manager’s ability to turn troubled projects around.  The PM has forged a good working relationship with the vendor Account Manager.

For this article, the edges are assumed to be undirected and unweighted.  In later articles discussing influence, directed edges will be introduced.  The degree of influence will be encoded as edge weights.


Table 2 Edges

Table 2.  Edges (relationships) in desktop outsourcing project


Model parameters

Aside from representing the stakeholders as network vertices and the relationships amongst the stakeholders as network edges, we can augment the model by adding attributes to vertices and weights to edges in the graph.  There are three vertex attributes we will consider in this simple case.

The first is obvious:  Location.  The project staff is geographically dispersed across three sites, one of which is the vendor’s.  Table 2 includes Organizational Level.  It should be clear that individuals at the top of the organizational chart have more power than those at a lower level, relative to their position in the organization.  This is muddled in that a contract project manager and vendor staff are included in the scale.  Their perceived level of power is subjective compared to the strict hierarchy of the organizational chart.  In this case study, we are assuming that the PM has less power or authority than the IT Director, Procurement Agent, and VP Network; but, more authority and power than the IT staff.  The placement of the vendor Account Manager is more problematic.  Because of her close tie to the PM, along with her ties to the Procurement Agent and IT Director, it is assumed she has more power to influence the outcome of the project than the IT staff.

The third node attribute is the Opinion of the project.  This represents the stakeholder’s applied influence for or against the project.  As a project manager, it is naïve to think that all stakeholders are 100 percent behind your project.  There may be some that are 100 percent against it.  In the list of vertex attributes (Table 1), we see that the Network VP, PM, Procurement Agent and vendor Account Manager are totally for the project succeeding.  The Network VP is the project sponsor or champion.  It is his idea and he is accountable if the project fails.  The procurement officer wrote the contract and the vendor Account Manager obviously wants to see the project succeed.  The PM is assumed to have a strong positive interest in a successful outcome.  His reputation and future business depend upon it.

However, in this case study, the IT Strategist, and the IT staff that used to work for her in Indianapolis, are not supportive of the project.  It was not their idea and, perhaps, they are disenfranchised after the merger of the company.  The IT Director is a year or two from retirement.  He does not want to rock the boat by getting between the IT Strategist and the VP Network.  The Executive VP is concerned with growing the merged company through acquisitions.  The desktop outsourcing project is not high on his radar.

As mentioned above, the network edges are unweighted and undirected.  In subsequent articles, when we consider degree of influence, we will apply weights to directed network edges to show the degree of influence.

Graphic representation of the stakeholder network

Figure 2 shows the graphic representation of the stakeholder network.  The graph conveys much more information than the partial organization chart in Figure 1.  It shows more than just the organizational titles and hierarchical reporting relationships.  It exposes stakeholder opinions and the relationships that amongst the stakeholders has been expanded to include communication channels and personal connections.

Figure 2 Initial Graph

Figure 2.  Stakeholder network.  Node size=organizational level; node color=opinion; edge (dotted=communication channel; solid=reporting; thick green, dashed=personal; thick green, solid=personal and reporting); background color=geographic location.


The graph was created using the R programming language and the igraph library (see Ognyanova, 2016).



At this point, there are three important caveats to consider.  While it is unproblematic to present reporting and communication relationships, displaying opinion and interpersonal relationship information in a way that is not anonymous could be very problematic, due to the highly subjective nature of such data.  While this information might be useful to a project manager, if the information is incorrect or openly disputed, it could be damaging to the project, the project manager and the individuals who are misrepresented.

A second caveat relates to the ease with which objective data can be obtained.  While monitoring information flow or assessing reporting relationships is straight-forward, objectively and anonymously gathering data about opinions and relationships is not easy.

And, a third caveat concerns how the information in the graph might be used.  If a project manager uses social network analysis to target individuals in order to change their opinions or remove their influence, with or without their consent, it could be considered unwanted interference or persuasion.  No one wants to feel compelled, obligated or manipulated.  There are ethical considerations.



We have introduced an anecdotal case study for the purpose of explaining how social network analysis tools can be used to manage project stakeholders.  Representing the stakeholder network as a graph is the first step. In the next article, we will explore how the network topology affects centrality and community in such a network.



Block, R.  The Politics of Projects.  (1983).  Yourdan Press.

DeLuca, Joel M. Political Savvy.  (1992).  Horsham, PA: LRP Publications.

Ognyanova, K.  (2016).  Network Analysis and Visualization with R and igraph:  NetSci X Tutorial.  (; retrieved 6 June 2018)

Pinto, J. K.  (1998).  Power and Politics in Project Management.  Newton Square, PA:  Project Management Institute.

Project Management Journal.  (2018).  April/May, 49(2).  Newton Square, PA:  Project Management Institute.

Pryke, S., Badi, S., Almadhoob, H., Soundararaj, B., & Addyman, S. (2018). Self-Organizing Networks in Complex Infrastructure Projects. Project Management Journal, 49(2), 18–41.


© Nicklas, Inc. and, 2018.  All rights reserved.  Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited.