There's No Such Thing as an IT Project!

By Andy Burrows

[First published 11th March 2017]

“There’s no such thing as an IT project. All projects in business are business projects.” That was a tweet I put out a while back. And it drew a response from a young programmer.

“By the same logic, there’s no such thing as a construction project either. Erecting a new office building is pure business,” he tweeted back. And the exchange continued.

So, I thought it might be good to explain what I mean when I say that there’s no such thing as an IT project.

Why Pick on IT?

Firstly, why pick on IT?

Well, in business circles over the last 50 years it has become common to think of IT and software development when talking about projects. If you say the word ‘project’ in a business setting, people will think you are talking about IT. The reasons for that are probably related to the fact that methodologies developed for running projects, such as PRINCE2, initially applied to projects involving software development or implementation. And so, it was IT managers who were first encouraged to take up project management roles.

When is an IT Project Not an IT Project?

But the problem isn’t that we’ve forgotten about the projects that don’t involve IT – the construction projects, the writing projects, the movie making projects, process re-engineering projects and renovation projects.

The problem is that shortcut terminology means we often lose sight of why we are doing our projects. We don’t do an IT project to deliver a new system. We do it to deliver a business benefit. Perhaps it will give better information to enable better decisions. Perhaps it will eliminate rekeying of data from one system into another. Perhaps it will enable customers to manage their accounts more easily and improve retention. If it doesn’t do something to enhance profitability, at least over the long term, why would a business do a project?

So, we don’t just do IT projects in business so that we can have nice shiny new IT systems. And if we just focus on delivering the system, because it’s an IT project after all, we risk several problems. 

What Could Possibly Go Wrong?

First, we may neglect the people whose jobs will change because of it. The programmers will say that all they were asked to do was to write some new software and make it available. But new software doesn’t do anything until people use it. And people don’t use software they don’t know how to use or don’t know anything about.

Second, we may fail to get the benefits we wanted. For example, we may spend $100k developing new software that will automate a manual process that currently occupies four people full-time and therefore costs $100k per year. The aim is to reduce the costs of running the business. And on the face of it, it’s a great investment. But if no one tells those four people to stop the manual process, or if they don’t get redeployed or made redundant, then we won’t have saved any money.

If it was just an IT project, just the delivery of new software, then the crucial part that would crystalise the benefit we were aiming for wouldn’t get done.

So, projects that involve IT change almost always involve process change, and a need to communicate well and inform/train those who will be impacted by the change. So the project itself is not just about IT change, but about a business change that involves both programming and changing what people do. Projects bring about change that is deeper than just IT.

Third, scoping decisions go wrong when all we focus on is delivery on time and under budget. And that’s all that IT programmers are tasked with. But during projects, some elements take longer or cost more than expected. And the project manager has to make a decision whether it is still possible to go live on time, and whether the costs can be contained. If not, the overrun can either be accepted or the scope of the project can be reduced. Thinking of the project as an IT project, delivering an IT asset, will push towards reducing the scope and just getting something in on time. And sometimes the lost scope will reduce the benefits of the project. In other words, the software users may say, “it’s not what we wanted and it’s not much use to us now”. If we keep sight of why we wanted the IT change - the benefits - then we’ll make sure that the scope never excludes the elements that will deliver those benefits.

That means continually being aware that it’s a business project, aiming at business benefits.

In the Year 2000

The two analogies I’ve used in the past are the Millennium Dome (now The O2 Arena) and the London Eye. Two Millennium construction projects. Which was the more successful? The Dome, which came in on time and on budget, and underachieved its visitor projections by 50%? Or the Eye, which delivered several months late (not in time for the Millennium celebrations) and well over budget, but exceeded everyone’s expectations in terms of visitors? 

The London Eye is now the top London tourist attraction. But from the project point of view of view it could have been deemed a failure, if we were just focussing on time and cost.

On the other hand, from a project point of view, The Dome’s project management delivered what was asked – a striking building and the regeneration of the Greenwich Peninsula. But it didn’t deliver enough financial gain to pay for it. (Obviously since 2001 things have moved on, and the very successful O2 venue is now an established part of the London entertainment scene. But that wasn’t envisaged until well after the end of the Millennium exhibition. Which goes to show that all is not lost even when a project/strategy initially under-achieves.)

The point is that successful projects are those which deliver the business benefits we’re aiming at (as well as not taking too long or costing too much).

Controversial Conclusions?

Coming back to IT projects, how does this affect the way we run them? Two thoughts:

First, the achievement of explicit business benefits (detailed in the business case) should be part of the project plan, in my opinion, and not left to chance after the delivery of the new asset. That puts an onus on the project manager to be more closely linked with the business areas and stakeholders affected. It also influences the nomination of the project sponsor and the members of the steering group, and, in fact, the project governance structure as a whole.

Second, just because a project involves IT, and can be called an IT project, does not mean that IT should be responsible for managing the project. In one of the projects I was involved in, senior management explicitly said, “this is an IT project, so the IT Director will be responsible for the it.” I knew we were headed for problems as soon as I heard that. And as expected, the pressure to deliver by a certain date overrode everything else – planning, project control, risk appetite, testing and scope. No one mentioned project benefits, or referred back to why we were doing the project. And the project was finished a little late, and the mopping up and remediation afterwards were absorbed quietly in “business as usual” operation. From an IT point of view the project certainly broadly did everything it was supposed to. But who knows whether the intended benefits were obtained by the end of it.

Thus my other controversial saying: “Making IT manage a project just because it involves computers is like a plumber managing a construction project because it involves toilets.”

But the big point, as usual with my thinking, is to change our project management mindset: Focus on why you’re doing it; Focus on the benefits you want; Plan for realising the benefits, not just building/implementing a new system.

Related Posts

Don't Waste Money on Projects (The Purpose-Driven CFO Part 5)

7 Things Finance Can Do to Help Projects Succeed

Free downloadable resource

The Projects Partnering Healthcheck Tool - to identify where can you do more to support projects as a Finance Business Partner