How to analyse a customer specification and capture requirements, deadlines and open points quickly.

The order is in, and so is the customer specification. 120 pages, a folder of annexes, a layout drawing and a spreadsheet of utility connections. By the kick-off, the project manager is expected to know what the customer wants, by when, and on what terms the customer will accept the plant.

In German-speaking plant engineering this document is the Lastenheft. It is written by the customer and describes what they expect, as opposed to the Pflichtenheft, in which the supplier describes how they will deliver it. Whatever you call it, the first weeks of a project are decided by how well it is read.

Read it thoroughly and you win the project a second time. Skim it and you pay later in rework, customer changes without a change order and a drawn-out acceptance.

What do I need to pull out of a customer specification?

The specification states what the customer expects. Your job is to turn it into something the team can work from. Five things belong on every list, kept apart from one another.

Requirements by chapter. Output, cycle time, formats, materials, controls, safety, documentation. Record each requirement with chapter and page rather than as a loose summary. A typical case is the safety enclosure that chapter 4 describes only as "state of the art", while annex C suddenly specifies material, colour and access concept.

Deadlines and milestones. Delivery date, FAT, arrival on site, commissioning, SAT, handover of documentation. Add the deadlines that are easy to miss, such as the date by which the customer must approve the layout or deliver interface data.

Acceptance criteria. How will the customer judge that the plant is finished? Availability over a set period, reject rate, test records, training. Anything left vague here gets negotiated at acceptance, and by then you are the one under pressure.

Gaps and contradictions. What is missing, what is described twice in different ways, what refers to a document that was never sent? The classic is a supply voltage that reads one way in the text and another in the utilities annex.

Questions for the customer. The gaps and contradictions turn into a list. It is the most valuable output of the whole exercise, because every question asked now is one less customer change later.

How do I analyse a specification properly by hand?

A method that works without any software mostly needs discipline.

1. Pin down the scope first. Which documents belong to the specification, which revision is valid, which annexes are missing? Record that status with a date.
2. Set up a table with fixed columns. Requirement, chapter and page, category (technical, deadline, acceptance, documentation), status (clear, open, contradictory), owner.
3. Read chapter by chapter, not by skimming. Every statement that creates an obligation for you goes into the table. Phrases like "shall", "must", "is to be ensured" and "by agreement" are the signals.
4. Check annexes against the main text. This is where most contradictions hide, because annexes are often written by other departments on the customer side.
5. Pull deadlines into a list of their own. Working backwards from the delivery date quickly shows which approvals the customer has to give, and when, for you to hold your date.
6. Phrase open points as questions. Specific, with a source, so the customer can answer without asking what you mean.
7. Have a second person read it. Project management and engineering notice different things. One shared list stops everyone carrying their own version in their head.

It is tedious work, but it pays off. The table becomes the basis for your own functional specification, the kick-off and, later, acceptance.

Where does the analysis go wrong in practice?

The method is clear. It gets hard in three places.

Size. Past a hundred pages with references to standards, attention fades. Chapter 9 gets read faster than chapter 2, and that is exactly where the requirement for spare parts documentation sits.

Revisions. The customer sends revision B, then revision C three weeks later. What changed? A clean change list rarely comes with it. The table built on revision A is now only partly right, and nobody knows exactly which rows.

Scattered documents. The specification in the project folder, annexes in one email, the answers to your first list of questions in another, a call note in OneNote. The status is spread out, and anyone who wants to pull it together starts by searching. It is the same pattern we describe in the lead article on project status scattered across Excel, OneNote and email.

On top of that, the analysis often depends on one person. If they are off sick or move to another project, the knowledge of the gaps leaves with them. How to cover for that is the subject of the article on project handover in plant engineering.

Why does every detail need its source?

A detail without a source is a claim. With chapter and page it becomes checkable, for you, for colleagues and, if it comes to that, for the customer at acceptance.

The source also helps with revisions. If you know the cycle time came from section 3.2 of revision A, you can look at that exact place in revision C instead of reading the whole document again.

How does KoAssist help analyse a customer specification?

Project Memory, part of KoAssist, the AI project assistant for machine and plant engineering, is in pilot operation. It takes over the legwork of this method without taking the decisions away from you.

You create a project and upload the specification or connect the project folder. "Fill from documents" builds a project profile. Every detail carries its source, requirements are ordered by chapter, and whatever the documents do not answer shows up as an open detail. Milestones, dates, deadlines and commitments go into the project timeline.

For open details, "Who knows?" suggests who on the team to ask. Anything only the customer can answer goes on the "Questions for the customer" list. KoAssist sends nothing itself. You copy the list into your own email or download it.

Spotting contradictions is still your team's job. Because every detail is backed by its source, though, you can see at a glance when two values come from different places and open both passages directly. If you want to ask targeted questions, say which standards the specification cites, the Knowledge Assistant answers from your own documents and backs every answer with file, page and section.

Your source systems stay in charge. The specification stays in the project folder, the permissions from your file storage apply in KoAssist too, and your data is not used for training.

What changes at project start?

The kick-off no longer opens with the question of who has actually read the whole specification. It opens with a project profile in which every detail has its source, and with a list of open questions that goes to the customer before design begins.

You can see how this looks on the Project Memory page, and try it with one of your own specifications in a demo.