Why many development projects take too long

Limit the number of concurrent projects to cut your product development lead time 

Many development projects take longer than planned. The automatic reaction is to add extra capacity. However, that is often not where the real problem lies. When too many projects are running at the same time, expertise becomes fragmented and delays occur. By carrying out fewer projects simultaneously, you can significantly reduce the lead time for your product development.

This makes sense, because a development project doesn’t exist in isolation. It shares specialists, knowledge and resources with all other projects that are in progress at the same time. It isn’t just the amount of work that determines the lead time: other projects are a significant factor too, as they draw on the same expertise. 

Too many projects slow down product development

If you launch more development projects than you can support at the same time, two mechanisms come into play that lengthen the lead time.

First, the available capacity becomes fragmented. Engineers, designers and testing specialists have to divide their time between an ever-increasing number of projects, so each individual project has less effective capacity. A task that could previously be completed in a single week is now spread over several weeks because the employee in question can only work on the project from time to time.

In addition, waiting times increase. Projects are put on hold until the right specialist is available again, colleague feedback has been received or results from other disciplines are obtained. As more projects simultaneously call on the same expertise, these waiting times increase and the overall lead time is extended even further. 

More projects mean longer waiting times

What is remarkable is that many organisations unwittingly create this situation themselves. When a major new development project comes up, the instinct is often to get it off the ground as quickly as possible. That seems to be making sense: the sooner a project starts, the sooner it can be completed.

However, such thinking only takes the new project into account: it fails to consider the impact on all the other projects that are already in progress. Every additional project relies on the same group of specialists, so the available capacity is spread even more thinly and waiting times for every project increase.

The question, then, is not just whether a new project is important enough to go ahead with, but what impact that decision will have on projects that are already under way. If you add an extra project without postponing other projects, you increase the load on the entire system, often with the result that, rather than any one project being completed more quickly, all projects take longer.

What this means is that the quickest way to complete an important project is not necessarily to start it straight away: it may be better to complete another project first, so that the new project can be carried out later when there is more capacity available. 

Limit the number of projects running at the same time

The most effective way to reduce the lead time of development projects is to deliberately limit the number of projects being carried out simultaneously.

As a result, the available capacity is spread across fewer projects. A simple example illustrates this. Suppose five engineers divide their time between five projects. On average, each project therefore has the capacity of just one engineer. If the same five engineers focus entirely on a single project for a certain period, that project can be completed much sooner. The entire capacity will then be freed up for the next project. Completing projects more quickly creates a continuous flow of work, rather than a large number of projects all progressing slowly.

What’s more, organisational complexity is reduced. There are fewer project meetings, less coordination between projects, fewer discussions about priorities and fewer arguments over the allocation of scarce expertise.

Consequently, project teams are able to focus on the same project for longer. As well as boosting productivity, this also strengthens the sense of ownership. Staff can see their project making visible progress, and feel more responsible for the end result. 

Start later and deliver faster

_{Figure: Why starting later doesn’t necessarily mean delivering later.} 

A common objection is that this approach means some projects will have to start later. This is true: having fewer projects running at the same time inevitably means that new projects may have to wait until capacity frees up.

However, a later start doesn’t automatically mean a later delivery. Because a project has greater capacity from the outset, faces fewer delays and can be carried out with greater focus, much of the time lost before getting started may be recouped.

As well as ensuring that more capacity is available, starting later also means that more information is available. Development projects rarely start with all the information to hand. Customer needs evolve, specifications are refined and new technological possibilities emerge. If a project isn’t started until another one has finished, it is often possible to work with more up-to-date information. The objectives are clearer, technical uncertainties are reduced and the likelihood of design iterations decreases.

Paradoxically, time to market isn’t necessarily lengthened by delaying: it can actually be reduced by only launching projects when sufficient capacity and sufficient information are available. 

Set clear priorities for projects

Even if you limit the number of projects you are working on at the same time, you will still have to make choices. Different projects will still require the same expertise and unexpected events will still occur.

This means that it is essential to set clear priorities. It must be clear to everyone at all times which project takes precedence. As soon as doubts arise about this, multitasking, waiting times and capacity conflicts start to increase again.

Clear priorities ensure that scarce expertise is always deployed where it has the greatest impact at that particular moment. They prevent staff from constantly switching between projects or trying to make progress on several projects at the same time. The result is a continuous flow of completed activities, enabling projects to move through the organisation more quickly and predictably.

A final note: priorities are only meaningful if they remain sufficiently stable. If they change on a daily basis, multitasking reappears and the benefits of focus are largely lost.

Use this simple rule of thumb: always have staff work on the highest-priority project and, as far as possible, avoid having different projects competing for their attention at the same time. 

Conclusion

The challenge in product development is not to launch as many projects as possible, but to successfully complete as many projects as possible. By concentrating your development capacity, you can cut waiting times and minimise multitasking. This gives teams more focus and enables your organisation to bring innovations to market sooner.