Shouldering project management responsibilities isn’t for the average Joe or the fainthearted.
It requires people who have a relentless, or one might even say obsessive-compulsive, attention to detail. They must also be thick-skinned individuals, willing to withstand verbal barbs, insults to their genealogy and possibly some old-fashioned assault and battery from people tired of being prompted for their part of the project.
“It’s a tough job with long hours and stress that needs someone who’s a cross between a ballet dancer and a drill sergeant,” says Richard Murch, author of Project Management Best Practices for IT Professionals (Prentice Hall PTR, 2000).
I think there’s one more trait to look for in great project managers: They must be a tad bit larcenous.
That trait comes in handy when using project management tools. First-tier project managers know when to override or ignore thresholds on deliverables. They know how to beg, borrow and steal other resources without accounting for them. They know when and where to overspend. And they know how to spin the details to upper management. In other words, they can cheat and get away with it.
Murch, like many others, would vigorously disagree with me. He argues that today, project management tools and exacting training programs make project management a serious, proven discipline that will reap significant ROI. The field is populated by serious, professional practitioners who use tools and techniques in a highly rigorous and logical fashion.
I don’t disagree. Without a well-conceived and well-run project management system, an organization, especially a large one with many ongoing projects, will devolve into chaos. But the best project managers aren’t single-minded about the tools they use or even the business processes involved. Slaves to project management systems often make excellent workers on a project team, but they tend to be lousy managers.
I developed this theory in my past life as director of the largest independent PC-testing lab in the U.S. We ran lots of projects — some large, some small, some straightforward and others mind-bogglingly complex. Some projects took a couple of days; others would run for months. Every project had its constituents. Some you liked to work with. Some you didn’t.
Each project was assigned people with an array of talents. And each had its manager, budget, deadlines and copious reports.
Every project also had its bumps in the road, crises, angry encounters, wholesale catastrophes and even the occasional lawsuit — not necessarily in that order.
We used many tools to oversee projects. And we created new ones when necessary. We had countless meetings about process and then codified agreements into project management systems.
Despite all the pain and anguish, projects did get done. And I noticed that the highest completion rates and deadline achievements were those projects whose team leaders understood the value of skullduggery.
For example, testing new software, operating systems or networks usually involved standard-configured clients and servers. While a technician ran a benchmark or an application suite for compatibility or performance data for one project, a clever project manager for another effort conned that technician to run a different benchmark on a nearby test bench. Instantly, that manager’s project got new resources, and the tracking system never knew a thing.
One might argue that the data on one or both of those tests was flawed because resources were used and not factored in. So you can bet when I heard about the fellow’s practice, I called him into my office and asked him how he dared do such a thing. Then I suggested that he instruct other project managers on how to leverage the idle time of other testers and continue to bypass the system.
Another project manager was known to get his team together after hours and physically move machines from one test area to another to bulk up the test loads for server evaluations. In theory, the team would sneak the purloined systems back in during the wee hours of the morning. But not everything was always properly reconnected, and there was grumbling among the less-resourceful project leaders.
Yet once uncovered, the wisdom of the thievery became obvious. So we built mobile testbeds with pre-wired clients and servers that could be easily added and removed from any test area. It saved us money and improved completion rates.
So the next time you’re interviewing candidates for a project manager’s position and you need a really great one, you might check their rap sheets — and hope you find something.
Mark Hall is a Computerworld (U.S.) editor at large. Contact him at mark_hall@computerworld.com.
