Test & Learn

Make sure you are building the right it before you build it right.   - Alberto Savoia

There are many ways to test that the solution you and your team plan to put in place meets customer needs, stakeholder expectations, and project objectives set out in the project charter.

You can test an IT solution to make sure the tools functions as expected, pulls the right data, works at an appropriate speed, and is acceptable from a usability perspective.

You can test a process by conducting a “dry run” – where you go through the entire process flow from start to finish and note down issues that arise, upstream or downstream impacts that were not considered, or whether it meets service level agreements agreed to ahead of time.

In many cases, running a pilot – where you choose a subset of the population to test the solution for a given period of time – makes sense for your project. During the pilot, you would measure performance, work out any kinks, and solidify your change management plan based on feedback from the pilot. Then you would have a go/no-go decision with your project sponsor or steering committee to confirm whether you should move forward with a full rollout.

These testing examples assume that the project team has done a lot of work to develop an IT or process solution, prepped materials for a pilot, trained the individuals involved, and likely invested a lot of time and money in the project to date. While I do think this testing is incredibly important when you get to that stage of the project, there are some “quick and dirty” tests that teams can perform toward the beginning of your project to learn if the idea is even a good one in the first place.

 Image courtesy of http://www.pretotyping.org/

Image courtesy of http://www.pretotyping.org/

I had the opportunity to go out to California last year and learn about a concept called pretotyping, coined by Alberto Savoia of Google and Stanford University. Pretotyping is defined on the website as “a way to test a product idea quickly and inexpensively by creating extremely simplified versions of that product to help validate the premise that ‘If we build it, they will use it.’” You test initial interest, repeat interest, usability, functionality, and practicality of an idea. And if it does not pass these simple tests, you scrap the idea and move on to something else.

Think about all of the time and money you can save by having this kind of test and learn mindset, with the goal of gathering as much usable information as possible and failing fast if it turns out the idea is a bust. I think this topic is fascinating and likely underutilized in much of the business world.

A project I am currently working on has put forth a minimum viable product to test a concept in one store. The goal is to gather feedback from employees on how it feels to use the tool with clients, whether it is displaying the information they need to perform the tasks asked of them, and what else they would need to make their jobs even easier.

It is NOT pretotying – we have done too much work on the tool for it to be considered a pretotype. But it reminded me of that concept because we did not spend a ton of time and money developing the perfect tool. It was actually developed over a weekend in what we are calling a "scrappy" fashion! And now we get to gather data that will feed into the eventual development of a tool – which we will test from an IT and process perspective, and also pilot with a subset of the population. And if we hear feedback that the tool is not really helping our employees, we will really need to challenge ourselves as to whether we pursue it any further.

So whatever it is you are working on, think about ways to gather some actionable information before you invest too much time and money into developing a solution. You want to make sure you "build the right it" as pretotyping says, "before you build it right."