This post is a continuation of Keys to Project Success - Part 5
Build in Quality from the Start
“The problem with quick and dirty, as some people have said, is that dirty remains long after quick has been forgotten.” Many times in my career I’ve inherited systems where this quote is so applicable. There are always various reasons: “They needed a solution really fast so we just banged it out,” or, “It was only supposed to be a temporary solution,” and so on. The thing is, once the solution is in place, it tends to stay in place, and if it isn’t done with quality in mind, then the future cost of maintenance and enhancement will be substantial, and much more than what it should have been if quality was built in from the start.
The same principle applies on the initial project as well, which is the focus of this series. Taking a holistic quality approach to the project will result in catching errors earlier, with the result of reducing overall cost of the project, and increasing the satisfaction of not only the customer (be it an internal customer or an external one), but of the project team too.
OK, so that all sounds good, but how do you do it? How do you build in quality from the start? I like to do the following:
- Follow all the other guidelines in this series. Each aspect of a well-run project actually contributes to the quality of the end product. For example, if you haven’t planned the project well, and you wind up spending all your time fighting scheduling fires, dealing with resource problems, and having to manage budget overruns, how much of your focus do you think will be on the quality of the end product?
- Create quality-oriented processes for the team to follow from the start of the project. For example, one process that I build into all my projects is peer-reviews of all work products. That includes requirements documents, design documents, code, and even test cases. The idea here it to catch mistakes as soon as possible after they are made, and not waiting until finally testing the overall end product to discover it doesn’t work the way it was supposed to work. At that point, repair is extremely expensive! Other practices and disciplines that should be part of your overall process include:
- Requirements tracing. Often referred to as “requirements tracability”, this is actively ensuring that every requirement can be traced forward to functionality and the test cases that will ensure it works properly, and that each work product (code, piece of hardware, test case, etc.) can be traced back to a bone fide need articulated in the customer’s requirements.
- Test-based design. Ensure that anything that is to be implemented (code, hardware components, etc.) can be tested as part of the process of designing the component.
- Rigorous modelling. Be it data or process, timing or load, a clear, rigorous model is critical to ensuring that the end product will deliver the required service.
- Track defects. Defects can occur right from requirements all the way through to a test case that doesn’t really test the functionality in question. All defects should be tracked through to resolution, with an eye to spotting systemic problems in the process. For more on this see Software Quality Metrics — What to Measure When for Competitive Advantage | Part 1.
- Source code control, configuration management, and release management will all have an impact on the quality of the product, and so these should be part of your quality assurance plan as well.
- Have a quality assurance plan. Write down everything you’re going to do throughout the project, ensure your team knows what the accountabilities are, and then follow that plan.
- Per an earlier post, divide and conquer and deliver functionality incrementally throughout to your end customer, so they can validate that it is indeed what they need.
- And of course, that means you must involve your end customer throughout the project. They need to review and agree with key work products, such as the way a prototype works. To deliver the final product only to have the customer say, “That’s not what we asked for!” is clearly project failure, so get them involved all along the journey.
- Finally, testing is still an important element of ensuring quality, but to be sure, testing does not ‘build in’ quality. It only confirms whether or not that quality is there. Relying on testing to ensure fitness for use alone is akin to putting together an airplane without any inspection of the rivets as they’re done, and hoping you don’t fall out of the sky on the first test flight. No one would do that!
 Software Project Survival Guide, Steve McConnel, Microsoft Press, 1998.