Patterns in Project Behavior

Ben Linders

Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior, by Tom DeMarco, Peter Hrushcka, Tim Lister, Suzanne Robertson, James Robertson, and Steve McMenamin, ISBN-10:0932633676, ISBN-13: 978-0932633675. Dorset House, 2008, 248 pp.

This book contains 86 patterns, described in an easy, well-written style that helps you recognize and think about how people behave in projects. The authors have a lot of experience in various areas; their different views give a broad understanding of the issues you can face in projects.

Patterns help us understand things. They’re not necessarily good or bad; in fact, they might or might not apply to a specific situation. I’ve seen many of the patterns described here in my projects and daily work. Reading about them made me think about how we do things and helped me discuss them with colleagues. I present two example patterns here and how they helped me understand and improve my way of working.

Pattern 37: Talk then write

This pattern calls for decisions made in meetings to be immediately communicated in writing. Pretty obvious, but I still see that we can take a long time to communicate what we decided in meetings and that sometimes we don’t communicate it at all or don’t inform all the people affected by the decision. Over time, the decision loses both force and clarity and is forgotten or becomes a source of resistance rather than a solution.

With agile methods, we now have much better means for communicating instantly, so let’s do it! Use the war rooms, information radiators, wiki’s, and so on, as much as possible and as quickly as possible after decisions are made. And don't forget to update any records and recommunicate when decisions change.

Pattern 56: Undivided attention

This pattern states that undivided attention in a single project improves individual performance. With agile, we usually have technical teams with full-time members, focusing on the iteration at hand.

But what about supporting functions? They’re usually allocated to multiple projects and to general operations such as process support, quality, process improvement, and line support. Task switching makes it difficult to give sufficient attention to each assignment, to build up relationships with the teams, or to really understand the issues and provide effective, timely solutions.

Maybe it would be better to combine some of those part-time roles and have somebody working most of his or her time on them for one project? Or make the business case for a support role, increase the funding, and ensure that somebody can spend at least half-time on one project, instead of just of couple of hours or a day each week.

These are just two patterns from the book that helped me think about ways to improve the projects I work on. Reading the book felt like attending a good conference. It includes a lot of interesting material, some confirming what you already know, some of which are less relevant for you, but some that are very useful. The net result is some discoveries that help think about your work, discuss it, and improve it.

Ben Linders is a specialist in Operational Development & Quality at Ericsson Telecommunicatie BV, the Netherlands. Contact him at ben.linders@ericsson.com.