Monthly Archives: April 2013

Stakeholder analysis

Stakeholder management is critical to the success of every project. By definition larger projects and programmes will affect more and more people. The more people you affect, the more likely it is that your actions will impact people who have power and influence over your projects. These people could be strong supporters of your work – or they could block it. Stakeholder Management is an important discipline to help win support from others and Stakeholder Analysis is the technique used to identify the key people who have to be won over.

One of the key benefits of using a stakeholder-based approach is that you can use the opinions of the most powerful stakeholders to shape your projects at an early stage. Not only does this make it more likely that they will support you, their input can also improve the quality of your project Gaining support from powerful stakeholders can help you to win more resources – this makes it more likely that your projects will be successful By communicating with stakeholders early and frequently, you can ensure that they fully understand what you are doing and understand the benefits of your project – this means they can support you actively when necessary You can anticipate what people’s reaction to your project may be, and build into your plan the actions that will win people’s support.

The first step in Stakeholder Analysis is to identify who your stakeholders are. The next step is to work out their power, influence and interest, so you know who you should focus on. The final step is to develop a good understanding of the most important stakeholders so that you know how they are likely to respond, and so that you can work out how to win their support – you can record this analysis on a stakeholder map. The steps of Stakeholder Analysis are explained below:

Step 1 – Identify Your Stakeholders The first step in your Stakeholder Analysis is to brainstorm who your stakeholders are. As part of this, think of all the people who are affected by your work, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion. Often people include members of the project or programme team as stakeholders. I don’t generally – after all, you will probably have enough stakeholders to deal with, and I feel that the way you interact with team members is fundamentally different from the way you interact with stakeholders. However it is worth remembering that internal managers – the people your team report to in a matrix managed organisation – are often key stakeholders for you

Step 2 – Prioritize Your  Stakeholders You may now have a long list of people or organizations that are affected by your work. Some of these may have the power either to block or advance. Some may be interested in what you are doing, others may not care. Map out your stakeholders on a Power/Interest Grid as shown in figure 1, and classify them by their power over your work and by their interest in your work.

image
Figure 1

For example, the Senior Responsible Owner in MSP is likely to have high power and influence over the project and high interest. Peer managers may have high interest, but are unlikely to have power over it. Someone’s position on the grid shows you the actions you have to take with them: High power, interested people: these are the people you must fully engage and make the greatest efforts to satisfy. High power, less interested people: put enough work in with these people to keep them satisfied, but not so much that they become bored with your message. Low power, interested people: keep these people adequately informed, and talk to them to ensure that no major issues are arising. These people can often be very helpful with the detail of your project. Low power, less interested people: again, monitor these people, but do not bore them with excessive communication.

Step 3 – Understand Your Key Stakeholders You now need to know more about your key stakeholders. You need to know how they are likely to feel about and react to your project. You also need to know how best to engage them in your project and how best to communicate with them. Key questions that can help you understand your stakeholders are: What financial or emotional interest do they have in the outcome of your work? Is it positive or negative? What motivates them most of all? What information do they want from you? How do they want to receive information from you? What is the best way of communicating your message to them? What is their current opinion of your work? Is it based on good information? Who influences their opinions generally, and who influences their opinion of you? Do some of these influencers therefore become important stakeholders in their own right? If they are not likely to be positive, what will win them around to support your project? If you don’t think you will be able to win them around, how will you manage their opposition? Who else might be influenced by their opinions? Do these people become stakeholders in their own right? A very good way of answering these questions is to talk to your stakeholders directly – people are often quite open about their views, and asking people’s opinions is often the first step in building a successful relationship with them. You can summarize the understanding you have gained on the stakeholder map, so that you can easily see which stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters or your project. A good way of doing this is by color coding: showing advocates and supporters in green, blockers and critics in red, and others who are neutral in orange.

When you have identified the stakeholders and analysed their impact on the project or programme, you need to move on to decide what you do to manage them. This is covered in the next stage, stakeholder planning.

Roles in an agile programme

One of the common criticisms made of agile is the inability to scale to large systems and programmes. It seems worthwhile, therefore, to think about the differences in agile structure between a programme and a project.

Just as in waterfall many programme roles relate directly to those in a project. However the programme level is fundamentally about business outcomes rather than project outputs and therefore focusses on business change implementation and benefit realisation, functions not normally found in projects. At development level though, the responsibility is larger and coordination greater but the roles are basically the same. The Programme Manager, Product Owner and Technical Architect roles are like this, corresponding to Agile Project Manager, Product Owner and Technical Lead.

In addition a programme needs some roles that don’t appear at all in a project, notably Programme Director and Business Change Manager. Again these roles are a result of the increased scope and communication necessary in a programme and also because of the focus on organisational change.

Programme Organisation Chart

Lets look at a typical agile programme organisation.

agileorg

The people in the technical teams (product development, integration, infrastructure) have Agile project roles. The Agile programme roles are in the Programme Board (Agile Programme Manager, Programme Director, Programme Product Owner, Technical Architect) and Change Implementation workstream (Business Change Manager).

Programme Director

The Programme Director is a senior manager responsible for the overall success of the programme. He/she is the final point of responsibility at the programme level.

The Programme Director is the key manager in ensuring the programme remains aligned to corporate strategy.

Typically the Programme Director is the business sponsor for subordinate projects. They might also be the Programme Product Owner and could be the Product Owner for the Technical workstreams.

MSP actually expects a Senior Responsible Owner (SRO) at the head of a programme although it accepts that some organisations have a Programme Director instead.

Programme Product Owner

The Programme Product Owner is responsible for the entire product being delivered by the programme team. Normally the Programme Product Owner is a different role to the Programme Director but the two roles can be held by the same person. As the size of the programme grows the Programme Director will definitely have to delegate increasing amounts of product responsibility to other people. At some point the two roles split.

MSP doesn’t have the concept of a Programme Product Owner as many programmes are not about building something (although our interest is software development).

Agile Programme Manager

A Programme Manager is responsible for the programme from programme setup (including governance), through the delivery of the capabilities and benefit realisation, to programme closure. A Programme Manager has to do all the normal project tasks (Planning, Monitoring and Control, Change Management, Risk Management) but at the programme level.

In addition the Programme manager must shape the programme team including subordinate projects. They need to form the various teams, manage the interdependencies beween them and ensure the projects deliver as tasked.

Technical Architect

The senior technical person on the programme is usually a Technical Architect. They have overall responsibility for technical quality of the product including how it is structured, organised, and implemented.

Business Change Manager

The Business Change Manager (BCM) is an MSP role. It doesn’t appear in a project (Agile or not). That is because a programme is about business change and a project is about delivery of outputs.

The BCM’s role is to manage the organisation through transformation. The programme might create capability but it is up to the BCM to ensure the organisation adopts the products and whether the organisation achieves the desired benefits.

The nature of the role, including close stakeholder contact, means a BCM is usually from the business. The role can be full or part time, long term or short and are often local champions recruited to support roll out in their area.