Smooth Acceptance

How to Prepare a Smooth Project Acceptance

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

Some software developers repeatedly have problems with user acceptance. For some teams, that is how things are “supposed” to be, so they don’t even give it a second thought.

  Acceptance problems are like self-fulfilling prophecy. That’s why always the same teams are affected.

In my experience, these types of teams usually facilitate user acceptance in a way that inevitably causes some friction, which only strengthens their belief that nothing can be done, so they do the same thing for their next project.

Those developers usually choose a strategy that is flawed from the start.

Flaw #1: Requiring That Your Customer Believe You

When a team finishes their software, they invite users to come and give a presentation of the system’s screens. Then, they click their way through several scenarios and show that everything works as designed.

  Requiring that your customers “believe” you puts them in an awkward position.

This approach puts your customer in a slightly awkward position, as they have to trust you at your word. Whether they are inclined to do that or not, this form of user acceptance is challenging for both sides.

Flaw #2: Customer Provides Functional Testing

Software developers sometimes let the customer provide functional testing, which then doubles as acceptance testing.

At first glance, this sounds reasonable, but in real life it often leads to a nightmare. You never want your deadlines or user acceptance to be dependent on something that’s out of your control.

Flaw #3: Drowning Your Customer in Details

Some teams go through the finished application and list its functionalities in detail, either with or without the requirement specifications in front of them. Then, they try to demonstrate for the customer that every detail works as expected.

 Details are secondary. What your customer wants to see is that end users’ main operation can be done flawlessly, from start to finish.

However, it’s difficult to properly prepare for each item on such a list, and it’s very easy for that sort of demonstration to get fragmented and chaotic.

Also, there is one other crucial point that this approach lacks: your customers mainly want to see that their end users’ main operation can be done flawlessly, from start to finish. Details come second.

The Outline of the Solution

When you present it as I have shown above, a big part of the solution should already be obvious.

Don’t require your customer to believe something or take it on faith; demonstrate each point so that they have tangible proof of functionality. Also, if you have everything scripted and documented, your customers will thank you, as that’s exactly the sort of “paper trail” they need for their bosses, as well as for any audits that may occur.

 Provide tangible proof for important points. Demonstrate complete end-user scenarios; also be sure to use real data.

Maintain control over acceptance testing by keeping it in your hands. Any functional testing that is done by the customers should not be taken as the main point of reference. Also, you need to be two steps ahead of the customer’s team to avoid simply being pushed aside.

Demonstrate complete end-user scenarios with real data and allow the details to be examined by a smaller group.

Don’t Leave Room for Any Doubt

When you agree with your customer in advance about how functionality can be conclusively demonstrated, then user acceptance can be a breeze.

In order to achieve this, start early in the project, when goodwill is abundant. Later on, it can be much harder, considering that a number of compromises have probably been made, and some project members may have doubts and reservations about some of them.

  Agree on concrete criteria far in advance. Later on, the only thing you need to do is to make it easy for the customer.

A good time to begin is whenever you have all the items in your spec identified and each of them detailed to a reasonable extent. Then, share this information and collaborate with your customer; for each item, write down how you can be 100% sure that it will work as intended. Customers usually love this, so you shouldn’t have any problem getting their cooperation if you approach the issue in this manner.

To avoid making major demands on your customers’ time, you can keep this document short for now. A single paragraph for each test will do. You and your customer should also agree on when and how you will do the testing. Write that information down and include this document in the project documentation. That’s your master test plan, and it will save you a great deal of effort later on.

Make Everything “Testable”

For product implementation to be easily tested and accepted, user requirements must be measurable. An additional benefit to making everything measurable is that such explicit metrics represent invaluable guidelines for your developers, and can heavily influence your architectural decisions.

Again, a simple paragraph can cover most of the important points. For example, you can start with a simple statement, such as “Response for all transactions must be under 0.5 seconds, under 3 seconds for predefined reports, and under 30 seconds for ad-hoc reports.”

  You can’t test what you can’t measure.

Sometimes, there are ambiguities that you must push to solve. For example, one of the project goals may be to shorten the time it takes to process the average customer. However, your users might refuse to say more than “We need this step to be as fast as possible”, mistakenly thinking that any other answer would result in you putting less effort into fixing that issue.

In such situations, you might need to take some measurements yourself. In a thirty-minute observation of the existing process, for example, you could determine that ten customers were processed. This averages to three minutes per customer. You can agree to reduce that time to two minutes and document it as a rather precise measuring stick for your implementation.

Other situations require complex calculations, with only the final result being displayed somewhere in your application. For this scenario, Martin Fowler’s writings (especially his “Refactoring book“) opened my eyes many years ago. Basically, who is stopping you from making all of the intermediate results available somewhere? If it’s web pages, for example, all the intermediate results could be listed in HTML comments in the pages provided by the application server. This way, you can test a much wider range of things on the spot.

Use Real-Life Data Sets

A very convincing way to demonstrate that your system works is to closely simulate the performance of the actual job it’s supposed to do.

To do this, you need to determine which of the relevant data sets you want to use for each user scenario. If you do it in a systematic fashion, you can make your life easier by designing these data sets so they can be applied for several situations. This way, you could end up with only a dozen data sets that can handle 90% of your tests.

Since you have to do it anyway, it is best to do this early on in the project. Then, you benefit from developers working from the start with data that’s both realistic and specifically chosen to cover all the scenarios. You definitely want to avoid developers testing their work with all the names and addresses typed in as “Aaa” and all the numbers as “123”.

  A very convincing way to demonstrate that your system works is to closely simulate the performance of the actual job it’s supposed to do.

For some situations, such as reports from a data warehouse, for example, you might need to determine which parts of the existing database to copy to put one or more test databases in place. This way, the testing data sets are fixed and all the results are repeatable.

For complex calculations, you might need to develop a method of performing each calculation in parallel in a spreadsheet. This way, your customers’ experts can help you debug the calculation itself much more easily. Also, by crosschecking each calculation’s results for as wide a range of data as you can feed it with, you can conclusively prove that the calculation results produced by your system are correct.

Performing the Acceptance Workshop

Acceptance is best done in a workshop, where you go through all the test cases one at a time.

Since you want your users to be conclusively convinced afterwards, you need to keep them focused throughout the whole process. This is why such workshops shouldn’t last too long, and they should be conducted in a relaxed manner, if possible.

You can’t avoid detailed explanations when your customers require them, but those are best if done beforehand. Otherwise, it could prolong your formal acceptance for hours, which would make people become indifferent – and you need them focused or they won’t be convinced afterwards.

Acceptance: Premise, Preparation, Delivery

In other words, make the acceptance a two-step affair. The first workshop is informal, is done together with the customer’s product owner, and it can (and should) be as detailed as your customer desires. This is also a good opportunity to uncover any final objections that your customer may have, as well as to agree on what will be done about those issues. For example, some issues will be dealt with before the second more “formal” acceptance workshop, and some others will be left as they are, while the rest should wait until after the rollout.

Think of this first workshop as a general rehearsal, so you can polish everything for the formal acceptance workshop.

 Hold two acceptance workshops; the first one should be in full detail, but just for the core team.

When the formal acceptance meeting comes, the product owner is already conclusively convinced, so this workshop should essentially be a formality. Its purpose is to comprehensively demonstrate to a wider audience that everything works. In this formal acceptance, you are also heavily supported by the customer’s own product owner, and this lends you a significant amount of additional credibility.

For this workshop, you will want to prepare a test results document, which is a simple list of all the test cases, with a pass/fail field and an optional comment for each. This way, even when a few test cases don’t pass and you can’t fix that in time, it won’t result in the complete failure of the acceptance. Because of the first workshop, the product owner is already aware of these issues and can confirm that they have been identified and are being dealt with.

By using the two-stage approach, you can afford to conclusively demonstrate to a wider audience that everything the customer paid for is working as expected. After this type of effective demonstration, it should be difficult for anyone to even consider you if they are looking for someone to blame.

The Complete Formula in Short

The above-mentioned formula has been repeatedly proven in the trenches, so let’s briefly summarize:

1. Start preparing acceptance early in the project, as a joint effort with the customer.

2. Don’t require your users to believe something; demonstrate each point instead. Demonstrate complete end-user scenarios with real data.

3. Hold two acceptance workshops; the first one should be in full detail, but just for the core team.

Basically, what you are doing is:

  • Earning trust by being transparent and professional right from the beginning.
  • Making it easy for product owners and their team to do the acceptance.

Sometimes, I’m truly amazed at how many people dismiss the simple psychology behind this, especially because it works flawlessly!


What now:

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

1 comment

  • Wendy

    I especially appreciate your point of “Make everything testable.” For smooth and effective project management, it is vital to create clear and measurable goals. Thanks!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>