#3 From Bid to Baseline

Why This Step Exists

Once a project is won, there is often a push to move straight into design. But in professional systems delivery, we make a conscious stop here.

Before we define how the system should behave, we need to understand exactly what we have committed to not just what the client asked for, but what we said we would deliver. This transition from bid win to engineering start is not just a procedural moment it is the handover from intent to obligation.

This post explores the Bid-to-Baseline Handover Process the structured activity that aligns delivery teams with the realities of the contract and how we apply it using our working example: the OTP Locker System.

When Does This Start?

The trigger is typically one of the following:

• Receipt of a signed contract or formal Notice to Proceed (NTP)

• Internal approval that the deal is confirmed and resourced

At this point, engineering takes ownership of delivery, and we formally initiate the process of turning commitments into actionable baselines.

Step 1: Reviewing What Was Promised (Bid Handover)

We begin by reviewing the winning bid response. This is not always part of the signed contract, but it reflects the commitments that shaped the client's expectations.

We ask:

• What scenarios or capabilities were described?

• Were timelines or performance levels promised without verified evidence?

• Were assumptions made about environment, tooling, or stakeholder roles?

This is where we reconcile optimism with engineering feasibility.

Locker System Example: The bid for the OTP locker includes “Installation shall be completed within two hours by a single technician using standard tools.”

At handover, we ask:

• Was this benchmarked under real-world conditions, or assumed based on bench tests?

• Does this consider building access constraints, installer skill level, or available power sources?

This line now becomes a tracked assumption and potential schedule risk, not just a sales line.

Step 2: Reconciliation - What Was Promised vs. What Is Required

Here, we perform a side-by-side review of:

• The bid response

• The signed contract and annexes

• Any technical specifications or referenced standards

We use structured methods:

• Comparison tables with BidID vs. ContractID labels

• Tagging requirements by source and ownership

• Initiating the traceability matrix that will be extended throughout delivery

We explicitly track:

• Gaps: Bid claims not supported by contractual obligation

• Ambiguities: Phrases open to multiple interpretations

• Inherited risks: Items assumed feasible without scope allocation

Locker System Example: Bid states “Remote administration capabilities.”The contract says nothing about how this is provided.

Engineering flags this as:

• A scoping issue (Does the backend server come from us or is it hosted by the client?)

This becomes a clarification point and a boundary-defining decision that must be resolved before interface design can begin.

Here is how our reconciliation output might look:

Category	Example	Contract Clause	Implication/Action
Install Time	2 hours, single technician	Not specified	Risk: needs validation / installer brief
Solar Support	Solar-ready unit	No mention	Scope creep: define as optional/variant
Remote Admin	Mentioned, no method specified	No technical scope provided	Clarify: backend ownership & interface method
OTP SLA	5-second delivery via SMS	Contract silent	Risk: Mobile carrier dependency flag it

Role of the Systems Engineer

This phase is not just commercial housekeeping, it is a technical leadership responsibility.

As Systems Engineers, we:

• Chair the reconciliation and bid handover sessions

• Own the compliance matrix structure

• Define how traceability is initiated and propagated through tools (or lightweight equivalents)

• Log assumptions and risks into the project risk register

• Facilitate alignment between technical, commercial, PM, and client-facing teams

This is where we act as the interface between disciplines turning soft intent into structured control.

Tools

Whether you are using DOORS, Excel, or a well-structured Google Sheet the principles remain the same:

• Every contractual statement must be traceable

• Each obligation should have a source tag and owner

• Every deliverable must be linked to a milestone or phase

Smaller teams or suppliers may not use full RM suites, but even a disciplined spreadsheet with source ID, requirement, delivery method, and due date can prevent costly rework.

Step 3: Building the Compliance Matrix and Delivery Framework

We then extract all contractually binding statements and create:

• A compliance matrix with delivery method (document, test, config, etc.)

• An initial Contract Data Requirements List (CDRL) mapping each deliverable to phases/milestones

• A summary of assumptions and risks, passed to the formal Risk Register

Locker System Example:

The contract appendix includes:

• “Provide user instruction manual”

• “Define audit log format”

These are not engineering features but are still contractual.

We track them with delivery dates linked to acceptance testing and handover milestones. It ensures they are designed for, not chased in the final weeks.

The first Delivery Schedule produced here is milestone-based not a full project plan. It links obligations to project phases and provides PMs a foundation for detailed scheduling.

Step 4: Defining Handover Completion & Formal Signoff

We do not consider this phase complete until we have achieved internal agreement on:

• All contractual items are understood, tagged, and owned

• Risks and assumptions are logged in the formal risk register

• Outstanding clarifications have been raised or tracked

• The handover pack is signed off by:

  • Engineering lead (technical feasibility)

  • PM (schedule and milestone fit)

  • Commercial lead (contractual scope)

This may be a formal document or a recorded review session, what matters is traceability and shared understanding.

How to Push Back When Rushed

Teams are often under pressure to start “real work” writing code, drawing architecture, defining functions.

To push back constructively:

“If we don’t do this, we risk building to the bid instead of the contract. That leads to late rework, missed obligations, or downstream claims. A two-week delay now can avoid a 10x cost multiplier later.”

Engineers must not just build systems. we must also protect delivery integrity.

What Happens If Gaps Are Found?

When we uncover high-risk or infeasible commitments:

• Escalate within the delivery team (technical + commercial)

• Log risk in the register with owner and mitigation strategy

• Engage the client early to renegotiate, clarify, or agree scope changes

Unspoken mismatches between bid and contract are time bombs. This is where we defuse them.

Legacy Projects and Subcontractors

If the project is an upgrade to an existing system, we add:

• Context review of what is being reused vs. replaced

• Identification of interfaces that must be preserved or translated

If subcontractors were involved in the bid:

• We request their bid documentation

• Verify their capability claims

• Initiate subcontractor requirement flow-down sessions

We ensure their scope is reconciled just like ours.

Closing Reflection

The Bid-to-Baseline process is where engineering inherits the project with all its promises, risks, and ambiguities.

Handled poorly, it creates uncertainty and misaligned delivery.Handled well, it aligns intent, scope, and accountability, setting a stable foundation for everything that follows.

This is where systems engineering begins acting as a delivery function not just a design discipline.

What’s Next?

With our contractual commitments now mapped and risks understood, we turn to the world the system must live in:

Establishing the System Context - We will define the operational environment, external constraints, real-world users, and the forces that shape the system boundary not just from assumptions, but grounded in context.