The page in a project proposal that needs the most detail isn't the solution. It's "assumptions and preconditions"

Requirements keep growing and milestones keep slipping. Who pays for the extra time and people? Settle that at kickoff, in the least noticed chapter of the project proposal: assumptions and preconditions.

If it isn’t written down at kickoff, all that’s left later is arguing. The business says “this should have been included all along.” The project team says “this is out of scope.” Neither side can convince the other.

This post covers: the eight things to lock at kickoff, how to write the one most often missed, and how to write up the organization and the deliverables.

1. Eight things to lock at project kickoff

Our project proposal has nine chapters: introduction, requirements, goals and scope, assumptions and preconditions, proposed solution, implementation plan, organization, cost estimate, deliverables. Broken down, these are the eight things to lock:

• Scope: down to which plant, which shop, which production line; which systems to integrate, such as SAP, MES, SRM, QMS, WCS; which functions to build. Write down what is out of scope, too
• Goals: measurable, such as how far slow-moving inventory drops or what on-time delivery rate is reached. No lines like “improve efficiency”
• Acceptance criteria: as earlier posts kept saying, the bar for acceptance is set at kickoff, not negotiated at acceptance
• Milestones: kickoff, blueprint, build, go-live preparation, trial run, acceptance
• Organization, staffing, deliverables: who decides, who does the work, what gets handed over; more in section 3
• Budget: estimated separately for hardware, software, integration and implementation, and person-days, each with a basis

One detail in the functional scope is very useful: tag every line of the function list as “reuse” or “modify.” Reuse means it already exists on the platform; modify means development. You can see at a glance which functions eat person-days, which gives you solid ground later when estimating effort and negotiating changes.

2. What kickoff misses most: no concrete limits on the cost of changes and delays

Even with all eight written down, the arguments still come. What gets missed most: no concrete limits, set at kickoff, on how much time and how many people requirement changes, added requirements and slipped milestones will cost.

Without limits, every new requirement means another argument: does this count as a change? Who covers the extra person-days? Does the milestone move?

This belongs in the assumptions and preconditions chapter. What it says is: the project can be done with this scope, this timeline and these people only under certain conditions; if the conditions change, the plan changes, and someone has to carry the cost.

The kinds of clauses we write in:

• Reply deadline: when the project team submits a document, the business replies within a set number of working days; no reply counts as approval
• Sign-off owner: who signs for the business and who their delegate is. If an unclear signer delays a decision, the project team is not responsible for the delay
• Data responsibility: the business owns preparing the data and keeping it accurate. If bad data causes go-live to fail, the extra work of going live again is on the business
• Scope changes: any addition, enhancement or modification outside the scope goes through change control
• Business changes: if the business changes its organization or operating model and that affects a confirmed design, the extra cost is on the business
• People: key users must attend training and work alongside the project team

This chapter isn’t a courtesy. It settles in advance who pays for the extra time and people.

3. Organization and deliverables in the proposal: who decides, who does the work, what gets handed over

Organization: first write down who decides and who checks. The organization in our proposals has these layers:

• Steering committee: sets direction, makes the final call on major issues, authorizes the project management office, and makes sure the relevant departments are fully involved
• Project management office: plan, resources, schedule, risk, communication and coordination; organizes acceptance
• Project supervisor: checks that contract responsibilities are clear, reviews whether the solution is sound, and guards budget, schedule and changes on the company’s behalf
• Key business group: guides and reviews business processes, and owns process quality
• Data group: cleans and migrates historical data, sorts out container and storage location data, maintains PFEP
• Product and development: product design; development resources, schedule and quality

The last post said that when a project won’t move, you escalate in writing. Escalate to whom? It’s written here at kickoff. With a steering committee in the proposal, when nobody on the business side will decide, there is somewhere to go and ask for a decision.

Staffing: estimate person-days by role. For each role, write what it does and how many person-days it needs, with implementation and development estimated separately. How the two split depends on the project; there is no fixed ratio. One more rule: the total person-days charged in the cost estimate must not exceed the total person-days declared in the organization. The two have to match.

Deliverables: list them by phase, each with an owner:

• Kickoff: project implementation plan, project proposal
• Requirements: research plan, system requirements specification
• Blueprint: business blueprint, blueprint review minutes
• Detailed design: detailed system design, interface design
• Go-live preparation: functional test report, user manual
• Go-live: system trial run report
• Acceptance: acceptance report, program list and the code

List them at kickoff with owners, and at acceptance you hand over exactly that list, with no scrambling for documents at the last minute.

---

Does your project proposal say who pays in time and people when requirements change?