As a team lead in higher education, I was responsible for six semesters during a curriculum renewal. We once had a simple process. Students enrolled in a semester, followed the programme, and moved on. Not perfect, but manageable.
Then we wanted to add choice. Students could decide for themselves which semester they wanted to do. Sounds like one small adjustment. But the moment you add choice, you have to decide who gets to make which choice. So a credit check was added.
Then external clients wanted maximum group sizes. So alongside credits, capacity also had to be tracked — and that was tied to the semester choice, because not every client could supervise the same number of students. On top of that, subject lecturers, materials, and rooms were not available in unlimited supply.
Then it turned out that students were entering without the right prior knowledge. So admission requirements for prerequisites were added. But prior knowledge is not the same as credit points. Someone can have enough credits but have taken the wrong courses.
And then came external — often international — students. Different prior education, different credit structures, different language requirements, different rules.
What started as “we’re adding choice” was no longer a process adjustment. It was a network of dependencies. And every addition touched everything that was already there.
The maths nobody does
That is exactly where a lot of process design goes wrong: we count components, but forget the relationships between them.
We act as if processes are lists. First this, then that, then a check. But processes are networks. And in networks, a simple formula applies: n(n-1)/2.
With five elements you have ten possible relationships. With ten elements, 45. With twenty, 190.
Brooks described this in The Mythical Man-Month for communication in teams. Add one person to a team of four and you don’t go from four to five lines of communication — you go from six to ten.
The same applies to process steps, business rules, and software components. Every addition looks linear. The number of possible relationships grows quadratically.
Where it tips
In our enrolment process, the tipping point came around the admission requirements for prior knowledge. Until that moment you could still explain it as a series of checks. But once prior knowledge had to be verified against semester choice, capacity, credit points, and scheduling, it was no longer a checklist. It became a web.
And that web was made harder still by timing. The grades needed for the prerequisite check only became available at the end of the previous semester. Students could still sit resits. Some results only came in while the new semester had almost already started.
The pragmatic solution: conditional admission. Students were allowed to start while awaiting their resit result. But if they failed three weeks in, they were already in a project group — assembled based on capacity, prior knowledge, and client requirements. Precisely the checks the entire system was designed for were thereby temporarily undermined.
And then everyone solved it in their own way. One coordinator only started the project after four weeks. Another made groups robust enough that students could drop out. A third just got started and hoped for the best.
Three solutions to the same problem, in the same programme, in the same year. Not because people were incompetent — but because the system had become too complex to solve consistently.
And every local solution itself became part of the system. An extra agreement, an extra exception, an extra way of working. Before you know it you have six variants of the same process, each with its own rules, its own spreadsheets, and its own tacit knowledge.
Try standardising that. “Yes but we work differently.” “Our client requires this.” “This approach actually works really well for us.” And usually they are all partly right.
There you stand as a team lead. Six semesters under your responsibility. An admin team running on spreadsheets. Schedulers who can no longer process the exceptions. And the irony: this started as a good idea. More choice for students.
This is also software architecture
What happens here is not unique to education.
You “quickly” add an extra status to a workflow. But that status affects notifications, dashboards, authorisation, error handling, and support procedures.
You “quickly” add an exception for one client. But that exception has to be remembered by developers, administrators, support, documentation, and future migrations.
In software we call this coupling.
In processes we usually call it hassle.
But it is the same pattern. A system does not become unmanageable because one component is complicated. It becomes unmanageable because too many components need to know too much about each other.
What you can do about it
The solution is not to never add anything again. But it helps to be honest about what an addition truly costs.
Count relationships, not steps. Don’t ask “can we add this?” — the answer is almost always yes. Ask “with how many existing components does this need to interact?” That number is the real measure of impact.
Look for decoupling. Not everything needs to work with everything. Sometimes you can do a check earlier, make a decision definitively later, or split a process into smaller parts with clear boundaries.
Dare to remove things. Much process complexity doesn’t arise from bad ideas, but from good ideas that were never cleaned up. Rules that were once logical. Workarounds that were once meant to be temporary. Temporary solutions tend to become permanent once they land in a process.
One thing is almost never just one thing
Every time it feels like one addition. An extra step, an extra rule, an extra check. But in reality you are adding relationships with everything that was already there.
And those who don’t see that are slowly building a system that one day can no longer be managed. Not because one big mistake was made — but because too many well-intentioned things were added without designing the relationships alongside them.