Learning outcomes
Two documents, two moments
| Projektantrag / application | Projektauftrag / charter | |
|---|---|---|
Moment |
before the decision |
after the decision |
Purpose |
propose: this is worth doing |
commission: this is what we do |
Changes later? |
irrelevant — it is superseded |
no — it is frozen |
Signed by |
the team |
team and client |
The same fields appear in both. The application argues; the charter commits.
The fields
| Feld / Field | What belongs in it |
|---|---|
Projekttitel / project title |
the result in one line, not the technology |
Ausgangslage / initial situation |
what exists today and why it is unsatisfactory — no solution |
Untersuchungsanliegen / research objective |
the open question the project answers |
Zielsetzung / objectives |
verifiable goals, each with its evidence |
Geplantes Ergebnis / planned deliverable |
what exists at the end, and how you recognise it is done |
Meilensteine / milestones |
dated, checkable results — not activities |
Verantwortlich / responsible |
one named person per work package |
Aufwandsschätzung / effort estimate |
hours, as a range, per work package |
These are the fields of the diploma thesis application. You fill them for the first time now, in year three, so that in year five the form is familiar rather than new.
|
The field names are German because the form is German. That is why this course teaches governance vocabulary in both languages — under exam pressure you should not be translating "research objective" back into Untersuchungsanliegen. |
Frozen — and why
The charter is frozen at approval. Everything after that happens against it:
Without a fixed point, a team can quietly adjust its goals to whatever got finished — and then every project is complete by definition. The difference between charter and result is not a failure; it is the subject of scope management, and it is only visible because one side does not move.
Decisions
-
The charter follows the field structure of the diploma thesis application, with bilingual field labels.
-
It is frozen at approval. Changes go through
openspec/changes/and are visible there, not through edits to the charter. -
Effort estimates are ranges, never single numbers.
-
Every work package has exactly one responsible person — shared responsibility is none.
Pitfalls
-
Filling in the fields as prose without a single verifiable statement. The form is then complete and useless.
-
Writing the charter after building. It happens, it is visible in the git dates, and it removes the only yardstick you had.
-
Milestones that are activities ("work on the frontend"). A milestone is a result you can check on a date.
-
Editing the charter quietly when the plan changes. Then nobody can say what changed, and the archive of changes is the wrong place to look.
Terminology
| Deutsch | English |
|---|---|
Projektantrag |
project application / proposal |
Projektauftrag |
project charter |
Untersuchungsanliegen |
research objective |
Geplantes Ergebnis |
planned deliverable |
Verantwortlich |
responsible |
Aufwandsschätzung |
effort estimate |
Further reading
-
templates/governance/projektantrag.adocandprojektauftrag.adoc -
Module
bridge-charter-to-specs— which openspec artefact carries which field