Don’t rush your projects
There are many statistics showing that IT projects are being delivered late and over budget. Believe them if you want, but according to the managers we speak to they are not really representative. What I do see though, is that the larger the project, the more likely it is to go off the rails. Maybe, then, we should be breaking down our projects into smaller sub-projects. One of the best pieces of project advice, is to deliver value in a continual stream, rather than wait for a miraculous event in a year’s time. This allows users to get to know a new system, and can provide important input to improve the next phase.
The vast majority of IT projects are given the go-ahead, work starts on them immediately. Most of the time they go live on the date that was estimated. Maybe, though, that isn’t what we should be doing. There is a danger with this, and it has some relation to the personality characteristics of IT professionals. Most IT professionals are Myers Brigges type ST (60% from our assessment). This means that they see the world in terms of problems and solutions. They like to identify problems so they can go ahead and solve them. And, the sooner they can find a problem, the sooner they can work out a solution.
For most companies then, the projects that are given the go-ahead first, get implemented first. And most of the time the project timeline describes how the project can be delivered as fast as possible. But then updates need to be made; changes come are identified by the users and the perfect timeline never seems gets met. And the fact that we are always behind the perfect schedule, means that there is a danger that as we rush to do these projects finished, to catch up on the impossible timeline, then we never do them as robustly as we ought.
Yes, part of this is because we didn’t think through possible and even likely contingencies that needed to be taken into account. And also, new requirements have been identified by the business stakeholders which are now essential for a project to deliver the best value. Instead of rolling their eyes, IT managers should recognize that these are often perfectly valid. The business requirements have changed because of different market conditions from when the project was approved. Perhaps a competitor is launched a new product, perhaps there’s been a change to the regulations.
The other problem with doing projects as soon as possible is that we don’t lift our heads above the parapet to see if there on some more important projects that have been approved later with a more significant benefit that are being put on hold because they were first in line to get approval.
It often makes sense to take a bit more time, to do it once and do it right. An old manager of mine used to say, we never have time to do it properly, but somehow we always managed to find the time to do it twice. And you know what, this is the fault of IT managers and business stakeholders. They put pressure on the business case owners to deliver the business benefit as soon as possible. It is easy to demand this, thinking that it is helping the business, and that they are being tough and effective managers. In fact, the approval committee needs to recognize that the value will realistically take longer to be delivered, and therefore the business case needs to be slightly de-emphasized. And if this means that the business case return falls below the threshold, then maybe they should step up and not approve the project. It will probably free up valuable resources to do a better project waiting in the wings.