Agile vs. Traditional IT Project Management – Using The Right Tool for the Job

This article was published more than 1 year ago. Some information may no longer be current.

We’ve all faced IT projects that haven’t met expectations (perhaps even a disaster like the Canadian Federal Government’s Phoenix pay system). We put in place quality assurance processes to try to learn from our mistakes and avoid future problems. What root cause analysis tends to tell us is that the failure of a specific project may simply be due to not following the IT project management process right. But the failure of multiple projects is usually a sign of not following the right IT project management process.

The Best Approach to IT Project Management

When it comes to the important task of managing IT projects and services there are two quite different methodologies:

  • Traditional (e.g.  using ITIL or PMP standards)
    • Managed processes and documentation (lifecycle documents)
    • Emphasis on planning, risk management, standardization
    • Carefully planned/staged delivery
  • Modern (e.g.  using Agile or DevOps guidelines)
    • Lightweight processes and documentation (user stories)
    • Emphasis on client/end-user engagement
    • Incremental delivery of software

Between the planned, managed traditional approach and the lean, flexible modern approach, which is better?  Of course, it depends on the project!

If a particular service or project is mission-critical with fixed requirements than traditional processes are usually appropriate. If, on the other hand, the success of a new project or service upgrade requires ongoing user engagement and feedback then modern agile processes are the way to go.

One Size Doesn’t Fit All

Unfortunately, many organizations fall into the trap of adopting a “one size fits all approach” to IT that can lead to project failures. It’s human nature for teams to become over-reliant on the skills they’ve trained for and honed, regardless of whether they actually suit the situation. The cultural tendency (which may sometimes border on religious zeal) is to use the same project management hammer regardless of whether they are trying to drive nails or turn bolts.

To avoid this, IT projects and services should be assessed using three characteristics:

  1. Size/complexity
  2. Risks and constraints (eg. security, usability, time-to-deploy, budget
  3. Uncertainties and unknowns

A clear-eyed evaluation of these characteristics will point to the right project management process for the job.

So next time you’re stirring the ashes of a failed IT project or service, consider whether it’s indicative of a larger issue. Are your projects and services not consistently meeting expectations because the wrong process approach is sometimes followed?

Try applying a project assessment filter before diving into the work. Perhaps process changes are needed? Perhaps your team needs to diversify its project management skills to confidently accommodate the variety of work they face?  Better to add a new wrench to your team’s toolbox than throw a wrench into your next big IT project!

  • Categories