Manage stakeholders more effectively with AAI, not RACI
Having trouble herding the cats? Here’s why, and how to change it for the better.
The need for using a project management framework
In today’s modern businesses, anyone can find themselves at the center of managing a project — even without carrying the title of “Project Manager.”
Whether you’re a Product Manager, Product Ops or even if you’re in Marketing or Sales, managing complex projects with multiple cross-functional stakeholders is unavoidable.
To help manage the numerous stakeholders with varying degrees of input across these complex projects, Project Managers and Program Managers often look to frameworks to simplify the process. These frameworks can include anything from a set of processes, tasks, and/or tools to help guide the execution of a project from start to finish.
What makes these frameworks so helpful is they provide guidance and structure with a shared language that everyone can understand.
Ultimately, the use of project management frameworks improves the chances of successfully completing the project on time, on budget, and within scope. With a framework in place, teams can benefit from improved efficiency, better collaboration, as well as increased consistency and predictability from planning to execution.
A good framework helps teams be more accountable, more organized, and provides visibility into the current progress across multiple deliverables simultaneously.
Understanding the RACI framework for managing stakeholders
Stakeholder management is a critical piece of successful project management. And one of the most popular stakeholder management frameworks is the RACI model.
The RACI model (which stands for: Responsible, Accountable, Consulted, and Informed) is a project management tool that helps project teams and the broader organization better understand the roles and responsibilities of stakeholders in a project.
RACI provides a clear and concise way to assign and communicate responsibilities for different project tasks and decisions. This way, everyone knows the effort and commitment being asked of them and they can see the same for everyone else involved in the project.
A RACI chart helps Project Managers understand who to involve, at what level of commitment, and how those dynamics change as the project matures.
Key components of the RACI framework
The four key components of the RACI framework are:
- Responsible: This refers to who will carry out the task or deliver the output.
- Accountable: This refers to who is ultimately accountable for the success or failure of the task. This usually identifies who delegates the work and is on the hook to review the task/deliverable before it’s marked as “complete.”
- Consulted: This refers to who needs to be consulted or involved in the decision-making process for the given task. Consulted individuals provide their input based on their subject-matter expertise, how it will impact their team, or how it impacts their own projects & tasks within their domain.
- Informed: This refers to who needs to be kept informed of the task progress/completion or decision outcome. This is simply anyone who should be kept in the loop and doesn’t need to be dragged into the gorey details of each task.
With the RACI framework, the business can ensure clear lines of communication and accountability among all project stakeholders. As a result, the team has better alignment around project outcomes and project goals.
Here’s an example of a typical RACI chart:
Limitations of using RACI for project management
Even though the RACI framework is a widely used and effective tool for managing stakeholder responsibilities, it does have some limitations:
- Complex projects: RACI charts can become cumbersome for complex projects with many tasks and stakeholders. This makes it difficult to manage and maintain.
- Rigidity: The RACI framework can sometimes create rigid structures that are difficult to adapt around changing circumstances. This can sometimes lead to inflexibility and ultimately delays.
- Overlapping responsibilities: The RACI framework may not address the issue of overlapping responsibilities, leading to confusion and conflicting expectations among stakeholders.
- Limited representation: The framework only considers four key roles, and may not fully capture the complexity and nuances of all stakeholders involved in a project.
- Resistance to change: The RACI framework may not be well received by stakeholders who are resistant to change, and may require significant effort to implement and maintain.
RACI works very well when there are clear individual lines of responsibility. But RACI falls short when project leaders are forced to put stakeholders in a bucket they don’t agree with.
Putting a stakeholder in a role of being “responsible” gets messy when ultimately it’s that person’s team who is responsible. This is common when teams are too large or specialized and a delegate is assigned to represent the team in project meetings. The delegate must carry the assignment of being responsible, but in reality, they are just a conduit for the team performing the actual work.
Another area of friction with RACI is the “consulted” assignment. Hardly any stakeholder will want to be asked to contribute their context without knowing for sure that input will be taken into consideration or used in the process. This is especially true for when the stakeholder is a more senior member in the organization. What these stakeholders want is to be included in the process and decision-making.
Understanding the AAI Framework
The AAI (Awareness, Alignment, and Inclusion) framework is another project management tool that helps organizations better understand the roles and responsibilities of stakeholders in a project.
I was first exposed to this framework in the Product Leadership program from Reforge.
As Product Operations Manager, I quickly saw the possibility of applying the AAI model to the projects I was managing. We were suffering from stakeholder bloat and needed a way to streamline our project meetings without excluding any critical voices.
The AAI framework provided us with a clear and concise way to assign and communicate accountability, authority, and inclusion for different project tasks and decisions.
It’s similar to RACI but with some added benefits due to some simplicity in the model itself.
Key components of the AAI framework
The three components of Awareness, Alignment, and Inclusion that make up the AAI framework are defined as:
- Awareness: This refers to anyone who is impacted by, or has the ability to affect the outcome of a task or decision, even if they don’t have direct authority.
- Alignment: This refers to who has the power to make decisions and take action on a task.
- Inclusion: This refers to who is responsible for executing a task or making a decision.
How AAI is used in practice
The components of the AAI framework are represented by 3 concentric circles, with the level of participation becoming less involved as you move outward from the center.
At the center is the Program or Project Manager. Everything else flows outward from here.
The inclusion layer
In the innermost circle is the inclusion layer. This is the set of stakeholders who are paramount to the successful achievement of the project goal. They should see themselves as partners to one another. For anyone who works in product development, I like to think of the inclusion layer as akin to a product trio as described by Teresa Torres and Marty Cagan.
The inclusion layer represents a commitment to one another to contribute significant communication, buy-in, and collaboration at every step.
The key to success when using the AAI framework is to keep this group as small and tight-knit as you possibly can.
An inclusion layer with more people means more input and opinions that are involved with each decision. Too many voices here means slower progress.
This is why balance is key and you need to find the sweet spot because there are trade-offs:
- Too many stakeholders in the inclusion layer means more perspectives and slower progress
- Too few stakeholders in the inclusion layer means a greater risk of leaving out key perspectives — with more people, you can move faster but it’s harder to keep everyone focused
Who gets placed in the inclusion layer depends on company norms such as who is typically included in projects and the specific needs of the project itself. For instance, in some companies, certain teams are expected to always have representation in core project work.
On the other hand, it can sometimes be beneficial to go against company norms given the specific needs of the project. Moving some teams into the alignment layer could help you move faster. Likewise, moving some teams into the inclusion layer that don’t normally have that level of access can dramatically shape the decision-making ability of that group. You’ll have to use your best judgment to know who to include and when to follow the norms.
The alignment layer
The next layer is the alignment layer. This is the set of stakeholders who have the ability to provide critical input to achieve a successful project.
Stakeholders in the alignment layer are typically department heads of the stakeholders in the inclusion layer. They require updates, fairly detailed communication, will require some collaboration, and will provide necessary buy-in and approvals as the plan matures.
The awareness layer
The final and outermost circle is the awareness layer. This is the group of people within the company who need to be aware of the work the project team is doing.
They will require progress updates but with much less detail and less frequency than the alignment layer. This includes anyone who is impacted by the project but isn’t a significant contributor to the project itself.
Putting it all together
Once your circles are defined, you need to commit to sticking to them. Use them in the context in which they were constructed. In other words, don’t make decisions without buy-in across your inclusion layer. And don’t neglect your alignment layer by excluding their input and seeking their approval when needed.
A note about communications
Identifying which stakeholders to place in each layer is great but you’ll probably still encounter friction if you don’t consider communication channels for each layer.
For the inclusion layer, a dedicated, private Slack channel plus weekly standup is probably the way to go. For the alignment layer, a weekly meeting plus an email summary is likely a great place to start. Finally, for the awareness layer, a dedicated Slack channel for the project with regular updates in a forum such as Towh Hall is probably sufficient. If you do create a dedicated project Slack channel that’s company-wide, be sure to invite the inclusion and alignment layer stakeholders as well.
Example of how our team used the AAI framework
For my project, we were sun-setting an acquired software application and migrating its users to our platform. It was a product-led project in the sense the Product team was building the migration experience and required collaboration with go-to-market teams to coordinate the user migration effort. We chose to use the specific needs of the project to inform how we structured our circles.
Our inclusion layer was myself, the Product Lead over that division of our product portfolio, and the Product Marketing Manager assigned to the project.
Our alignment layer was composed of representatives from the broader product development ecosystem, Marketing executives and specialists, Sales leaders and Heads of Customer Success.
Our awareness layer consisted of essentially everyone else in the company receiving project announcements through a dedicated project slack channel and cascading updates from the inclusion and alignment delegates belonging to their respective teams.
By organizing our project team in this manner, we were able to make decisions faster and keep distractions to a minimum, without excluding anyone’s opinions.
This was possible because although we had a small inclusion circle, everyone had an avenue to bring forward their concerns and cascade their contributions up and down through their own delegates.
I should point out that in our case, the Product Marketing Manager was given authority by the CMO to act as the primary delegate for the go-to-market teams overall. Without that authority, our inclusion circle would have looked much different but this enabled us to move faster by appointing a single delegate.
Advantages of using AAI for project management
By using the AAI framework, organizations can ensure that all stakeholders understand their roles and responsibilities. Members who want and need to contribute input have a role and channel that enables them to do so. The project team can make informed project management decisions without slowing down to hear from everyone at every step.
Here’s an example of what the stakeholder roles might look like if we replace the RACI assignments with designations from the AAI model.
Why AAI is better than RACI for project management
Hopefully you can see how the AAI model can make stakeholder management easier — even for complex projects. Compared to RACI, the AAI framework gives you:
Improved collaboration and communication: Eliminates over-communicating and reduces noise on email, Slack, and other channels.
Increased clarity of accountability: You can more easily set expectations with stakeholders to ensure they know what level of communication and participation they can expect.
Flexibility and adaptability: Similar to RACI, stakeholders in AAI can move into (and out of) different circles as the project matures, but without the rigidity RACI often demands.
The AAI template
Interested to try the AAI model on your next project? Give this template a try instead of a RACI chart for your next project.
👉 👉 AAI Stakeholder Template 👈 👈
In conclusion
To recap, there are many different frameworks to use when managing projects. Effective stakeholder management is critical to improving the chances of successful project completion.
When it comes to stakeholder management, being clear about everyone’s role is key to keeping the project on track and running smoothly. A common tool for mapping stakeholder involvement is RACI but it has some nuances that create challenges for anyone managing the project.
To address the challenges and shortcomings of RACI, I’m suggesting you use the AAI framework instead of using RACI.
The AAI model exceeds where RACI falls short because of its simplicity.
The AAI framework also adds flexibility where RACI is too rigid. It also improves collaboration and communication because it establishes clearer expectations around stakeholder participation.
Interested in giving the AAI framework a try? Use this template to use this model on your next project.
Stakeholder and project management is quickly becoming an area of focus for Product Operations teams. If you’re coming to this article as someone interested in learning more about Product Ops, check out my articles on that topic:
- Product Operations: From zero to one
- Product Operations: From one to many
- The 3 Qualities to Measure When Evaluating Product Operations
Want more templates?
There are no shortcuts in life… but a good template is pretty darn close! I’ve packaged up 10 of my favorite Product Ops templates for anyone who wants some help getting started or is already on their Product Ops journey. These are templates that I’ve used in my day-to-day work, and are designed to be easy to use, customize and update.
You can find the Product Ops templates here:
👉 👉 More Product Ops templates 👈 👈
