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

What We Liked - Part 2

Gary discusses the pros and cons of the matrix organizational environment and suggests that the contrasting project-driven organization is better suited to agile project management for the following reasons:[11]

• Business and project decision-making are better integrated than in the matrix
• The sole goal of project teams is to achieve the business objectives
• The multiple, separate, and often conflicting objectives of the matrix organization don't exist
• The silo mentality that so often inhibits project progress, especially when it involves changing requirements, is eliminated, and
• Your unique and key players can be put in place to guide your most important projects, the ones defining your business, without encountering obstacles from competing functional management

Well said and businesses involved in software development should take heed. But considering that most organizations do operate in a matrix environment for the efficiencies that they think it brings, this narrows the field considerably. However, in a subsequent chapter, Gary recognizes this fact by observing that "Most companies running projects today are set up as some variation of the matrix" and he explores the dynamics that support agility.[12] In this Chapter 4, Gary offers sixteen Agile Strategies to deal with various situations identified, and a Communications Plan Workflow together with a practical template that is available on line.

At the end of Chapter 7 is a section titled "Project Data Sheet Workflow". This twelve-page document describes in some detail a "Project Data Sheet" to be used when initiating a new project. This is a very useful reference document and reads to us very much like a project charter or project brief that one would use as the management-approved plan for a project's execution phases.

In Chapter 8, Gary discusses risk management in the agile environment. Through it, he makes a number of interesting points, for example:[13]

• "Risks" are forward looking, i.e. something that may happen in the future, while "Issues" have happened or are happening in real time. A risk may, and often does, turn into an issue and project managers should strive not to let this happen.
• Risk events involve extra work whichever way you look at it. Obviously, you can reduce the amount of that work by identifying and planning for those risk events before the situation gets out of hand.
• You can take care of possible risk events either by adopting a mitigation strategy or by adopting a contingency plan. That's assuming that you've ruled out the possibility of total avoidance in the first place.
• The difference between "mitigation" and "contingency" is that with mitigation you do extra work anyway, while with contingency, you do extra work only if needed.

What We Liked - Part 1

Downside - Part 1

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