How to prevent IT projects from failing

IT project management is far from an exact science. According to a 2018 study by the Standish Group Report “Chaos”, 31% of IT projects are halted before they are ever finalized, and never go live. Additionally, 53% of IT projects see their budget forecasts balloon by 189%.

With those stats in mind, let’s discover 4 little-known but very effective ways to avoid having your IT project fall victim to failure.

Rule n°1: Adding developers to a lagging project will just delay it further

Brooks’s Law (1975) explains how adding new developers to a pre-existing team of developers working on a delayed project will have the effect of delaying it even more.

The reasons?

• Communication becomes more complex as you add resources to a project.

• Doing so will disrupt the team, and this fact alone will add considerable delay to the project. New developers will have to take time to get started on the project, understanding its context and history, and to discover the code. This will consume the time of other members of the team.

• The team’s velocity will deteriorate. They might have to endure 4 to 6 iterations over 15 days with the new developer on the team to see the beneficial effects of the new resource on the team’s overall performance.

Of course, this all depends on the complexity of the project – its architecture, the skill level of the newcomer(s) and also the ability of team members to work together, etc.

Rule n°2: Do not overload the developer team

Another misconception is that eliminating downtime will increase productivity.

According to the queue theory, when the system is 100% loaded, the delivery time explodes.

We can replace the word delay with “lead time”. In agile, the lead time corresponds to the period during which a story is processed and finalized (the lead time corresponds to the time between when the story is created and when the story is finalized).

You should also know that the lead time is proportional to the cost of the delay. If software delivery time tends to infinity then there is a loss of value in terms of the downtime of what was supposed to be delivered at a specific time. In other words, the more the lead time increases, the more the software loses value over time. We could also call it a cost of non-use of features, which is proportional to the lead time.

If developers are loaded to 100% of their development capacity, then the time to complete a user story will tend to infinity.

For a team of developers to function optimally, all of the team members should be working at 80% of their maximum capacity. The bottom line is that when you unload a system, you can optimize how it works.

Rule n°3: Try to manage projects in sequence rather than in parallel

Putting one person on multiple projects at the same time is usually not the most productive method to opt for. Peter Bergman (2010) states that individual multitasking kills productivity.

Indeed, multitasking causes productivity to drop by 40% and results in a loss of 10 points in IQ (intelligence quotient) applied to the tasks.

A study by Rubenstein of Meyers and Evans says that managing projects in sequence (one after the other) rather than in parallel (at the same time) can reduce costs by up to 40% on the most complex projects.

Rule n°4: Understand that IT maintenance is an important step that requires investment

We often mistakenly think that the maintenance phase of an IT project is the phase in which we can afford to allocate less advanced – and above all less expensive – skills.

This is wrong: the higher the quality of the software, the more important it is that the maintenance phase is appropriately realized.

When software is widely used, over a long lifespan, the maintenance phase will need to be prevalent throughout the project.

According to Robert L. Glass (2002), maintenance activity can consume 40% to 80% of the costs of manufacturing software. This is arguably the most important stage in a project’s lifespan. Indeed, some will recognize their own situation in this statement: maintenance is more complex than the development phase.

When a team of developers takes over a project for maintenance they find themselves faced with a much more complex situation than they would if building a project from scratch. Indeed, when a team takes over a project, it must understand the work of the previous developers, understand the context of the project, its quirks and intricacies, etc. Taking over the maintenance of a project does require more specialized skills than simply starting a project from scratch.

With this in mind, we have noticed that we tend to assign our best profiles to taking over new maintenance projects. After all, maintenance projects require the most advanced profiles, and are therefore more expensive.

Do you want to know more about the teams of developers offered by Bocasay? Send us a message and we’ll get back to you on how to optimize your web, mobile or software development resources.