We run transformations rather than advise on them: roadmap, delivery, and the part that decides whether it worked, which is whether people changed how they work. In Belgium that last part has a legal front door. Where a technology change affects a category of staff, information and consultation are due three months before implementation begins.
Before implementation starts, written information and consultation are due where a technology change carries important collective consequences.
The threshold: half of a professional category, and at least ten people affected.
The protected window around it, during which a dismissal has to be justified.
Roadmap and sequencing
What changes when, and in which order.
Business alignment
Ensuring initiatives support your goals.
Change management
Driving adoption with clear communication.
Social consultation planning
Because it starts before implementation.
Ways of working design
The part people actually experience daily.
Training and capability
So the new way is usable, not just live.
Adoption measurement
Usage, not attendance at a briefing.
Adoption first
A transformation is judged on whether people work differently afterwards, not on whether the system went live on time. Those two things fail independently, and the second one is much easier to report than the first.
A calendar that fits the law
The consultation obligation planned into the roadmap rather than discovered six weeks before go-live. In Belgium that obligation can open three months before the date most plans treat as the start.
Resistance handled early
Objections surfaced while the design can still absorb them. Resistance that appears at rollout is rarely new. It is usually something someone said in month two that nobody wrote down.
It holds up
Measured on usage months after the programme closes, not on training attendance during it. A transformation that reverts once the consultants leave has bought an expensive pause rather than a change.
With us | Strategy firm | In-house | Systems integrator | |
|---|---|---|---|---|
| What you buy | Delivery, and the change around it | A direction and a business case | Nothing, you run it yourself | A working system, on a date |
| Who owns adoption | Shared, and named on both sides | You do, after they leave | You do, entirely | Nobody, contractually |
| Consultation planning | In the roadmap from the start | Rarely their scope | Yours, and usually well done | Outside their scope |
| Success measured on | Usage after we leave | The recommendation being accepted | Whatever the sponsor asks for | Go-live and acceptance |
| Fits when | The direction is set, the change is not | The direction itself is unclear | You have capacity and a mandate | The change is mostly technical |
If the system is straightforward and the people are not, you have a transformation.
Diagnosis and roadmap
What has to change, who it touches, in what order, and where the obligations fall on the calendar.
Consultation and design
Information and consultation run properly, and the design adjusted by what comes back from it.
Rollout in waves
Population by population, with each wave changed by what the previous one exposed.
Adoption and handover
Usage measured after the programme closes rather than at go-live, with named owners inside your organisation carrying it from there. We would rather report an uncomfortable adoption number at month six than a clean one at month one.
Before implementation starts, written information and consultation are due where a technology change carries important collective consequences.
The threshold: half of a professional category, and at least ten people affected.
The protected window around it, during which a dismissal has to be justified.
Digital and platform change
New systems replacing ways of working people have used for a decade.
AI adoption in operations
Where the consultation obligation now clearly applies, and where informal use runs ahead of policy.
Operating model redesign
Reporting lines and decision rights, which is what people actually notice.
Shared services and centralisation
Where work moves between sites and countries, and consultation applies in each.
Process standardisation
Usually resisted because the local version worked, which is worth hearing out.
Post-merger ways of working
Two organisations that both think their way is the reference point.

Financial services
Strong works councils and long approval chains, so the consultation calendar sets the plan.
Automotive and manufacturing
Where a change to work organisation touches production and negotiation at the same time.
Business services
Centralisation programmes, where the people affected are the ones running the process.
We do not set the direction. That is a genuine limit and we would rather state it than blur it. What we do is run the change once the direction exists: sequencing, consultation, ways of working, training, and measuring whether anyone actually works differently afterwards. Strategy firms are good at the first part and the adoption gap is where most programmes are lost.
In companies with at least fifty workers, where an investment in new technology carries important collective consequences for employment, work organisation or working conditions. Important means at least half of a professional category and at least ten people. Written information and consultation are due at the latest three months before implementation starts, through the works council or, failing that, the union delegation.
Yes. The Belgian occupational knowledge centre treats the same convention as applying to data collection and the use of algorithms at work, so an AI deployment affecting a category of staff sits inside it. That matters because AI programmes tend to start informally, with people already using tools before anything is announced, which makes the formal calendar harder rather than easier.
On usage, at a point after the programme has closed. Attendance at training tells you people were in the room. Logins tell you they opened it once. What matters is whether the old way is still running in parallel six months later, which is the number most programmes avoid collecting because it is usually disappointing.
Project delivery produces something to a scope and a date. Transformation changes how people work, and the scope cannot be fully written at the start because the design moves with what consultation and early waves reveal. A system delivered perfectly that nobody uses is a successful project and a failed transformation. They are often bought together and they fail separately.
Three things, in order of frequency. The consultation calendar is discovered late, which compresses the design phase rather than the technical one. The sponsor changes halfway and the mandate quietly changes with them. And adoption is declared rather than measured, which means nobody finds out until the old process is still running a year later.
Tell us what has to change and who it touches. You get a view of the sequence, of where the consultation obligations fall, and of what is likely to resist.