When to compromise on a project

Mike Acaster
November 26, 2014

It may seem strange to consider compromise on a project because, surely, we start out expecting to deliver on time, on budget, to quality expectations and to meet all the requirements. After all, if we thought we’d fail then we might not even start. So why compromise?

When we start a project there is usually a phase of defining what is required and what the benefits are. Gathering requirements can be a challenge in itself; perhaps the objective is not clear. But I hope we all can recognise being in workshops to uncover the requirements only to feed off each other’s ideas. The danger here is that the requirements grow and grow; without prioritising the requirements they all become ‘must-haves’. The product produced then will have features we may never use or are not really required.

I think we have to be realistic in determining what the minimal viable product is and some of our pet desires may have to be compromised to achieve this. Think about it: how many of us have gadgets that we rarely use or use only about 20% of their functionality at best?

Prioritisation may not always be straightforward but techniques like MoSCoW analysis helps all involved in the project to determine and understand what is necessary, what is only desirable and—equally important—what the product won’t do.

The project may also face a variety of options that could deliver an acceptable output. The project therefore needs a means to determine the best option. This could be done by considering the value of the project output for each option. At its simplest, this can be reduced to considering the balance of benefits, both tangible and intangible, against the cost for each option. Therefore, the project could determine the best value for money solution.

This can be expressed as:


No organisation has a bottomless purse hence the best compromise must be struck to achieve the best value from the investment in the project. There may be times when we want the Rolls-Royce solution but our budget may not stretch that far. Consequently we sometimes have to compromise our ambition because of budgetary constraints. So, perhaps we have to compromise our ambition to match our means. That is not the same as saying we should not be ambitious or seek new and innovative solutions but, rather, reality creeps in and we must cut our cloth accordingly.

Back to business

One of the principles within PRINCE2® is that of ongoing business justification. If the justification is no longer there then the project should be closed down and any project assets protected. I accept it is probably an apocryphal story but I am reminded of the rush to go into space and the need to be able to write in zero gravity. The Americans invented a pen that could do that while the Russians used a pencil. Clearly, we should not lose sight of the objective of the requirement nor rush to an overly complex solution.

While we might see compromise in defining the features the project product must have, we should not compromise the intent and the business justification for carrying out the work in the first place.

The current edition of PRINCE2 recognises six dimensions for tolerance that a project has. So, the project manager has some latitude on delivering within time, cost, quality, scope, risk, and benefits expectations.

What happens if project delivery is jeopardised? Then the issue needs to be escalated. One possible response to such a situation is to ‘de-scope’ the project. It will deliver less but time, cost and quality are not compromised; only the scope of the project is compromised. That triggers a thought about how tightly the prioritisation was carried out in the first place (but that’s another story). So one way of still bringing the project to an acceptable conclusion is to compromise on the scope or features of the project’s product.

Depending on the cause of the threat to the project, adding some extra resource may bring the project back onto the desired delivery schedule, protecting quality and scope through compromising the cost element. It is not uncommon that for a new product to be successful it needs to be launched/released within a certain time window. For example, a new toy coming out after Christmas may be less successful than one launched before or to coincide with the peak Christmas shopping period.

Running more activities in parallel to save time on the remaining part of the project may help deliver in a shortened time frame. This may not always be possible and tends to increase risk. The National Audit Office, the independent body which audits UK Government departments, reported that too much concurrent activity increases the risk that we might waste more of the investment if the project was subsequently cancelled as we would have delivered more components of the project that are now not required.

Compromises are a normal part of life and projects are no exception to that. When we make compromises on projects we need to understand the consequences and the impacts on the final product and the project’s viability. Still, there are some things that we cannot compromise on in projects and right at the top of that list is the need for an ongoing business justification. Without that we are wasting time, effort and money.

Author avatar
Mike Acaster
Mike Acaster is the PPM Portfolio Manager at AXELOS, the organisation behind some of the world's most popular project management methodologies including PRINCE2, ITIL, MSP, M_o_R, P3M3, P3O, MoP and MoV.
Read more