Remember Microsoft Project? Gantt charts? Week-long stakeholder reviews? Successful IT project management in the '80s, '90s and even in the first part of the last decade was a horse of a different color compared with what it is today. The sad truth is that those techniques are not only dated, but also aren't successful IT project management styles any longer. Why? I see two big reasons why the traditional methods of project management have become obsolete.
First of all, IT project boundaries aren't as clear as they were even five or 10 years ago. What does finished actually mean? Projects usually are thought to have some type of conclusion wherein all stakeholders agree the project has reached a satisfactory state. Ten years ago, the process of building an internal application was finished when it was deployed and being used by a CIO's users: Install, run and that's the end of it.
Now the definition of finished is very fuzzy. Consider your customer relationship management (CRM) system. Is a Web application ever finished? You tinker, make minor releases, fix broken things without reshipping boxed copies, and solicit end user feedback right from the application. In the case of CRM or a Web application, what does finished really mean? Hitting project tollgates obscured by a heavy fog bank -- that's a challenge for even a very successful IT project management team.
Three guidelines for successful IT project management
In today's new management environment, the true art of project management is to integrate well between teams and team members. Here's how to do that.
- Cultivate a sense of ownership about the project's completion. Be crystal-clear in your vision, but also be receptive to feedback from the other end.
- Let team members define their areas of expertise and orchestrate the talent, not the road signs. Like a symphony conductor, establish the pattern of the music and coax the right sounds out of each section. Don't write the music for the players.
- Step out of the way and let team members do their jobs. Micromanagement is anathema; the project will flourish when your team members are able to execute at the top of their game. Focus on the outcome, not the journey.
Second, a CIO's business environment has completely changed. Project managers used to have months, if not years to deliver solid results and keep projects on track. They had some wiggle room for unanticipated delays, and their project teams weren't operating at 150% for extended periods of time. What's more, they might have been very particular about the discrete next actions that took a project from one milestone to another. It was simple to see (however, not necessarily easy to execute) the remaining work, and thus relatively simple to generate estimates of the time involved to complete it.
Today's CIOs run a different environment, one with significantly compressed timelines. Your services' consumers -- whether they're internal customers working with a line-of-business application or external customers getting services from you -- expect quick turnarounds and updates. A successful IT project management team is expected to deliver solid results in half -- sometimes even less than half -- the time. Moreover, your project team's work probably is going to be deployed to a user base instantaneously. That makes problems and issue and crisis response even more challenging.
Let's face it: Old-school project management techniques just don't work anymore. Your team members' attitudes have morphed -- and so have your stakeholders' expectations. In today's economy, a CIO can't afford to manage like it was 1999.
What's the solution? Believe it or not, the solution is a little more freedom. Today's IT developers and artists work better when they are given the freedom and the space to work within loosely defined boundaries. As a CIO, you're responsible for setting a project's vision and expectations. Your project managers should define various milestones, then solicit the input of developers and artists working on a project about the time required for progress. But here's the fun part: Allow those groups to chart their own course forward without having steps prescribed for them. This bottom-up approach allows developers and designers the creative freedom to get their work done on compressed time frames while it maintains a CIO's ability to clearly define the expectations of a successful project.
Jonathan Hassell is president of The Sun Valley Group Inc. He's an author, consultant and speaker in Charlotte, N.C. Hassell's books include RADIUS, Learning Windows Server 2003, Hardening Windows and, most recently, Windows Vista: Beyond the Manual. Write to him at firstname.lastname@example.org.