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?

  • There won't be a canonical answer to this question but a lot of observations and opinions, which I find valuable, but may not be compliant with the rules on this exchange. – David Espina Oct 25 '18 at 14:55
  • Otherwise, I think this is a great question to explore. – David Espina Oct 25 '18 at 14:56
  • That's a pity of course. – BigMadAndy Oct 25 '18 at 14:57
  • @385703 To clarify - you're asking what the statistical mean for project time overrun is over all IT projects in all fields? – Sarov Oct 25 '18 at 15:01
  • @DavidEspina, I had a look at other topics on here and many seem to be as "subjective" as mine. For example pm.stackexchange.com/questions/25113/… – BigMadAndy Oct 25 '18 at 15:04

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.

  • 1
    Completely agree - jobs are rarely won with realistic proposals & scope creep is inevitable as few people understand what they are asking for. Obviously the scope creep gives an opportunity to claw back money & push back the unrealistic original deadline! – amelvin Nov 1 '18 at 17:09

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.


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!)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.