We were originally a small part of a big corporation — about 1 percent of the total business. In 2009, while we were still part of that group, my team built our own document management system. We used raw HTML, largely independent of the parent corporation's own tools. We called it ProMaS (Process Management System), and the name stuck — we still call it that today, even though IPW is now the platform running underneath it. The system had no search function, and every time we revised a document, we had to manually convert the outgoing version to PDF and link it into the revision history before the replacement could go live — a workaround for not having real version control.
That said, our homegrown system kept running quietly for the next thirteen years. Then Lindemann was carved out and sold to a private equity firm. We planned to keep a copy of the old parent company's shared systems, including whistleblowing and incident reporting, but in the end we weren’t able to do so, and so we were left with nothing.
Looking back, it was the best thing that could have happened. We were cut off from everything and were able to start from scratch. By the time we talked to IPW, thirteen years of living with the old system's limits meant our requirements weren't vague. They were pretty exact: we needed one lean system instead of several scattered ones, something we could maintain and expand ourselves, with a real search function, mobile access for the sales and service staff who are rarely at a desk, and hosting in Germany to meet our own data protection standards.
Even the build order was a considered choice
The first decision that mattered was what to build first. Many companies begin an implementation with documents — the low-risk, easy warm-up. We did the opposite. The first things we put live were whistleblowing, safety and incident reporting with investigations and corrective actions, and centralized training records with digital sign-off. Not because they were simple, but because they were exactly what the carve-out had wiped out, and two of them were compliance-critical for us, working in heavy industry.
Documents came later, and even then, in a specific order. Content that needed no review (such as our ISO standards, once we'd confirmed the current version) went in first. Then documents that needed genuine review went in. Flowcharts came last, on purpose, since a flowchart only has value once the documents it links to already exist.
There was also a third rule behind what we prioritized, and it's less about risk than about pull: where do people have a personal interest in having a piece of content? Once they come into the system because they've got what they want, they start using the rest of it too. Give people one specific reason to open the system, and the rest of their adoption tends to follow on its own.
Someone's name is on every document now
Our fix for ownerless documentation was to make it personal. Some companies still think that if there's an instruction or a procedure, quality has to write it — even when quality has nothing to do with the process itself. Every controlled document at Lindemann now gets one accountable owner and one or more approvers, using RASCI (Responsible, Accountable, Supportive, Consulted, Informed) as the framework. The owner is always whoever actually runs the process, not whoever happens to sit in quality. You are accountable. It is your baby.
Buy-in was engineered, not assumed
Getting people on board wasn't something we left to a memo. We ran training as three live sessions, staggered by time zone and language to cover Asia, Europe, and the Americas. It reached 80 to 90 percent of the organization, tracked through a confirmation click inside the system itself.
Our managing director told colleagues directly, in that training, that the new system was binding — not optional — while explicitly inviting open feedback. Authority and genuine openness, delivered together, not one instead of the other.
Alongside that top-down push, my team went looking for our loudest skeptics on purpose — the people most likely to say a new system wouldn't work. Rather than working around them, we built their specific complaints into the design. If you win over the critical employees, it becomes easy to bring everyone else on board too.
I'll be honest about how hard old habits are to break, even once people are on board. People, including myself, are lazy. If a paper printout is still sitting on your desk and the same document already exists in ProMaS, you'll reach for the paper — unless someone tells you plainly to stop. That's exactly why making the system binding mattered as much as it did. A good system on its own isn't enough if going back to the old way is still an option.
Getting expectations right was harder
than getting the system live
The decision I keep coming back to more than any other isn't the rollout at all — it's managing expectations.
Nothing is a bigger setback than when users say, this and that is missing — that should have been in ProMaS a long time ago. The fix isn't more features. It's saying, clearly and early, what's included now and what's deliberately coming later, so a gap reads as “not yet” instead of “forgotten.”
The same discipline applied to timeline, not just scope. We'd set ourselves three months to get a working system live. It took six weeks. That's the kind of result you're tempted to treat as the headline, but I treat it as a checkpoint, not a finish line. Getting there meant an intense three-week testing phase, not a longer, more comfortable one. It doesn't get any better if you stretch it out to three months. There's a saying — better ready than perfect. It goes hand in hand with the eighty-twenty rule. In the end, it's the same discipline twice over: don't let the discomfort of a visible gap talk you into promising more scope, or taking more time, than you actually need.
Built to keep changing
The system hasn't stopped evolving since launch, in three ways: people are still using it, what it can do keeps growing, and we've built a real loop for acting on feedback.
Start with usage. Monthly logins have stayed consistently high — 535 in the most recent month at the time of writing, against a low of around 400 the previous November — proof, to me, that the system is genuinely in use, not just sitting there with nobody logging in.
What it's capable of has grown too. The search we asked for from the start now covers everything, including text extracted from inside uploaded PDFs. Power BI, which started as a single dashboard, now pulls a live feed from SAP's quality module. I open the page, type in a supplier's name, and within about ten seconds I have their on-time delivery rate and quality ratio in front of me — a task that used to mean assembling supplier ratings once a year, by hand.
And we've built a real loop for acting on feedback. Earlier this year, we ran a formal user survey. Respondents could stay anonymous or put their name to their feedback. Two things came back clearly. People wanted more training, not just at rollout but as new workflows are introduced. And they wanted instructions for the forms we'd designed ourselves, since those aren't standard templates. We put together a small review team, including some of the people who'd put their name to their feedback, specifically to prioritize what to do about it. The first result is already live: a short guide attached directly to the first forms.
What this means if you're about to do this yourself
My advice starts with commitment. It has to come from the top, and it has to be visible, not just assumed — which is exactly what our managing director did. Without it, you're lost.
Identify every real stakeholder before you start building — including anyone who can effectively veto the project. Our own team included IT, our data protection officer, and — notably for a German company — our works council.
Design your own structure deliberately, rather than recreating your old system's shape. IPW is totally flexible, it doesn't request a certain structure. Take a white piece of paper instead. Other customers' setups, which the vendor can show you, are still worth using as a reference. Then limit the work with a project charter: what's included now, what's left for later, expected effort, timeline. The project charter is very important, so the project doesn't become like a sponge — taking in more and more water until it's not able to swim anymore.
When you think something isn't possible, ask the vendor before assuming it. Describe the result you want, not the steps you think it'll take. When we needed a signature field that wasn't a standard feature, IPW built it as a customization — and eventually enough other customers asked for the same thing that it's since become standard.
One more thing: don't stop just because you hit the target. Setting a three-month target and hitting it in six weeks felt like an obvious moment to stop and enjoy it, so we did — we told the whole company. Then, immediately, we moved on. So, celebrate it. Really celebrate it. But then — okay, new tasks. Don't wait.