Project Management Book

Chapter 12 - Quality Management

Which of these would be the better way to do a project:

• Do it right as quickly as possible
• Do it quickly as right as time allows

This represents a choice between two quite different approaches to projects. Setting out to do it quickly as right as time allows not only means there is a perfect excuse for not bothering too much about quality, it will probably mean the project will actually take longer: driving for quality tends to reduce project cost rather than increase it. Set out to do it right as quickly as that is possible - that should mean the project delivers better quality and gets done more quickly.

We trust you do not recognise any of these symptoms of poor quality in systems:

• errors in live running
• system crashes
• floods of improvement requests
• unhappy users
• overtime during testing
• mushiness

Mushiness? Go and look at a project and everything about it is mushy. Nothing seems to be firm, pinned down or disciplined. It can be an indication that quality, amongst other things, isn't being managed.

What causes errors in systems?

• continuously changing requirements
• no clear "manufacturing process", no-one is quite sure what should be done at each stage
• lack of testing
• no process for removing errors
• and many more

Even in some large projects there is no process in place for getting rid of errors as the project progresses and then everyone wonders why there are huge numbers left to be found at the end - surprise surprise.

And some project teams never ask the question: what causes us to make errors? If that question is never asked, error causes are unlikely to be addressed and the same problems are repeated over and over, but nobody realises.

When building anything complicated the errors probably won't be distributed evenly throughout it, they will tend to cluster together. If the project manager and the team have no idea where these clusters are, corrective action will not be focused where it is most needed.

So often people say they want to deliver good quality but in practice on the ground they are doing little or nothing to achieve it. As project managers we need to manage quality not just hope for it.

What is quality in the project context? Delivering what the customer/user asked for in terms of functionality, auditability, enhanceability, performance, etc and meeting the requirement to deliver on time and on budget. If the customer wants a bicycle we deliver a bicycle that works not a gold-plated Rolls-Royce. Adding unnecessary features is not adding quality it's wasting money.

If the customer wants a system with 1000 bugs in it and we deliver one with 1000 bugs in it we have met the customer's requirement - a quality job has been done. If the customer, by implication, wanted a system with few or no bugs and we deliver one with 1000 bugs we have failed. And that is usually what the customer wants - a system with few or zero bugs. Unless the customer states otherwise, this should be the target. Can we guarantee zero defects in software? On the contrary, we can be almost certain there will be some defects - we can almost guarantee we will fail to meet the zero defect target. This may sound odd, having a target we know we will fail to meet. We will resolve this apparent conflict later in this chapter.

Quality should not be something we hope for vaguely and we should not only measure it after delivery - that's rather too late. Quality should be something that has objective, even numerical, targets set at the outset of the project, a plan for achieving those targets and some way of knowing as we go along whether we are meeting those quality targets. Quality should be as planned, predicted and measured as any other aspect of the project - something we manage actively rather than hope for passively.

The chart shows two project cost profiles. One before getting the quality message, the other after seeing the light.

Getting the Quality Message

Before getting the quality message a relatively small amount of resource is spent getting the requirements roughly right but if we're honest not really correct or complete. The user functions design is sort of right but again not complete or correct and not fully understood or agreed by the users. Then during the build stage all the problems start to crawl out of the woodwork. And sometimes there is a huge panic peak in testing where a very large number of errors are tested out and the actual user requirements are tested in. And when the system goes live a flood of bugs to fix and enhancements to be made.

When people get the quality message they invest a lot more during the requirements step: rigorous, hothouse sessions to identify business processes fully and in detail and then time and money to check that the requirements are right. At the UFD stage it is very hard to over-invest in getting it right. Churning out good quality code from a thorough, complete and correct UFD document is relatively straightforward these days. And then no panic in testing and many fewer problems when the system goes live.

Looking at the chart, which will be the cheaper way of doing the project? The 'After' way, the quality way: what you invest up front in getting the requirements and design right you will almost certainly more than get back in build and test - and the real benefit comes when the system goes live.

Unfortunately the notion that going for quality will make the project cost less is not how it feels at the beginning: all people perceive is this 'enormous' cost of being meticulous and of checking, checking, checking. This cost is real and tangible and certain whereas the savings that will come in the build and test step are only potential. The easy option is not to fight to incur that upfront cost, and instead to fire-fight the 'inevitable' problems at the end of the project. Be strong, plan those upfront checks in - you may find nobody tells you to take them out: it's your own inhibitions you're fighting, not others' resistance.

When talking to business users and sponsors about quality, IT people have a tendency to say things like: "We should improve quality, we are getting far too many defects, far too many bugs, far too many crashes." And the users have no idea what you're talking about - they don't know what these words mean and so they aren't interested. How might we interest the sponsor in quality? Talk about money.

Some bugs found in live running are cheaply and easily fixed. Others can be very expensive indeed, not so much to IT to fix, but expensive for the business. There is a nice story of a UK bank that sent a letter one Christmas to its richest clients thanking them for being good customers and entrusting the bank with their money. The programmers, as programmers always do, made up silly names when testing the production of the letters and due to a slight oversight several thousand of the bank's best customers got a letter which began: "Dear Rich Bastard". Apparently some were highly flattered, but others were not at all amused and took their money elsewhere.

...next

Privacy Policy and Cookies