Where quality suffers in digital projects

There are several areas where a lack of quality assurance can really impact your projects. When we’re working with clients to offer quality assurance on their projects, we tend to look from three angles:

  1. Do we have a quality problem caused by lack of knowledge or expertise?
  2. Do we have a quality problem caused by preconception?
  3. Do we have a quality problem caused by lack of quality or agreement?

Of the three points above, point one is the most serious — this is typically where you’ve ended up delivering a product, or got a certain amount of the way through development, without really understanding what it is you’re supposed to be delivering. Occasionally, you’ll have put the wrong people on the job. Almost always, you’ll have been rushing and are already past the expected deadline for delivery.

You’ll have a product full of bugs and errors, and you’ll be frantically dashing about trying to fix them (and in the process, making them worse). You’ll be responding adhoc to client bug reports, likely creating new problems as you fix the old ones. If you’re not careful, this will go on for months, and cost you lots of time, money and all of your client’s patience and trust.

Even when you’re already in that mess, quality assurance testing can still help you out — what really hurts in these situations, and makes you fly into a blind panic, is the constant reactions to client demands once you’ve put a damaged product in their hands. By assessing your product before your clients see it, you can identify any problems and either remedy them, or make the call to re-do some (or all!) of the project if things are sufficiently bad.

As much as it may sound painful now to have to re-do any part of a project, you can be 100% assured that it will cost you far more in lost time and revenue to try to fix it piecemeal once you’ve handed it over to your clients and they come back to you with a moody face on.

Point two — the problem of preconception — is usually much easier to deal with, as it typically covers off smaller errors or bugs that an otherwise well-briefed and competent team simply overlooked because of their prolonged exposure to the project. Sometimes, you’ll find that what’s been overlooked is significant, but it’s rarely fundamentally broken, and can be easily remedied. All you need to remedy this is a competent group of people who don’t work on the project day-to-day, allowing them to subjectively review what you’re creating and give honest, solid feedback.

The last one basically deals with your documentation and agreements. If they’re vague or incomplete, then you don’t really stand much of a chance of confidently delivering the right product, first time — ambiguity or lack of detail will mean that your developers are guessing as to the expected approach. They might get it right, but they might get it wrong…so it’s good to know that you’re covering all bases with by quality checking your assets on a regular basis. Ultimately, even the most competent team will get things wrong if you’re not giving them a solid briefing and agreed scope, so make sure you’re working hard to confirm everything and capture all the detail you need to deliver a high quality product.