John Hendow

When I was studying Computer Science, one of my favorite CS Professors was a fan of Steve McConnell’s approach to system analysis and software design. I had read his book Code Complete, which is an industry standard for software design. When I was getting ready to go on the road for a brief tour, my professor suggested I take McConnel’s Rapid Development as reading material.

Side note : I have always been a voracious reader when traveling, particularly on band tours. I would carry a few books with me at the start of any trip, and as I completed a book, I’d look for a bookstore where I could trade it for another title. In some cases, venues provided a “band house” for our lodging while performing several shows in the area. This was especially nice, because it meant we could (1) do our laundry and (2) actually cook a meal. The band houses usually had a small collection of videos and books to keep us entertained. I often would leave books behind for others to read. On occasion I found an interesting book and brought it along for the next leg of the journey. In Victoria, BC, the band house had a copy of Foucault’s Pendulum, by Umberto Eco, which I finished reading as we made our way down the west coast. Ultimately, that book was left in Bend, Oregon. I’m sure it continued its journey in the hands of another musician.

My copy of Rapid Development is from the first pressing. It’s a dog-eared book with post-it notes, and hand-written margin notes. It’s been on my work bookshelf in various cubicles and offices for the past 20 years, and I’ve loaned it out more times that I can count. This is the book that made me want to become a project manager. It also has been a book that I have found useful as a manager and leader.

Among the highly useful principles in this book is the practice of “Function Point Analysis”, which is an estimation technique that is very useful in modern Agile decomposition and estimation. I have adapted FPA for use with my PMO team at Disney, and it’s a good basis for task estimation in software development. In addition, the book emphasizes effective principles for managing high-performing teams, and for business customer satisfaction – which has a strong basis in effective, precise communication.

For Agile development teams, one of the initial opportunities for improvement tends to be estimation. Newly formed teams will not have a baseline velocity, and will not have estimation / retrospective data to feed the continuous improvement loop. Narrowing the estimation error has an immediate effect on normalizing the team’s performance; this is where FPA can be effectively leveraged. After 4-6 sprints, estimation variability versus actuals will be reduced, and sprint loading will become a reliable predictor of the work that will be actually accomplished in each sprint.

This book is worth a read. Steve’s seminars are also interesting, and he has established a good curriculum for technology thought leaders.

As a Senior Program Manager, I spend a significant portion of my workday engaged with project and program management. During the 15+ years I’ve been in this profession I’ve encountered a variety of approaches to managing projects. It’s especially interesting to me how these approaches rise in popularity and may become considered the “new perfect way”. One of the current popular approaches is “AGILE”. I’m glad to see that aspects of this software development process are being considered valuable, but I have a few concerns / caveats: (1) AGILE is actually a collective term for several somewhat different approaches and (2) it’s not suited for all projects or teams.

In terms of exploring my first point, AGILE may refer to any of the following PM methodologies:

• Agile Modeling / Unified Process
• Dynamic Systems Development Method (DSDM)
• Essential Unified Process
• Extreme Programming (XP)
• Feature Driven Development
• LEAN
• Prince2
• Scrum
• Velocity Curve Management

I would also add that principles from Rapid Application Development (RAD) and even 6Sigma belong in this list. Most people use AGILE interchangeably with Scrum, which is probably the best-known approach within AGILE.

To address my second point, in subsequent articles I will go into the characteristics of each methodology, along with providing some guidelines for identifying AGILE-friendly projects. In the mean time, keep those comments and questions coming!

As a project manager, I’m occasionally presented with the challenge of compressing work into a tight timeline. Sometimes this is the result of the customer (business) of wanting results sooner, and other times it’s because there is an external deadline that cannot be moved. In either case, the scheduled activities are reviewed to identify opportunities for parallel effort. In PM parlance, attempting to get more done sooner is often called “crashing” the schedule; a degree of caution is advised when considering this approach. Because most projects involved a fixed pool of resources, this can result in over-allocating individuals (overtime / long hours) and there are well-understood diminishing return curves for demanding extra effort.

Whenever possible I attempt to negotiate the schedule with the project sponsor, but I’m finding it fairly common to be called in for projects where a delivery date has already been communicated to the customer. This means working backwards by building the task schedule from the end milestone. Tasks are identified for possible overlap and the critical path is shortened as much as possible. Crashing the schedule is usually identified as a risk, although I’d be tempted to say it is a mitigation plan undertaken in response to an issue. Call it what you like… getting more done with less resources in less time… everybody loves that idea and many PMs find themselves being expected to make this happen on a regular basis. I suspect the nature of our industry is that we’ll need to introduce greater training for optimization into the PMI knowledge areas.

This week I’ve been reviewing a book by Dr. Harold Kerzner that focuses on his five-level project management maturity model. Dr. Kerzner sits on the advisory board of PMI and is considered a leading thinker in the project management field. Earlier this year I completed a 5 day training course based on his approach and am considering how I might apply this model to future projects and programs.

Overall, this is essentially a textbook and holds all thrills one might expect from such a tome 🙂

As a PM, I find this book is a great read, it holds an essential place in the reference library of any good project manager.