By The Readers # 101 - Lessons On Stakeholder Management For Large Cross-Functional Projects
S1E01 - How to implement effective stakeholder management in large cross functional projects without creating too much work for yourself.
Howdy Tribe -
Today's newsletter is going out to 152 dedicated readers.
Last month, I did a survey with you all about questions, ideas, or topics you would like to read more about from me. So, I have picked some interesting ones which I will share my thoughts on every week for the month of December. It is a faster pace of writing and a break from my every other week schedule. Here is what to expect in the coming weeks:
(Dec 1) Lessons On Stakeholder Management For Large Cross-Functional Projects
(Dec 8) Psychology of Project Management: Half Truth of Leading Without Authority
(Dec 15) The Sprint Plan - 2, 6, or 8
(Dec 22) Power of Tribes - How To Build An Internal Network
(Dec 29) Challenges of Building In BigTech
Welcome to Building Romes Newsletter - By The Readers Issue, Season no. 1. 🎉
ESSAY.
What are we solving today?
All large cross-functional project have a plethora of stakeholders each with their own agenda. It creates for a collaborative engineering process but becomes a hurdle in decision making if left unmanaged. We have all been there, that one meeting during the development phase of the project where you have have suddenly gone from a handful of stakeholders to two dozen now. Suddenly every decision is a marathon instead of a sprint because every thinks their voice matters; Hard reality check - it doesn’t.
Stakeholder Management has two key components:
Decision Making
Information Sharing
The typical agile methodology to address decision making is a responsibility assignment matrix (RACI or RAPID). My suggestion - don’t make a RACI or RAPID.
Why? Software engineering is complex and unpredictable already especially when developing new things so trying to fit things into neat boxes can overwhelm and create more chaos. Business processes, traditional IT structure or programs with ISO compliance requirements and strict Profit and Loss, yes, that is where RACI type artifacts do make sense and work wonders. I have yet to see a responsibility matrix like RACI at either Apple, Google, or Blackberry.
Lessons Learned and A Solution
So - next time keep it super simple and start with this framework - DOERS, DECIDERS, INFORM.
All projects stakeholders breakdown into three categories:
DOERS - People responsible for a deliverable, tasks, or output as part of the project. Output can be UX design, architectural solution, a line of code, marketing copy, project schedule, PRD, any thing materially necessary to the complete the Project.
DECIDERS - People who are accountable for the project completing on time, to spec, with high-quality. Often times, this category of stakeholders tends to overlap with the DOERS. More on this later.
INFORM - This is everyone else. The engineering manager who wants to attend the meeting just to stay in the know; the PM who wants to be kept looped in on status reports; the VP whose team is impacted by the work you are doing but doesn’t necessarily have a stake or say. This is the hardest category to maintain and manage given that many people within this category believe they deserve a place on the DECIDERS table.
You will be surprised how often many people think they have the right to make a decision in a project just because they are impacted or are interested in the project. I know it’s a bit harsh but the goal for Program Managers, managing multiple projects at a time, is to reduce the steps required to make decisions.
A Quick Note
DECIDERS fall into 2 categories:
DAY DECIDERS - These are leaders directly accountable for delivering the various milestones of a project. They also tend to be Doers as well - Product Managers, Program Managers, Engineering Leads, Product Marketing Leads. They make the day to day decisions and keep the training running.
STRATEGIC DECIDERS - These are often Senior Leaders accountable for the project as it pertains to the overall strategic fit with company wide vision and goals. Strategic decisions like push the program out due to a delay, or needing more resources to prevent slippage, or review difficult decisions that cannot be made by daily deciders due to the potential trade-offs and impact, that is their job.
How to Implement This Framework In A Project
I have used this approach to manage stakeholders on projects at Apple and Google, both software and hardware, some as large as 2 dozen cross-functional teams and as small as 3 teams. It has taken some years to develop but it has worked well so far.
Here is an example of the framework applied to the largest project I managed at Apple (~ 2 dozen engineering (client and server), prod marketing, design and QA teams across iOS, macOS, and iCloud):
Some pitfalls to watch for with this simplified approach
Be careful of who you make the DECIDERS - Title doesn’t always nor should it necessitate a decision making vote. Keep this group as small as possible as each additional person is more overhead increases the Collaboration Tax.
Senior Leadership must empower the DAY DECIDERS - Make sure there is alignment on the Senior Leadership level that the DAY DECIDERS are empowered and mandated to make day to day decisions.
Keep the INFORM stakeholders looped in on a regular basis - On the surface, the INFORM category sounds like a dumping ground for everyone we want to prevent from meddling in the projects day to day. DO NOT DO THAT. Many of these folks are potential end users of your project especially if it is internal tools you are developing. Continue to push fresh regular information to these stakeholders and you will benefit from unexpected feedback that can prevent a disaster.
Final Thoughts
A responsibility assignment matrix is a powerful tool. Yet, it’s, RACI or RAPID or RASIC or altRACI, numerous incarnations within software engineering create unnecessary overhead work. In my opinion, its a great tool to analyze the complex nature of an organization and it’s poorly designed matrix structure. It’s feel-good-stuff work that all Project Managers must avoid.
Perhaps in places like Intel, Management Consulting, Outsourcing etc, B2B SaaS, it has a necessary function to make sense of the org titles. App development, SaaS, consumer tech, startups, growth stage companies, it is best to start simple with something like this framework and then add on versus to start trying to answer everything all in one go. Latter is exhausting. As always remember - avoid dogma or prescription of processes and frameworks - use them as a guideline to help you get started and build it to match your team or organizational needs.
The DOERS, DECIDERS, INFORM framework reflects the simple accountability structures of Engineering at Apple and Google.
If you are constantly in need of a RACI like tool to help you figure out who is making decisions on even the most simplest of projects - perhaps its time you took a look at your organizational structure and think real hard whether its current form is working or impeding your ability to create surprise and delight.
I hope this helps.
Until next time! 👋🏽🙏🏽
-Aadil
How do you handle stakeholder management at your company with large cross-functional projects? Try using the DOERS, DECIDERS, INFORM framework to see if creates better clarity for you.
Was it useful? Relevant? Help me to improve!
Was this edition useful? Relevant? Pointless? Help me to improve!
