Whether you have been testing for years or you are just getting started, building a successful optimization program depends on careful planning, implementation, and measurement.
This is the first in a three-part series of articles that looks at the steps involved in creating a successful optimization program. In it, we'll look at three critical elements in optimization planning:
- Forming a great testing team
- Getting your stakeholders on board
- Writing a formal test plan
Forming a Great Testing Team
In Web analytics, one good analyst can provide great insights, but not so in testing. The testing process is typically too political and requires too many resources to be executed by just one person.
Consider what is often involved in making a change to a website:
- Someone decides that a change is warranted.
- Management needs to review the change request.
- If the changed is approved, management initiates the change management process.
- Depending on the change, developers, designers, marketers, and copywriters may be required.
- Information Technology needs to deploy the change.
- Quality Assurance needs to test the change.
- Analytics needs to validate the change.
Now, compare that to a situation where a testing program is already in place. Instead of someone deciding a change needs to be made, marketers regularly ask themselves, "What would happen if we changed X, Y, or Z, or even all of them?" And although the best testing solutions help to minimize the need for some of the resources required—most commonly developers and IT—there is still a need for a cohesive group to create and run tests and analyze their results.
Address that need by forming a testing team of appropriate resources within your organization, then give that team a mandate for making improvements and allow it to incrementally prove its value and earn the right to test increasingly large projects.
Assign your internal superstars to the team to couple their insights with technology and process to allow them to measurably demonstrate their brilliance. Give the team access to other internal resources, at least as long as they continue to produce results.
The two most important roles on your testing team are the project manager and the executive sponsor.
The project manager needs to be someone who combines incredible organizational skills with a shocking enthusiasm for change. That person's role is to ensure that defined testing processes are followed to the letter, thereby increasing the likelihood of successful tests. That person does not have to be a jack-of-all-trades, but he or she does have to know Jack (or Jill) to get the job done:
- The skills to produce a sound statistical design are not required, but the ability to understand basic statistical principles is.
- The skills to create brilliant design are not required, but the ability to think from the perspective of an end user is, because visitors do not interact with your site the way you think they do.
- The technical skills to write JavaScript, HTML, or ActionScript are not required, but the ability to keep all resources—technical or otherwise—on task and on time is.
- Seamlessly juggling people, process, and technology are the hallmarks of an effective project manager.
The role of the executive sponsor is obvious: Without an internal champion for change on the management team, most testing projects are dead in the water. Fortunately, a new class of digitally minded executives are actively signing up to manage testing projects. These soon-to-be "rock stars" clearly see the opportunity available and want their names associated with the financial gains that testing so commonly produces. They also recognize the value of using testing to prevent mistakes from happening, and they are just as happy to report saving the company millions as they are reporting incremental revenue.
Finally, make sure to socialize the testing team's efforts throughout the company. Doing so—essentially announcing to the world your commitment to optimization and demonstrating that commitment by assigning some of your most valuable resources—has a two-fold effect.
- It clarifies to other internal resources why their content is changing in a seemingly random way.
- It creates an expectation for the team to produce and gives them a platform to talk about their successes and failures.
Obviously, building and socializing a team requires senior management's support.
Getting Your Stakeholders on Board
Management's support for testing projects is absolutely critical. Having buy-in from members of the senior management team is a make-or-break condition of testing efforts.
Work with these stakeholders from the beginning—in concert with the executive sponsor—and directly solicit their feedback, suggestions, and ideas that can be tested by the newly formed testing team. You might consider establishing a "Multivariate Testing Steering Committee" made up of senior people who are helping to decide what will be tested, when, and how.
I recommend socializing the testing program with senior management early on. You will undoubtedly need their support to assemble the testing team and will often need budget, approval, or assistance getting testing technology deployed.
By approaching management with a clear plan for success, you are far more likely to gain their critical support and validation for your work.
Writing a (Formal) Testing Plan
Companies with highly successful testing and optimization programs have a very formal process for requesting and planning tests. Although some in our industry love to proclaim, "Test early, test often, test aggressively," the reality is that good testing can be quite involved and results are usually commensurate with effort. Absent a structured plan for testing, it is incredibly easy to end up with meaningless data, wasted time, and frustrated internal stakeholders.
Fortunately, developing a test plan is simple. Make sure yours answers the following questions:
- What is being tested?
- Why is it being tested?
- What are the expectations for the test?
- What are the measures of success for the test?
- What are the risks associated with running the test?
- What internal resources are required to run the test?
- Who is requesting the test?
- By when are results needed?
Individually, each of these questions is relatively easy to answer. Some are technical ("what risks are there" and "what resources are required"), some are theoretical ("what are the expectations"), and some are political ("who is requesting" and "by when are results needed?"). The best answers are not page-long explanations; rather, you want concise explanations designed to help the testing team best plan for the deployment of the test.
Most people initially get stuck answering questions three, four, and five. Measures of success, and risks associated with testing, are important enough issues that they merit their own best-practices. Expectations are tough, at least until you start to get the hang of testing, because it is impossible to know ahead of time whether a change will result in a substantial improvement, a small improvement, or a net decline.
Your testing team should plan to have a formal testing-planning document ready to go when you start to socialize the group with senior stakeholders. The presence of that document and a few examples of the kind of information you're looking for will go a long way toward demonstrating that you are serious about testing. Most senior executives have seen enough ad hoc exercises designed to drive incremental improvement during their tenure to appreciate the level of consideration a plan conveys, and they understand the likelihood of failure in the absence of a testing plan.
Most important, requiring a formal test-planning document from anyone in the organization wanting to make use of the testing team, including members of the testing team themselves, will allow the team to insert tests into a long-term schedule prioritized by opportunity, risk, and political considerations.
Though I don't recommend the creation of a timeline so structured that real opportunities will be lost—testing is frequently an opportunistic endeavor, especially when there is a high-level of awareness about testing efforts—having such a "road map" for testing projects dramatically improves each test's likelihood of being successfully executed.
Ultimately, the goal for requiring a formal test plan is to drive home an appropriate level of seriousness and rigor about testing in your organization.
Your successes will breed the desire to create more successes; but if any product manager who walks through the door can have his or her test jump the queue with little more than waving of the hands and saying "make the button more blue," then you are destined to struggle to get your testing program off the ground.
Conversely, if you provide clear guidance about what is required and how the requirements will be evaluated and slotted, at least in our experience, you will soon exceed your expectations and be well on your way to success!
(Readers seeking more information on optimization are invited download the SiteSpect whitepaper titled "Successful Web Site Testing Practices: Ten Best Practices for Building a World-Class Testing and Optimization Program.")
Articles in the series:
