How Software Projects Go Wrong
There is a high visibility and aural version of this page
(to listen, you will require an aural browser or screen reader).
The Need for Change
One way we can improve the Quality Management System is by learning from those occasions when it goes wrong. No system is ever completely problem-free, unless - perhaps - it is obsolete. But we want to avoid such problems so far as possible; they cost money, waste time and incur risk.
This is an opportunity to gain an advantage over the competition. Over-optimism, crises, timescale slips, poor field performance and customer disappointment are endemic in the software industry. Brooks wrote about the "Tar Pit" [3] in 1975; high profile I.T. based projects still go wrong; and there is a perception that "Not all computing projects fail - only most of them" [5], [16].
The following notes* illustrate a few of the problems that can occur in software projects. Some of them may be familiar, or suggest things that have occurred in your experience. If not, then either you are very lucky, or you already have an excellent Quality System!
Some Software Quality Problems
Late Delivery
Projects may run late for many reasons. The initial estimates may have been too low. There may be a lack of suitable resources. The original feature list may have been too ambitious.
One of the most common reasons is feature creep.
Example: During a large, complex software project, the customer asks for many extra features. The company agrees to all of them. By the time the project is a year behind schedule, both company and customer are worried.
This is bad for everyone. The customer might have preferred the product on time, without the enhancements, had the impact been made clear. The company is out of pocket, as it most likely cannot charge extra for the work.
A good Quality System would have controlled these changes. This does not mean it would prevent or inhibit change. But it would ensure that the full impact was understood and allowed for. One way of doing this is through Rapid Application Development [18].
Keeping the Customers in the Dark
Customers expect to be told what is going on. This is most important in times of crisis. But companies too often neglect it.
Example: A web hosting company suffers a major system crash. Staff work round the clock to reconstruct customers' data. Customers keep ringing up to ask "what's going on?", "when's it going to be back up?" and "why did this happen?" The company's staff get fed up, and either stop answering the phone or give very offhand and unhelpful replies.
The customers' concerns are reasonable and have to be met. But the staff's reluctance to be distracted from the job in hand is also easy to understand. The problem is that no-one has thought to provide a better method of keeping customers informed. Such planning should be part of the Quality System.
What software is this?
Mix-ups over which version of a software item is which, what an item's status is, or which items go with which others, are common. The results can be embarrassing or worse.
Example: After a company issues a new product version, an old fault reappears. It was fixed in the previous version, but the fix was not included in the official copy of the master source.
To prevent this sort of error, you need Configuration Management [1]. This should be part of the software Quality System.
Let Down by Others
If the company's products or services fall short, the company takes the blame - even when it may seem to be someone else's fault.
Example: The customer holds the company to blame for late delivery of a product. This occurred because a supplier, to whom the company had sub-contracted some specialist work, went out of business.
It does not matter if the problems are the fault of a supplier, sub-contractor, partner or even the customer. The company made the arrangements and has to make sure that they work.
To do this, you need to identify, analyse and control dependencies and risks. This is an essential part of project planning and control. You also need reviews to check that the plans were realistic and the control effective. All this should be part of your Quality System.
The Product that Should Not have been Released
There is always pressure to get products out of the door, so as to earn revenue and free staff for other work; but shipping them too soon can have quite the opposite effect.
Example: A product is released, although it is still very unstable. The result is a deluge of customer complaints. Engineers are sent on site to try to fix the problems, so work on other developments stops. This sets back potential revenue, which adds to the financial shortfall caused by the support costs. And what happens when those other products are due for release, but aren't ready - will they be sent out in an unfinished state, too?
Clearly, this product should not have been released when it still needed so much more work, however strong the pressure. But we need to look deeper. Were early signs of trouble overlooked? Was the true scale of the project ever really understood? Why did the problems not come to light?
Part of the solution is better project planning and control. This is the job of line management. But some of the issues to be faced may be quite hard. You need a Quality System, and an independent Quality Manager, to make sure they get attention.
Savings Through Quality Management
The Cost of Poor Quality
Problems such as these cost money. How much time and effort are spent on testing software, correcting faults, re-testing and so on [2]? This work need only be done because the software contains faults. In other words it is time, effort and money wasted.
In the long term, they may even threaten the security of the company. For a large software company, failure of a major project can have a severe impact. For a small company, it could be fatal.
How Quality Management Helps
We have seen how elements of a Quality Management System can help with each of these problems.
But the essential thing about a Quality System is that it is a system. Only by having such a system do you ensure that what is needed actually gets done. The quality company does things by design, rather than forever being driven by accidents or crises. There is a culture of conscious decision-making based on facts.
Better Quality means fewer faults. This will save rework, support and maintenance - and so reduce costs. As Crosby says, "Quality is Free" [6].
Problems