Introduction | Book Structure
What We Liked | Downside | Summary

What We Liked

All of the chapters are quite brief and very much to the point. They provide clear descriptions of the problems and the steps to take to fix them, or avoid them in the first place. These are easy to follow through the use of extensive bullet-form entries.

So, having established all the reasons why projects fail, the question is: How do you know your project is out of control? Good question. In the Introduction, the authors identify these telltale symptoms:[6]

• Missed milestones and deliverables
• Differing opinions of the project's goals and objectives
• Exceeded budgets
• Missed schedules
• Dependence on heroes
• Customer dissatisfaction and disapproval
• Frustrated staff, and
• Concerns voiced by various and many stakeholders.

While this list may not be comprehensive, at least it gives you a good idea of what to look for. In our own experience we have had to extricate projects that have effectively come to a complete standstill - at which point, executive management finally took notice.

But as if that is not enough, the authors also point to Other Subtle Signs of Trouble:[7]

• Requests from customers to make changes to requirements
• Staff attrition
• Tension during meetings
• Surprises
• Lack of trust
• Lack of honest feedback
• Lack of management support
• Consistently operating in "crisis mode"
• Finger-pointing
• Defects in delivered work products
• Frequent rework
• Declaring incomplete work products "done"
• Poor assumptions
• Project risks aren't mitigated
• Ineffective meetings
• Delayed decisions
• Counterproductive responses to bad news

Sound familiar? Each of these is described in greater details.

We rather liked Chapter 3, Analyzing Your Project. As the authors state:[8]

"Planning should be based on the business objectives that must be met and the functional goals of the completed project. If project teams want to succeed, they must focus on project planning, then on process and procedure development. PMs often believe that such effort is unnecessary, but in our experience, the failure to develop (or adapt from others' experience and existing documents) processes, procedures, and checklists is a root cause of project problems."

While later they observe about The Plan Components:[9]

"As we worked with the project's stakeholders, it became clear that many thought that a Microsoft Project schedule equaled or provided a project plan. This is a common misconception. We realized that we needed to educate the team about what a plan contains, each component's purpose, and how long a good plan would take to develop." [Emphasis added.]

The authors then go on to describe seven key components of a good plan. Of these, we were gratified to see that they list Product Breakdown Structure (PBS) and Work Breakdown Structure (WBS) as two separate items, and explain why they are distinctive and necessary. For example:[10]

"If a project team does not identify all of the products it must build, it cannot account for all the associated work or accurately estimate the effort, time, and resources required to execute the project effectively. If the plan does not address all of the needed resources or allow enough time to get the job done, then the project automatically starts behind schedule and over budget."

How often have you seen "secondary" products like time-consuming team meetings and administration quietly ignored as though they didn't exist or were not a part of the project? And then you find the "management" time charges and costs coming home to roost later on, see Figure 1. Clearly, in planning and estimating it is not sufficient to consider only the technical delivery work.

Figure 1: Distinguishing between Management and Technical work[11]

Later the authors observe that:[12]

"Even if you have prior experience, creating a plan can be very challenging. It's critical to obtain stakeholder acceptance during the planning process. Without stakeholder support, it becomes difficult, if not impossible, to execute the plan ... Developing a plan should be considered a mini-project with its own schedule and resources."

As might be expected, the chapters on Managing Scope and Quality are all about managing the technology. Here, the authors have pearls of wisdom of general application. For example:

• The average project invests three percent of total costs in the project-long requirements process, but data from NASA show much better results are achieved when 8 to 14 percent of total project costs are invested in the requirements process.[13]
• Customers and users provide what we call stated requirements, the requirements given at the beginning of a system- or software-development effort. Of course, the stated requirements are never the real requirements.[14]
• The earlier a defect or error is discovered, the easier it is to fix; the less impact it will have on other work products and the project as a whole; [and] the less it will cost, and time it will take, to get back on track.[15]

Book Structure

Downside

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