Management for Data 101 — Managing Stakeholders
Preface: This is the third article in a series that talks about things we’ve learnt while trying to organise the data team at Aircall. Hence it goes without saying that some of the things we talk about will have a certain SaaS flavour to them. However, these articles are not meant to serve as a guide but more like examples that we hope will help you structure your ideas.
Why bother?
When you work in a transversal field like data, the projects that you work on will often involve various stakeholders. From my experience, I’ve learnt that the successful delivery of a project does not just depend on handing in your deliverables, but rather on doing so in a timely and predictable manner.
What do you mean by predictable?
Did the different parties involved know what they were supposed to do at the various stages of the project? Did your manager have a good sense of visibility on the project? Was the “client” aware of the timeline of reception and made aware of changes as they took place?
Ideally, your answer to all these questions should be yes.
The best way to ensure that you’re communicating with all the parties at the right time is to prepare a framework that informs you of the involvement of the various parties at each stage of your project.
Presenting RACI
The RACI framework was designed to respond to this precise need. The framework proposes that involvement of a stakeholder be classified into one of four simple categories, and then you assign a category to each stakeholder for every stage of your project.
The categories are as follows:
- Responsible — people that’ll be directly executing on a certain stage of the project. There should ALWAYS be at least one responsible party, but you may have multiple people or teams responsible for a certain stage.
- Accountable — the one who is ultimately answerable for the successful completion of the project, they’ll have to sign off before a stage is complete. Also compulsory for each stage.
- Consulted — people who may be needed to provide helpful or necessary input for a particular stage (optional)
- Informed — people who need to be kept in the loop during the stage. These may the ones who are going to receive the project or the people who’ll be impacted as you change something (optional)
Applying RACI to your project
In order to apply the RACI matrix to your project, the first thing you need to do is to break the project into different sprints, decide what you’ll do in each sprint and arrange these sprints into a timeline. I’ll try to illustrate with a ride along example.
List the tasks
Let us imagine that you’re working on developing an analytics feature for some of your top clients. This is how you could break it down into sprints:
- Research and understand client needs
- Audit existing analytics data sources and pipelines
- Spec the final list of data points
- Provision infrastructure
- Build the necessary data pipelines
- Create a draft of the dashboard
- Beta release, feedback, modifications
- Create documentation and support material
- Release the feature to all users
Now that we know the different sprints the feature development will go through, let us try to list all the stakeholders that will be involved in this project. For the sake of this example, we’ll consider the following teams: Data, Support, Product, Infra and Design.
Create the timeline
Now, all that is left to do is to arrange your sprints and teams into a table, and for each sprint mark out the role the team is going to play in terms of R, A, C or I. Multiple teams may be Responsible, Consulted or Informed during a stage, but you should always try to have a single person/team who is Accountable.
Improving the level of precision
Since we notice that the Data team is often both the responsible and the accountable, we should try to split them into separate entities. You could do this by specifying names of your people, referencing sub-teams but for the sake of this example, I’m simply going to take “executive” and “management” as the two sub teams.
Wrapping Up
At the end of the day, the objective of the RACI framework is to help you avoid unpleasant surprises or unnecessary roadblocks.
For example, if you already know that you’ll need the Infra team to dedicate some time to provision the necessary infrastructure for your feature during the 4th sprint, you can put in your request ahead of time. The infra team should then have ample time to take this into account when they plan the allocation of resources. If they feel that they might not be able to help you out at the said time, you would learn about it well in advance — giving you time to think of other alternatives.
It can be difficult to manage a team timeline when it may be affected by so many external factors/teams, but this way everyone knows what is expected from them at each stage. Once validated by all the involved stakeholders, the RACI is like a commitment between the various teams and should help you avoid future misunderstandings.
Hello fellow data warrior, I hope you found the article useful and it helps you organise your next project a little better. Check back in right here next week for the next article in the Management for Data 101 series, where we share more about what we’ve learnt while working on data at Aircall.
If you enjoy reading about such things, do consider following Aircall on Medium or Twitter, we try our best to share our learnings as often as we can.
