Your supplier has just advised that an important item will arrive two weeks late. Another supplier can deliver on time, but at a higher price. Your team could also use a different item, although that would change part of the design.
Which option should you choose?
You could save the budget and miss the completion date. You could protect the date and spend more money. Or you could change what you deliver.
The client will probably tell you they want everything delivered correctly, on time and within budget. Fair enough. That is what you planned to do. But now you need a decision, and “all of them are important” does not tell you which option they would accept.
Problem: Everyone Has a Different Idea of What Matters Most
Meeting the requirements is the starting point
Normally, you should expect to deliver the agreed scope, meet the required standards, finish within the agreed schedule and stay within the approved budget. You do not get to choose your favourite and ignore the others.
However, when those requirements come into conflict, you need to understand the consequences of changing each one. That is where project priorities become important.
The client may consider a particular completion date essential. Your company may be focused on protecting its profit. The designer may want to retain every specified feature. Each person could make a reasonable decision from their own perspective and still create a problem for the project.
If these priorities have never been discussed, the disagreement usually appears when you have the least time to resolve it.
Scope and quality are related but different
Discussions about what is most critical often refer to time, cost and quality. Others use time, cost and scope. It helps to be clear about what those words mean.
Scope describes the work and deliverables included in the project. Quality concerns how well the relevant requirements are met. ISO’s explanation of quality management describes quality in terms of fulfilling requirements. For your project, you also need to establish that those requirements will produce something suitable for its intended use.
For example, installing ten specified pumps is a scope requirement. Achieving the required flow, reliability and installation standard involves quality requirements. Delivering all ten pumps does not prove they work correctly.
Equally, delivering eight excellent pumps does not complete a contract requiring ten. Removing two needs an approved scope change and a check that the revised system can still do its job.
An article on the APM website about project priorities and quality makes a useful point here: successive scope reductions can leave a solution unable to fulfil its purpose. A cheaper project is of little value if the client cannot use the result.
Meeting the client’s price can still cost your company money
Cost also needs a clear definition. The price paid by the client and the cost incurred by your company are different figures.
For example, suppose your company agrees to deliver a project for $500,000. Its internal delivery budget is $420,000, leaving an expected margin of $80,000 before any costs not included in that estimate.
The client pays the agreed $500,000, but rework and extra labour take your delivery cost to $530,000. The client’s price has been maintained. Your company has spent $110,000 more than planned and incurred a $30,000 loss on that comparison.
Calling that project “on budget” without explaining whose budget you mean would be misleading.
Your general assessment should distinguish the quality of the deliverables, performance against the agreed project requirements, and the commercial result for your company. A happy client does not automatically mean a profitable project.
Solution: Agree on What Is Most Critical Before You Need to Choose
Find out why the project exists
Start with the outcome the client needs. What problem are they trying to solve, and what would make the project worthwhile?
A sports event needs its facilities ready before the event starts. A treatment plant upgrade may need to deliver a specified capacity. An internal improvement project may only make business sense below a particular total cost.
Those reasons help you understand which changes could be acceptable. They also help you challenge unnecessary work. If a proposed feature does not contribute to the required outcome, it may be worth discussing before anyone spends time designing it.
Ask your own management about the company’s objectives too. The company might accept a modest profit target because it wants experience in a new market. That can be a deliberate business decision, but it should be agreed by the people authorised to make it. The project manager should not quietly sacrifice margin on the assumption that future work will make up for it.
Understand which dates are actually fixed
A date on a schedule does not tell you why it matters. Ask what happens if the deliverable is late.
For a sports event, finishing on Monday when the event was on Saturday may make much of the work useless. For a construction project, a short delay might be manageable, or it might mean missing a shutdown window and waiting months for another opportunity.
You cannot assume all construction projects have flexible dates. A building may be needed for a school term, a tenant’s move or another contractor’s work.
My post on why project due dates are set covers this discussion in more detail. Ask about intermediate milestones as well as final completion. A design approval or equipment delivery can be just as important as the handover date because other work depends on it.
Then check that the schedule allows for reviews, procurement, testing and commissioning. A fixed opening date does not make those activities disappear.
Confirm the scope and acceptance requirements
Before deciding what could change, establish what has actually been agreed. Read the contract, scope, specifications, drawings and acceptance requirements together. Resolve inconsistencies with the appropriate people.
This is why you need to know the scope of your project. The project manager, designer, client and contractor need a common understanding of the required result.
For a building, essential capacity or functionality may be the main priority. There may be flexibility in finishes or the timing of some external works. On another project, those finishes could be central to the client’s requirements. Ask rather than assume.
Define how acceptance will be demonstrated. That could include performance tests, inspection records, approved drawings, operating manuals and training. If those items are needed for safe operation or agreed handover, the asset is not ready simply because installation has finished.
Keep the quality assurance and quality control requirements in the plan. Required checks need people, time and budget.
Identify the real cost limit
Ask whether the budget is a planning target, an approved funding limit or a contractual price. These can have different consequences, and there may be a separate process for changing each one.
A politically sensitive project may face strong pressure to stay within its announced budget. Another may face greater pressure to meet a publicly promised opening date. Political sensitivity alone does not tell you which constraint matters most.
For the client, compare the overall effects of each option. A cheaper item may take longer to install, require more maintenance or cause expensive downtime. Include those consequences in the decision where they are relevant.
For your company, maintain a forecast of the cost to complete the remaining work. Include commitments, likely rework and the resources still required. Looking only at invoices received so far can hide an approaching overrun.
An available contingency allowance is not automatic permission to spend it. Confirm who controls it and what approval is required.
Ask practical questions and record the answers
I would ask the client or sponsor questions such as:
- Which dates cannot move, and what happens if we miss them?
- Which deliverables and performance requirements are essential to the outcome?
- What is the approved cost limit, and can additional funding be considered?
- Which features could be changed, deferred or removed if necessary?
- Who can approve those decisions, and how quickly can they respond?
You might record the result as: “The facility must be operational before the event. Required safety and performance checks remain unchanged. Additional branding may be deferred with client approval. Any additional expenditure requires sponsor approval.”
That gives the team something useful to work with. “Time is important” does not.
Include these decisions in your project management plan and make them easy to find. Record the reasons as well as the priorities. Someone taking over the project needs to understand why the decisions were made.
There may be several firm constraints. If the available options cannot satisfy them, escalate the problem. Ranking priorities does not make an unachievable project achievable.
Separate essential requirements from optional features
Where scope flexibility is possible, identify it early. It is easier to agree which features could wait before the team has designed, ordered or installed them.
The MoSCoW method provides a useful way to discuss requirements: Must Have, Should Have, Could Have and Won’t Have. The Agile Business Consortium describes this well. The important part is agreeing what each category means for the particular delivery period.
You could use that discussion for an initial release or a staged handover. For example, the essential operating functions may be required at opening, while a nonessential reporting feature could follow later.
Check the dependencies carefully. A feature that appears optional may support another essential function. Also, calling a contracted deliverable “Could Have” does not remove your obligation to deliver it. Any change still needs the appropriate agreement.
If everything is essential and nothing can move, record that honestly. Do not manufacture flexibility by leaving important requirements out of the plan.
Present the options with their consequences
Let’s return to the late supplier example. Suppose the item is required for facilities at a sports event, and the approved opening date cannot move.
The original supplier offers delivery two weeks late at the agreed price. A second supplier can provide a compliant item in time for an additional $15,000. A third option uses a different item and needs five days of design review before its suitability can be confirmed.
The first option misses the event requirement. The second could protect the date, provided installation and testing still fit. The third has an uncertain outcome and needs a decision before the alternative supplier’s stock is sold.
Present those facts to the authorised decision maker. Explain the extra cost, technical checks, remaining risks and latest decision date. Recommend an option based on the agreed priorities.
If the sponsor will not approve more money, explore an acceptable scope change or another delivery arrangement with the technical team. If none is workable, the sponsor needs to know immediately. Do not promise that the original scope, price and date can all be maintained when the evidence says otherwise.
Keep safety, applicable compliance obligations and essential performance requirements within the assessment. A deadline does not justify installing something unsuitable or omitting required verification.
Approve changes and keep the team informed
Once an option is selected, record the decision through the relevant change process. Update the affected scope, budget, schedule, drawings and acceptance requirements. Make clear who approved it and any conditions attached.
An informal conversation about priorities does not itself change the contract. Equally, a client request for additional work does not automatically provide more time or money. Obtain the necessary approvals and document the agreed effects.
My posts on documenting changes in scope and scope creep cover the importance of keeping those changes visible. Make sure the people doing the work receive the updated information, including subcontractors and anyone holding printed drawings.
Review priorities when significant circumstances change, such as a revised opening date, funding decision or new sponsor. Keep the original baseline visible alongside approved changes so reporting still explains what happened.
Also check resource commitments across other projects. Your project’s urgent task may need the same specialist as another project’s fixed deadline. Resolve that conflict with the relevant managers instead of assuming your project takes precedence.
Lesson: Know What the Client Cannot Afford to Lose
All the agreed project requirements matter. Your job is to understand what happens when you cannot satisfy them all under the current plan, and to get a decision while useful options remain.
Find out why the project is required, why its dates are set and what the client needs the completed deliverables to do. Clarify the funding limits and your own company’s delivery costs. Then agree which changes could be considered and who can approve them.
Keep those priorities written down and explain them to the team. Revisit them when circumstances change, and record any approved changes to the project requirements.
Before your next project review, ask yourself: if an important delivery slipped tomorrow, would I know which options my client would consider? If the answer is no, have that conversation now.
