 |
|
 |
|
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
Purchase: |
|
 |
|
 |
|
|
Though I have spent the great majority of my IT career as and a "methodologist," several of my assignments in the past two or three years have been of a very specialized nature: working as an "expert witness" on computer-related lawsuits. And for reasons I'll explain shortly, this has given me an appreciation for the advice and guidelines in Andy Carmichael and Dan Haywood's new book, Better Software Faster, and a strong desire that every IT project manager should read it carefully. Most of my assignments follow a similar pattern: an ambitious business organization decides that it needs an innovative new information system; it then contracts with an aggressive software development firm to build the system. At the beginning, the atmosphere is one of enthusiasm and optimism; the customer promises to devote resources and energy throughout the project, the vendor promises to provide high-quality, "professional" services, and both parties pledge to work in a "partnership" mode. A contract is generated and duly signed, though inevitably it turns out that the attorneys for at least one of the parties have never seen it; indeed, one often wonders whether anyone other than the vendor's marketing representative has actually read the document. After a period that ranges from a few months to a couple years, things begin to turn sour. Deadlines come and go; budgets are exceeded; amendments to the contract are hurriedly negotiated and signed; and the mood gradually turns grim and hostile. Sooner or later, one of the parties abandons all hope, and terminates the contract; in most cases, it's the client who pulls the plug, complaining that the project has taken twice as long as initially promised, and has cost twice as much as originally budgeted. And to add insult to injury, the system either doesn't work at all, or is full of bugs, or runs so slowly that only 3 users can access it concurrently, instead of the 300 that had been promised. At that point, both parties bring in their respective lawyers. Notwithstanding all of the cynical jokes you've heard about lawyers, most of them are simply trying to clean up a mess that was created by naïve business managers who let things get out of hand. But because the mess involves the mysterious technology of computers and software, "experts" like me are brought in to advise the lawyers, the judge and the jury. All of them want credible answers to some very basic questions: whose fault was it that the project failed? How did it happen? When should it have been evident that the project was in trouble? Why didn't someone, on either one side or the other, do something about it? If you don't think such things can happen in the "real world," let me assure you that they do; indeed, the cost of litigation now exceeds the cost of coding for most large software development organizations. Only a small percentage of such failures actually result in lawsuits; a much greater percentage of the failures result in both parties walking away from the mess, swearing never to speak to one another again. And an even larger percentage of such failures are completely "invisible," because they involve a business department and an IT department within the same organization. Companies don't sue themselves, but IT project failures result in ruined careers, missed business opportunities, and staggering financial losses. If you've never seen such a disaster unfold, just turn to the first chapter of Better Software Faster; the example may be fictionalized, but it's typical of what is happening in thousands of business organizations day in, and day out. The amazing thing is that Carmichael and Haywood summarize the strategy for avoiding such disasters within the first two pages of the book: "By discovering what the business imperatives are, the team can deliver enhancements to the current capabilities within the specified period while also preparing for longer term requirements. If the team follows this route, it will need a flexible and lightweight development process with rapid feedback loops to report holdups and roadblocks—and it will need to plan contingencies accordingly." If it's as simple and obvious as that, why doesn't everyone do it? And, having glimpsed the "secret" for avoiding project disasters, why do you need to bother reading past page 2 of Better Software Faster? The answer to both questions, unfortunately, is that the devil is in the details. There are still some obstinate and/or stubborn business managers who insist on getting all of the functionality for their IT system in one fell swoop, delivered for an unrealistic amount of money on an outrageously optimistic schedule. But any IT project team with an aggregate IQ exceeding two digits already understands the concept espoused by Carmichael and Haywood right at the beginning of their book: "…there will need to be many deliveries of the software, each adding incrementally to the desired functionality. The development team’s question to the business team is not so much “Which of these requirements do you not want delivered?” but “Which ones will contribute most to the business now, and therefore, which ones should be delivered first?" The concept may be familiar and obvious, but it's the details that distinguish the winners from the losers in the IT project game; and it's the details you'll find in this excellent book by two veterans who have succeeded often enough that they truly deserve to be called "winners." One of the "details" that remains controversial, and that requires careful, detailed explanation involves the software "process" associated with the familiar activities of analysis, design, implementation and testing. For at least a decade, IT project teams have rejected the ponderous bureaucracy of the "heavy" processes that were first created in the 1970s and 1980s*; unfortunately, they have often replaced it with anarchy -- no process at all. Carmichael and Haywood describe, in detail, a happy medium: just enough process, with just enough formality, and just enough documentation. One way of accomplishing this efficiently and productively is to use an automated development environment -- but one that far exceeds the kind of "programming environment" that most developers associate with languages such as Visual Basic, C++, or Java. The authors are predisposed to using the development environment from Togethersoft, which creates object-oriented analysis/design models, and keeps them continuously synchronized with the code in Java or C++. As someone who has no business relationship or involvement with Togethersoft, I can confirm that it is indeed an elegant choice; but readers should also be aware that other choices are possible. The main thing that IT project teams need to realize is that a modest investment of time and energy in "light" processes for analysis and design does not slow the project down, but actually speeds it up. It's easy to say such things in the abstract; but as noted earlier, the devil is in the details. And the only way to see those details, and to be persuaded that a combination of light processes and advanced systems development tools really can prevent the project disasters that keep lawyers and juries busy, is to see a detailed example. Much of the content of Better Software Faster is devoted to a detailed case study; in addition to what's in the book, the authors provide additional material that you can download from their web site. Even with an excellent book like Better Software Faster, one can't help wondering if it really will improve the situation in today's IT industry. If only one systems analyst on the project team reads the book, he or she might be overwhelmed by the other project team members, and/or the end-users or project stakeholders -- many of whom are convinced that brute-force coding, starting on the first day of the project, is the only way to succeed. If only one person can read the book, it should be the project leader; even better results can be expected if both the project leader and the responsible customer/ user representative read it before the project begins, and reach a consensus on the contents. Ideally, everyone on the project team should read it, so that they have a shared mental model (which, as you'll see from the book, is a colored mental model) of the system they are developing, and their strategy for building it. In the best of all worlds, every IT professional and every business person who wants an IT system would read Better Software Faster. Then there would be no more lawsuits; lawyers would have to get an honest job, and I could go back to helping people build systems, rather than helping to assign blame and explain why the disaster occurred. Meanwhile, Carmichael and Haywood would grow rich and famous as they watched their book zoom to the top of the New York Times bestseller list, and could dream about Pulitzer Prizes and perhaps even a Hollywood rendition with famous actors and actresses. I'll help get the process started by buying a copy of Better Software Faster for my own bookshelf, and a couple more copies for some project manager friends and clients. How about you? Ed Yourdon |
