In early 2013, I was working as a technical writer and a facilitator for a startup company on the precipice of its commercial launch. The company had found a site for its factory and had begun to build it out, and the manufacturing team was gunning to spec, buy, and install equipment in time to hit the production launch date. Trouble was, the product was still very early in its development stage and thus not fully defined. This of course led to big frustrations between the teams:
“Can’t you just tell me what material you need this equipment to be able to make?”
“I cannot believe you’re considering buying that piece of equipment. It’s not what we need at all!”
I was in a really interesting position to tackle this communication gap, because I worked directly with almost every single person in the company at that time, and thus had a very high level of influence, even though I had no direct authority or power by title.
This case study steps through the scenario, my assessment of the problems, the planning work I did to bridge the gap, and how I evaluated the success of the project. It’s an interesting case, because there’s truly only one major deliverable: transferring enough knowledge to build out and standup a manufacturing plant (I’ll spoil it for you: the company did open a factory). But there were lots of interim projects, successes, and realignments, and I step through those as well.
One of the biggest realignments, which I reference in the case study, is that initially the two teams were operating in different working structures and methods. The development team had been using Scrum to great effect and was feeling really good about it (I was that team’s Scrum Master), and part-way through the knowledge transfer project, the manufacturing team switched to using Scrum as well. Here’s a short Scrum 101 post, which includes the presentation I made for the manufacturing team, to explain to them how the development team was using Scrum. It’s an interesting way to manage work in that context — it’s a framework designed for software development, which has no lead times, but product and equipment design can involve very long lead times — and requires a bit of adjustment.
This case study also looks a bit at why the approach was successful, which was matching the method to the situation. I talk a lot more about knowing which are tools and skills are necessary for which project, product, and company stage in this post about transitions.