by Phillip Smith

If you’ve ever watched an episode of Dirty Jobs then you’ve seen Mike Rowe get up close to some type of difficult and risky task. He usually reports on a sensationally dirty, greasy, goopy process that leaves him in need of a bath. While I suspect that he’ll never create an episode about IT project management, those of us in the industry know a dark secret: every day, we’re at risk of being slimed.

As IT project managers, we face risk and issues head on, often leading unproven project teams through difficult times to meet objectives set by a client with a limited timeline and budget.  We negotiate, we coach, and we deliver bad news.  We drive our teams like cattle and defend them like our firstborn.  We gather data that points to frightening conclusions, and then challenge ourselves to overcome.  We follow detailed processes and also make time for the soft stuff necessary to keep leadership, people, and clients synchronized. We’re surprised with ever-changing expectations, unforeseen expense, and impromptu meetings.  We travel, we sacrifice, and we deflect credit to the people that did the “real work”.

And when we tell our kids what we do for a living, they tilt their heads sideways and say something inspirational like “huh?”

At this point a sane person would ask, “Why do we do it?”  I’ll save that answer for a different article on a different day.  Instead, I’m going to explore some of the reasons this job is so demanding compared to other industries, and next week I’ll give you some suggestions for getting through its unique challenges.

Project managers in all industries have to overcome similar things that we deal with in IT.  However, in IT we deal with an extraordinarily large number of variables, and usually in their most complex form.

For example, the project manager on a construction project may be dealing with moving prices and availability for material and labor.  He or she may also have difficult deadlines, variable weather, engineering changes, multiple stakeholders, and perhaps even union rules to work within.  The good news for the construction manager is that the industry is mature, so variables that need to be managed are well understood and recognized by all parties involved.  There is also the fact that progress is visible, estimates are generally dealt with through commonly accepted algorithms (an example), and changes in requirements show up on a drawing.

The variables impacting an IT project are not always so straightforward.  Do you know the true cost of your labor when it is spread across multiple time zones, cultures, organizations, and the mix of that labor is in flux?  Do you know the true cost of a line of code that was designed here, written there, and tested by a 3^rd party?  Will your cost go down for the next line of code that is written?  Will a team’s expertise on a business domain area contribute to more reliable cost and delivery, and if so, how much training should you provide to them?  Do you trust the estimate that was done by an architect on shore, when the work will be led by an offshore tech lead whom you’ve never met?   Are the cost and timing efficiencies that the sales team committed to a mystery?  Are the requirements detailed enough to eliminate interpretation?  Is your reusable code really reusable?  Will your test case library meet your expectations?  Will the technology your project relies on most be outdated before it delivers value to your project?

I could go on with similar questions, but the good news is that when you boil it down, there is actually a handful of noble ideas that can be implemented to eliminate much of the variation and risk on a project. Next [week], I’ll tell you about the three keys to “clean” project management—three guidelines you can think of as your rubber gloves and waste high waders when things get messy.