prototype | Demand Clarity

Henry David Thoreau, in 1854, said something very prophetic.

“Every man looks at his woodpile with a kind of affection. I love to have mine before my window, and the more chips the better to remind me of my pleasing work. I had an old axe which nobody claimed, with which by spells in winter days, on the sunny side of the house, I played the stumps which I had got out of my bean field. As my driver prophesied when I was plowing, they warmed me twice – once while I was splitting them, and again when they were on the fire.”

The moral is that the process, or the journey, is as rewarding as the result.

It turns out, that chopping your own wood is important for helping to change your thinking and your work behaviors.

Implementing a concept and business process like Flowcasting, in retail, requires people to change their current work practices – both internal teams and external ones. Education, as we’ve often outlined, plays a crucial role. However, it’s not enough. People need to experience the new process and get comfortable with the new ways of working. How do we typically suggest people do that?

With what we call a process prototype.

A process prototype is a day-in-the-life execution of the new process, using real, company specific data to “experience” or simulate one or more key planning scenarios – for example, product introductions and discontinuations, promotions planning, and seasonal planning to name a few big ones in retail.

End users are guided through each of these scenarios by more knowledgeable and experienced project team members. Crucially, however, the end users are the ones who operate the keystrokes and execute the new process – effectively chopping their own wood.

This helps people turn the educational theory into practical applications as they get to see, develop, manage and revise real forecasts, replenishment plans and supplier schedules for various business scenarios. In some prototypes they can even experience new collaboration approaches – for example, how demand planners, merchants and suppliers will work together in the new process to produce promotional plans that are agreed upon and executable.

For the project team who’s leading the change, process prototypes are invaluable. You get the see how well the educational program instilled new thinking, as well as getting early feedback on the newly designed processes from the people who’ll be executing it. You also often get good ideas to improve the design. Incorporating these ideas helps the change effort, as people see that they are being listened to. Invariably you’ll also get ideas that aren’t so great, often rooted in maintaining the status quo. These are also valuable as they help uncover where additional education and coaching will likely be needed.

Personally, I’ve had good success using process prototypes (having people chop their own wood) but I’ve been thinking about taking the concept up a level, so to speak.

To date, we’ve only done process prototypes with the planners who’ll execute the new processes – sometimes, to be fair, also including key suppliers to get their feedback and suggestions. An improvement, I believe, would be to develop and execute process prototypes for the senior and executive leadership teams. I believe that would help leaders better understand the new day in the life for their teams. And a process prototype where executives could see, execute and collaborate on a process like retail sales & operations planning would be valuable, but also help to cement why the concept of a single set of numbers is important in retail planning.

Of course, this is not really a new idea, and the best retailers do something like this regularly. Retail leadership teams often work many days a year in their stores – helping customers and doing the work that’s needed to deliver a brand’s promise. A very valuable learning experience and my idea would be to take this thinking to the planning processes. It’s really part of what folks call experiential learning.

David Kolb introduced the idea of experiential learning in 1984. It’s a simple concept – you basically learn by doing and it comprises four elements: concrete experience (experiencing something firsthand); reflection on and observation of that experience (thinking about it); abstract conceptualization based on the reflection (learning from the experience); and active experimentation (putting the learning into action).

A process prototype is experiential learning and is like chopping your own wood. It will warm you twice – once when you do it in practice, and then again when you do it to deliver actual business results.

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.

Tag Archives: prototype

Prototyping the prototype