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