How Do I Write a Good IHK Project Proposal?

A practical guide for IT specialist apprentices specialising in application development

When I wrote my project proposal, my first surprise was this: the requirements differ from one IHK to another. There are general guidelines, but the structure, scope and formal requirements can vary depending on the Chamber of Industry and Commerce.

So don't rely solely on examples you find online. Always check the current requirements of the IHK responsible for you. If anything remains unclear, ask at your vocational school or your trainers. That's what they're there for — and asking beforehand takes less time than dealing with a rejection afterwards.

What I've written down here is what I learned while writing my own proposal. Hopefully, it will save you some of the research.

Finding a Good Topic — and Recognising Bad Ones

Ideally, your company will tell you which project you are going to work on. If not, this checklist can help.

A project is suitable if it has the following characteristics:

• It is complex and includes both technical and business-related tasks.
• It involves a genuine problem: you are not simply following standard procedures, but making real decisions with room for design choices.
• It requires communication with project stakeholders and interfaces.
• It incorporates a broad range of skills and knowledge.
• Your own contribution can be clearly distinguished from that of others.

The following are not suitable:

• Routine tasks carried out according to predefined instructions
• A programme that merely puts together predefined code snippets
• Simply working through a list of tasks without considering the underlying context and consequences

The key point is this: your project should solve a real problem. Ideally, you have a real client or stakeholder and a task that requires analysis, design, implementation and testing.

The Structure of a Strong Project Proposal

The official IHK template specifies the structure. A proven structure is:

1. Project title (project assignment or part of an assignment)
2. Project description
   1. Current-state analysis (reason for the project, current situation)
   2. Target concept and objectives (benefits for the customer)
   3. Business process and practical problem (your own contribution)
3. Area of application and specialist field
4. Project environment (context, process interfaces, contacts)
5. Project phases with time planning in hours — as a table
6. Project period
7. Project supervisor at the training company

You will also need to specify the type of documentation and include any attachments, such as a diagram.

The quickest way to make progress is to use the official template and fill it in field by field. Don't invent your own structure. The examination board is specifically looking for these components, and rearranging them only makes their job unnecessarily difficult.

Cur­rent-State Analysis, Target Concept and Objectives

The Current-State Analysis

The current-state analysis is where most proposals either fail — or really stand out. It describes the situation before your project: How does the process work today? What makes it cumbersome, error-prone, expensive or slow?

Four rules helped me:

• Describe the current business process concretely and in complete sentences.
• Explain who does what and how they do it today. Phrases such as "manually in Excel" or "forwarded manually by email" say more than any abstract description.
• Clearly identify the problem: time-consuming, error-prone, no validation possible. The problem is the justification for your project — without it, there is no reason for you to carry out the work.
• Write so that someone from outside the organisation can understand it. Don't use internal abbreviations without explaining them.

The rule of thumb is: current state + specific deficiency. Both need to be there. A process without an identified deficiency simply reads like a description of something that is already working well.

The Target Concept

After the current state comes the target state. What should have been achieved by the end? Define a clear project objective and list the specific requirements.

Keep current state and target state aligned: every problem identified in the current-state analysis should have a solution in the target concept. This creates the clear thread the examination board is looking for — and it will also help you later when writing your documentation because the structure is already in place.

Project Planning: The Phase Table with Hours

The examination board wants to be able to see at a glance that your project fits within the required 80 hours. That's what the tabular time plan is for, ideally structured into main and sub-phases, including the number of hours.

Getting Personas and Target Groups Right

A common beginner's mistake is to write the application or documentation as if the examination board were the users. That's wrong.

The IHK template asks about internal and external contacts, affected departments, employees, target groups, customers and suppliers in the project environment. What matters here are the actual users of your software within the company or at the customer's organisation.

Here's how to define personas meaningfully:

• State their role or function, for example, "administrator in the pricing department"
• Describe what this person wants to achieve with the system
• Add their context and prior knowledge — if they have "no IT background", this leads to specific requirements regarding usability
• Explain why they benefit from your project

The examination board evaluates your proposal. It is your audience, but never your target group. Write for the people who will actually use the software later.

Recher­che-Tipps

You don't have to reinvent the wheel. There are some good, free resources available for project proposals in IT professions:

IT-Berufe Podcast (german): This podcast has helped countless apprentices enormously. There are dedicated episodes covering the project proposal, project documentation (german) and the presentation.

Ausbildung in der IT (german): Here you can find more information on the structure, examples, assessment criteria and specific help with wording your project proposal.

One word of advice when using examples you find: use genuine, approved proposals as a reference for structure and language — but always write about your own actual project at your company. Copied or invented projects can be recognised and may be awarded zero points.

Good luck with your final examination!