Executives In Training?

Can a project management career path eventually lead to the corner office? From what I've seen in my own organization, PM experience is more highly valued than ever when it comes to climbing the corporate ladder. And technical skills have little to do with this.

To begin with, project managers can get a fantastic strategic perspective by working across the length and breadth of their organizations. No silos for US. You may be a technology PM, but your projects can immerse you into the arcane worlds of marketing, supply chains, procurement, human resources, facilities, vendor management, and legal contracting. Every time you design an IT solution for a business, you learn a surprising amount about how that business operates.

The next advantage flows from a project manager's basic talents. The negotiating, influencing, planning, risk management, and budgeting abilities required to deliver complex projects mirror an executive skillset. In an article in The International Journal of Project Management, Linda S. Henderson observed that "projects are incubators for the development of future leaders. Experience on project teams often tests a wide variety of skills and behaviors." None other than Harold Kerzner concurred, noting that "project managers already consider themselves to be executives on the project, and naturally expect their next steps to be as executives in the company." More evidence is provided by CIO Insight magazine, which surveyed thousands of IT executives in 2006 and found that 82% of CIOs had been project managers at one point in their careers.

Those project managers with superior interpersonal skills, however, may have the decisive advantage. The aptitude to manage conflict, instill trust and team unity, sense and address unspoken emotions, ask incisive questions, please clients, work across international borders, and solve problems collaboratively is vital at the next level. Catherine Daw notes in her article Turning Successful Project Managers Into the Executive Leaders of Tomorrow, for example, that "the ability to influence, motivate team members, and achieve significant project results through a team are all key skills that successful project managers have and executive leaders require."

Daw also observed that while project managers often enter the field due to their technical abilities, they are quickly called upon to display executive behavior such as "more clearly understanding the corporate objectives; gauging the big picture; dealing with executives as sponsors and being able to draw teams from disparate departments and geographies together to deliver specific business results." While technical skills remain important to simply getting the job done, the interpersonal and leadership abilities demanded of project managers are truly essential for moving up the career ladder.

In some sense, as Kerzner noted, project managers are already executives. Every cross-functional project is like a mini-organization. No surprise to me that project managers are finally getting rewarded and promoted for what they've been doing all along: successfully leading people toward a common goal.

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.

How Technical Does a PM Have To Be?

Ever volunteer to speak at a school "career day?" Try this some time if you want to test your presentation skills in front of a demanding audience. These events feature everyone from chefs to cops, all of whom try and explain their job routines to 7th and 8th graders. Trying to engage these kids with a discussion of IT project management can be a tough sell.

My approach was to lead off with a slide showing a firefighter, a baseball umpire, and a symphony conductor. I would then explain how a PM's day was a mix of troubleshooting, coordinating, and mediating. But the conductor, I would add, is the best metaphor for the job. You don't necessarily need to know how to play the violin or the trombone. But you have to make sure everyone is playing the right notes and at the right pace, for starters.

In retrospect, I should have added more to this. The conductor who can grab the bow and nail Shostakovich's Violin Concerto No. 1 is indeed a rarity. There are still certain expectations, however, for the guy who waves the little stick. Conductors need to know the technical terms that the violinist uses (which are different from those of the cellist or trombonist), proper bow and finger placement, perhaps even the application of the Suzuki method and how often to apply bow rosin.

And so it is in the IT world. Never wrote a line of code, set up a server, or designed a user interface? Well you can still be an excellent project manager, even if you've never programmed anything more complex than a VCR. You simply need to have a base level of knowledge that can give you credibility with the team and allow you to make informed decisions.

Your credibility begins with simply getting things done for the project team. If you can successfully escalate issues, drag in needed new resources or information, and smash through bureaucratic logjams, you can win respect from most. But dedication and problem solving is only half the equation. You also need to speak the language of whatever architecture/technology/domain you are working with, know the common issues and risks, understand requirements and design docs, and be able to diagram the workflows and how the pieces fit together.

The depth to which you need to know all this may depend on the size and complexity of your project. In larger projects you'll probably have lead designers and architects to lean on, for example. But the one constant is that you will often need to mediate team debates over technical approaches, and explain to your boss the pros and cons of each angle. You'll have to write cogent minutes and other communications that accurately reflect technical decisions and issues. You'll need to identify when a design approach may have upstream or downstream system impacts (this is crucial, since your team members may only be thinking of their own application realm, not the big picture....that's YOUR job.)

Over time and through osmosis, you may learn just enough to be dangerous.

So, You Want To Be A Project Manager?

You’re not alone. The past few years have seen an explosive growth of new PMP (Project Management Professional) certifications. According to Allan Hoffman at Monster.com, there are now about 181,000 certified PMPs, 12,000 of them in IT.

I’ve lost count of all the developers, testers, and even product managers at my company who have asked my advice on how to make the switch to a technology project management career. Outside of work I get these questions as well. One oblivious friend of mine actually lectured me on how easy the job must be, since all PMs seem to do is make schedules and set up meetings.

Really? Who knew.

I’ve been an Information Technology project manager for twelve years. I work at a large corporation in the San Francisco Bay Area which I’ll keep anonymous for obvious reasons. In 2001 I earned my PMP and two years ago I completed my MBA. As a director-level PM in my current organization I’ve managed projects with budgets up to $17 million, usually several at a time.

I like my job, and here’s why:

• The constant variety. No two days at work are the same. Rarely are any two projects the same, at least in my world.

• The mix of left and right brained skills required. Emotional intelligence and savvy negotiation ability are as important as your capacity for financial and technical analysis.

• A sense of completion and accomplishment. Once your project is wrapped and your customer is happily using their new application, network or hardware, it’s a great feeling. For operational managers, such moments can be rare (trust me on this, I used to manage an accounting department.) A project manager in my company closes a project every six to twelve months.

• Education. Every day at work is like being in technology school. Projects are fantastic opportunities to learn through osmosis. It’s unavoidable. As an undergraduate liberal arts major, I never took a single programming class, but today I can actually have an intelligent conversation about data warehouse architecture or middleware configuration or business intelligence system design. Who would have thought?

• (I’m also fortunate to work with people I like, and a boss who trusts me to get things done. These two factors certainly make life much easier.)

But as to my friend’s comment about project management being a picnic, I respectfully disagree. For starters,

• You have Responsibility without Authority. In a matrix organization, which most big corporations seem to embrace, a project manager doesn’t have any direct reports. People are “borrowed” from other departments (development, QA, documentation, hardware, etc.) for the duration of the effort. They may be working on several project simultaneously, and you may find yourself horse trading with their manager for their time. The loyalty of your project team could be stretched in a half dozen different directions.

• You’d better enjoy being a control freak. If the guy in Singapore who was supposed to test the firewall ports for your server never followed through, look in the mirror if you want to blame someone. You should have known to have someone follow up on HIM.

• IT PM’s spend a big chunk of time firefighting. Especially when you’re working with new technology, be prepared for thorny system issues that have your developers scratching their heads while the customer screams about the delays. You better have the salesmanship (and internal network) to escalate these issues quickly and get enough resources on the problem.

• In many organizations with a mature PM structure, management puts as much stress on complying with paperwork and methodology as on successful project delivery. You’d best make sure your presentations are formatted correctly, that the right documents are in the right folder in your sharepoint directory, that customer signoffs are property documented. If all this sounds too trivial, controlling or exasperating for you, then you might want to consider another line of work.

• Scope creep, shrinking budgets, resource contention … the bread and butter of a PM’s day. Especially in this fun era of layoffs and cutbacks.

That’s just a taste of it. The purpose of this blog is to give those of you who are considering making the switch to a project management career some insider advice about life in the PM trenches. So we’ll dive deeper into these issues and more in posts to come. Feel free to email me with questions or topics and I’ll be glad to give you my perspective.

IT project management can be an immensely rewarding career if you have the right mindset and are well prepared for the inevitable headaches. Hopefully I can help you decide if it’s the right career for you.