There Is No Such Thing as an IT Project

You've probably heard this one before. There truly are no "IT Projects" - only business requirements that have IT solutions. A good project manager keeps steering their team back toward this principle.

What's the alternative? To paraphrase another cliché, when you're an IT hammer, everything looks like a technical nail. For example, on my current project, the infrastructure leads are telling me it will take nine consecutive weekends of outages to migrate from one application environment to another. This for a service where the customer throws a fit if we are down for maintenance for only a few occasional hours. In other words, these guys are working with their technical blinders on. The customer's needs aren't part of their equation, only their ideal, methodical infrastructure migration plan.

This is the kind of situation where an experienced and creative PM earns their paycheck, asking questions like:

• Does everything need to be sequential? What tasks can be overlapped?
• What constitutes the minimum scope for getting the service up and running? What are the "nice-to-haves" on the task list that we can consider deferring?
• Is an outage truly required? Can we run the service from Server A while updating Server B on the same cluster and switch over, vice versa?
• How much can we do between maintenance windows? Does everything HAVE to be done during a service outage?
• How did you come up with the time frames for each task? What is this based on?
• If we pull in more resources, will this help or make everything more unwieldy?
• Does this long timeframe has to do with the way that the service is currently architected, and what can we do to make it easier to migrate in the future?

And so on. The point is that the PM's role is to keep customer sensitivities and interests front and center when evaluating their team's recommended approaches. In situations like this one, where the proposed solution will simply never fly with the business side, you have to push back. Get everyone in a room and ask probing questions, get a dialogue going, force them to think outside their usual comfortable pattern.

For example, if you've seen the Tom Hanks movie "Apollo 13," you might remember the scene where the NASA engineers on the ground have only a few hours to figure out how to maintain the capsule's oxygen supply, given a very narrow set of materials. The final solution, I recall, involved the use of duct tape. Hardly part of NASA's standard methodology, but their customers in orbit weren't able to wait for the perfect technical solution.

Almost every PM will have a day like this one at some point. A moment where the clock is ticking and you're frantically trying to facilitate a compromise solution like NASA's duct taped hardware. Where ploughing ahead with the standard nine weekends of service outages simply isn't an option, no matter how happy your technical team would be to do so. All in the name of meeting your customer's legitimate business needs. Embrace these moments. These are the experiences that will serve you well in every future effort.