Anyone who has software developed or reorganises a workflow will sooner or later deal with two documents. In German they are called “Grobkonzept” and “Feinkonzept”: the high-level concept and the detailed concept. The terms sound like paperwork. Used well, they save exactly that, because they prevent too much being fixed too early.
The high-level concept: the picture of the whole
The high-level concept describes how a workflow should run in future, without fixing every detail. It answers the question: where do we want to go, and in which order do we tackle it?
It typically covers:
- the future workflow in broad steps, from intake to result
- which areas and people are involved
- where software belongs - and where a clear rule or a template is enough
- which systems stay and which are connected or replaced
- the order: which area comes first, because that is where the benefit is greatest relative to the effort
- open questions that need answering before the next step
A good high-level concept is short and can be gone through with management in one meeting. It is the basis for deciding whether and how to continue.
The detailed concept: the precise plan for one area
The detailed concept takes one area from the high-level concept and describes it so precisely that it can be built. It answers the question: how exactly will this be solved?
It typically covers:
- the workflow step by step, with its exceptions
- screens and fields: what is entered and displayed where
- rules: calculations, checks, approvals
- permissions: who may see and change what
- interfaces: which data is exchanged with which systems
- data migration: what comes along from the old system
- an effort estimate for the implementation
After the detailed concept, both sides know what will be built and with how much effort.
The difference at a glance
| High-level concept | Detailed concept | |
|---|---|---|
| Question | Where to, and in which order? | How exactly? |
| Scope | the whole | one area |
| Detail | steps, people, systems | screens, fields, rules, permissions |
| Result | a decision on direction | the basis for implementation, with effort estimate |
| For | management | the department and the developers |
Why not everything in detail straight away?
The classic route is a thick concept for the whole project before the first line of code is written. That sounds thorough, but it has three drawbacks:
- It takes a long time, and meanwhile nothing happens that helps in daily work.
- It goes out of date, because workflows and requirements change while it is still being written.
- It fixes things too early. A lot only becomes clear once the first part is in use.
That is why we work differently: first a rough overview of the whole, so the direction is right. Then the detail is worked out where it hurts most. After the first area comes the next detailed concept - with everything learned up to that point.
Where the content comes from
Neither concept is written at a desk. The basis is recording the actual workflow: who does what, with which program, where is data retyped, where do people wait? For us, that means standing next to your staff, watching and asking, one morning per station, while the business keeps running. The result is process documentation on which both concepts build.
Who owns the documents
The high-level and detailed concepts should belong to you - even if you carry on with someone else afterwards. A good detailed concept is written so that another team could build from it too. If that is not agreed, ask for it.
How the two concepts relate to the German “Lastenheft” and “Pflichtenheft” is explained in our guide Requirements or functional specification?
