Introduction | Book Structure | What We Liked - Part 1 | What We Liked - Part 2
Downside - Part 1 | Downside - Part 2 | Summary

Downside - Part 1

Although described at length in the book, Agile Project Management is not specifically defined. However, we may conclude that it is a conceptual project management framework for undertaking software development projects in which the "emphasis is moved from planning to execution."[14] That should satisfy the brigade of people who are inclined towards: "Never mind all that planning stuff. Just let's get on with the work!" But as Gary says: "Agile project management concepts are not for every project, yet they can be invaluable to others."[15]

Gary identifies two criteria for Agile PM. The first: The project environment, of which he recognizes three different types, namely "operational"; "product/process development"; and "technology development".[16] The operational project environment is low uncertainty and therefore "Classic" and more process oriented, while the other two are highly uncertain and most suited to agile PM. His second criterion is Organizational Stakeholders in which agile PM concepts have the best chance of success when the project operates under, more or less, a single organizational umbrella.[17]

Gary's use of the term "operational" is a little confusing because it is usually used to distinguish between on-going business operations and projects. However, in Gary's environment, the business is made up of projects. As he says: "After all, if your projects are your business and your key players are the heart and soul of your project, then it stands to reason that your key players are your business."[18] Indeed, he makes this case for Agile Strategy: "View your projects in the same perspective as your business, by integrating project and business decision-making processes, and you will better achieve your business objectives."[19] While the last is obviously good advice, we think the description is a little exaggerated for most companies.

On the subject of excessive project management paper work, Gary writes:

"[I]n the uncertain environment of agile PM, we would be naïve if we did not expect changes to the project plan on several occasions, certainly much more than in a mature project environment... . If the project manager maintains an inward-facing perspective and subscribes to the notion that project performance is based on the team's ability to deliver what they signed up for (i.e., the original plan), then he will spend a good portion of his time analyzing and documenting these variations from the original plan. As the zigs start to mount where the plan called for a zag, the project manager will soon be consumed with tracking, analyzing, and documenting ever more complex variations. When this happens, the project manager reduces himself to what is essentially an administrative support role... . [A]s project manager you need to keep your eye on accomplishing your project objective - not on excessive paperwork."[20]

In that last line, we think that what Gary really means is product (objective) and not project, otherwise, well said. In fact we've experienced managements that believe that project managers, even project directors, are really no more than "administrative followers". This inevitably means that someone else is really in charge of the product development. This confusion of terms confirms our belief that it is time to start distinguishing between project management and technology management.

Later Gary provides an "Agile Strategy" that says:

"Track trends of key external influencers, as well as variances from what is expected, and you will move from being reactive to proactive." And "By monitoring [these] trends, the project manager and team are better able to make the decisions that will keep their project aligned with the true business needs."[21]

And in opening Chapter 9 on "Creating an Environment of Agility", he says:

"Agile project management is about deftly managing the change in requirements associated with project uncertainty, so it becomes a positive force for both the project and the business, rather than a negative one. The project manager guides the team through the changes necessary to bring the project to a successful completion."[22]

That all sounds like good advice and may be true, but what is the meaning of "success" in this context? Is it on-time-within-budget or a wonderful-product-regardless? Is it really the job of the project manager to change the course of the project? Surely it is his or her job to determine the manner of accomplishment and not the destination? That sounds to us like a weak sponsoring management incapable of doing its homework and providing direction!

Indeed, Gary seems to confirm this confusion by observing:

"In the classic project management environment, upper management has minimal involvement with course changes within a project. Their primary project roles include endorsing/sponsoring the project, committing resources, setting a project deadline, receiving status reports, managing escalations, and providing rewards to motivate the team."[23]

If the "course change" is concerned with the route and timing of how to get there, this is quite true, but if the course change changes the destination (i.e. a "product scope change") then that is a very different matter.

What We Liked - Part 2

Downside - Part 2

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page