Example 3: Requirements tracking

 
Our client was the Australian division of a large international software-development company, which specialised in custom software for a highly technical vertical market. Software maintenance was a major issue, as their market required high-performance software which could be quickly adapted for new technology as it became available. After one of their clients threatened legal action following an acrimonious dispute over documentation and management of changing software-requirements, we were asked to assess and report on the company's documentation procedures and requirements-tracking.

Requirements-tracking is a problem for every software house, but this was one of the worst examples we'd seen. What we found, beneath the surface appaearance of a highly productive development environment, was a classic example of the chaos and confusion caused by poor management and repeated 'restructuring'. Some procedures and support-tools did exist: but they were inadequate, incomplete and out of date, and few staff used them properly, or even knew that they existed. In the rush to get completed code out through the door, the developers assumed that documentation and requirements-tracking was someone else's job; project-managers struggled to keep track of sometimes bewildering changes in client-requirements on home-made spread-sheets and a woefully inadequate database. The company depended heavily on contract developers, but no-one thought to give them essential training in the company's procedures; and network access-control was so poorly defined and managed that one developer accidentally deleted an entire project on the morning of its required delivery, thinking that it was part of a private work-directory. So it went on...

It was clear that urgent action was required, at every level of the company. We prepared a formal presentation, and held a meeting for all development and project-management staff, describing the problems we'd identified, and explaining our recommendations (see the edited PowerPoint file 'PPT file: doc_mgmt.pptdoc_mgmt.ppt'). There were some long faces amongst the managers as the seriousness of the situation finally sunk in.

Yet despite a few desultory actions, such as a half-hearted attempt to update some of the document templates, nothing really changed: no resources were provided, no support - or even interest - was forthcoming from the company's senior management overseas, and it became clear that the problem was being firmly shoved back into the 'too hard' basket. The company's decline continued: within six months, it had lost several more of its senior developers, two of its four project-managers, its quality-manager, its human-resources manager and both its technical writers - all of them citing demoralisation as a key reason for their departure. When last we heard, one of the company's clients had finally lost patience, and was no longer threatening, but taking, legal action.

In effect, all our efforts to warn the company of the probable consequences of their situation, and to provide practical solutions, had simply been ignored. The results had indeed been disastrous, not for us, but for our client. And that hurt: not just our pride, but more the hope - or illusion - that we'd actually been able to help. But the reality is that all we can do is observe, and advise: what happens after that is, and can only be, up to the client themselves.