How to Overcome a Project DisasterBy Guest Author | Posted 2015-12-22 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
Sometimes a project hits a few speed bumps, and sometimes it suddenly crashes into a concrete wall. Here are some suggestions for dealing with these disasters.
By Steve Caseley and Chris Ward
The ultimate goal for any project manager is to complete the project on time and on budget. And yet, despite our best intentions, this doesn’t always happen. Sometimes a project hits a series of speed bumps, and sometimes it suddenly crashes into a concrete wall.
Steve Caseley and I are project managers, and we’d like to share a couple of our personal disaster stories with you, as well as our solutions and the lessons we learned. By doing so, we hope you’ll take something away from our experiences.
The first story involved restarting a software upgrade project for a large international bank two-thirds of the way through—which is certainly not a position any sane person wants to be in.
Steve Caseley’s Challenge:
I was managing a project to upgrade a highly customized convertible bonds trading system for a major international bank. The requirements were straightforward: Upgrade the software and preserve customizations so they could be used in the new release.
The project went very well for the first two trading desks in New York and London. My project sponsor was tightly connected to both desks and had a firm understanding of what customizations had been done. Coincidentally, these were identical for each location.
However, the wheels fell off the bus when we implemented the project at the third trading desk, which was in Hong Kong. We had done a substantial amount of customization for this desk, but many of the changes were unfamiliar to staff members throughout the bank.
We suggested they could modify trading practices to “fit the software,” but that idea fell on deaf ears. “That’s just not how it works here,” we were told.
The end result was that we had to restart the project two-thirds of the way through, and integrate all the changes the third desk needed. We were substantially over schedule and over budget, causing significant operational issues for the bank because it had to keep duplicate copies of the trading system active for an extended period of time.
Ultimately, we completed all the modifications and successfully implemented them into the third trading desk, much to the delight of the local manager.
Lessons learned: Never underestimate the complexities of an international project, and always ensure that you have full coverage for your key project stakeholders. Originally, we didn’t have adequate stakeholder representation from Hong Kong, simply because the people there were harder to reach due to the time difference, and our project sponsor had assured us that “all the desks operate the same way.”
Chris Ward’s Challenge:
I was tapped to be the team lead on a project to develop training for a large tech firm, since I had experience with e-learning companies, helping corporate tech employees pass certification exams and learn skills.
The tech firm had printed material, but it wanted self-paced e-learning, too. I knew the material very well and was certified, so I felt confident that my style and methodology would blow them away, even if I went off script.
After recording several tutorials, I persuaded one of my colleagues (a sought-after Cisco trainer) to record an associated lesson on security. It was not exactly what the client had asked for initially, but I was sure they would love it.
After we sent our initial recordings and amazing graphics to the head of the training group, we received scathing reviews. One customer email read: “You sound like a bunch of monkeys pretending to teach this information.”
I was stunned. In subsequent meetings, “stick to the content” was drummed into our heads. So that’s what we did. We simply read the content and added the graphics once we had finished. The course was sent back for approval.
The responses this time were quite different:
“Exactly what we wanted.”
“This is more like it.”
Lessons Learned: “Gold-plating” is not how to make your project succeed. Always identify your stakeholders and make sure you understand their requirements. Quality is ultimately in the eye of the customer as you fulfill the agreed-upon requirements. It was a painful lesson, but I have not made that mistake again.
Ultimately, even people with stellar track records can become entangled in a project that just doesn't work. To minimize the chances of disaster, here are some concrete steps you can take.
· Develop a schedule and use it to monitor your progress every week.
· Communicate up and down the chain, so no one is caught off guard if a project slowly drifts behind schedule.
· Continually improve your skill sets and keep current with changing technology through training.
If you do these things, you can help prevent delays. And, even if a project is suddenly derailed by unforeseen events, you will be in a position to handle it in the most effective way possible.
Steve Caseley has taught project management at the graduate and undergraduate levels at several universities and has developed and delivered project management training programs for organizations all over the world. He is currently finalizing an online PMP training series for the PMI Project Management Professional certification exam based on the 2015 RDS exam definition.
Chris Ward has been an expert on Microsoft products since the days of Windows 3.1. He holds PMP certification from PMI and was an online instructor for several of the world's top e-learning companies. He currently works as a trainer for CBT Nuggets and is finalizing an online training series, ITIL Intermediate Lifecycle: CSI.