Consider project costs across development, operation and maintenance

A new business website or specialist application often receives a development budget first. Further work appears after launch: content changes, interfaces need attention and somebody answers operational questions. If these tasks enter the discussion only after publication, the initial development price can no longer serve as a complete basis for the decision.

This guide builds a manageable cost model for a fictional digital project. Its purpose is to make assumptions visible and help people understand decisions later. It replaces neither a specific quotation nor your organisation's cost accounting. The example is deliberately nominal: it excludes discounting, taxes and claims about financial returns.

1. Define the boundaries of the calculation first

Start by writing down the job the solution must perform. “Customer portal” is too vague. “Existing customers can retrieve approved documents and report missing information” describes something that can be checked. A portal with payment processing, delegated access and complex retention requirements is a different undertaking, even if both quotations use the same heading.

Also define where the comparison starts and ends. Our example includes a one-off preparation and delivery phase, followed by 36 operating months from go-live and a final transition allowance. The three operating years do not begin at the first workshop. This prevents project duration and recurring subscription periods from being confused or counted twice.

Separate the common baseline from optional additions. Another language may be essential for one organisation and unnecessary for another. Your comparison needs to state the required scope explicitly. Otherwise a smaller quotation can appear cheaper simply because it leaves out work that the organisation actually needs.

The GOV.UK introduction to choosing technology identifies total ownership costs and avoidable supplier lock-in as decision points. For a small business, a practical question follows: which later tasks and transition options should we consider now? The structure below is our simplified working model, not an official accounting requirement.

2. Organise costs around tasks rather than invoice headings

Begin with the work that has to happen. It may include reviewing the current situation, resolving requirements, design, development, migration, verification and introduction. Only then identify which tasks are already included in a package price. This makes work visible that might otherwise disappear between the different headings used by different suppliers.

For example, a quotation includes both “setup” and “migration”. Does that cover configuring the connection to an existing system? Must your team clean the source records beforehand? Either arrangement can be reasonable. What matters is clear allocation. Each cost line should have one owner and a reference to the corresponding deliverable or evidence.

Distinguish one-off, recurring and event-driven work. Hosting normally recurs. Initial data cleanup happens once. A substantial interface change may be required only when another system changes. A single annual allowance can conceal these differences. Keep separate planning lines even if a supplier later combines them on one invoice.

For each line, record quantity, unit, assumption, owner and source of the figure. “Editorial work: four hours per month” is more reviewable than “some content effort”. An unknown amount remains an open assumption. Do not silently replace it with zero or an apparently precise number that nobody can explain.

3. Make internal participation visible

Even a fully commissioned project consumes time inside the organisation. Someone makes content decisions, reviews designs, provides data and accepts the finished work. In a small business, this participation may matter more than an additional software subscription. If it is absent from the calendar, waiting periods and repeated discussions can follow.

Initially record internal hours separately from external payments. For a full-cost view, your own accounting can supply an appropriate internal rate. The selling price of a consulting hour is not automatically suitable. Equally, an hour reserved for existing staff is not necessarily an additional cash payment. Preserve that distinction in the results.

A simple resource list identifies the person or role, task and available window. Accounting might prepare representative cases, a specialist checks their processing and management resolves two remaining scope decisions. This also exposes bottlenecks: one person cannot simultaneously handle normal work, source-data cleanup and every acceptance activity.

Our fictional operating example assumes 40 internal hours each year at an illustrative cost rate of EUR 60. The result is EUR 2,400 per year. Both inputs are invented for the calculation. They are neither a staffing recommendation nor a promise about the actual support effort that a particular project will need.

4. Treat migration as its own piece of work

A source file may be technically importable without being ready for use. Duplicate records, inconsistent dates and obsolete ownership information can burden the new application immediately. Plan data profiling, cleanup, mapping, a trial import and specialist review as visible activities. A successful file transfer does not establish the meaning or quality of its contents.

Select difficult cases for the trial as well as ordinary ones. One typical record is insufficient when the source contains unusual characters, missing required values or historical status codes. Record which cases are accepted, rejected or need manual work. Migration effort therefore depends on quality and variation, not merely the number of rows.

Include any necessary duplicate work during the transition. If staff must maintain both systems for two weeks, that time belongs in the plan. First check whether dual entry is really necessary. A defined cutoff with a controlled final import may be simpler than a long period of parallel operation that creates discrepancies.

Migration should finish with a reviewable state. Compare important totals, relationships and selected business cases as well as record counts. Assign responsibility for specialist acceptance. An import log can document technical completeness, but it cannot guess the business meaning of information that nobody has defined.

5. Describe operation and maintenance concretely

Operation covers more than storage space. Consider monitoring, backups, recovery exercises, security updates, certificates and external connections. The actual arrangement must establish which responsibilities belong to the hosting provider and which belong to your service partner. The phrase “hosting included” does not answer those questions by itself.

Maintenance also has different triggers. A faulty existing function is a different issue from a new business requirement. Updating a dependency may require verification without adding functionality. Separate routine operation, defect handling, agreed maintenance and additional development in the model. Specific contractual treatment needs its own review rather than an assumption based on a package name.

Describe the expected service: when is a report received, who assesses urgency and how is completion confirmed? A guaranteed response is not the same as a guaranteed resolution. A modest support arrangement can be sufficient when it matches the system's importance and includes a clear escalation route for genuine disruption.

Your model can reserve a monthly work allowance. State whether it is prepaid, merely reserved or billed according to actual use. Unused time and unexpected events need understandable treatment. Do not count the same reserve both as expected consumption and again as a separate general risk allowance.

6. Build a complete worked example

Our fictional project supports a bounded digital process. Its initial phase assumes EUR 2,000 for clarification, EUR 12,000 for implementation, EUR 3,000 for migration and EUR 1,000 for introduction. Together these make EUR 18,000. These are teaching inputs and say nothing about the price of any particular application.

The four ongoing items add up to EUR 6,600 per year, equivalent to EUR 550 per month for this calculation. Across three years they contribute EUR 19,800. Add the initial phase and transition to obtain the nominal EUR 39,600 total. The same information must not appear again as an additional annual package charge.

This model combines internal costs and external payments. Separate them again when considering cash requirements. Taxes, financing, price changes and payment timing remain outside this simplified model. If any of them matter to the decision, add them explicitly. A tidy total does not become reliable by hiding the limits of its calculation.

7. Explore uncertainty by changing assumptions

An early estimate is not certainty. Consider a few understandable scenarios. In this example we change only recurring monthly costs. At EUR 450 instead of EUR 550, the total becomes EUR 36,000. At EUR 750, it becomes EUR 46,800. The initial phase and final transition remain unchanged in both cases.

This range is neither a statistical confidence interval nor a guaranteed maximum price. It answers only how much a particular assumption affects the result. A second comparison might vary migration effort. Initially change one influential factor at a time so that the reason for each difference remains visible.

The GAO Cost Estimating and Assessment Guide addresses documented assumptions, sensitivity, risk and later updates. Our small working model does not reproduce a complex estimation method. It applies the underlying idea of showing a figure alongside its premises and revising it when evidence changes.

An assumptions register needs a date and a trigger for review. An unknown export format can, for example, be investigated through a trial with representative real data. Revisit the allowance after that trial. Leaving a reserve untouched after the corresponding uncertainty has been resolved produces a calculation that becomes progressively harder to explain.

8. Describe benefits separately and make them testable

A cheaper option can still be unsuitable if it fails the essential task. Record a few benefit hypotheses alongside the cost model. For example, an incoming enquiry should no longer need copying into three lists. Observe the current process and identify the exact step that the proposed solution would remove.

Released staff time does not automatically produce a matching reduction in expenditure. It might improve availability or create capacity for more complex cases. Cash savings, available capacity and quality improvements are different outcomes. Keep them distinct so that a plausible process change does not become an unsupported claim about financial returns.

The GOV.UK guidance on cost per transaction describes relating complete service costs to completed transactions. For a business application, both numerator and denominator must match the task. A page view is not a completed customer case. Supported alternative contact channels may also belong to the same process.

Revisit the hypothesis after introduction using the same definition. Record the period, case count and unusual conditions. A quiet month cannot be compared with a peak month without explanation. With small numbers, carefully described individual cases can be more honest than an impressive percentage based on an unstable denominator.

9. Compare quotations on a shared basis

Give everyone the same required scope, source-data description and comparison horizon. Ask for open assumptions to be marked explicitly. Then assemble a common list separating included work, necessary client effort, recurring charges and excluded tasks. The lowest initial total becomes one relevant piece of information rather than the entire decision.

Avoid a weighted score that conceals an essential requirement. If an option cannot provide a necessary data export, strong visual-design marks do not compensate for that gap. Check exclusion criteria first. Comparing cost, convenience and extension options makes sense only among solutions that can actually meet the essential need.

Ask about a later transition now: which data can be exported, in what format, which accounts are handed over and who documents the connections? These questions concern a concrete handover effort. Neither general anxiety about dependency nor an unsupported claim of complete interchangeability replaces the practical check.

Record the decision together with its limits. “Option A selected because it covers the standard workflow; the exceptional report remains manual for now” is more useful than “best overall solution”. That note explains why a later request was not automatically part of the originally compared scope.

10. Reproduce the calculation with JavaScript

This small example uses whole cents and whole months only. It is a reviewable teaching calculation, not accounting software. Inputs are fixed in source code. An interface accepting user input would additionally require suitable parsing, validation and understandable errors before passing values to the function.

function projectCost(initialCents, monthlyCents, months, transitionCents) {
  const values = [initialCents, monthlyCents, months, transitionCents];
  if (!values.every(value => Number.isSafeInteger(value) && value >= 0)) {
    throw new TypeError('Non-negative safe integers are required.');
  }
  const total = initialCents + monthlyCents * months + transitionCents;
  if (!Number.isSafeInteger(total)) {
    throw new RangeError('Result exceeds the safe integer range.');
  }
  return total;
}

const eur = new Intl.NumberFormat('en-GB', {
  style: 'currency', currency: 'EUR'
});
const cents = projectCost(1800000, 55000, 36, 180000);
console.log(eur.format(cents / 100)); // €39,600.00

The guard rejects negative inputs, fractional values and unsafe integers. It also checks the result because multiplication can move a valid input combination beyond the safe range. Using cents simplifies this specific nominal addition. It does not answer general questions about rounding, taxation or payment schedules, which this example does not calculate.

For the scenario comparison, replace the monthly input only. A value of 45,000 cents produces EUR 36,000; 75,000 cents produces EUR 46,800. Keep each assumption next to its result. A copied total without its inputs cannot later be verified or updated in a meaningful way.

11. Maintain the model as the project develops

The first estimate is a baseline. After bounded pieces of work, compare actual effort, remaining work and changes in scope. Distinguish an underestimated original task from a later addition. Both can require more effort, but they explain different decisions and should remain separate in the review.

The GOV.UK guidance on agile planning discusses different levels of detail for near and distant work, together with revision as understanding improves. For small projects we suggest a brief regular cost review with explicit choices: continue, change scope, investigate uncertainty first or deliberately defer an additional task.

Each change needs an impact statement, decision and named owner. “Another interface requested” is insufficient. Record which other task moves back or which additional budget is available. This prevents ongoing maintenance from quietly turning into a second project without a shared acceptance basis.

Checklist for a useful cost overview

• Define the task, required scope and comparison horizon.
• Separate one-off, recurring and event-driven work.
• Include internal participation using an appropriate cost basis and realistic availability.
• Plan cleanup, trial migration and specialist acceptance.
• Distinguish operation, maintenance and additional development.
• Give assumptions a source, date and owner.
• Avoid counting reserves and expected consumption twice.
• Vary at least one influential assumption separately.
• Keep benefit hypotheses distinct from costs and cash payments.
• Describe handover and a later transition concretely.
• Update the result when evidence changes.

Common questions about project costs

Is a fixed price always the safest basis?

It can suit clearly bounded work. The assumptions, included deliverables and treatment of changes remain decisive. A fixed price for a different scope is not a meaningful alternative price for your actual needs. Establish the common task before deciding which charging arrangement fits it.

How many operating years should I compare?

Choose a horizon appropriate to the intended use and decision. Three years is simply the example here. A short experiment and a long-lived specialist application may need different horizons. Every option in a comparison needs the same time period and the same treatment of introduction and transition.

Should every possible future feature be included?

Essential tasks belong in the baseline. Possible later additions should remain visible as separate options with prerequisites. Including every uncertain request in the initial total obscures the distinction between the launch that is actually needed and a possible longer-term direction.

What is the most useful next step?

Take an existing quotation and add missing work for introduction, internal participation, operation and handover. Mark unknown inputs and investigate the assumption with the greatest influence first. A small reviewable overview is more useful than an elaborate model filled with unsupported numbers.

Sources and next steps

The primary sources explain broader methods. The numerical example, table structure and checklist are original working models for this article. Sources checked on 9 November 2026. All example amounts are fictional nominal values excluding VAT.

• GOV.UK: Choosing technology
• GAO: Cost Estimating and Assessment Guide
• GOV.UK: Measuring cost per transaction
• GOV.UK: Planning in agile