When an IT project plan falls apart

by Andy Weeks | Mar 21, 2000 8:00:00 AM

Tags: Andy Weeks

Takeaway: Coordinating vendor schedules is like building a house of cards. If one vendor doesn't show up, your creation collapses. Find out how one IT project planner found a solution in the rubble.

It started as a typical day for Michael Brennen. He was up at 6:30 A.M., first checking his schedule on his PalmPilot, and then checking the price of his company stock. He was sure that he was going to get stock options once his project came to a successful close, and he was already calculating the return.

Perhaps his plans were premature. The technical lead on the project called him with this troubling update:

• The contractor at the site in Kansas City left a voice mail last night. They can’t finish the wiring because not enough cable was ordered. They left to go on to Dallas because that installation has to be finished tomorrow.
• The integrators are arriving this morning to begin installing the network, but they can’t do the job if the wiring isn’t finished.
• The software team finished early in Atlanta. The team members are already on a plane for Kansas City.
• The phone company cancelled for today because they haven’t received all the hardware for the new phone switch. Since the cabling isn’t done, they wouldn’t have been able to do anything anyway.

This narrative is based on a true story. The author, Andy Weeks, is the vice president of business development at Henderson Electric in Louisville, KY. Henderson is part of Toronto-based Bracknell Corporation, which has a client base across the U.S. Weeks knows first-hand the importance of coordinating contractors and vendors during project planning.
Brennen started putting the pieces together in his mind. Kansas City was the site of the new Midwest call center. It was supposed to go live in two weeks, just in time for all the calls the new ad campaign was supposed to generate. They had known that the schedule was aggressive:

• Set up three new 100-person call centers in three cities.
• Upgrade the software in the two existing centers.
• Coordinate the resources and contractors with nearly split-second timing.

Creating a solution
Once Brennen got into the office, he knew he had to get a handle on the situation. His telephone calls to the vendors and contractors consisted of a creative mix of negotiation and delegation.

Fixing the cable
His first call was to the engineer who was responsible for the cabling. Brennen learned that when the design for the cabling was created, it was assumed a nearby closet could be used as the wiring closet. It turned out that the room had no power, so the crews had to use another closet that was about 50 feet farther away. As a result, there wasn’t enough cable. No one ever checked for power there because the planning team trusted the information from the property manager.

His conversation and directions to the engineer were brief—find out why there’s not enough cable in Kansas City and call back with a plan for fixing it.

The network installation
Next, he got the team lead for the network integrators on the phone. He found out that they could do 75% of the work without the cabling in place, and wouldn’t hit a stopping point for another day.

The software team
He also discovered that the server the software team would need to install would be up by mid-afternoon, so the install could even be completed early once the team arrived. Of course, with no network, they couldn’t test the software.

He then called the phone vendor and asked when they were going to have the system installed. They explained that the missing parts were being sent from California and would arrive tomorrow. They promised to have a crew on site as soon as everything was received.

The puzzle comes together
By the time the first round of phone calls was complete, Brennen received an answer on the cable. The engineer ordered cable from a distributor, and they have enough in the Kansas City warehouse. It’ll be on site this afternoon. This shaped the project schedule for the following week:

Wednesday: The cabling guys should be able to arrive at the project site in Kansas City.

Thursday: The network integrators would need this day to complete their work.

Friday: The system would be available for testing in the morning. That, of course, meant that five days of testing would have to be squeezed into two days to make the startup deadline. If they found any problems, the startup would probably have to be delayed.

Brennen put together a revised project plan to show how the critical path had been changed.

Lessons learned

1. Don't build a schedule that's so tight there's no room for error.
2. Complete enough advance work on the engineering so the schedule isn’t affected adversely.
3. When things go bad, don’t focus on why they went bad, but what can be done to fix them.
4. Don’t depend so heavily on the vendors without putting a contingency in place.
5. When the schedule falls apart, the first thing to go is testing, so be aware that quality may suffer.

Brennen didn’t know it, but on that day, he earned those stock options. He would later find out that he earned his bonus not because he was able to plan a perfect project, but because he was able to recover from adversity quickly and learn from his mistakes.
Share your project success story with TechRepublic. There are so many reasons why:

• If you publish your accomplishments, it provides more proof of performance when it's time for your review or when you want to change jobs.
• If you brag about your staff members, you'll show them that you appreciate their hard work.
• If you share the details of a tough project you've tackled, your peers can benefit from the lessons you've learned.

Just post your comments below or send us some mail and describe your successful project in a sentence or two. We might contact you to learn more.

Print/View all Posts Comments on this article

slucar@... | 03/27/00

Tight Schedules - Not for ALL Jack-of-all-trades | 01/16/01

Salesfolk are not Project Managers Bucky Kaufman (MCSD) | 01/18/01