Where do delays in IT projects come from?
Grzegorz Papaj, 12 June 2019
Exceeding the deadline is a quite common thing in IT projects. The Pmreaserch.pl research shows that, as many as 61% of projects are completed over time, just 33% on time and only 6% ahead of schedule. Thereby, the assessment of the effectiveness of project implementation by commissioning party is usually quite low. What are the reasons for delays in IT projects? Find out what to keep in mind to assure your software project is finished on time.
Challenges for the contractor?
When it comes to project delays, most often it is the contractor who is blamed for any setbacks. In many cases, rightly so, but not always, as we will present later. Now, let’s look at the most common mistakes made by programming services providers.
Most of the causes for delays occur even before starting the IT project, i.e. during the initial analysis. At this stage, it is necessary to estimate how much work and time will be required for the project to be successfully completed, i.e. in the given scope, time and budget. It is known that such forecasts are always only an approximation and their precision decreases as the size of the project increases. So the chances of correct estimation are reduced by the scale of the project. Of course, the risk of estimation error is also increased by the lack of the experience in implementing similar projects. Term “similar projects” refers not only to the business or technological specification of the system. Its scale is also important, because developer working on a system with 10.000 users faces completely different challenges than a creator of system, which is used by 100 users.
Underestimating the difficulty and complexity of the project is a separate problem. It is a common mistake for novice programmers who often don’t recognize the complexity of problem presented before them. If the team doesn’t have experienced specialists who have already faced similar projects, chance for not even delay, but total failure of the project increases dramatically.
It is quite common for clients to relentlessly claim that their design is “small and simple”. This way (more or less consciously) they press on the supplier to lower the implementation price. Unfortunately, even experienced programmers sometimes succumb to customer suggestions and accept optimistic, instead of realistic, estimation under customer pressure. It leads to narrowing (or even complete skipping) safety margins included in the estimation. As a result, not only do delays occur during the implementation, but also numerous tensions appear on the client-contractor line, when both sides start to accuse each other. Most often underestimated aspects of IT projects include, for example, all kinds of integration with external systems and not taking into account system loads resulting from e.g. large number of users or records in the database.
On the other hand, delays at the stage of developing a programming project are often caused by communication problems. They can occur both inside the programming team (or for larger projects between teams) and on the client-contractor line. Although it might seem that in the second example the blame is on both sides, it is not always the case. After all, it is the contractor who routinely runs projects, so he is more responsible for most communication problems. An experienced contractor should sense them at the an early stage and put efforts into improving communication with the client. For example, run the project with Scrum or related Agile project management methodologies.
Of course, failure to meet the project deadline can also be caused by “standard problems”, that arise during implementation, and unfortunately are not always predictable or avoidable. They vary in nature – it may be the key member of the team falling sick, considerable technical problem discovered during implementation or a gap in the specification provided by the client. Using aforementioned safety margins in estimating time and costs prevents such mishaps.
Although it is usually difficult for customers to acknowledge, delays in implementing an IT projects can also be caused by their actions or omissions. The most common problems come from communication sphere. If client needs are not sufficiently detailed, the risk of error in time (and costs) estimation increases, creating additional tension during implementation. This is often due to the client’s downplaying their own expertise in the given field. For the commissioning party, a lot of aspects of domain knowledge that affect the final shape of IT system are obvious. We have to remember that even the best programmer can be a complete layman in the client’s business area. Although the team of programmers know how to build given system from technical side, the client is always the specialist here. Lack of sufficient commitment and erroneous assumptions that some things are just “obvious” are a straight path to incorrect implementation and significant delays.
Another common difficulty during project implementation is the client’s inability to make key decisions. As the work progresses, the project team faces a number of technical and business choices. While it is possible to rely on the contractor’s expertise in technical matters, it is more difficult for the client to make decisions concerning business matters. The choice between possible solutions, should be made by the client who knows the specific of their business. Unfortunately, clients tend to take a lot of time making such decisions. It is often necessary to involve many people, or sometimes reconcile the expectations of various interest groups (e.g. different departments). As a result, work in some areas of system development may have to be suspended. This situation can result from indiscriminate business concept that the system has to implement. Sometimes, a person with insufficient decision-making power is delegated to coordinate the project on the client’s side. At this point it is worth emphasizing once again that an experienced contractor should minimize delays which can result from client’s lack of decisiveness. But in many cases they are still unavoidable.
Despite appearances, the members of the programming teams also notice when the delays come from lack of client involvement, which can manifest in different ways. Except mentioned lack of decision-making abilities, clients contribute to delays, e.g. by not delivering promised, and from the development point of view, crucial information or system components on time. It can be for example the server to host the system, access data, API for communication with other programs or specific equipment which the system has to be integrated with.
Another example of lack of commitment is avoiding testing early prototypes. Although it may be a time-consuming task, it gives invaluable benefits for the client too. Early confrontation of the contractor’s ideas with expectations of the commissioning party allows both parties to avoid misunderstandings at the first stages of the system’s development. Of course, delays can also occur at the stage of final testing. If the client has not tested prototypes, then this is when they get to know the system. Often, only then do they discover that the client tests of the IT system are a major undertaking and they cannot be done in one afternoon.
Unfortunately, if there are delays, regardless of their source, there are always consequences. Most often these are the business damages resulting from delayed system startup, but sometimes also various types of shortcomings and problems caused by creating the system “quickly”. In extreme cases, this can lead to creation of unfinished projects.