The success (or otherwise) of IT projects is often difficult to measure; it's even harder if you have no clear idea of the results.

A successful project (IT or otherwise) should meet a few goals:

• be delivered within the agreed time-frame
• be delivered within budget constraints (resources and costs)
• cover the project deliverables
• achieve the required project outcomes

The first three of these are generally included in the project plan (if you don't have a plan stop here) and can be monitored by normal management practices. The last one (outcomes) is more difficult; it is usually left out of the planning stage and only rarely measured after completion (in my experience).

Do you know where you're going to? [1]

You don't need a website, database, hardware upgrade or software package; you need to solve a business problem.

Sometimes it's easy

In some cases that problem might be simple "We have to upgrade to a more current software version to keep compatibility with clients/vendors etc", in which case the completion of the project deliverables is the goal.

Here success is easy to measure.

But not always...

For many projects there is a cost/benefit equation - "If we do project X at cost Y we will gain Z", so long as Z>Y the project is worth doing.

There are two problems here:

• Estimating the expected benefits.
• Measuring the outcomes.

Planning phase

The project business case (the cost/benefit justification) is a common part of many project management practices.

This is a Good Thing and covered well in other places [2] so I'll skip over that part.

Review phase

This is where things fall apart.

It's easy to measure costs and deliverables (so you can tell if you met the project targets) but harder to measure benefits. Not only are some benefits intangible, but most require time to achieve - for instance, the efficiency gains of a new software system may take months to be realised.

Of course if you can't measure the outcome, your business case probably depends on guesswork (a cynical person might suggest that this is partly why people don't review outcomes - it would reveal their plans as works of fiction).

What to do about it

In your project plan:

• Include measurable expected outcomes in your project plan [3]
• Ensure that the resources are available make these measurements after implementation
• Allow for at least one post-implementation review to

Planning is not enough, you have to actually do the measurements and review them against the project requirements.

Your project might be finished, but it is not a success unless it produces the outcomes required.

References

[1] It's not bad grammar, it's a film reference

[2] Wikipedia article on Business cases

[3] Wikipedia article on KPIs