Best practices for successful IT project management

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

    Requires Free Membership to View

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.

Jonathan Hassell

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.

 -- J.H.

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 editor@searchcio-midmarket.com.

This was first published in April 2012

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.