Reducing Surprise: Another Feature of Good Project Management


The portions of projects that are not yet complete occur in the future. Since the future is an uncertain place, there will always be surprises. Some surprises are so obvious that they should hardly be called surprises at all. This is the kind of surprise that project management helps to avoid.

I am not a believer in astrology or fortune telling, but some things about the future can be predicted with reasonable accuracy. If I plant a field of bean seeds in the spring, I will probably get beans in the summer from that very same field.

Project trouble sometimes seems to “come out of nowhere” to those on the team—but, often, as wise man Jerry Weinberg says, “It’s not a crisis, just the end of an illusion.”

In the course of doing project reviews, I have had several occasions to review a year or more of project progress reports at a single sitting. Most recently, it was thirty month’s worth—about 750 pages—for a very large systems-integration effort. I suspect there aren’t many people who do this. It’s more interesting than you might expect and very educational, reinforcing good project management practices (and underscoring the danger of poor ones). Reading through 750 pages of status information in a day is like watching a grade-B horror film. The clues are often pretty obvious.

Psychological thrillers set the stage by introducing you to the characters and helping you empathize with the predicament in which they find themselves. The cheesy thrillers immediately start you wondering, “What the heck are they thinking? There’s been an escape at the local asylum for the criminally insane, and these morons are camping in the middle of nowhere with cars that don’t start reliably and friends too stupid to bring flashlights?”

In my mind, the equivalent for a project is the initial assessment of project risk. Set aside the formalities of risk management; let’s go with a professional gut check. Have this organization and team ever done anything of this size and complexity before? Are the technologies new? Is the management team new? Has the team worked together before? Are the processes new? Is the schedule aggressive? Is the project staffed appropriately? Are the quality goals understood? Are the requirements clear? Is the funding adequate? If the answers to many of these questions are ringing alarm bells, grab some popcorn and a Coke—there are going to be surprises (and likely not the “I got a puppy for my birthday!” kind).

Even great project management can’t spin straw into gold, but definition documents, early progress reports, and risk discussions should be pretty clear about the risks inherent in a high-risk undertaking if the project manager has a clue. Just like reasonable people cancel their camping trip to the creepy forest next to the asylum that can’t seem to retain its inmates, good project managers encourage organizations to take realistic—not suicidal—risks.

Getting Around to Action
I suppose my view may be a bit skewed. As a consultant, people don’t call me in because things are going so well that they want someone else to see and appreciate their success. It is surprising how often the cause of a project’s grief is there at the beginning for everyone to see.

One of the first progress reports of a project I recently reviewed noted, “The schedule is very aggressive.” Later reports echoed this sentiment, adding that critical project skills were in short supply and were likely to remain so for the foreseeable future. Can you guess the kinds of “surprises” this project encountered over the next year? If you guessed schedule and quality problems, you’re either a good guesser or you are thinking more clearly than the people who were later “surprised.”

I once read a project concept that described the sophisticated data exchange that would be required to support migrating the target system from one complex operating environment to another as part of a technology stack upgrade. The likelihood of this affecting the project was written off as extremely low probability with an entry that said, “We found a vendor who says the next version of their product will support both environments and will greatly simplify this conversion.” I don’t mean to impugn the character of software marketing reps everywhere, who might this very instant be whispering sweet nothings in their customers’ ears in order to make quota, but can you guess the source of this project’s “surprise”?

One project I reviewed was going pretty well. The team was green, but the project manager was a seasoned professional who had done similar projects before. I read the project-definition documents and had a phone conference or two with the project manager before ever meeting her, and my biggest concern was that there was so much responsibility for project success being placed on her as an individual. I was assured that this was nothing to worry about, and when I arrived for my site visit (I’m not making this up), I found the project manager was about seven months pregnant. She assured me she would be training a replacement as soon as she “found the time.”

If the first step toward avoiding problems is a good risk assessment, the next step is action. Project management isn’t about writing status reports to cover your butt because you “warned them this might happen.” The whole point is to find ways to prevent or remediate the problems. If the schedule is tight, how about reducing scope so that there is some hope of not disappointing everyone. If you don’t have the resources to do the project successfully, why not let stakeholders and sponsors know the likely outcome before they waste the effort? If someone on the team needs to be replaced or backfilled, don’t wait until the last minute—that’s silly.

Surprise? Surprise. Surprise!
Not all surprises are created equally. Some may be unavoidable. Finding genuine errors in a mature, widely available, commercially distributed product is annoying and should be worth a little sympathy. A meteorite streaking from the sky and destroying a van carrying key members of your architecture team to a karaoke night is a bad break and a legitimate surprise.

To separate true surprises from things that shouldn’t have surprised anyone, consider the likelihood of the specific event happening, the amount of warning received before a surprise happens, and the consequences of the surprise to the project. Many of these attributes can be addressed with effective project management and communication before the potential surprise event.

For example, one of my clients had a portfolio of projects converting several very large legacy systems from one environment to another. Think big, old systems with dozens of connections to existing systems—all of which needed to be up and available 24/7. A schedule was laid out showing the sequence of system migrations over the course of eighteen months. Each system had its own window for implementation (usually about an eight-week period), but if a system overshot its window, it had to get to the back of the line to avoid causing a cascading delay among the other systems. In addition to building and testing the re-engineered system, there was an elaborate choreography that had to occur with regard to data conversion and interface conversion for each system and all of the systems it exchanged data with. The project managers made sure that the teams and the users knew the importance of hitting the window and the consequences of missing their assigned timeframes. The few systems that missed their window—a small slip resulting in a slip of six months or more—caused some disappointments, but the proactive communication of the consequences eliminated the surprise factor.

Another client had a parting of ways with a systems integration firm partway through a project and needed to quickly find a new firm and restart the effort. In order to avoid the significant schedule delay that would normally be associated with this setback, they reduced the scope of their effort significantly, stripping out all optional functionality for the first release to reduce the complexity (and risk) of the project for their new vendor.

Proactively identifying risk and then acting to assure that risks are mitigated, monitored, and effectively communicated is what project management is all about. This doesn’t guarantee that there won’t be surprises, it just decreases the likelihood that they will be of the unpleasant, “How could you not see this coming?” variety. This helps conserve energy and sympathy for the inevitable surprises that the future holds.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.