On Monday, a new piece of technology will launch at work. It’s a tool I both designed and built, and I’m extremely proud of my work.

The tool itself is web-based. It lives on a SharePoint server, is written in HTML with a healthy dollop of jQuery and the SPServices library thrown in for good measure.

It took some effort to build it, and I think the approach is a good one because on the back-end it makes good use of SharePoint’s functionality, but the front-end is completely custom with in-line error checking and user interface customizations that go far beyond what could be accomplished with SharePoint alone.

But that has nothing to do with why I’m proud of my work.

I’m also not especially proud of the project management stuff I did to bring this all together. It’s not that it was bad work, but my tool ran the risk of butting heads with a six sigma project that somebody else was running. They were basing a certification on their work, so I agreed not to implement anything until they were done. I thought I’d sequenced my work correctly, but when their three week pilot turned into a seven month pilot, I had nothing to do but wait.

To understand why I’m proud, we need to step back a bit.

The tool I’ve developed replaces another tool that was previously in use. It was also web-based, and it was owned by our organization’s IT team. As best as I can tell it was introduced in 2002, and in the eleven years since it launched we’d noticed a few niggly errors. We had a list of changes we wanted but this was minor stuff, the tool was used only by a select group of staff, IT resources are a hot commodity, and this was basically a priority for nobody except me. It’s at that point I decided my approach would be to build a new tool myself, from scratch. By going to all that trouble though I was opening up a whole new world of opportunity, and why waste it by reinventing the wheel? I wanted a smarter approach. And I had one.

I gathered together a group of SMEs from the handful of teams that used the tool day in day out – the people that had their hands on it every day – and booked a full day in their calendars to go through a kaizen event. We spent the morning mapping current state processes on the wall, writing out steps on post-it notes as we went and sticking them up in the relevant places.

By the time our lunch arrived this was done, and what I already knew was now abundantly clear to everyone else in the room. Our process was built around the tool that IT had delivered to us, eleven years prior.

After lunch I ran through a five minute PowerPoint I’d put together about muda, and we began unceremoniously ripping post-its off the wall, eliminating wasteful steps from the process. By the time we were done we had a vastly simplified, lean process mapped out. The kaizen participants surprised me more than once, coming up with things I would never have thought of on my own, changing the order of steps to support their ideal workflow, and eliminating hand-offs that I had thought might be sacred cows.

The tool I’ve built is only subtly different from what I was envisioning before the kaizen, but those subtle differences add up to a huge impact, and that’s why I’m so proud of my work.

It would have been all too easy to skip the kaizen and work from the already documented, well established business processes we had in place. What we’d have ended up with is a tool that looked prettier than the one that came before it, functioned better, and supported our processes beautifully. I’m fairly sure everybody would have been pleased with the outcome, and nobody would have stopped to think about whether or not the business processes were right to begin with.

What we have instead is, I think, a game changer – at least within the scope in which the tool and processes operate. We have re-engineered, optimized, lean processes along with technology that supports them but doesn’t define them. Management are happy because we’ve eliminated waste they hadn’t realised was there, on a scale they hadn’t imagined. The staff are happy because they’re empowered. Not only do our new processes support that, eliminating hand-offs and re-work that were only included to begin with in order to check the output of a group of people who were already perfectly competent, but also because they now have processes and a piece of technology that were designed and defined for them, by them.

That’s why I do what I do, and that’s why I’m proud of my work.