Stuck at stakeholder engagement? Try an Agile approach.
Stakeholder engagement is increasingly important in complex projects. If you keep balancing narrow error margins vs. potentially large outcomes, you might want to make sure that stakeholders -the individuals who can make or break your success- are properly engaged. At the same time, stakeholder engagement should not be overblown, as to stand in the way of your actual work. This is why we suggest taking an Agile approach that keeps things simple, focused, and effective.
Basics of Agile methodology
Why Agile?
The Agile mindset
How Agile works and why should you care
Basics of stakeholder engagement
Who are the stakeholders?
How to select the right stakeholders?
How to keep them engaged?
What happens if you don’t?
Establishing a shared vision of the product
Project charter
Project elevator pitch
Definition of done
Agile modeling
Wireframes
Personas
Communication with stakeholders
Personal communication
Knowledge sharing
1. Basics of Agile methodology
Why agile?
In the last decades, companies switched their focus from the manufacturing of goods to information and data. They value ownership of information and data and the ability to use it to create/improve goods and services.
The work involved in IT projects is more uncertain and less definable than for industrial, classical projects. That’s why using traditional management techniques and planning on IT projects leads to more frequent failures and frustration.
Classic management techniques and planning do not work for many IT projects. Agile appeared as a collection of those methods and frameworks that are most effective when building IT products.
Agile’s 4 core values
Practicing Agile works best with an agile mindset that resets priorities:
Individuals and interactions over processes and tools. Yes, we do need processes and tools – they are logical and predictable, and it is hard to complete a project without them. But they are static assets, useful for solving old & established problems and tasks. By contrast, it is the people and their interactions that solve the new problems and that are capable of innovating and moving things forward.
Working software over comprehensive documentation. Software without proper documentation is difficult to support and maintain. But comprehensive documentation without working software is useless. Therefore, documentation should be just in time, just enough, and it should not become the main focus.
Customer collaboration over contract negotiation. Use a flexible contract that allows for deeper collaboration with the customer. It’s one of the best ways to switch effort from low-value activities (e.g. discussing what to do when the project’s scope changes) to your most productive work.
We are aware of traditional Change Management processes that take a lot of time and effort to agree upon. They tend to result in Change Suppression processes, which is the opposite of Agile. Therefore, we recommend not to spend too much effort on Change Management clauses.
Responding to change over following a plan. It does not mean we should abandon planning – we still need plans, but we need to accept that they were put up when we knew the least about the project. Instead of hammering the project back in line with the original plan, we should update the plans more often so we can adapt to inevitable changes.
Agile mindset: Inverted triangle of constraints
A project is defined by three main constraints: features, time to build, and cost. In traditional project management, we constrain the features first: we spend a lot of time in the beginning on a detailed definition of requirements and assume that we will deliver 100%.
Based on these requirements, we estimate the time and the costs and go ahead. But no estimation is 100% perfect when facing real life. Therefore, time and cost would need to be flexible in order to deliver 100% of functionality.
In Agile, we flip the constraints upside down. We constrain the time and the cost at the beginning and accept that scope and features will be flexible. By prioritizing the features based on their business value, the allocation of time and cost is more relevant. Also, when the original estimation will change, the most important features will already be delivered – within the agreed time and cost.
We, therefore, see two main advantages of Agile over traditional planning:
- You know the (fixed) cost and timeline.
- You can focus on delivering (say) 75% percent of functionality that covers 95% of the project’s business value.
How Agile works and why you should care
The traditional is called Waterfall because it looks like one: it is a succession of steps that get you to the big, final outcome.
Those fixed steps are:
- Define the requirements
- Design the technical architecture
- Complete the actual development of the product
- Test the product
- Deploy
Agile follows pretty much the same steps, but for a smaller scope and through multiple iterations, i.e. reaching a satisfying result incrementally.
There are further benefits coming from iterative, incremental deliveries:
- More business value
- Less risk
- Better visibility
- More adaptability
2. Basics of stakeholder engagement
- Who are the stakeholders?
- How to select the right stakeholders?
- How to keep them engaged?
- What happens if we don’t?
Who are the stakeholders?
The stakeholders are any people or groups of people who will be impacted or have an impact on the project. May include:
- Customers
- Business consultants
- End users
- Managers
- Vendors
- Suppliers
How to select the right stakeholders?
Getting the right stakeholders is crucial – and you should push hard for it. The more of these three qualities in a stakeholder, the better:
- Has the right knowledge
- Can make decisions
- Has authority
Here’s what to look for:
Knowledge: individuals who cover the requirements, features, technical aspects, certain rules, or legal constraints of the project. Make sure they can also explain effectively – it will help the development team to understand your context and requirements quicker. Typical characters: end-users, business consultants, technology/subject-matter experts.
Decision maker: someone who can take the necessary steps to move things forward. They are either representatives of a group of people (i.e. can take decisions in their name) or can facilitate the decision-making process and can communicate that decision to the team. Typical role: product manager.
Authority: someone with the appropriate position and power to whom you can escalate issues for a swifter solution. Typical roles: department manager, sponsor.
It would be great to find individuals with all these qualities. But in practice, this does not happen, so we need a group of stakeholders. Keep in mind that the best people are also the busiest people, which makes them even harder to get on board.
How to keep them engaged?
- Show them what you build
- Discuss estimates and projects
- Manage their personal interest
- Note: some stakeholders can become a burden
For the stakeholders, your project might not be their main focus but just a side activity among (many) others. Further complicating: they might be spread across different organizations beyond your direct supervision and influence.
The stakeholders usually expect to only be involved in the planning phase – which makes it even more important for you to keep them interested in the project for as long as possible. Here are some hints on how to do it:
Frequently show them what has been built on the project, so they can see things moving and not lose interest. More important: it helps you focus and not get too far with building the wrong things.
Show them the true progress; discuss estimates and projections. The bad news: sometimes the true rate of progress is not what the customer / the stakeholders want to hear. The good news: transparent information, delivered as soon as available, is priceless. By discussing delivered features versus the remaining features, your team and the customer can make trade-off decisions based on solid data.
To keep stakeholders engaged, add “candies”:
- Make sure their involvement is visible and monitored; report and underline the benefits of their engagement.
- Recognize and reward their involvement, for example, by celebrating project accomplishments together.
- Talk to their managers about how to best recognize their contributions, possibly by including them in their performance reviews.
What happens if we don’t engage:
The Gulf of Evaluation
By not engaging the stakeholders, the project is likely to fall into the “gulf of evaluation” and get lost in the cracks between:
- what the customer needs,
- how the customer describes what he needs,
- how the development team understands that description,
- what the team actually implements.
This is where a lot of mismatches come up. If left unchecked for too long, they will result in costly rework or even project failure. Therefore, instead of multiple different images of your product, try creating a single one shared by all participants: “the shared vision of the product.”
3. Establishing a shared vision of the product
Practical examples of how to create a shared vision:
- Project charter
- Project elevator pitch
- Definition of done
- Agile modeling
- Wireframes
- Personas
The project charter (W5H)
is one of the first documents to be created within any project. It provides authorization from the sponsor to proceed and should important building blocks such as:
- What this project is about: a high-level description of the project’s vision, missions, goals, and objectives.
- Why is being undertaken: the business purpose of the project.
- Who will be engaged: a list of project participants and involved stakeholders.
- When it will start and end: target start/end dates and timeline of partial releases.
- Where it occurs: information about the various work sites (e.g. where will the common meetings take place), deployment requirements, etc.
- How it will be done: a description of the approach, methods, and framework to be used. This can also serve as a notification to stakeholders that the Agile project will need increased involvement on their part.
Please note: if we accept / assume that the scope is not absolutely fixed, and that some project parts might even be unknown at the beginning, then there is no need to fully specify the scope.
The project elevator pitch
is the project’s most concentrated, sparkling description. Imagine yourself in an elevator with someone who can support/sponsor your project: you have at most 20-30 seconds to describe it, so it must be brief, convincing, and “sticky.”
Here is a possible structure (and made-up example):
- For | Target Customers | Diana Travis is a marketer at InnerWorks who…
- Who | Need / opportunity / problem | …cannot cope with creating all the reports she needs.
- The product / service | AnswerASAP is…
- The category | …a report generator tool that…
- Key benefits | …helps answer any market-related question nearly instantly.
- Unlike / competing alternatives | Creating a report now takes 30 minutes…
- We / differentiator | …but we can generate the report in 4 minutes.
Definition of “done”
surprisingly, it can mean different things to different people. By having a list of everything that needs to be completed, all stakeholders will have the same understanding:
- Coded: has all the code been written?
- Designed: is the code’s design up to the agreed technical standards?
- Tested: are all the tests finished?
- Integrated: does the feature work from end to end?
- Installs: does the application install on the expected servers?
- Reviewed: have customers reviewed the feature and confirmed that it meets their expectations?
- Approved: have customers approved that functionality?
- Fixed?
- Migrated?
- Compliant with regulations?
Without a common definition, you risk hitting frequent mismatches.
For example, the development team is usually focused on the first topics (design, coding, and testing) and wants to get them done before moving on to the next thing. On a separate narrative, the customer looks at a different set of criteria, such as integration, approval, or compliance. As you can expect, putting the two together without prior alignment and common understanding will definitely result in hiccups.
Agile modeling
can be done with use-case diagrams, data models, and screen designs:
- The use-case diagrams usually refer to actors and actions (e.g. end the users and the processes behind their actions).
- Data models: the data entities and their interlinking.
- Screen designs: how the product should look on a web page, desktop or mobile device.
Wireframes
are mostly useful when creating mock-ups of a product. They are a series of screen designs, prototyping a certain part of the product or a specific workflow, with minimum needed functionality (e.g. only take care of moving from one page to another). Wireframes are highly useful at the very beginning as a quick and cheap way to get feedback on a proposed functionality.
Personas
are quick guides and reminders about the end-users and their usage cases. They are one more tool for the development team to prioritize their work and stay focused on what matters. Personas do not replace the requirements but rather augment them.
- Provide a description of a representative user
- Be grounded in reality
- Be goal-oriented, specific
- Generate focus
4. Communication with stakeholders
If the first step in avoiding the gulf of evaluation is the establishment of a shared vision, then the second step is communicating with the stakeholders in the right way. In the context of agile stakeholder engagement, the most effective ways to do it are:
- Personal communication
- Knowledge sharing
Personal communication
can be done either in a dispatching model or a collaborative model.
The dispatching model usually follows the hierarchical structure of an organization, flowing from top to bottom, from Product Manager to Team Leader, then to the ones who actually do the job, the Team Members. This command-and-control approach might be easier for the one who sends the message, but it is not effective in software projects.
The collaborative way (i.e. two-way communication) is built on direct messages followed by feedback and validation, such as:
- Development team to the customer: “Here is what we think you asked for, and this is what we have built. Please confirm that we are on the right track.”
- Customer to the development team: “I like these two-part, but you got the third piece wrong. Oh, and this reminds me that we really need something to cover for a new request.”
For obvious reasons, the collaborative way is the most effective, therefore, preferred in Agile software projects.
Knowledge sharing
Information radiators are highly visible information displays, such as large charts, simple graphs, and summaries of project data. The information should be displayed in high-traffic office areas or online on simple and fast Wiki pages. This is opposed to information refrigerators, where project information is kept away in complicated documents, reports, and KPI sheets – meaning that nobody knows what is going on.
- Bidirectional information flows are critical.
- From stakeholders to the development team: the shared vision about the project and outcomes.
- From development team to stakeholders:
- Features map
- Who is working on what (Kanban board)
- The features selected from the current iteration
- Velocity chart
- Defect metrics
- List of threats and issues
- Burn charts
In this example of a webstore’s features map, the first row includes the fundamental steps of that journey (the epics) that would provide the map’s “backbone.”
The red line shows the user journey (how the user will use the product).
The individual features will be distributed along the main phases of the journey, with gradual releases (R1, R2, R3).
At the bottom, you have the backlog to include the features with no clear release date.
The benefits of a features map:
- it shows the big picture of how the product is used;
- is an excellent tool to visualize priorities and the feature release timeline.
The columns show the stages of a process, while the individual cards represent work items/tasks. Progress is visualized by moving the cards from left to right, thus simplifying team coordination. If needed, The board can further be split into separate rows to indicate different work areas or different teams.
You can count the remaining days of specific tasks to detect the lagging ones and highlight any potential issues.
Kanban boards are included in various software packages – but a physical whiteboard that you can draw and stick notes on makes it more prescient and hard to ignore.
Although the stakeholders are not performing the actual work here, it the Kanban is still useful for them to see how things are moving. For example, if they want to track the implementation of certain features, the board shows who is working on it.
Ideally, the grey line should match the green line. In practice, it will usually not – and if there are no major issues, that’s ok.
One scenario has the grey line constantly ahead of the green one (i.e. Estimated > Completed): this means the team is overestimating its capacity, meaning they believe they can do more than they actually do.
On the opposite, when the grey line is constantly below the green line (i.e. Estimated < Completed), the development team underestimates its capacity, possibly because they don’t want to overpromise.
Either way, this is valuable information when planning: it helps assess/decide how much work is to be done within a certain timeframe.
5. Collaborative work
Once you have established and communicated the shared vision, let’s look at how you can build it in a collaborative way through:
- Workshops and brainstorming sessions
- Collaboration games
- Decision-making games
Knowledge sharing
comes in two flavors: workshops and brainstorming. The workshops are most effective when following a few simple rules:
- Start with a kick-off activity that has everyone involved within the first 5 minutes (e.g. participants to introduce themselves and/or their expectations).
- Establish a clear goal, with a schedule and rules that are visible to anyone.
- Encourage diversity: by bringing in a diverse group of people instead of just a few experts, you will generate a wider range of options, new ideas, and solutions.
Involve all participants: input is both expected and encouraged from everyone. Prevent dominant individuals and extroverts from monopolizing the discussion. Some practical hints on how to run it:
- Take time for quiet writing: reserve 5 to 10 minutes to generate a list of individual ideas to minimize the influence of stronger individuals in the group.
- Round robin: pass a token around the group; only the token holder token speaks, which allows the ideas to build upon each other.
- Free for All (i.e. people shouting their ideas spontaneously), only works in a supportive environment, where people are familiar with one another and are comfortable with speaking their minds.
Collaboration games:
- Shape the product tree
- The sailboat
- The trunk and the main branches represent what we know at the beginning, i.e. the main ideas about what the product should do.
- The outer branches show new or more refined functionalities that are yet to be designed and implemented.
Ask the attendees to record the product’s desired features on individual notes to be placed on the tree. How we place the notes is very important:
- The related features should be grouped on the same branch.
- The supportive features must be placed closer to the trunk than the supported features.
Seeing how the features relate to each other makes it easier to understand the process of setting priorities and defining development sequences. That’s why progressive elaboration is a key concept in Agile projects.
Make sure to review this tree on a regular basis: some new branches or new leaves could be added, while others might be removed.
- Where you want to go: “the goal,” e.g. the set of features needed for the upcoming release.
- What can get you there: facts and actions that help build the project (e.g. “helping team”; development team’s direct access to a key stakeholder; clear feedback from an end-user, etc.)
- What slows you down: “delay reasons” (e.g. the staging servers are slowing down the automated tests; no clear conclusions came from your last review meeting, and it needs a repeat etc.)
- The risks: anything that has a disruptive potential over the product/project (e.g. maternity leave that starts sooner than expected; an important feature that’s not sufficiently detailed etc.)
The sailing boat speeds up your finding of threats and opportunities, of positive and negative facts impacting your project. It also helps your team express and clarify concerns – as long as they put the work in to address the issues.
Decision-making games / Participatory decision making
It is very rare (and not realistic to expect) that a group of people achieves total agreement on all discussions and decisions. Therefore, we need a way to make tough decisions while keeping everyone motivated and engaged in the project.
Here is what we use on a regular basis:
＿
As hinted at the beginning, Agile stakeholders’ engagement balances simplicity and effectiveness. As long as you think in terms of outcomes and get the basics right (establish a shared vision, communicate and collaborate on a regular basis), your stakeholders will be an important element for your project’s success.
＿
How do you approach stakeholders’ engagement? Got any experiences that you can share? Let us know!