If someone asked me to summarize myself, I’d probably say that I’m a life-long student – an avid reader and someone who knows that things can always be made better – a lot better.
Some recent experiences have got me thinking about our approach to designing and implementing Flowcasting-like solutions for our clients.
First, what has made our approach so successful? It’s really an obsession with simplicity and a deep understanding that instilling new behaviors is about people and process.
At the heart of the approach is what we call a process lab, or process prototype.
Think about how successful products are created. They are designed. Then a prototype is created. Then it’s tested. Then it’s revised. Prototyped again. Tested again, and the process continues until the product sees the light of day.
Why can’t a process change also be prototyped?
It can and we do.
We work with teams to design new processes and workflows on paper then build a lab-like environment and prototype the process with real end-users. It helps people see and feel the process first-hand, and also provides us critical early feedback on the process – how it works, what people like, what they struggle with, where it can be improved, etc.
It’s all consistent with our belief about change – that people rarely believe what you tell them, but they always believe what they tell themselves.
On our recent implementation of Flowcasting for a hard goods retailer in Western Canada, I was fortunate to experience what could be described as rapid prototyping, with respect to the technology solution.
To set the stage, the Flowcasting solution we used was an early and immature solution. However, the fundamental foundation and architecture, along with the retail focused functionality was second to none.
Of course, even though we designed and did our prototype lab work with the team and users, a number of things emerged that we needed to revisit as we made the journey. As luck would have it, we were working with the actual architect of the solution and, over a couple of months, we made some important and elegant revisions to the solution that improved it considerably.
Essentially we did a series of small, software-focused prototypes (to support our process thinking, of course) that were quickly designed, tested then deployed. It was one of the most exhilarating experiences I’ve been involved in and I’ve been doing project work since the dawn of civilization (at least it feels like that!).
The result was equally impressive. Even though the RedPrairie Collaborative Flowcasting solution was already an excellent one, the changes that were prototyped and implemented transformed the solution into something special and unique.
In my professional and expert opinion the solution solves all the major retail planning challenges, is intuitive, scales like stink on a monkey and is so simple that even an adult can learn and use it. Even. An. Adult.
Not long after this experience I read an interesting book called Scrum – about an approach for designing and implementing new technologies that relied on rapid prototyping. The basic idea was to design things quickly, make the changes, test it and demonstrate it to people and adjust accordingly. Then rinse and repeat.
Boom! It was essentially the approach that we’d used so successfully to transform the Flowcasting solution. And, it got me pondering.
Why wouldn’t we apply the same thinking to our implementation framework? After all, the idea of a process prototype was not foreign to us – in fact, it’s a cornerstone of our approach.
Perhaps we should do more than one…just like this:
The idea would be to do shorter bursts of design and lab work, then engage the users, get them to work with the process, and provide feedback and adjust. I have no idea how many of these micro-prototypes we might need but the approach could be flexible to have as many as required – depending on the magnitude and scope of the change.
I really like the idea and hopefully will test it soon. We’re working with a great bunch of folks at a Canadian retailer and hopefully we’ll get the opportunity to help them with the implementation. If that happens, I’m sure we can leverage this thinking and incorporate it into our approach.
It will be like prototyping the prototype.