Many IT projects do not fail because of technology, but because of people: the business unit feels ignored, the works council is consulted too late, IT security vetoes the solution shortly before go-live. Good stakeholder management in IT projects ensures that such surprises do not happen in the first place. This article shows in five steps how to identify, assess and deliberately engage stakeholders – and which mistakes to avoid.
Stakeholders are all people and groups who can influence a project or are affected by its outcome. Stakeholder management is the systematic way of dealing with them: finding out who is affected, understanding what these groups expect and fear, and shaping collaboration so that the project gains support instead of resistance. The Project Management Institute's PMBOK Guide has treated the topic as a knowledge area of its own since its fifth edition – a sign of how strongly project success depends on the people involved.
It is important to distinguish it from mere communication. A status report sent by email is information. Stakeholder management goes further: it asks whose approval the project needs, whose knowledge it must use and whose concerns must be taken seriously before they become an obstacle.
The starting point is a list that is as complete as possible. It is best created within the project team and together with the sponsor, for example in a short workshop during project initiation. In IT projects, these groups typically appear:
A helpful control question is: who could stop, delay or significantly improve the project? Anyone who comes to mind belongs on the list.
Not every stakeholder needs the same attention. A proven tool is a stakeholder matrix that contrasts influence and interest. This results in four quadrants with different strategies:
It is also worth looking at attitude: who supports the project, who is neutral, who is sceptical – and why? Record this assessment together with expectations, concerns and contact persons in a stakeholder register. Because the attitude assessment is sensitive, the register should only be accessible to a small group within the project.
The analysis determines how you work with each group. The communication plan answers five questions for every important stakeholder: What information do they need? In what depth? How often? Through which channel? And who in the project is responsible? Management needs a compact overview of schedule, budget and decisions required. Key users need details on features and dates for testing and training. IT operations needs technical constraints early on.
Plan not only reports but also decision formats: steering committee, acceptance dates, review meetings. A communication plan that only defines who receives which report is not enough.
Involvement has the greatest effect where the project needs decisions. Three moments are particularly important in IT projects:
Simply collecting requirements produces wish lists. Developing and prioritising them together with the business unit, end users and IT produces viable results. Our article The Underrated Success Factor: Clean Requirements describes how this works.
Prototypes, demos and sprint reviews give stakeholders the chance to react early. A correction after the first demo is considerably cheaper than one after acceptance.
If the business unit and sponsor define at the start of the project how they will recognise a good result, acceptance becomes a comparison rather than a dispute. More on this in Acceptance Testing: How to Get Software Sign-Off Right.
The stakeholder landscape changes: people in charge move on, departments are reorganised, a previously uninvolved area is suddenly affected. Review the stakeholder register regularly, for example at every milestone or every few sprints. Signals such as missing feedback, cancelled meetings or criticism through informal channels indicate that a group is no longer on board. Such developments also belong in risk management in IT projects, because a lack of support is one of the most common project risks.
Resistance is not a disruption to be moderated away, but information. Behind rejection there are often understandable concerns: extra work during the transition, loss of know-how or influence, fear of monitoring or simply bad experiences with earlier projects. A direct conversation has proven effective, in which you ask about the concerns specifically and check which of them the project can resolve – for example through training, an adjusted rollout sequence or clear rules on data usage. Where interests genuinely conflict, a decision by the sponsor or steering committee is needed. What matters is that this decision is made openly and explained. If a project fundamentally changes the way people work, structured change management is also worthwhile.
In Scrum, the Product Owner is the central interface to stakeholders: they gather needs, prioritise the backlog and invite stakeholders to the Sprint Review, where the increment is inspected together. This does not make stakeholder management unnecessary, but it shifts it. If the Product Owner has no mandate or important groups never attend the reviews, the same problems arise as in a traditional project – they just become visible later. In hybrid projects, the steering committee and the team also work in different rhythms. Read more about the differences in Agile vs. Traditional Project Management.
Stakeholder management in IT projects is not an extra task but part of project control. Clarifying early who is affected, prioritising groups by influence and interest, deliberately planning communication and involvement and updating the picture regularly prevents many delays and conflicts before they arise. How to also keep schedule and budget under control is covered in Keeping IT Projects on Time and on Budget: How It Really Works.
As early as possible, ideally during project initiation, before scope and approach are defined. After that, the analysis should be reviewed regularly, for example at every milestone, because responsibilities and interests change over the course of the project.
In traditional projects, responsibility lies with the project manager, supported by the sponsor and sub-project leads. In Scrum, the Product Owner is mainly responsible for alignment with stakeholders. Individual relationships can be delegated to team members, but the overall view should sit in one place.
Communication management defines who receives which information, when and through which channel. Stakeholder management is broader: it analyses the influence, interests and attitude of those involved and defines how they are involved in decisions. The communication plan is therefore a tool of stakeholder management.
30-minute initial consultation — free and without obligation. Together we look at your project and show how to engage those involved and decision-makers effectively.
Book a Free Initial ConsultationMore about our service: IT Project Management in Hamburg →
Related: Change Management in Hamburg →