Letter of Intent Signed Before the Charter Is Approved
You are the project manager for a $4.2 million replacement of a 14-year-old warehouse management system at a third-party logistics company. Six weeks into initiation, the COO (sponsor) has signed a non-binding letter of intent with Vendor A to lock in a 22% discount that expires at quarter end, and wants the contract signed before the charter is approved. Meanwhile: the operations director insists the new system keep a paper-based picking fallback; IT security requires SSO and MFA that Vendor A's current release does not support until version 6; the union steward has raised job-redesign concerns. A customer audit last month revealed a contractual obligation for lot-level traceability with four-hour recall reporting that appears nowhere in the draft requirements. The steering committee meets in three weeks. No scope baseline or requirements traceability matrix exists. The sponsor's email reads: 'Sign now, we'll sort out requirements during design.'
1. How do you respond to the sponsor's instruction? Set out what you would do in the next three weeks and what you would refuse to do.
Read the worked answer
Separate the commercial deadline from the delivery decision, then give the sponsor a real option rather than a flat refusal.
Why signing now is risky. A firm contract needs a defined statement of work. With no requirements baseline, the vendor prices what it imagines, and every gap (SSO/MFA in v6, traceability, the paper fallback) becomes a change order or a dispute. The 22% discount is a number you can actually compare only against the cost of that exposure.
What I would do.
- Quantify the discount (roughly $X against a $4.2M base) and put it beside the cost of the three known gaps plus the rework risk. Take that one page to the sponsor within 48 hours.
- Propose a three-week requirements sprint covering only what the contract must price: traceability, security, fallback, interfaces. Freeze the rest.
- Ask the vendor for a reservation-of-rights extension, or a short paid feasibility/proof-of-concept agreement that preserves the price and tests the v6 claim without committing scope.
- Get the charter approved at the steering committee with the traceability obligation written in as a success criterion and constraint.
What I would refuse to do. Sign a fixed-price contract with undefined scope, and let the team start design work against unapproved requirements. If the sponsor overrides me, I document the decision, the assumptions, and the accepted risk, and I make sure the contract carries a clear change mechanism.
2. The union steward, the customer, the operations director, and IT security all have a stake. How would you analyse and engage them, and what would you change about your approach for each?
Read the worked answer
Use a power/interest and salience analysis, but the point is the differentiated action that follows, not the grid.
- Customer (contractual requirement, high power, currently low interest): their audit already produced a non-negotiable obligation. Engage directly now, confirm the exact acceptance criteria for recall reporting, and get it in writing. They are a requirements source, not a bystander.
- IT security (high power via gatekeeping, moderate interest): they can block go-live. Bring them into the requirements sprint as approvers of the SSO/MFA criteria, and ask them to state the compensating controls acceptable if v6 slips.
- Operations director (moderate power, high interest): wants the paper fallback for operational continuity. Treat this as a design decision with a cost, not as resistance. Ask for the fallback duration and volume threshold so it can be priced, and record it as an accepted requirement or a documented exclusion.
- Union steward (low formal power, high influence over adoption): the risk is industrial, not technical. Meet early and separately, explain the job-redesign intent honestly, and build a consultation cadence into the communication plan. Excluding them until deployment is how you get a late-stage stoppage.
Update the stakeholder register with engagement stance and named actions, and review it at each steering committee.
3. Requirements are still unresolved. What belongs in the project charter now, and what must explicitly stay out of it?
Read the worked answer
The charter is a high-level authorisation document; it should tolerate uncertainty about detail while nailing down authority, boundaries, and success.
Include:
- Purpose and measurable objectives (go-live date, recall reporting within four hours, picking accuracy target).
- High-level scope in and out: the WMS replacement covers these sites and functions; hardware refresh is out.
- Success criteria and acceptance approach, including the customer traceability obligation as a non-negotiable.
- Summary milestones and a high-level budget with the basis of estimate stated as order-of-magnitude.
- Key constraints (quarter-end commercial window, security standards, plant freeze periods) and assumptions (Vendor A will support SSO/MFA by the required date - to be validated).
- High-level risks: undefined requirements, vendor capability gap, workforce change.
- Sponsor, project manager, and delegated authority, including who can approve changes and up to what value.
- Key stakeholders and the governance/reporting arrangement.
Keep out: the requirements catalogue, detailed WBS, activity-level schedule, and the traceability matrix. Those live in the scope and requirements documents that the sprint will produce, and they will change.
Putting detail in the charter creates a false baseline and forces charter amendments for ordinary design decisions. Putting the traceability requirement in it does the opposite: it prevents the project from being declared successful without it.