Conducting Successful UAT as a team- Bridging the Last Mile in your project

Jason Sindel Jason Sindel
November 12, 2012
User Experience Design , Web Development , Web Strategy

In the Telecommunications industry, there's a saying, "the last mile is the longest mile." It is used to denote the so-called Information "bottleneck" when data traveling over high-speed fiber for example hits the bandwidth limitations on the last link of the journey before reaching the customer. The phrase is evocative and from its original connotation in the world of bits and bytes and fiber and copper it is now used to describe a phenomena that can affect any human endeavor, from bridge building to film making to website design and development.

In the world of web development, the "Last Mile" problem can be summed up succinctly as the final steps required before a project is considered complete by both the client and the vendor and the terminal resistance that often occurs, for whatever reason, and stretches the timeline, the budget and the patience of everyone involved; even more so, since the end is often clearly in sight, but the means to get there feel thwarted.

In a popular TED Talk by social scientist Sendhil Mullainathan the "Last Mile" was applied to healthcare and the world's health problems. In that presentation the idea was captured perfectly by an unfinished bridge—a stark image of startling futility.

Why does the "Last Mile" problem occur?

The problem has been studied by social scientists and engineers for a long time and the truth is that there isn't a firm consensus on why it happens, but there are a lot of theories. Here are a few I've identified to give you an idea:

  • The Shifting Sands Theory:The longer something takes the more likely it is that conditions that affect a project's dependencies will change therefore making a project take longer, creating a cycle of terminal resistance.
  • The Feedback Loop:The more you build, the more there is to want to change.
  • Runner's Fatigue: The journey took so much out of your team, there's not that much left.
  • Jenga's Revenge: We often save the toughest thing for last, so there's more risk at the end.
  • Integration Conflagration: We tend to build things in a controlled environment, so in the real world (in production), things behave differently and tend to blow up.
  • Field of Dreams: We built it but we don't know how to use it.

The antidote to what's ailing you…UAT

UAT or User Acceptance Testing can be the tool that drives the final screw. At Roundedcube, It's the final part of a well designed process (unless you want to count warranty and support). And for many organizations and their projects, it's often the least discussed and most misunderstood phase of a project. But without it a project won't end well for the simple reason that no one will know when or how to say that something is definitively done.

How to UAT in Six Easy Steps:

1. Roles and responsibilities:
Name the users and define their responsibility., i.e. Dale from accounting is the User Acceptance Tester for the reporting tool, Mike from customer service signs off on the forms, and Lisa is the developer that benchmarks and tests for site performance. For every part of the site that requires functionality or design, there is a team member on the client side that must bless the work. Ideally stakeholders should be part of the Scope and Requirements process before they are asked to give final approval; otherwise you risk a fundamental disagreement around the scope.

2. Define expectations:
Demonstrate the proper way to evaluate and approve the product. This isn't functional testing in which something works or it doesn't, it's the seal of approval that says a product has been inspected and meets stakeholder requirements. Acceptance isn't another round of feedback; it's a check box that needs to be checked.

3. Define what is ambiguous:
The truth is, if there isn't a requirement defined, there can really be no User Acceptance Testing, so acceptance requires definition.

4. Plan:
Make it part of the project plan, put each component or section in a list and work your way down. Don't skip anything, but review them one by one as a team.

5. Report:
Publish the list with check marks and meeting notes. This is the final approval so everyone that needs a say gets a say.

6. Discuss the Results:
For anything that isn't approved, work quickly to define the problem, identify the original requirement and propose a solution if there's a new requirement. At this point, there may need to be compromise if an area of scope was left without definition, but where there's a will there is always an alternate way.

At Roundedcube, we are constantly reviewing and improving process. Much of that process requires a team approach with the client, so it isn't something that can be imposed from above. Successful UAT isn't just a checklist; it's a methodology for achieving consensus and mutual satisfaction. For our projects, UAT begins with detailed scope and requirements, starts in earnest after client training, continues with developer and content manager support, and ends with a collective agreement that requirements have been met and the product is ready for the end users. All of these key components come into play, so if there's a gap, your UAT will suffer and the project will be at risk. Stay tuned for more posts on projects and process, design and development and feel free to contact me directly if you have any questions regarding our process at Roundedcube.

comments powered by Disqus