Solution Estimation and Commercial Planning

An Estimate Is a Delivery Commitment

An enterprise implementation is often approved through a small set of numbers: a fee, a team size and a target go-live date. Behind those numbers sits a much larger promise. Processes must work, data must be usable, people must be ready and technology must support the business when the project team steps away.

Chapter 4 connected the investment to the business case. Chapter 5 established how sourcing and supplier evaluation turn business intent into a proposed solution. This chapter examines how that solution becomes an estimate and a commercial plan that both the customer and the implementation partner can deliver.

A weak estimate describes the work everyone hopes will happen. A strong estimate describes the work required, the evidence available, the assumptions still open and the consequences if those assumptions change.

The objective is not to remove uncertainty before making any decision. It is to make uncertainty visible enough to manage. Every example in this chapter is fictional and illustrative; the quantities, rates and allowances are not industry benchmarks.

6.1 Separate Effort, Duration, Cost and Price

These four terms are related, but they answer different questions. Effort is the work required, usually expressed in person-hours or person-days. Duration is the elapsed time needed to complete that work, including dependencies and waiting periods. Cost is the expenditure incurred within a defined cost boundary. Price is the amount charged to the customer under the agreed commercial terms.

An integration may require 80 hours of work but take four weeks because a third-party environment is available only in week three. Assigning a second developer will not necessarily bring that environment forward.

Likewise, a competitive selling price does not reduce the effort required to cleanse data or rehearse cutover. If the price changes while the delivery model stays the same, the commercial result changes. The project has not become easier.

State the units explicitly. A person-day should have an agreed number of working hours, and a rate should specify currency, role, location and what it includes. Otherwise, two apparently comparable estimates may describe different commitments.

6.2 Establish the Estimation Baseline

Before estimating activities, define what is being implemented. The baseline should identify business entities, locations, processes, user groups, systems, integrations, data objects, reporting needs and the deployment approach. It should also identify the required service, security and operational characteristics.

Separate confirmed scope from provisional scope. “Finance implementation” is too broad to estimate dependably. “General ledger, payables and receivables for two legal entities, with one reporting currency and specified statutory outputs” provides a more useful starting point, while still requiring clarification.

Record the source and version of the requirements. Accepted RFP clarifications and demonstration commitments belong in this baseline; they should not disappear when the proposal spreadsheet becomes the project plan.

State exclusions and the effect of those exclusions. If historical transaction migration is excluded, explain how users will access history. An exclusion that leaves an essential business activity unsupported is an unresolved solution decision.

The baseline is the common reference for estimation, commercial approval and delivery handover. Different documents may serve different audiences, but their underlying scope must agree.

6.3 Break the Work into Deliverable Outcomes

A work breakdown structure makes the estimate reviewable. Start with deliverables and break them into work packages small enough to assign, estimate and verify. An integrated order-to-cash process is an outcome; workshops, configuration, interface development, test execution and user preparation are activities that help produce it.

Each work package should carry a scope reference, quantity, complexity, responsible role, estimation basis and completion condition. A reviewer should be able to trace an allowance back to a requirement rather than accept a number because it appeared in an earlier proposal.

Avoid counting the same activity twice. If integration testing is included in the testing workstream, the integration build estimate should explain whether it covers developer testing only. Conversely, do not assume another workstream has included work without checking.

Review the structure through People, Process, Data and Technology. A technology-heavy estimate with no process ownership, business readiness or data preparation is rarely a complete implementation estimate.

6.4 Choose the Method That Fits the Evidence

Different stages of the lifecycle support different levels of confidence. An early strategic estimate may use comparable projects and broad quantities. A design-based estimate can use detailed work packages and known technical constraints.

Historical actuals are valuable only when their context is understood. A previous project with clean master data and a mature customer team may be a poor comparison for a business with fragmented ownership and undocumented processes.

For uncertain packages, describe an optimistic, most likely and pessimistic scenario. Explain the conditions behind each scenario. A weighted calculation can summarize those judgments, but it cannot turn weak inputs into certainty.

Use a range when the evidence supports a range. Record the date and event at which the estimate will be refined, such as completion of discovery or validation of a data sample. Do not present an early directional estimate with the confidence of an approved delivery baseline.

6.5 Cover the Full Implementation Lifecycle

The ten-stage lifecycle introduced earlier provides a useful completeness check: Strategy and Business Case; Presales and Commercial Definition; Mobilization; Discovery; Solution Design; Build and Configuration; Data Migration and Testing; Business Readiness; Cutover and Go-Live; Hypercare and Continuous Improvement.

Not every stage belongs in one partner contract. Strategy work may already be complete, and continuous improvement may become a separately funded operating activity. The estimate should make those boundaries explicit rather than imply that the complete lifecycle ends with configuration.

Include mobilization, environment access, governance, quality reviews, documentation and handover where they are required. Testing includes preparation, defect investigation, correction, regression and business participation, not simply the execution of a test script.

Hypercare needs a defined coverage window, staffing model, escalation route and exit criteria. Continuous improvement needs ownership and a funding route after the project closes. An undefined promise of “support until stable” creates uncertainty for both parties.

The commercial boundary may be narrower than the enterprise effort. Make both visible so that the customer can plan the total investment.

6.6 Estimate Complexity, Not Just Counts

Ten interfaces can represent ten simple file transfers or ten critical, bidirectional connections with different security models and recovery requirements. Counting them without classifying them creates false comparability.

For an interface, examine data direction, frequency, transformation, transaction volume, monitoring, error handling and third-party dependencies. For migration, examine source quality, mapping, cleansing, reconciliation, history and the number of mock conversions.

Reports require similar care. A standard operational report differs from a consolidated statutory output with complex allocation logic and audit evidence. Agree the complexity definitions before using standard effort bands.

Validate the categories with samples. Reviewing two representative interfaces and a real extract of customer data may reveal more than another round of high-level estimation meetings.

Record what would cause reclassification. If a supposedly standard interface requires custom middleware and nonstandard authentication, the change should trigger an impact review rather than be absorbed silently.

6.7 Make Assumptions and Customer Effort Visible

An assumption is useful only if someone can validate it. Record the statement, owner, validation date and consequence if it proves false. “Customer will support testing” is not specific enough. Identify the process owners, expected availability, test responsibilities and decision turnaround.

A dependency register should include access, environments, third-party specifications, licenses, business decisions and data readiness. Connect each dependency to the work it enables. This allows a delay to be assessed against the delivery plan.

Customer effort is often missing from the approved budget. Subject-matter experts attend workshops, resolve design questions, prepare data, execute acceptance tests and train colleagues while continuing their operational roles.

Estimate that contribution separately from supplier effort. Identify whether temporary backfill is needed and who funds it. A partner estimate can be internally sound while the enterprise plan fails because the customer team has no capacity to participate.

Assumptions are not a substitute for reasonable investigation. If a material uncertainty can be resolved before commitment, resolve it.

6.8 Build a Transparent Effort Model

Consider a deliberately small implementation used to demonstrate the mechanics. The following supplier estimate covers a defined scope from discovery through a specified hypercare period. Earlier strategy and presales activities, customer effort and ongoing operations are outside this supplier effort table and must be budgeted separately where applicable.

The 1,200 hours are a base estimate before the separately identified risk allowance. They are not a recommended staffing standard. In this example, mobilization is included in the governance row, developer testing is included in build activities, and the testing row covers integrated testing and acceptance support.

Each row would normally have supporting work packages. The integration allowance, for example, should reconcile to an interface inventory and complexity assessment. The migration allowance should identify mock loads, reconciliation and the agreed division of cleansing work.

A useful review asks whether the estimate can be explained without the estimator present. If it cannot, important delivery knowledge remains in someone's head.

6.9 Convert Effort into a Resource-Loaded Schedule

A schedule must account for role availability, sequencing and the customer's business calendar. It should also include decision lead times, environment readiness and periods when key users cannot leave operational work.

Suppose four people each provide 30 productive project hours per week. Their combined capacity is 120 hours per week. Dividing 1,200 hours by 120 gives ten weeks of aggregate capacity. This is a capacity illustration, not a promised completion date: it ignores risk allowance, sequencing and specialist bottlenecks.

If only one integration specialist can perform a critical package, unused capacity elsewhere does not automatically accelerate that package. Adding people may also increase coordination and onboarding effort.

Build the schedule from dependencies and role-level capacity, then reconcile it to the estimate. Include the customer and third parties where their work governs progress.

A fixed go-live date is a constraint to test. Where it cannot be met credibly, present choices such as reducing the first release, changing the rollout sequence or moving the date. Do not compress testing and readiness merely to make the spreadsheet fit.

6.10 Treat Risk Allowances Explicitly

The base estimate should cover the work currently understood. A risk allowance addresses identified uncertainty within that scope. It should not conceal omitted activities or provide an unlimited budget for new requirements.

In the worked example, the team includes 80 hours for possible additional migration reconciliation, 60 hours for interface remediation and 40 hours for additional cutover rehearsal work. The total allowance is 180 hours, bringing the planning total to 1,380 hours.

These are scenario-based allowances selected for this example, not a universal 15 percent rule. The team should examine whether risks overlap, share causes or could occur together. Summing allowances mechanically can overstate or understate exposure.

Document who controls the allowance, how its use is approved and how remaining exposure is reviewed. A supplier's internal allowance does not automatically create customer-billable hours; billing follows the agreed contract.

Keep scope change separate. A new legal entity or an additional deployment wave requires an impact assessment even if some contingency remains unused.

6.11 Connect Delivery Cost to Commercial Price

Commercial planning needs a defined cost model. Use agreed internal costing conventions and show which expenses are included. Do not confuse an illustrative delivery contribution with the organization's net profit.

For the same example, assume a fictional blended delivery cost of ₹1,500 per hour and direct project expenses of ₹3.3 lakh. The expense allowance represents agreed project costs such as travel and temporary project environments; it excludes taxes and customer-owned subscriptions.

At a selling price of ₹32 lakh, the difference between price and the defined delivery cost is ₹8 lakh. The delivery margin is 25 percent, calculated as ₹8 lakh divided by ₹32 lakh. The markup on cost is approximately 33.3 percent, calculated as ₹8 lakh divided by ₹24 lakh.

Margin and markup are not interchangeable. If the target margin on this cost boundary were 30 percent, the required price would be ₹24 lakh ÷ 0.70, or approximately ₹34.29 lakh.

Corporate overhead, financing, taxes and other allocations may change the broader financial result. Finance should confirm the applicable conventions. The delivery leader's responsibility is to ensure the work and risk assumptions underneath the cost remain credible.

6.12 Choose a Commercial Model That Matches Uncertainty

The commercial model determines how effort, scope and financial exposure are shared. It does not remove the need for sound estimation.

A fixed fee requires clear deliverables, assumptions, acceptance arrangements and change control. A time-and-materials model still requires a forecast, prioritization and active control of consumption. A cap should specify what happens as the limit approaches; it should not leave either party to discover that expectation during delivery.

A phased arrangement can be appropriate where discovery is needed to establish a dependable build scope. Define the first phase's outputs and the decision process for authorizing the next phase. The customer should understand that subsequent pricing remains subject to that decision.

Select the model through a joint assessment of uncertainty, decision maturity and the ability to control dependencies. The most attractive contract label is not necessarily the best delivery arrangement.

6.13 Plan Milestones, Acceptance and Cash

Milestones should describe verifiable outcomes. “Configuration complete” needs a definition: which processes, what evidence and whose review? Acceptance should specify the review period, criteria, treatment of defects and escalation path in terms the parties have agreed.

For an illustrative ₹32 lakh contract, milestone invoices of 20, 30, 30 and 20 percent would be ₹6.4 lakh, ₹9.6 lakh, ₹9.6 lakh and ₹6.4 lakh. Each milestone needs an agreed basis rather than a date alone.

Invoice timing and cash receipt are different. If payment is due after an agreed period, the supplier must fund delivery until cash arrives. The customer also needs a forecast of when approvals and payments will be required.

Model a delayed acceptance or payment scenario. Review the effect on working capital and delivery continuity without treating every delay as a dispute.

Billing milestones do not, by themselves, determine accounting revenue recognition. Finance and the relevant contractual terms govern that assessment. Keep the project cash forecast understandable without mixing these concepts.

6.14 Negotiate the Delivery Model as Well as the Price

A request for a lower fee should trigger a structured discussion. Examine scope, sequence, standard capability, staffing assumptions and the division of responsibilities before making a commitment.

For example, moving a low-priority report to a later release may reduce first-release effort. Asking the customer to perform data cleansing may also change partner effort, but only if the customer has the capability and capacity to do it.

Removing hours from the estimate while retaining the same deliverables does not create a saving in the work. It creates a commercial exposure that someone must knowingly approve.

Record the final concessions and their consequences. A reduced fee, shorter hypercare period or deferred interface should appear consistently in the proposal, estimate and agreement.

The delivery leader should participate before commitments are finalized. Commercial success is stronger when the team responsible for execution can explain how the promise will be met.

6.15 Maintain the Forecast After Approval

The approved estimate becomes a baseline, not a reason to ignore new evidence. During delivery, compare actual effort with completed work and update the estimate to complete.

Suppose the approved planning total is 1,380 hours. At a review, 600 hours have been consumed and the team estimates 850 hours remaining. The forecast at completion is 1,450 hours, which is 70 hours above the baseline.

Investigate the cause. It may be additional approved scope, lower productivity, an inaccurate original assumption or a risk that has materialized. Those causes require different actions and should not be grouped into an unexplained overrun.

Do not calculate progress from hours spent alone. A team may consume half its budget while difficult integrations and acceptance issues remain unresolved. Review deliverable evidence and remaining work with the people performing it.

Keep the original baseline, approved changes, current forecast and allowance use visible. Reforecasting should improve the decision, not erase the history against which performance is understood.

6.16 Complete the Estimation Review and Handover

Before commercial approval, bring delivery, solution architecture, finance and the relevant workstream leads into the review. Include customer-side owners when validating shared assumptions and obligations.

Review whether quantities reconcile to the scope, specialist capacity supports the schedule, risk treatment is explicit and acceptance can be demonstrated. Ask a reviewer who did not prepare the estimate to challenge its weak points.

The handover pack should contain the approved estimate, scope baseline, assumption and dependency registers, resource plan, risk allowances, commercial milestones and the history of material concessions.

The project manager should know which commitments are binding, which decisions remain open and when the estimate must be revisited. Unresolved questions need owners and dates, not merely a place in an appendix.

A successful handover preserves the reasoning behind the numbers. That reasoning is what allows the team to respond intelligently when the implementation meets reality.