Optimization is difficult. I’m often amazed that good, sound testing ever occurs on websites due to the fast-evolving complexities of digital marketing, web development, and doing business across the digital landscape.
One of the reasons that Optimization is difficult is because it’s extremely cross-discipline by nature. It’s part marketing, part user experience, part design, part analytics, part web development, and part statistics.
Anything that cross-discipline requires a great deal of coordination to make sure all the specialists involved in conducting a test are doing their parts efficiently.
Another challenge of cross-disciplinary digital work is that accountability is sometimes missing, or not strong enough. This is a major reason why a lot of corporate testing programs don’t grow from “skunkworks” into something more accepted and robust—testing efforts become inefficient due to a lack of shared understanding about who is responsible for what and when. And maybe more importantly, who takes command when things aren’t running smoothly?
Enter the Responsibility Assignment Matrix, a document that captures the responsible parties for a given business process or project, as well as what the project “owes” stakeholders in terms of status communication. I first learned about this approach as part of the Project Management Body of Knowledge training I received before I ever got into testing.
The matrix breaks responsibility levels down by task, using a variety of acronyms. The most popular is RACI, but there are many others like RAPID, CAIRO, and DACI. I prefer DACI because the letter D stands for “Driver,” and I really like the idea that someone needs to “drive” the project, even if they aren’t the final decision-maker! Often, this “driver” is an Optimization Consultant (external resource) or an Optimization Manager (internal resource). They drive most aspects of testing, even though they aren’t necessarily the final decision makers on what gets tested.
Driver: A single driver of an overall project, like the person steering a car.
Approver: One or more approvers who make most project decisions, and are responsible if it fails.
Contributors: Are the practitioners who are responsible for deliverables; and with whom there is two-way communication.
Informed: Those who are impacted by the project and are provided status and informed of decisions; and with whom there is one-way communication.
I’ve had success using a DACI model/matrix to help clients assign responsibilities and make sure their Optimization practice is accountable, repeatable, and efficient.
Here’s an example just to get you thinking [click to enlarge]. Each row is a work unit in a standard process used to run a test on a landing page or website. The D, A, C, and I columns capture which people (by job title) are involved in that step of the process, and what their responsibility is.
The exercise of simply filling out the matrix with your cross-disciplinary team will likely reap rewards. And once everyone is on the same page, you can refer back to it, if needed, to ensure accountability to your testing process.
Your process steps may be different, and your responsible parties will almost certainly be different (mine are purely fictional), but I believe this approach brings discipline into the dicey world of testing and continuous website improvement. Anyone can run a test or two, but it takes more structure to run test after test after test, ad infinitum.
Would love to hear from you on:
- if you’ve used DACI, or a similar model, in Optimization work
- has your responsibility matrix helped overcome challenges?
- did it fall short anywhere, or need customization?