1.What this page explains
A C1 presentation of a concept or project is more than a sequence of slides. It must connect problem, goal, value, approach, resources, risks, and next decisions so that the audience understands the logic quickly.
Core structure:
current situation
→ problem / need
→ goal
→ concept / solution
→ value
→ implementation
→ resources
→ risks
→ next steps
→ decision / discussion
Example:
Ausgangspunkt unseres Konzepts ist die Frage, wie wir die Bearbeitungszeit reduzieren können, ohne die Qualität zu beeinträchtigen.
Dazu schlagen wir einen dreistufigen Prozess vor, der zunächst in einem Pilotbereich getestet wird.
Entscheidend ist, dass wir Wirkung und Aufwand bereits in der Pilotphase messen.
At C1, several levels need to be controlled at once:
clear macro-structure
precise transitions
audience-appropriate depth
value argumentation
plausible evidence
feasibility
risk communication
linguistic qualification
time management
questions and objections
Core rule:
A strong project presentation answers not only “What do we want to do?” but also “Why? For whom? How? With which resources? With which risks? And how will we know it worked?”
The page is reference and self-study material. It contains no exercises or tests.
2.1. Purpose of a concept presentation
A concept presentation should create understanding, confidence, and decision-readiness.
Examples:
Ziel ist, die Entscheidungsgrundlage transparent zu machen.
3.2. Project vs concept
A concept describes the logic and solution approach; a project adds timing, ownership, resources, and implementation.
Examples:
Konzept → Projektplan
4.3. Audience first
The presentation should start from the audience's information needs, not the team's internal work process.
Examples:
Was muss dieses Publikum wissen, um entscheiden zu können?
5.4. Clarify the decision question
Before presenting, be clear about what decision or response is expected at the end.
Examples:
Wir bitten heute um Freigabe der Pilotphase.
6.5. One core message
The entire presentation should converge on one clearly expressible core message.
Examples:
Unser Vorschlag reduziert Aufwand, ohne den Serviceumfang zu verringern.
7.6. Make the macro-structure visible
A brief roadmap at the beginning makes orientation easier.
Examples:
Ich gehe zunächst auf die Ausgangslage ein und anschließend auf Lösung, Umsetzung und Risiken.
8.7. From problem to solution
The solution should not precede the problem if that would make its relevance unclear.
Examples:
Zuerst Bedarf, dann Konzept.
9.8. Do not assume value is obvious
Value should be explicit: for users, organization, cost, quality, or risk.
Examples:
Der Nutzen liegt vor allem in ...
10.9. Hierarchy of detail
Not every piece of information belongs at the same level. Core claims come first, details second.
Examples:
Kernaussage → Beleg → Detail
11.10. Time as a structural constraint
Available time determines how many levels can reasonably be explained.
Examples:
10 Minuten ≠ 45 Minuten
12.11. Evidence rather than assertion
Important benefits should be supported by data, observations, experience, or clear reasoning.
Examples:
Im Pilot sank die Bearbeitungszeit um ...
13.12. C1 goal
At C1, a strong presentation integrates content, argumentation, language, and interaction.
Examples:
Struktur → Begründung → Machbarkeit → Entscheidung
14.13. Strong opening
A good opening makes relevance visible without long preliminaries.
Examples:
Ausgangspunkt ist ein Problem, das derzeit drei Teams gleichzeitig betrifft.
15.14. Frame the problem question
A precise problem question creates focus.
Examples:
Wie können wir die Durchlaufzeit verkürzen, ohne zusätzliche Stellen aufzubauen?
16.15. Describe the current situation
The current-state section should contain only facts relevant to the concept.
Examples:
Derzeit werden Anfragen in drei getrennten Systemen bearbeitet.
17.16. Explain urgency
Urgency should be justified by consequences, deadlines, or risks, not dramatization.
Examples:
Handlungsbedarf besteht, weil ...
18.17. Describe the target state
The target state describes what success looks like after implementation.
Examples:
Künftig soll jede Anfrage über einen einheitlichen Prozess laufen.
19.18. Make goals measurable
When possible, goals should contain observable criteria.
Examples:
Bearbeitungszeit um 20 Prozent reduzieren.
20.19. Not every goal needs a number
Qualitative goals such as clarity or acceptance can also matter but need explicit criteria.
Examples:
Nutzer sollen den neuen Ablauf ohne Zusatzschulung verstehen.
21.20. Define scope
The presentation should clarify what is in scope and deliberately out of scope.
Examples:
Nicht Gegenstand dieses Projekts ist ...
22.21. Make assumptions explicit
Key assumptions should be stated explicitly.
Examples:
Wir gehen derzeit davon aus, dass ...
23.22. Name dependencies
Internal and external dependencies affect feasibility and timing.
Examples:
Voraussetzung ist die Schnittstellenfreigabe.
24.23. Do not open with process history
Long histories are useful only when relevant to the decision.
Examples:
Nicht: Zuerst hatten wir im Januar drei Workshops ...
25.24. Agenda as a value promise
An agenda can show which questions the presentation will answer.
Examples:
Warum ändern? Was schlagen wir vor? Wie setzen wir es um?
26.25. Frame without manipulation
Problem framing should focus attention without artificially excluding alternatives.
Examples:
Die relevanten Optionen sind ...
27.26. Transition to the solution
The transition should derive the solution logically from the need.
Examples:
Aus diesen Anforderungen ergeben sich drei Designprinzipien.
28.27. Concept in one sentence
The concept should be explainable in one clear sentence.
Examples:
Wir bündeln die drei Prozesse in einer gemeinsamen Eingangsstufe.
29.28. Structure the components
Complex concepts can be divided into a small number of functional components.
Examples:
Das Modell besteht aus drei Bausteinen.
30.29. Design principles
Design principles explain the rules guiding the solution.
Examples:
einfach · skalierbar · nachvollziehbar
31.30. Explain how it works
The operating logic should be explained in a clear sequence.
Examples:
Zunächst ..., anschließend ..., abschließend ...
32.31. User perspective
A concept presentation becomes stronger when it shows how the experience changes for users.
Examples:
Für Mitarbeitende bedeutet das konkret ...
33.32. Organizational perspective
Besides user value, controllability, quality, risk, and cost may matter.
Examples:
Für die Organisation entsteht der Vorteil, dass ...
34.33. Distinguish types of value
Value can be quantitative or qualitative.
Examples:
Zeitersparnis · höhere Transparenz · geringeres Risiko
35.34. Prioritize benefits
The most important benefits should come first.
Examples:
Der größte Hebel liegt bei ...
36.35. Connect value to evidence
A benefit is more persuasive when its evidential basis is immediately clear.
Examples:
Im Testlauf sank ...
37.36. Calibrate promises
Forecasts should be phrased only as strongly as data and assumptions allow.
Examples:
Wir erwarten eine Reduktion von etwa ...
38.37. Differentiate from alternatives
Explain why this approach is chosen over plausible alternatives.
Examples:
Im Vergleich zur Vollautomatisierung ist dieser Ansatz ...
39.38. Make trade-offs visible
A credible concept shows not only benefits but also trade-offs.
Examples:
Mehr Standardisierung erhöht Effizienz, reduziert aber Flexibilität.
40.39. Do not treat every alternative equally
Only serious alternatives need detailed comparison.
Examples:
Option A, B, C
41.40. Name the decision criterion
A comparison is understandable only when criteria are transparent.
Examples:
Kosten, Wirkung, Risiko, Umsetzungsdauer
42.41. Implementation as its own logic
After the concept comes the question of realistic implementation.
Examples:
Vom Zielbild zum Umsetzungsplan.
43.42. Phased model
A phased implementation reduces complexity and creates learning loops.
Examples:
Pilot → Auswertung → Skalierung
44.43. Pilot phase
A pilot should clearly define what is being tested and measured.
Examples:
Im Pilot prüfen wir ...
45.44. Milestones
Milestones mark verifiable intermediate states, not just dates.
Examples:
Freigabe des Prototyps
46.45. Responsibilities
Roles and decision rights should be visible.
Examples:
Für die Umsetzung verantwortlich ist ...
47.46. Resources
Resources include time, people, budget, systems, and expertise.
Examples:
Benötigt werden ...
48.47. Capacity vs effort
Planned effort is meaningful only in relation to available capacity.
Examples:
Der Aufwand beträgt ..., verfügbar sind jedoch ...
49.48. Make budget transparent
Budget figures should state time horizon and included items clearly.
Examples:
Die Schätzung umfasst ...
50.49. Dependencies in the timeline
A timeline should show critical dependencies.
Examples:
Phase 2 kann erst nach Freigabe von ... beginnen.
51.50. Decision gates
Between phases, deliberate go/no-go or adjustment decisions may be needed.
Examples:
Nach dem Pilot entscheiden wir über die Skalierung.
52.51. Success criteria
Success criteria should be defined before implementation.
Examples:
Erfolg liegt vor, wenn ...
53.52. Leading and lagging indicators
Early process indicators and later outcome indicators complement each other.
Examples:
Nutzung im Pilot ↔ langfristige Zeitersparnis
54.53. Learning loops
A good project deliberately integrates feedback and adaptation.
Examples:
Nach jeder Phase werden Annahmen überprüft.
55.54. Scaling
Scaling is not mere repetition; larger scale can create new issues.
Examples:
Was im Pilot funktioniert, muss nicht unverändert skalieren.
56.55. Name risks openly
Risk communication increases credibility when linked to mitigation.
Examples:
Ein wesentliches Risiko besteht in ...
57.56. Risk vs problem
A risk is a possible future event; a problem already exists.
Examples:
Risiko: Verzögerung; Problem: Schnittstelle ist derzeit nicht verfügbar.
58.57. Likelihood
Risks can be prioritized by likelihood and impact.
Examples:
hohe Wirkung, mittlere Wahrscheinlichkeit
59.58. Risk mitigation
Key risks should have a concrete mitigation measure.
Examples:
Zur Begrenzung dieses Risikos ...
60.59. Residual risk
Residual risk may remain even after mitigation.
Examples:
Vollständig ausschließen lässt sich ... nicht.
61.60. Feasibility
Feasibility includes technical, organizational, financial, and temporal dimensions.
Examples:
Technisch möglich, organisatorisch jedoch anspruchsvoll.
62.61. Assumptions as risk sources
The more critical an assumption is to success, the earlier it should be tested.
Examples:
Die wichtigste Annahme betrifft ...
63.62. Levels of evidence
Pilot data, benchmarks, qualitative interviews, and expert judgment have different evidential strength.
Examples:
Die Prognose basiert derzeit auf ...
64.63. Use benchmarks carefully
Benchmarks are useful only when context and definitions are comparable.
Examples:
Der Vergleich ist nur eingeschränkt übertragbar.
65.64. Do not present correlation as causation
Project rationales should distinguish causation from association.
Examples:
Die Daten deuten auf einen Zusammenhang hin.
66.65. Quantify uncertainty
Ranges can be more realistic than point forecasts.
Examples:
Wir erwarten zwischen 10 und 15 Prozent Einsparung.
67.66. Scenarios
Best-, base-, and worst-case scenarios can improve robustness if assumptions are transparent.
Examples:
Im Basisszenario ...
68.67. Not every uncertainty belongs on slides
The presentation should prioritize uncertainties relevant to the decision.
Examples:
entscheidungsrelevant vs. Detailrisiko
69.68. Feasibility conclusion
In the end, it should be clear under which conditions the concept is realistic.
Examples:
Unter diesen Voraussetzungen ist die Umsetzung realistisch.
70.69. Signposting
Signposting makes the logic audible.
Examples:
Damit komme ich zum zweiten Punkt.
71.70. Backward references
Brief backward references connect sections.
Examples:
Wie eingangs gezeigt, ...
72.71. Forward references
Forward references help defer questions in a controlled way.
Examples:
Auf die Kosten gehe ich gleich noch ein.
73.72. Highlight key messages
Explicit focus markers help the audience.
Examples:
Entscheidend ist ...
Der zentrale Punkt ist ...
74.73. Mark contrast
Contrasts should be linguistically explicit.
Examples:
Während Variante A ..., bietet Variante B ...
75.74. State limitations
Professional presentations state limitations without unnecessary self-undermining.
Examples:
Diese Aussage gilt zunächst nur für den Pilotbereich.
76.75. State a recommendation
A recommendation should be clear and justified.
Examples:
Daher empfehlen wir, mit Variante B in die Pilotphase zu gehen.
77.76. State the decision needed
At the end, it should be exactly clear what decision is needed.
Examples:
Heute benötigen wir eine Entscheidung zu ...
78.77. Speaking pace
Complex content needs deliberate pacing and short processing pauses.
Examples:
Nach einer Kernaussage kurz pausieren.
79.78. Speaking numbers
Numbers should not be read out in dense sequences; they should be interpreted.
Examples:
Wichtiger als 17 Einzelwerte ist der Trend.
80.79. Do not read slides
Spoken explanation and visual display should complement each other.
Examples:
Folie zeigt Struktur, Sprecher erklärt Bedeutung.
81.80. Explain visuals
A chart needs spoken guidance.
Examples:
Wenn Sie auf die linke Seite schauen, sehen Sie ...
82.81. Use terminology consistently
Key concepts should not be renamed unnecessarily.
Examples:
Pilotbereich bleibt Pilotbereich.
83.82. Audience-appropriate technical language
Technical terms are useful when the audience knows them; otherwise define them briefly.
Examples:
Mit Durchlaufzeit meinen wir ...
84.83. Prepare for Q&A
Typical questions can be grouped into value, cost, risk, timing, and alternatives.
Examples:
Was kostet es? Was passiert bei Verzögerung?
85.84. Listen to the whole question
A precise answer starts with understanding the whole question.
Examples:
Wenn ich Sie richtig verstehe, geht es um ...
86.85. Paraphrase the question
A brief paraphrase can focus a complex question.
Examples:
Sie fragen also, ob ...
87.86. Answer directly
Give the core answer first, then the reasoning.
Examples:
Kurz gesagt: ja. Der Grund ist ...
88.87. State uncertainty openly
If a number is not yet reliable, say so transparently.
Examples:
Dazu haben wir derzeit noch keine belastbare Zahl.
89.88. Not knowing ≠ being unprepared
Professionalism includes marking knowledge limits and naming the next verification step.
Examples:
Das prüfen wir in der Pilotphase.
90.89. Acknowledge objections
A strong objection should be acknowledged fairly.
Examples:
Der Einwand ist berechtigt.
91.90. Contextualize objections
After acknowledging it, clarify how much the objection changes the recommendation.
Examples:
Er verändert den Zeitplan, nicht jedoch die Grundlogik.
92.91. Close without a repetition dump
The close should bundle decision, value, and next step.
Examples:
Zusammenfassend empfehlen wir ...
93.92. Call to action
In decision-oriented presentations, the desired next step should be explicit.
Examples:
Wir bitten um Freigabe bis Freitag.
94.93. Open the discussion
A focused question can open discussion more productively.
Examples:
Welche Voraussetzung sehen Sie für die Pilotfreigabe noch als offen an?
95.94. Follow up after the presentation
Decisions, open items, and ownership should be documented after the presentation.
Examples:
Entscheidung · To-do · Owner · Termin
96.95. Typical error: going into detail too early
If detail comes before the overall logic, the audience loses orientation.
Examples:
erst Warum und Was, dann Wie im Detail
97.96. Typical error: showing only advantages
A presentation without risks or trade-offs can quickly seem unconvincing.
Examples:
Nutzen + Grenzen + Gegenmaßnahmen
98.97. Typical error: unclear decision request
If the audience does not know what should be decided, the presentation lacks a clear purpose.
Examples:
Was genau soll heute freigegeben werden?
99.98. Typical error: treating slides as a document
Too much text forces the audience to read instead of listen.
Examples:
Folie = visuelle Unterstützung, nicht Volltext.
100.99. C1 presentation algorithm
A clear sequence helps with planning and quality control.
1. Welche Entscheidung oder Reaktion brauche ich?
2. Wer ist das Publikum und was weiß es bereits?
3. Was ist das Problem / der Bedarf?
4. Welches Zielbild schlage ich vor?
5. Wie funktioniert das Konzept?
6. Welchen Nutzen schafft es und worauf stützt sich diese Annahme?
7. Wie wird umgesetzt: Phasen, Ressourcen, Verantwortlichkeiten?
8. Welche Risiken, Annahmen und Abhängigkeiten sind entscheidungsrelevant?
9. Woran messen wir Erfolg?
10. Was ist der konkrete nächste Schritt?
101.100. What to remember
A strong C1 project presentation combines clear logic, robust reasoning, realistic implementation, and a clear decision perspective.
Problem → Ziel → Konzept → Nutzen
Umsetzung → Ressourcen → Risiken
Evidenz → Annahmen → Erfolgskriterien
Q&A → Entscheidung → nächster Schritt
Publikum nicht mit Details überladen
Versprechen nur so stark formulieren, wie die Evidenz erlaubt
102.Summary
A robust C1 structure:
1. current situation
2. problem / need
3. target state
4. concept
5. value
6. alternatives / trade-offs
7. implementation
8. resources
9. risks and assumptions
10. success criteria
11. decision
12. next steps
Useful language:
Ausgangspunkt ist ...
Die zentrale Frage lautet ...
Unser Ziel ist ...
Dazu schlagen wir vor ...
Der größte Nutzen liegt in ...
Im Vergleich zu ... bietet dieser Ansatz ...
Voraussetzung dafür ist ...
Ein wesentliches Risiko besteht in ...
Zur Begrenzung dieses Risikos ...
Entscheidend ist ...
Daher empfehlen wir ...
Heute benötigen wir eine Entscheidung zu ...
For implementation:
pilot → evaluation → scaling
milestones
ownership
budget
dependencies
go/no-go points
success criteria
For Q&A:
Wenn ich Sie richtig verstehe, ...
Kurz gesagt: ...
Der Einwand ist berechtigt; er verändert jedoch ...
Dazu haben wir derzeit noch keine belastbare Zahl.
Das prüfen wir in der Pilotphase.
A persuasive presentation makes not only the idea understandable, but also its value, evidence, feasibility, risks, and concrete decision need.