Stakeholder analysis example

Software project stakeholder case study

This guide is continued from stakeholder analysis - power interest matrix.

To see how these powerful stakeholder analysis techniques work in practice let’s look at an example based on a CRM software implementation project. The software was procured from a 3rd party supplier, but to help illustrate the analysis method I haven’t included all of the project stakeholders and I have focussed on the stakeholders in the organisation that bought the software.

The following stakeholders were identified during stage 1 Stakeholder Definition and their interest areas added to a stakeholder interest map.

• CIO
• Change Manager
• Project Manager
• Developers
• Outsourced call-centre managers
• Finance
• Legal
• Networking & security
• Web standards
• Training Manager
• Legacy systems owners
• Outsourced call-centre staff
• Testers
• Customers

The CIO is sponsoring the project and identified the need for CRM software. The Change Manager is responsible for embedding the software, maintaining business as usual and delivering the return of investment (ROI). The Project Manager is responsible for managing the implementation from identification of the CRM supplier to ensuring a smooth cutover from the legacy software.

The software will be implemented in an outsourced call centre. It includes an online support site which will be integrated with the organisation's corporate website by the developers. The testing team will responsible for UAT and will be drawn from the business and the call-centre.

The completed power and interest matrix is shown below:

The influence lines are shown below. You will probably notice that they are specific to the organisation and personalities involved. Influence lines can clearly never be drawn between roles or ‘reused’ for other projects - there are so many different factors involved. Lines will not only change between projects, but also within projects as different phases in the lifecycle increase the interest and/or power of certain stakeholders. For example the legal department are particularly influential in the matrix below, but may become less so during the build phases on the project once questions around procurement and contracts have been answered. 

In this example there are a couple of stakeholders that are 'hubs' of influence. Those with power are not surprising, and probably would be managed appropriately in a basic analysis that doesn't consider influence. However, the lines of influence in this particular project show that the Outsourced call-centre managers have two connections to the Change Manager. One directly and one through the Training Manager. Even though they have little power their high interest level and influence means that they need to be carefully managed. Partly so that they don't negatively impact the project, but also because they could easily be turned into Key Players and therefore project champions.

The lines of influence can also identify stakeholders within a particular quadrant that need special attention. Legal fall within the high power/low interest square so at a base level the project simply needs to meet their needs. However, they influence finance who in turn influence the CIO this means that they have the ear of the most powerful Key Player and could stop or significantly delay the project. Legal don't have a political interest so the project manager needs to be proactive in identifying when Legal need to be involved and engaging with them.

The call centre agents are outsourced so they have little choice in the software procurement or configuration. Their power and interest is low, but they can influence their managers who can in turn influence the change manager who is a key player. Trouble from this influence chain is not likely to impact the project until the software is live, but it could seriously damage the perceptions of project success and ultimately lead to the software being replaced. 

This example shows how the influence lines add depth to the analysis which enable us to pick up subtle relationships and understand complexities that can be fed into project planning and risk management.

Resources

Further reading and Biblography