Causes of Delays in IT Projects

According to the industry Up to 75% of software development projects fall behind schedule. Let’s found out the main causes of delays in IT Projects.

1.   Expansion of functionality- Moving Target or Requirements.

The expansion of functionality is a phenomenon in which new functionalities continue to be conceived and requested as the project proceeds. The software can never be completed in this way.

2.    Gold plating (Adding Extra features)

Gold plating is a phenomenon in which programmers and designers try to make many details of the software or design too elaborate. Much time is spent improving details, even though the improvements were not requested by the customer or client.

3.    Neglecting quality control

Time pressure can sometimes cause programmers or project teams to be tempted to skip testing. This frequently causes more delays than it prevents. The time that elapses before an error is discovered in the software is associated with an exponential increase in the time that is needed to repair it.

4.    Overly optimistic schedules - (unrealistic) Deadlines

Overly optimistic schedules place considerable pressure on the project team. The team will initially attempt to reach the (unrealistic) deadlines. These attempts lead to sloppy work and more errors, which cause further delays.

5.    Working on too many projects at the same time

Dividing work across many different projects (or other tasks) causes waiting times that lead to many delays in projects.

6.    Poor design

Some project managers assign work to developers in a haphazard manner. The absence (or poor realization) of designs leads to delays, as it requires many revisions at later stages.

7.    The ‘one-solution-fits-all’ syndrome

Using the right software for a project is important. Some software platforms are more suited to particular applications than others are. Thinking that the use of particular software will greatly improve productivity, however, is also a trap.

8.    Research-oriented projects

Projects in which software must be made and research must be conducted are difficult to manage. Research is accompanied by high levels of uncertainty. When software development is dependent upon the results of research, delays occurs.

9.    Mediocre personnel (Skills Shortage)

Insufficiently qualified personnel can cause project delays. Technically substantive knowledge of the subject of the project plays a role of the project.This could lead to significant delays in the development of software and systems.

10. Customers/End User fail to fulfill agreements

Customers are not always aware that they are expected to make a considerable contribution to the realization of a project. When customers do not react in a timely manner to areas in which they must be involved, projects can come to a standstill. Worse yet, the team may proceed further without consulting the customer, which can lead to later conflicts.

11.  Project approvals

Waiting for projects to get approved is the most cardinal of all sins as this usually has handfuls of developers sitting around twiddling their thumbs and is a blatant disrespect for people’s time. Coupled with this is the fact that waiting causes dissatisfied and disgruntled employees and only serves to ruin the culture in an organization.

12.  Waiting for a proper prioritized list of requirements

So that work can get started.

13.  Waiting for resources to become available

Generally impacts projects significantly. This one is not necessarily an easy one to solve as there are generally budgetary concerns. 

14.  Change approval processes

Ever changing approval processes are also the cause of I.T projects delay.

15.  Delays getting client to sign-off on acceptance tests

We have a services business and we find that this is a huge problem for our organization. Not getting sign-off is just a liability for the company as you're not getting paid until you get sign-off.

16.  Partially done work (In Process Inventory)

Partially done work is probably the biggest killer of all the wastes. Partially done work is essentially work-in-progress. The idea should be to complete work-in-progress as soon as possible i.e. minimize work-in-progress as much as possible. Examples of partially done work are:

* Code that is completed but not checked in to your version control system - if it's not checked in, you don't know if your code changes are going to break the build

* Undocumented code - If your code is undocumented, if the developer leaves and someone has to take over, there's going to take longer for the developer to get up to speed. Additionally, if bugs are found, it will be harder for the original developer to figure out what he has done. Taking the time to document your code up front while it's fresh in your mind can therefore save the company time and money.

* Untested code (both unit tests and functional tests) - if your code is untested, you won't know till the code is in your customers hands that there is a bug. The further downstream you are in the process the more costly it's going to be to fix the bugs. So if you build quality in from the start (like writing unit tests) you'll find out the moment you execute the tests.

* Code that exists on your staging environment and not your production environment - I hear this all the time - "works on my machine" - enough said. Only once you're on production can you be sure the software is 100%. Production always surfaces issues, so the sooner you get it on production servers, the better. 

* Code that is commented out - makes the software less readable and maintainable

17.  Task switching

The more things you throw at a developer at the same time the longer things take to get done. Studies have shown that if you're working on anything beyond two separate and distinct tasks, your efficiency goes down drastically the more tasks you take on.

18.  Poor communication and recording of knowledge

I am suggesting short summaries of information on key decisions you made during development so that if someone else has to take over or you have to come back to that code in the future, the relearning curve is not that great.

19.  Transportation - Hand-offs

Transportation in manufacturing corresponds to hand-offs in software development. Anytime you hand a deliverable off to a different party, there is some loss in the transfer of knowledge.

* Developer hands off to another developer. Documentation is very important.

* Developers hand off code to testers to test. Many organizations still don't engage QA early enough. If the QA has no idea what the developer did or the problems he faced or the assumptions he made, then the QA is really just shooting in the dark. It's important that the developer at least includes the QA early on.

* Handing the code over to deployment teams. Many times I find separate deployment teams struggling to figure out how to get applications deployed. Configuration settings, compile instructions etc. if not properly communicated can cause significant delays.

* Handing-off to customers. If the client is not trained properly, or the software functionality is not documented properly, there will be more support calls for example.