Microwave Way of Project Management,
Bas de Baar, iUniverse press, 2002
This book is unique in several ways. First it can be read on–line before buying, second it is the second (I’ve encountered) that claims to address the issues of PM from the point of view of agility or at least from a non–traditional point of view. Third it is a book written in an anecdotal style using personal experience and narrated in a chatty voice.
My Point of View
As usually I have an “agile” specific point of view. Is this book useful to the agile project manager managing software development using some method that would be considered agile? This means can the principles of agility as defined in the literature be found somewhere in this book?
Let me start as usual with my issues as to why not much agility is present here:
I’d like to walk through each chapter, since the book is relatively short – in keeping with agile principles.
This book suggests there is a new way to manage software projects. “A way to avoid the traditional software project management problems.” Well maybe, but the book is full of traditional linear, phase based, high ceremony processes that are the source of many software project failures.
Would I buy this book? Since I read it on the web, I’m not sure. One test of book ownership is to ask have I read this book more than once since I bought it? Of course I can’t know this until later, but I’m not sure I would read this book more than once.
Now for some details. Since most book reviewers restate much of the publishers materials, I like to look for “show stoppers” as to why I would not recommend the book – after I’ve bought it of course.
The concept of stakeholders and requirements is presented first. One issue I have here is the stakes concept and it’s relation to project management. The PM should have some understanding of what makes the stakeholder tick, what are the hot buttons, and what concepts resonant with them. But having those pieces inside the project, as a management activity seems to blur the responsibilities. In the agile vocabulary this is the responsibility of the stakeholders.
The example of requirements seems to miss the point. The requirement of finish by the end of August, confuses non-functional, in fact schedule requirements with technical or functional requirements. I would have used a different example for conveying stakeholders and the changing of requirements. Having the users state a completion date without defining scope, functionality, etc. creates an instant failure opportunity.
After a bit I came to realize that Bas was using stakes in place of business requirements, so the chapter started making more sense, for a while. The next discussion has to do with feedback. The list of feedback items completely ignores the functionality of the software as the primary feedback mechanism. Reviewing test results and reports, plans, benchmarks, etc. says nothing about how the software provides business value to the stakeholders. Prototypes are interesting but agile methods don’t produce prototypes – they produce working software (incrementally functional).
Baas describes a process flow by which the business needs (stakes) are dealt with. The problem here is he makes use of requirements (in the form of a requirements document) as the sole communication and feedback vehicle. Documents are useful in the right context, but there are many other means of communicating other than words on paper that have been shown to be effective in the requirements world. For anyone working in this area, please read, “Issues in Requirements Elicitation,” Michael Christel and Kyo Kang, CMU/SEI-92-TR-12 as a starting point.
Chapter 2 – Intake
Bas describes the concept of “reengineering” the project from what the stakeholders have conceived to what is needed once the project manager comes on board. The concept of the “project” existing before the PM arrives is interesting, but not what I would call earth shattering. This is always the case, since some form of business process must have initiated the project for a monetary, process compliance, or regulatory reason. The introduction of the PM to the project allows the PM to “learn” these reasons first hand. OK, so she does this and gets on with the job of “managing.” Not what I would call a chapter’s worth of material. Further on it becomes a bit clearer where he’s headed – the PM needs to establish the goals of the project for herself rather than have the stakeholders control this process. The issue though is this is usually “assumed” to be the kick off process. This assessment process is likely to be done by an experienced PM, so reminding us at this point is good.
What happens next is a bit more troubling though. The concept of constraints on money, time, and resources is presented. Next is the concept of the strategy for software development project. To my weary eyes these appear down right simplistic. For situations where the requirements are stable, Bas suggests that we “think about the subject (problem), specify the solution to the problem, implement the solution, activate the solution in the organization.” This reminds me of an Edsger Dijkstra description of the “perfect” structured program – BEGIN; Do All Work; END; The concepts of “define the work,” “do the work,” “deploy the work,” might be considered a bit oversimplified.
When the goal is NOT clear, Bas suggests a new method – “first get a clear goal,” then execute the project with the above steps. Uhmmm sounds simple, when the outcome is not clear, get a clear outcome and proceed. No mention of “how” to resolve this ambiguity, just “do it.”
Chapter 3 – Requirements Determination
Bas acknowledges that requirements cannot be firm – which is the basis of agile PM processes and the bane of the traditional PM methods described in the likes of PMBOK. Bas suggests that a “workshop” is the method for gathering requirements. This is similar to the RAD/JAD sessions that were popular in recent times. The gathering of requirements is a rich and complex process. I might recommend that anyone entering the domain first read “Issues in Requirements Elicitation,” to establish the underlying issues with the requirements process. Other requirements reading should be done as well, but not much in the form of references on this topic is provided.
Chapter 4 – Requirements Validation
In my opinion Bas gives bad advice here. Following the suggestion that “once in awhile the software guru’s come out of their cave and tell in understandable words what they are envisioning,” is the likely source of most software project failures. The developers need to be continuously engaged with the stakeholders in some manner – daily, every other day, no longer than 3 days. This generates continuous feedback, which is the source of information most missing from traditional software project management methods. When the stakeholders ask, “…what happened to my requirements…” it’s too late for the PM to do much other than “dance.”
Chapter 4 has some quotes for Fred Brooks (stated as the 1995 version, but actually from the 1975 version). The concepts of “build one and throw it away” are no longer acceptable in today’s market. Refactoring, incremental feature deployment, test driven development, function driven development, all the current “development” methods are not mentioned here.
The section on testing does suggest “planning in advance” for functional tests. Bas uses a newspaper system, which I know something about as an example. He doesn’t mention Use Cases directly, but that seems to be what he is talking about.
Chapter 4 ends with another troubling statement. Change is a normal part of software development. Changing requirements (within reason) should be seen as desirable – since it means the requirements are moving toward the actual need. Bas suggests that “project management will decide if a change in the requirements set is accepted or rejected.” Wrong! The stakeholders decide this after they hear from the developers what the impact is on the schedule, technical and cost attributes of the project. PM is the facilitator of this process. The stakeholders are the “owners” of the outcome.
Chapter 5 – Project Progress
This chapter opens with a pet peeve of mine. “Gantt is project management,” is really bad advice. Project Management is a vague and amorphous process in the software world, a Gantt chart definitely does NOT represent it. Gantt’s are myth’s of how the project is going, working code is the primary reality, customers sitting in front of this working code telling the developers what they like and don’t like is the true reality. Gantt’s are reporting tools for cost accounting, they are “lagging indicators” of project progress.
At this point I got lost (reading on the web is not all it’s cracked up to be) in this chapter – too many anecdotes and analogies. My personal style of “planning and reporting” doesn’t match Bas’ so it was time to move on.
In the end Bas’ approach is too high ceremony for me, and reflects the 1975 style of his favorite author Fred Brooks.
Chapter 6 – Risk Management
Bas has done his homework here, with Boehm and Hall as the source of risk management. He suggests writing all the risks down. There is another step that is missing though – managing those risks. A simple risk management database tool is available from www.spmn.com.
Chapter 7 – The Bigger Picture
This chapter seemed to be a collection of ideas that were not specifically addressed in previous chapters. My limited time budget allowed me to skim through this material with little problem since I was on deadline for many things other than book reviews.
Start with the web version and try out some of the ideas. The price of the book is very affordable, so if a hard copy is needed it won’t impact the budget too much.
Glen B. Alleman
Niwot Ridge Consulting