Structure of the project application and charter — questions

Three of these carry most of the weight. The initial situation must be recognisable to somebody who does not know your solution. The objectives must be checkable by a third party without asking what you meant. The milestones must be results with dates, not activities.

Two smaller rules that are easy to get wrong: the effort estimate is a range, because a single number claims a precision nobody has; and each work package has exactly one responsible person, because shared responsibility is none.

These are the fields of the diploma thesis application. You fill them for the first time in year three so that in year five the form is familiar rather than new.

Points the answer must contain:

The same fields appear in both documents; what differs is their status. The application argues — it is allowed to be optimistic, and if it is rejected nothing follows from it. The charter commits — from the moment it is signed by both sides, it is the standard against which the project is measured.

That is why the charter is signed by the client as well. An application the team writes alone is a proposal; a charter that only the team agreed to would be a yardstick the team set for itself, which measures nothing.

Points the answer must contain:

Frozen means: after approval, the document is not edited. Everything that happens afterwards happens against it — changes run through openspec/changes/, where they are visible and dated.

Without a fixed point, a team quietly adjusts its goals to whatever got finished. Then every project is complete by definition, nobody has learned anything about estimating, and the acceptance is a formality with no content.

The important part is what the difference means. A gap between charter and result is not a failure — it is the subject of scope management, and the only calibration data a school team ever gets about its own estimates. It is visible solely because one side does not move.

The corresponding malpractice is editing the charter quietly when the plan changes. It is visible in the git dates, and it destroys the only yardstick the project had.

Points the answer must contain:

Untersuchungsanliegen, Geplantes Ergebnis, Aufwandsschätzung.

The reason for learning both is practical rather than linguistic: the form you fill in year five is German, and the course is taught in English. Under exam pressure — or in front of a client — you should not be translating "research objective" back into Untersuchungsanliegen while somebody waits.

Untersuchungsanliegen is also the field students most often misread. It is not the goal and not the deliverable; it is the open question the project answers — the thing that was genuinely uncertain at the start.

Points the answer must contain:

Because it is an activity, and an activity has no moment at which it is finished. Two people can look at the same state of the project and disagree about whether "work on the frontend" is done, which means it cannot carry a date and cannot be checked at a review.

A milestone is a result with a date that a third party can verify: "the attendance list can be opened and filled for one group — change add-attendance-recording archived by 15 December". Anybody can check that: the change is in the archive or it is not.

The practical consequence is what happens when the milestone is missed. With a checkable milestone, the review sees it immediately and the team can cut scope while there is still time. With "work on the frontend", the answer is always "yes, we worked on it" — true, unfalsifiable, and worthless as a warning signal.

Points the answer must contain: