All too often, quality is measured by the amount of bugs or errors found by the client when you release their project to them for acceptance testing — if it’s relatively bug-free, and there’s no typos, then you’ve delivered a high quality product, right?
Not quite. That’s simply quality of the product from the point of view of development and copywriting standards; there are other areas where quality is just as — if not more — important when it comes to really defining good from bad.
In our experience, there are four main types of ‘quality’ within a typical project:
- Has the product been delivered to a high standard?
- Has the product been delivered efficiently?
- Does the product match the agreed deliverables, in terms of scope?
- Does the product deliver against agreed objectives or KPIs?
The first point is largely down to the quality of your internal development and management processes — if you’re doing things properly, using people who are trained and knowledgeable in the work they’re expected to do, then you’ll find it relatively easy to deliver a quality product — all you’ll need to be worried about what we call the “can’t see the wood for the trees” problem, where your teams will miss some bugs or problems simply because of their prolonged exposure to a project having naturally formed blindspots and preconceptions of how things should work or look.
The other three points are a little more difficult to manage, as they’re very much a part of your journey through your delivery process rather than a hard asset that you can measure. Indeed, the documents and agreements you create within your project can only often only be tested when they are themselves used to measure other elements of the project — a functional specification is used to test the adherence to agreed site operation and scope, but this is dependent on the website being finished and ready for testing.
They are also difficult to measure for quality as many projects will tick along just fine, all the way through to launch, without any problems — when the client and project teams are on the same page, and what’s required is well known by all, incomplete or ambiguous documentation will go unnoticed simply because there are no problems or disagreements that require they such documents are referenced. Spotting problems with your documentation and agreed scope will generally only happen way down the line, when things are already on the wrong foot and you’re looking to firm up your position. That is, obviously, too late.
It’s therefore important that you assess your projects for quality right through the delivery process, constantly reviewing what you have to ensure that it’s robust, accurate and mutually understood and accepted by all. A quality set of project documents, agreements and plans will ensure that when it comes to assuring the quality of your final product, you’ve not only got a solid set of tools to measure with, but you’ve also got the confidence that you set yourself up with the very best chance of delivering a high quality product in the first place.