Delays in projects - what is normal on IT implementations?

Question

I have some experience in IT myself, but in a different type of projects, so I would love to pick your brains.

The context is that during conversations with some friends I had the impression that delays are completely normal during IT implementations. My experience of it is a bit different. We had some delays, but they were never more than 20-30% of the time planned for the project.

Now, imagine an IT project (implementation of an online platform). It started in mid-2017. The launch was planned for Jan. 2018.

Then it got delayed. First, just 3 months, then 1 additional month, 1 month... We are approaching Nov. 2018, the launch hasn't taken place yet. (No external, unpredictable factors contributed to the delay).

Is it normal in IT? Of course I understand that "normal" is a word that's difficult to define. But I imagine there are a lot of consultants and project managers among you, so you probably experienced some projects and can estimate what happens a lot and what doesn't. What is a typical delay (in %) on an IT-implementation?

Answer 1

My answer is based on my observations of IT work in the public sector. YMMV. What I have observed is quite a bit of project overruns, both cost and schedule, on IT projects in the space where I worked. The drivers in my view begin with initial proposals being far too optimistic--on the verge of totally fake--driven by some sense of price-to-win. In a scenario like that, it is nearly or totally impossible to meet initial targets in schedule or cost unless some significant compromises are made in terms of what actually gets delivered and the quality of what got delivered.

I would argue that is probably the leading driver. The next driver is scope creep. There seems to be a perception, I have noticed, that even with approved changes, results are compared with the original baseline. This is exacerbated, obviously, when you have a legitimate scope change but fail to pursue a proper change request that alters the baseline. The result is being late and more expensive. I think this is a secondary leading driver.

Finally, and I'll take heat for this opinion on this exchange, but project management in, say, capital type projects is very very different than project management in IT, with one of them being far far superior. Flame suit on.

Regarding what is typical, in my experience, I've seen projects come in on time with some quality issues to maybe a year out with most being around 3 to 6 months late. But a lot of that "lateness" was secondary to a choice being made NOT to pursue a CR.

Answer 2

I agree with David, there’s no canonical answer.

In my experience (I've worked mainly in the private sector), it depends a lot on the context of how this happens:

• Is the team fully able to work together? Have they worked for a long time together?
• Is the project something innovative? Or Do you have a clear understanding of what you want to do?
• Are most dependencies under the team’s control?
• Did you have enough time for planning?
• How experienced is the team?

“Innovative” projects by definition bring something that was not done before, hence they will meet with the unexpected and might imply delays.

“More normal” projects might be easier to estimate even when they are complex as long as you take enough time for planning.

Time estimates should improve when the team gets used to work together and also when they gain a better understanding of the project.

Personally I find constant delays a sign of bad planning/team issues. Even when there’s a delay, I think “everyone” see it coming and can act upon it.

Answer 3

To give an answer from the project portfolio perspective. If a project over runs a mile stone the project manager (PM) has a problem in his/her project. Managing weak signs of delay is an art PMs have to master as soon as they pass junior stage.
There are a lot of statistics and figures one I remember was 80% of IT projects overrun their budget by 200% and their time by 250%. But thats not what we should go for. It would be like 30% of all companies fail in their first year so lets go for that.
The art lies in having all the hard facts (which is easy) under control and play on the violin of social interactions (meaning with all relevant environments and not only the "stake holders") and within the project team. So if you plan for 15 months duration of the project and the going live is after 9 to 10 months, than you should ensure that you meet this timeline (and hit your 5-6 milestones). In the companies I worked in or for a deviation from an assigned and excepted time/budget/scope/milestone list meant for PM AND project owner to look for a "new chance on the labour market" (fortune 500 companies).
(IT) Project management is a business skill on its own and not a side task for an unmotivated (as a PM) developer.

Answer 4

There is no straightforward answer because milestone dates just aren't a good way of assessing IT project outcomes. Technology products tend to be delivered iteratively and continuously. Technical complexity is hard to define and is constantly subject to change and so it's inevitable that outcomes may look very different to what was forecast. That can be a positive thing and not a negative one however, so undue focus on one snapshot in time tells you very little. What matters is how soon you can start achieving business value, not when you stop doing it.

Answer 5

In a project that I recently managed – moving a manufacturer from "circa-2001 software running on a dying single machine, to an overhauled version of that software running on cloud VMs" – we actually reached "go-live ready" several months before "go-live" actually occurred.

The business elected to delay "go-live" until the moment that it judged to be "most risk-free," although this meant that the business continued to make changes to the old system which we were obliged to incorporate while retaining "go-live readiness." (Fortunately, the go-live still went off "absolutely without a glitch." Woo-hoo!)