Software projects are almost always late and underdone. Most executives take it for granted nowadays that developers will turn in something other than what was requested for more than was announced. They even admit that this is one of the biggest reasons that they outsource, because the contracts with outsourcers force the organization to develop software in a rational way. IT Cortex’s listing of IT project failure rates from a variety of sources is sobering. Sure, one would expect more software projects to fail than building projects (which do fail at an alarmingly high rate) because the ante for software is so much smaller. Regardless, we should worry about our almost perfect record of not performing.
There have been some admirable attempts to bring order to this chaos. The Software Engineering Institute (SEI) developed the Capability Maturity Model (CMM) for Software, which provides a model of how development organizations mature from chaos to continuous process improvement. Developers in the trenches almost uniformly razz the CMM as being restrictive and limiting creativity, unless they happen to work in a CMM Level 3 or above group. Unfortunately, maturity of high levels has been adopted almost entirely by governmental and Indian “off-shore” companies. XP techniques came about as a reaction, allowing programmers to “wing-it” in bi-weekly releases and continuous builds.
As much as the cowboy programmer would like to disagree, large software development houses require some form of structure and process to succeed. Hiring practices must become routinized so that a variety of skill levels can staff the project. Handoffs between teams must be predictable. Testing and quality must be attended to, even in the face of deadline pressures. Companies want to create projects that will succeed. Most software project management texts either treat software as the same as building a skyscraper or demand the PM follow a very rigid methodology. A few texts have reasonably dealt with the failure issue in surprisingly common ways.
Quality Software Project Management comes out of the University of Texas’s Software Quality Institute. The book is massive, weighing in with 1335 pages of text, with another 200 pages of appendices. Unlike many texts on project management, Quality starts not with the project lifecycle but software product lifecycles. Most developers think only of completing the product and getting it out the door. Managers have to consider the entire lifecycle of the product, from conception to retirement. This emphasis places the material outside the abilities of many project managers. Futrell, Shafer & Shafer have created a compelling case study that tracks through the book, making it ideal for their own courses at the SQI.
I have used many parts of this book in my work since it came out. Their Risk Management table has found many uses and is worth the price of the book. Like much of their tools they advocate, it reduces user error and increases output value. Instead of trying to think of probabilities for potential events, project staff simply choose which of three states best fit their project at this point in time. This gives the PM a starting point for discussing risks with the staff that eliminates a lot of the moaning and CYA that passes for risk management on software projects. This tool helped turn around an entire Fortune 500’s risk management process.
Yet, at 1335 pages, Quality is not for the faint of heart or the easily wearied. Futrell et al. identified 34 competencies for software project management and each is covered in the book in detail.
Scott E. Donaldson’s and Stanley G. Siegel’s Successful Software Development (2nd Edition) takes a similarly complex stance to project management. Donaldson and Siegel push their Object Measurement methodology but it is interesting, potentially useful and not distracting. Successful Software Development includes more details about potential project structures, including creating the necessary supporting roles and processes. Highly readable and thoughtfully put together, it still requires a manager to be able to both read it and understand the broad implications of setting up various processes and organizational structures within a development group.
Donaldson and Siegel spend the bullk of the book on the aspects of development that most developers give short shrift. They cover software development methodologies quickly, moving on to aspects common to any project regardless of methodology. They dedicate long chapters to change control (including the change control board and how it works); product and process reviews; measurement; and project planning. They even include in-depth chapters on cultural change and planning for process improvement. The authors obviously think that software development should be managed and managed in a predictable, high-level way.
In How to Run Successful Projects III: The Silver Bullet (3rd Edition), Fergus O’Connell makes a bold claim to have found Fred Brooks’s silver bullet for solving software developments problems. In an essay published in 1986, Fred Brooks — author of the seminal The Mythical Man Month — said that nothing had been found to greatly speed up development. There was no “silver bullet” that would increase software predictability. It was an inherently risky endeavour.
O’Connell disagrees. He believes the no one ever found the “silver bullet” because they looked in the wrong place. What if, he asks, the solution lay not in the future but in the past? He argues that project management is the silver bullet and that proper management of our software development will make predictable projects possible. His book provides a cook-book solution of ten steps, with a metric to see how likely completion of a project is at any point in the process. Some of his ideas (e.g., Know what you want to do before you start and There can be only one leader) are logical and straightforward, although little practiced. Somehow software developers believe that they can all get together and produce product, like the monkeys at typewriters trying to produce Hamlet, with comparable chances of success.
Building Effective Project Teams takes an entirely different tack to software projects. Wysocki says that the key is in the temperments of your teammembers. He uses organizational and group psychology to create a balanced project team that can face many different threats because the various members have such a broad range of psychological skills. He argues for testing project manager capability through a methodology that he has developed and of course sells. One is left wonderin whether this is simply a long sales tract. I am also not very convinced of the need to balance one’s team psychologically instead of organizationally. But the emphasis on knowing the PM’s ability and potential is solid advice.
Interestingly, all these books support the Elliott Jaques’s Stratified Systems Theory. I think the late Jaques would say that the right project manager for any particular project is one whose own mental complexity matches the time span of the project. These books, with the complex ideas and large texts, self-select only the more complex thinking project managers. Those with lower time horizons would not be able to comprehend the material, or even see the need to bother with it. While these books are certainly all good (with the reservations about Wysocki’s Building Effective Project Teams) and provide important tools for development managers to consider. Organizing Requisitely would provide many of these processes without having to fight as hard.
Image Credit: Space Shuttle Columbia launching (STS-1. 1981). NASA.