Some of the posts I’ve written in the past on key components of building a strong and scaling experimentation program seem obvious (such as having an executive sponsor), but that’s just table stakes if you want your program to be successful. Some components are not difficult, but doing them will ensure success and scale. Yet I still see programs skipping these stages only to have to circle back later.
Defining a RASCI along an experiment’s lifecycle for your program is one of these key components. A RASCI will set clear responsibilities for each stage in an experiment and create easier execution for the team.
As you memorialize your RASCI, consider which role in your organization applies to each of these:
- R = Responsible = Owns the stage’s completion
- A = to whom “R” is Accountable for = Who is on the hook for the success of the stage
- S = Supportive = Can provide resources or support the completion of the stage
- C = Consulted = Has information and / or capability necessary to complete the stage
- I = Informed = Must be notified of completion of stage, but need not be consulted
Think about each stage in an experiment’s lifecycle. What are the tasks in that stage that need to be completed? What is the exit criteria for that stage? Then plot each of your team member’s (and their roles) along the above. You can use this template to start building your and your output should look something like this:
(If you use Optimizely’s Program Management to manage your experimentation program, you should align your RASCI to the Stages found in the platform).
This will most likely look different whether you are using Optimizely’s Web or Full Stack platform for your experimentation program (the above is an example for a team using Full Stack). And you’ll certainly need to create two RASCIs if you use both platforms, even if the stages are completed by the same resources. The Implementation, QA and Launch stages will have differences to be sure, though others could as well.
I wrote in my experimentation team structures post on the value of a central team. Alongside your RASCI you should have representation from the central team and the other teams who own execution of experiment stages as well. In the RASCI example above you’ll see the Program Manager from the central team is accountable for each of the stages, but stages from Design through Analysis are owned by members of a product team.
Your team structure will also dictate the number of RASCIs you’ll have to establish for your program. Each Individual Team and Council within your organization needs its own RASCI. There will be differences in resources and tasks within a stage that require unique owners. Individuals may be represented in multiple RASCIs.
So what are your next stages?
- Look at the roles of a core team below. Do you have all of these filled? If not, assign someone within your organization to fill it.
- Take this template and assign a team member along the RASCI.
- Consider and be open to iteration on this in the short term. If you are a new team starting to launch your first experiments, there undoubtedly will be learnings on each stage and their related tasks. Set up time to review this once you see your first experiments go live in order to observe what needs to be shifted.
- Promote this to the rest of your organization once it is complete in the short term. Visibility on ownership will allow the rest of the organization to come to the right individual with questions when needed.
It seems obvious, but establishing this RASCI is important! It will allow your organization to focus on the higher value items of experiments (ideation, analysis, etc.) if you set these guardrails upfront.
How have you defined your own experimentation RASCI? Or what other tools / frameworks have you used to create the same output?