Project Change Requests: Has the Extra Work Been Noticed, Priced or Authorised?

A project app should let staff record a possible change without making it part of the agreed job immediately. Before commissioning change-request tracking, define the boundary between noticing extra work, estimating its consequences and receiving authority to proceed. A message asking for an alteration should not quietly rewrite the current project commitment.

This is about scope changes during an existing customer project. It differs from replacing an unaccepted quote or releasing a new manufacturing instruction. The decision here is what additional or altered work the team is authorised to deliver, on which commercial and scheduling basis.

Keep the current agreement visible

Imagine a fictional installation team discovering that a customer wants an additional outlet. Recording the request is useful even before the team knows whether the existing agreement covers it. The app should retain the current agreed work and link the possible alteration to it.

Ask for a description of what changes, its origin, the affected work and supporting material. Preserve the distinction between an unresolved scope question and a confirmed addition. Do not force staff to invent a price simply to log something that needs investigation.

This is a software planning guide, not advice on contractual entitlement, construction claims or when a customer legally owes an additional amount. Have the responsible commercial and professional advisers determine those rules and the wording used with customers.

Price discovery is not permission to start

Procore's current Create Change Events documentation gives a construction-specific example. It describes a change event as affecting original scope, schedule or unexpected costs, and preparing the team for potential cost changes before they become actual costs. It then describes requesting subcontractor quotations, reviewing responses and having information needed to create a potential change order.

That sequence illustrates why a logged issue, a supplier response and a commercial decision should not be treated as one event. It does not establish a universal approval process or mean every custom app should reproduce Procore's fields.

In your brief, distinguish the internal expected cost, the customer-facing proposed adjustment and the agreed outcome. They can differ. Identify whether a date is an estimate of impact or an approved replacement deadline. A supplier's price alone should not authorise a customer charge under a rule the business has never agreed.

Record an unresolved classification honestly

The same Procore guide offers scope choices In Scope, Out of Scope and TBD. For your own application, an unresolved classification is often more informative than a forced yes or no. Define who investigates it and what information they need.

Do not let an unresolved case disappear from the team's work list. Give it an owner and a next action. Conversely, do not assume that every logged change must produce an extra charge. A reviewed outcome might confirm that the work was already included, reject the proposal or authorise a different approach.

These are proposed workflow requirements. Whether a request is included in a particular contract is a matter for the responsible people and agreement, not a conclusion to infer from a status name.

Make the authority and its scope explicit

For each accepted change, preserve the reviewed description, amount or charging basis, relevant schedule effect and recorded decision. Specify who can give that authority and whether different limits require different reviewers. Keep an internal estimate separate from the material the customer actually receives.

If someone changes the proposal after the decision, show that the earlier decision concerned a different version. The application should not carry approval onto a materially different request merely because its record number is unchanged.

Also decide how genuinely urgent work is handled. If your business permits an emergency instruction, record its authorised scope and unresolved commercial questions explicitly. A generic emergency checkbox must not give every user unlimited permission or imply a legal right to charge.

Update the project without counting the proposal twice

After the authorised transition, connect the change to the affected work and the relevant order or billing process. Keep rejected and superseded proposals outside the committed total while preserving their history. If an authorised addition becomes an invoice later, explain how the report avoids treating those stages as two independent additions.

Separate recorded authority, work performed, invoicing and payment. None of those states alone proves all the others. Ask staff to be able to trace a changed project total to the particular decisions included in it.

For a project-workflow app discussion, bring an invented original work schedule and two change requests. Demonstrate one that is still being priced and one authorised for a specific version. Change the latter proposal, reject another request and repeat a downstream update. The accepted result should preserve the correct commitment and an explainable history. These are tests to commission, not claims about an app already built.