Saturday, 29 March 2014

Project Control

Working on a project recently, I found myself in one of those situations which a consultant hates.

The client had very clear time requirements. For various reasons the project had to be completed by a certain date.

But, right from the word go, the client's own managers seemed to forget that.


We started off very effectively. The project leader drew up a chart of actions with dates by when they needed to be done, and everyone agreed with what was proposed. We knew the project plan had a little bit of leeway, but we didn't want to use that up too soon.


Within a week we discovered that the data that had been promised wasn't available. Even when it did arrive it wasn't in the correct format. Extra resources brought in then could have minimised the effect on the project, but (despite warnings) no action was taken, presumably because someone knew there was some leeway, or believed we could all just work a bit harder later on.

But then something else went wrong, and the project slipped to the point where meeting the deadline began to look challenging. I held meetings with key project staff who agreed things were slipping, but client management had other priorities at that time and couldn't even meet up with us. Looking back I see now that no-one wanted to be the "bearer of bad news ", especially as it was still possible we would catch up.


Then it became clear that a relatively simple piece of work in one area was in fact more complex than anyone had realised.

So now we were in deep trouble!

How could we get the project back on schedule? 

Throw money at it? Accept the deadline was going to be missed?


It was agreed we would not do what had been agreed, and that we would "go live" with a system performing only 80% of what had been proposed, with the rest coming on-line in the following months.

As a consultant I hate this. The client is not happy. The developers are not happy. The users will not be happy. 

And the project leader feels control slipping away.

- o O o -

All projects have problems, and it is not possible to know in advance which ones will have most impact on the success or failure of the project. However there are a few guidelines which, if followed, will minimise risks.

To meet your project deadline:
  1. Be clear about what is to be delivered and the intended timescale. When in doubt agree to deliver less, or go for a phased implementation.
  2. Ensure everyone involved understands the time and budget constraints, and discuss in advance what the impact will be if the deadline is missed, and how any slippage will be handled.
  3. Prepare a detailed plan and make sure all involved have agreed that it is workable.
  4. Have an understanding of what resources are required for the project.
  5. Monitor progress carefully. When any slippage occurs, deal with it immediately. Discuss how it is to be addressed and the project brought back on schedule. Warn those who might be affected.**

** This last point is one I have seen ignored on many projects. When things go wrong, no-one wants to be the one who tells senior people the bad news. After all, they are very busy and believe you are coping. Everyone hopes the project can be brought back on to schedule. But if you don't start talking to them early enough, they can't help with resource or budget allocation when it is appropriate to do so. Asking later on for money or a time extension may not be appropriate.

Saturday, 15 March 2014

Why IT projects succeed (or fail)

Why do IT projects succeed or fail?

The Standish Group produces an annual report on the factors which affect whether IT projects succeed or fail. I've just been looking at the 2013 report, which contains some interesting reading. Here are a few quick points.

For example, "a large IT project has virtually no chance of coming in on time, on budget, and within scope".

In the case of small IT projects, "43% were challenged (late, over budget, or with less than the required features) while 18% failed (cancelled or never used)."

The good news is that nearly 40% succeeded!

They deem that the single most important area critical to project success rates is the competency of the executive sponsor, the person "who has the full weight and responsibility for the success or failure of the project squarely on his or her shoulders."

There are many other relevant points in this report, for example the importance of keeping projects small with clear borders. These factors are also relevant to other projects: see for example my article on Complexity Theory.

So what should we do about this?

How can we change the way we deal with IT projects so that we have a higher chance of success?

Firstly, expectations need to be handled appropriately. (See my article "What the Customer Actually Wanted".) The project scope needs to be clarified very early on, and a reasonable budget set.

Secondly, it is clear that the project sponsor needs to be given sufficient support to ensure that the project stays on track. That is where I come in. With my long experience of IT projects I know that the sponsor is typically very busy, without time for the necessary focus and often without anyone at their level to talk to about the project.

My strength is to be with them throughout the project, keeping them on target, adding weight to the project team, asking questions that others might prefer to avoid, ensuring that decisions are thought through fully and all issues are addressed.

Let me help you with your current or next project. Click on Contact above, and get in touch.

Saturday, 8 March 2014

Match processes to systems

Recently I've visited several companies to discuss their IT systems. 

One company had extremely impressive IT. They had adapted their systems to exactly match the company’s needs, using a wide range of the available features, giving everyone access to the files and reports they needed. The staff understood their software, and used it to achieve what they want. There was an enthusiasm about IT which I have found lacking elsewhere.

Some of the other companies I visited were quite different. Two had systems which should have been replaced years ago, but were still in place. They no longer met their users’ needs. The staff had battled on, but it was apparent that they were being driven insane by the shortcomings of their software. Such systems, which do not meet the business requirements, are a continual drain on all involved.

Now it is time for these companies to look for new systems (see “Selection of Package Software”).

However today I want to make another point.


My belief, which cannot be emphasised enough, is that a system installation is only truly successful when the users’ roles are redefined to make best use of the facilities provided by the new system.

When companies buy new software they often fail to use it appropriately because they neglect to change the way they operate. It is very tempting to continue in the old manner – slightly speeded up of course – with, perhaps, a few new reports. This might happen for various reasons such as a lack of management time, or possibly the users are comfortable with the old way of working.

But the real benefit to any organisation when new software becomes available (and this can include even Microsoft Office), is to look at the options provided by your new (or updated) software and be prepared to change how you operate. Amazing efficiencies can be achieved if you carefully examine the opportunities.

(For example, the ease with which files can now be shared among several users rather than each person having a different version is a simple process which has made many people better organised.)


So now take a good look at your software, even if you have had it for a while, and see if there are any features which you do not understand, or which might help to transform your area, department or company, and plan how best to make use of them.

Make sure all the users are trained in the software (even if only “Learning by Example”) and listen to their ideas about how you can make use of the new facilities.

Hopefully you will not end up like those companies I visited, with software which is completely inadequate.

And of course, examine your software regularly and be honest about whether it really meets your needs. If you want advice on this, just contact me.

© Copyright 2013, 2014 Cameron Somerville Web Designers Toolkit Websites