Anti Patterns in Project Management

William Brown, Hays “Skip” McCormick, and Scott Thomas

John Wiley & Sons, 2000

A Book Review by

Glen B. Alleman

www.niwotridge.com

October 18, 2001

The cause of many project failures can be traced to the passivity of management and participants in the face of the forces attempting to undermine a project’s success. This characterization may seem too general, but this book lays the groundwork for understanding the repeated bad behaviors of projects and addressing their solutions.

The concept of repeated bad behavior – described as an antipattern – has been developed by the same authors in two previous books. Antipatterns: Refactoring Software. Architectures, and Projects in Crisis, Brown, Malveau, McCormick, and Mowbray and Antipatterns and Patterns in Software Configuration Management, Brown, McCormick, and Thomas are the predecessors of the current book. This is a useful background for the current book and sometimes redundant, since many of the antipatterns developed in the previous books are repeated in the current publication.

In general the current book is a valuable addition to a project managers bookshelf, even if the other two volumes are not of interest to the non-software development project manager.

What is a Pattern and an AntiPattern

The foundation for using and writing Patterns – and therefore antipatterns – began in the 1980s and continued to grow in the software community in the 1990s. Christopher Alexander conceived the phrase pattern language in his book A Pattern Language [1]. Alexander defines a pattern as a three part construct.

· Context – under what conditions does this pattern hold.

· System of forces – In many ways it is natural to think of this as the problem or goal.

· Solution – a configuration that balances the system of forces or solves the problems presented.

Patterns and Pattern Languages are ways to describe best practices, good designs, and capture experience in a way that allows others to reuse this experience. The software community adopted Alexander ideas with the publication of several books focused on patterns and their use in the development of software. [2]

Antipatterns are negative solutions that present more problems than they address.

Where have we come from?

It has become fashionable to criticize the project management approaches that are built around a structured project management model. These methods range from the familiar Waterfall method to methods described in the PMBOK. [3] It may seem to any modern project manager that attacking the dinosaur of too much structure is a waste of time. While the traditional requirements–design–code–test process has long been discredited as inappropriate for the development of modern software systems, waterfall is still the basis of many of rigid, top–down, front–loaded processes, and methodologies that are used in large organizations to this day.

One of the reasons large structured project management methods flourished a decade ago was the pace of change of the software requirements and therefore changes to the software itself occurred at a leisurely pace.

Today’s project managers are faced with not only rapidly changing requirements but also ill–defined and conflicting requirements along with time to market pressures unheard of even 5 years ago. This Internet time approach to product development and the associated project management activities have out stripped the abilities of all but the most skilled managers to control the resulting chaos.

The concept of master planning found in traditional project management methods is no longer appropriate for the vast majority of software development projects. This is not to say that there aren’t some project domains that require extensive pre–planning and rigid control processes. But they are rare in the software development domain. The prominent failures of the past, IRS, FAA, are too complex to attribute to simple project management failures. But the failures of many commercial development projects can be attributed the mis application of rigid methods to a problem domain that required flexibility, agility, and adaptability.

The Problem Is Not Change, It’s Uncontrolled Change

The fundamental problem with any structured top–down project management method is that real world requirements are moving targets. Antipatterns describes how the project manager doesn’t have a hope of managing the project in a fixed and predictable manner, with a single all–encompassing schedule because, by the time the schedule and tasks are fully defined, the problem will have changed. The concept of planning must be replaced with the concept of continually adapting the plan. If the project manager and stakeholders can't fully anticipate what is going to happen, then he must all be prepared to be nimble.

“If you can’t plan well, plan often,” is a famous Watts Humphries quote that is applicable here.

In the absence of this nimbleness – agility is the current buzzword – antipatterns begin to appear. This book is about those antipatterns, how to recognize them, how address the problems they produce and most importantly how to avoid them.

Project Management Antipatterns

Project management antipatterns are familiar to anyone practicing the art of project management in a modern organization. This book pulls together patterns of behavior common to troubled projects. Some are obvious, some are subtle, and some are new observations that bring to light the complexities of managing projects in our modern times.

Like the two previous books, Antipatterns is a compendium of experiences and observations of how managers and participants – in this case Project Managers and their stakeholders – can create the foundations of failure by not understanding the consequences of their behavior.

The antipatterns presented in the book are divided into categories

· Project management

· People management

· Technology management

· Process management

This division is logical in that it is representative of the problems encountered in the typical software development project. This partitioning is of course software project centric, but other domains may find it familiar if the details of a software project are ignored and a broader project management perspective is taken.

Issues with book

This book can be read in several ways:

As a traditional cover to cover read of a technical book is suggested for those who are not familiar with the patterns literature.
As a reference book for those who are familiar with patterns and their application to specific problems.

For the latter there is an important gap in the mechanics of the book:

· The book needs a map of the patterns and their relationships. Without this map the reader can easily get lost. The index provides some help, but the reader must somehow understand how to locate the antipattern that matches the problem at hand.

· Along with no map each page has the same header. If the page top at least had the title of the antipattern, this would be some help.

These are trivial issues of course, but they do detract from the daily use of book.

Another issue with the book is that it assume the Software Engineering Institutes Capability Maturity Model [4] is the foundation on which good project management processes are built. There is a risk that basing a project management method on CMM without understanding the consequences will lead to another set of antipatterns. This is surely not the intent of the authors, but is a common outcome of using CMM in an improper manner.

The search for a repeatable mature process that enables successful software development is the holy grail. In many instances the CMM approach to project management is wholly inappropriate. The authors in this case do not present a broad enough view of project management methods, but stick to the CMM foundation.

This is not a problem in principle, but leaves out many other methods that are useful and sometimes better suited to solving the antipatterns of software development. [5]

Using the Book in Dailey Practice

In order to put the book to proper use, two reads may be necessary. A cover–to–cover read to become familiar with the content, then a reference read to locate the specific antipattern when the time is needed.

This issue of patterns navigation is part of the patterns community and is usually addressed in electronic form with hyperlinks and the web style of patterns cataloging. In print form no such resources are available so the mechanical lookup of a pattern and the related information can become tedious.

This does not take away from the value of the book or its predecessors. It just requires slightly more effort than the typical Project Management book. Since the book is not a tutorial on project management, but rather a collection of case studies in antipatterns, so that accessing the contents can be done randomly.

How to Apply the Book in Practice

With the broad number of patterns available in the book the reader will need to identify the class of problem being experienced on the project. This can be done through the Table of Contents or the Index. Once located, an understanding of the cause of the antipattern and the remedies will provide some guidance.

Applying the solution is always problematic no matter what the situation, since dysfunctional projects usually have more than one antipattern in place.

The authors address this issue in the appendices, with a synopsis of the antipatterns, a cross reference, and a moderate bibliography.

The cross reference may be the best starting point, since it is the closest thing to a patterns navigation guide.