By John Sitek

Professional golfers often repeat this adage—I’d rather be lucky than good. For an IT project manager, this same rule often applies.

There are lots of ways to achieve the same outcome. Often, no one particular method is significantly better than another. That’s the lesson I learned from completing this project.
This article was written by Master Sergeant John Sitek, who has worked in IT for the U.S. Air Force for more than two decades. In his previous article , Sitek discussed the risks he accepted when he looked for shortcuts in completing his assignment after his deadline was advanced several months.
The mission
The assignment involved completing two projects:

  • Upgrade the message handling system to increase the speed and capacity of the information manager. We accomplished this task by adding more input and output circuits along with the requisite processing capability to carry the increased load.
  • Relocate the entire system without incurring downtime.

The big chill
The room where the system would be relocated was adequately cooled. But the chiller would not be able to handle the additional heat load once we brought in the new system. Ventilation was also a concern.

In overcoming these problems, I had three advantages on my side:

  • Due to raised flooring, there were no ducts to deal with.
  • Since the project’s timeline was accelerated, funding was increased.
  • I purchased a 15-ton air handler that was installed in less than two weeks.

The cooling problem was solved.

Get it done yesterday!
We centered the project timeline on ground shipment of the system. But now, we didn’t have time for that method of transportation. Without budgetary constraints, it was easy to upgrade to airlift support.

With two phone calls and a stroke of the mighty pen, I eliminated three months of travel time for our information manager. This brought my timeline back into February. I’d asked for a two-week extension, but my request was denied.

How could I meet this unforgiving deadline? I reviewed the acceptance-testing schedule that was originally programmed for two weeks. It involved about 1,000 messages per 24 hours from one workstation. If we had a problem, we could take out time to correct it.

To speed the schedule, I rewrote the acceptance test plan requirements and dedicated 10 workstations each dumping 1,000 messages into the system in 24 hours.

Another timesaving idea
Staging and system dry out were scheduled for about one week. I had no choice but to reduce the time dedicated to those tasks.

Flatbed trucks met the airplane and the crates were delivered straight to the facility. We pulled the crates off the trucks and disassembled them in the parking lot, rolling each of the racks into place and leaving them on their pallet jack stands.

If you lower the ambient air temperature in an environmentally controlled facility, you also reduce the humidity. We set the thermostats as low as they would go, shut off the lights, and went home for the night.

If you’ve ever dealt with a communications center housing a large number of servers and switches, you know they’re usually pretty cool. By morning, the temperature in the facility was below 50 degrees with very little humidity.

I signed off on the papers accepting responsibility for powering up the equipment before the dry out period was complete. Using temporary electrical connections, we powered up the system bays and began our loading and testing. We cut over the minimum number of connections to complete the acceptance tests. By the time the switch had passed, we had completed one project and started another. The second assignment was a relocation project that involved moving the system.

Moving-day headaches
In the Department of Defense, it’s always easier to move something around than to add something new.

It takes an act of Congress to install a new system. But if you move an existing system, half your paperwork is eliminated. We rolled our equipment bays across the parking lot, leaving our old switch intact.

We soon discovered a major design problem. I mentioned earlier that we mirrored the two systems for the acceptance and original cut-over. When we went to place the new system in its final location, it was backwards.

All of the cable and fiber lengths had been pre-cut for immediate installation into a bay that was about 25 feet further from the punch block rack it was designed for.

Luckily, we came up with a simple solution. Holes were drilled in each bay to accommodate the connections between them. Rack-mounted components solved another glitch. It took more time to determine the feasibility than it did to implement the solution.

The final touches
We tediously cut over hundreds of circuits one at a time. Each circuit was manually wired into the new system.

Each circuit was tested end-to-end and marked off as completed. I stood by with a spreadsheet printout of each circuit and checked them off. Each circuit was left in an active mode so that it would accumulate test hours.

After all circuits were cut over, we ran the new system in either test or bypass mode for another 24 hours. During this time, the new system was allowed to simulate the handling of all the message traffic. After testing was completed, I signed the relocation project acceptance certificates.

We placed the system in full standby mode. Doing so allows all messages to pass through without interruption unless there is a failure along the circuit path. If a failure occurs, the system immediately re-routes the message, bypassing the fault and moving it to its final destination.

We walked through the tunnel and went back to the old system. I hit the main power switch and held my breath. The project deadline was the end of February. It was February 28th and certainly not a leap year.

What did I learn?

  1. No matter how well-developed your timeline, you are still in control. Ultimately meeting the customer’s demands takes priority. The Gantt chart is not in charge.
  2. One of the most important keys to success in any project is learning when to say YES. We often let ourselves become focused on milestones rather than customers. Consequently, we tend to shy away from risky action that might impede our perceived progress toward a milestone.
  3. Every project is unique and each carries its own flavor and character. The difference between a project manager and someone who is simply handed a project is the ability to put the puzzle pieces in order and look at the big picture.

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 an e-mail describing your successful project in a sentence or two. You don’t even have to write the article. We’ll do all the writing if you’ll tell us about your accomplishments.