Here's an experience I had recently at a startup that taught me about process, when it can help, and when it can be sidestepped.
Sometimes You Have to Break the Rules
As we rolled toward 2009, two things were clear. First, our WiMax Forum-compliant product was going to take longer than planned to finish field testing and subsequent new product introduction milestones. Second, our contract for deploying a wireless broadband network using this new product had financial and other incentives that required us to get the network up and running as soon as possible.
We couldn't just try to accelerate the schedule to achieve our goals. Such a move hardly ever works, and everyone agreed that we needed a more creative solution.
Short of donning a Superman cape and flying around the Earth backwards to reverse time, we weren't goingto be able to proceed in the normal manner, of taking the product through its product introduction cycle before beginning the process of ordering and shipping systems. We were going to have to run the two projects in parallel, note the areas where "rework" might occur if the design changed after we had ordered components, and work hard to keep the system design in synch across the two efforts. Since I had ownership of both projects, it provided a natural point of synchronization (and also occasionally caused my head to nearly spin off my neck).
The first step, one I hadn't initially expected to have to take, was to figure out what it was that we were trying to ship. I had recently begun asking several people, "what's in the box"? I had started by asking, "what is the product?" but was getting different answers from different people. This was puzzling, since everyone talked about the "system" and yet they seemed to refer to different things.
Having worked at Nortel Networks for many years, I got used to hearing the word "system". It was a word that was applied at many levels (from the chip to the board to application servers to entire switching networks) but always encompassed the same thought: what do I have when I have the whole thing? It also happens that the first definition of "Product Management" I received (thank you, Bob Hoffman!) was, "when it falls out of the truck crossing over Highway 101, you're the one that drives out and picks up the box".
So why the confusion? Why did I get different answers from each engineering group?
Thinking about that brought me back to a tidbit I'd filed away years before.
Tracy Kidder Confirmed
Tracy Kidder, in his book The Soul of a New Machine, observed that the architecture of Digital Equipment Corporation's latest-and-greatest minicomputer (yes, it's an old book) seemed to closely mirror the company's organizational structure. It wasn't the main point of the story, but (perhaps because I was trained in Anthropology to look for structure) it was a point that stuck with me.
In our case, we had three distinct Engineering groups, in three geographic locations. One group built the WiMax base station, another the radio, and a third wrote the firmware that "glued" the radiohardware to the higher software layers. Ask each of these groups what "the system" included, and you were likely to get an answer that very specific for that group's piece of the system and very vague about the rest of the components. Three groups, three descriptions of a product architecture that sounded like "my stuff, and then everything else."
What's in the Box?
This approach apparently worked in the past, when the system installers went out and secured all the various cables, cabinets, lightning protection and so on that was needed to put a complete system togehter. But people (especially the Supply Chain folks) knew that this approach wouldn't scale. They were insisting that we follow a process that required any part to be ordered already be in an "approved" state. Supply Chain people weren't willing to "wing it", feeling that there was too much opportunity to mis-communicate requirements, resulting in costly delays and wasted parts.
So that led me to a new question: "what's in the box?". Since I couldn't get a decent answer to the "what is the product?" question, I developed a more specific one: "When we put everything needed for a WiMax base station in the shipping container and send it to India... what's in the box?". I asked so many people this question, so many different times, that "what's in the box?" became the catch-phrase for the whole exercise of defining and documenting what it was that we intended to ship, install, support, and operate.
My first step was to draw a picture--a "guzinna guzoutta" diagram I called it--that captured what components were needed, and how they connected together. There were a large number of configurations, having to do with number of sectors, location of the base station and so on, but I picked a "reference design" to get things going. I started with different system descriptions that had been developed over the course of the design project and used them to draft a picture. Then I met with everyone that had a hand in the project to verify the accuracy of my drawing. Of course, there were lots of errors, as a lot of the documentation had grown out of date as design changes were made over time. Meeting with each person one-on-one also helped flush out areas where interconnections weren't completely defined. Did we need lightning protection on the tower only? on the tower and at the rooftop? There were dozens of details to sort out, but I could tell we were iterating toward a common, correct view of what the product really was going to be. Once I had a drawing that wasn't getting changed with each new meeting, I created a PowerPoint slide deck to capture the details.
The next step was to make sure each component was sufficiently defined--description, engineering drawing, preferred vendor, and so on--so that we could assign it a part number and begin finding suppliers. It was important to (1) get the process working, so that "release to production" for a part meant that enough people had looked at it and confirmed that it would work in the system; and (2) get the parts under change control, so that if--when--we needed to modify a part of the system we would have an "audit trail" that captured how and why the design had changed.
While this definition was happening, I assembled the team--Engineering, Supply Chain, Design Services, Manufacturing, and Logistics--for daily meetings. The agenda was simple:
- what do we need to order first, given lead times?
- do you (Supply Chain) have what you need to begin placing orders?
The initial meetings were lengthy, as parties got their points of view on the table, raised other issues, and so on. But quickly people understood what I was trying to achieve, and we were able to move crisply through the issues and discussions in our allotted 30-minute time. (It's a pet peeve of mine to attend meetings longer than 30 minutes, as they seem to invite time-wasting.)
Soon we were all on the same page; OK, the same Excel worksheet. We had a list of component parts, each tagged with an anticipated lead time, cost, quantity and so on. Each day we ran through the list:
- was the design documentation completed?
- was the part number released to the Supply Chain group for ordering?
- had the part been ordered? if not, what was holding up the process?
- had the part been delivered? if not, when was the "promise date"?
- had the parts been kitted for shipment? when was that scheduled to happen?
- had the shipment taken place? what was the expected arrival date?
By breaking down the process into a discrete series of steps, were were able to focus on each step in turn, asking ourselves if the step was completed and, if not, what action had to be resolved to complete the step. By the end of the project, we were able to move through our agenda in less than half the time needed, and people contributed their inputs without prompting; everyone knew the drill.
Of necessity, we also solved one other problem. The original system concept had presumed that site surveys would be completed before any ordering took place. Variables like distance up the tower, distance to the base station, choice of antenna coverage arc and so on would be determined up front. This was a great idea from the standpoint of ordering only what was needed, but didn't reflect conditions "on the ground", where often times base station sites weren't identified until the last minute and parts lead times stretched to sixteen weeks. If we waited for site surveys to be done before ordering materials, we'd never achieve our project milestones.
After some weeks, we expanded our meeting participants to reflect our evolving problem set. We now had materials in transit and needed to know that our teams in-country were prepared to receive the materials, clear customs, and install the base stations. Since we were working in time zones offset by some twelve hours, I set up a separate meeting schedule with just the key players from the US side joining the in-country logistics and installation teams. I held these calls twice a week, the evening before our US meetings. That way, issues raised at night could be addressed the following day and closed a day later at the next evening call.
Success and Its Lessons
The result of all this activity was placement of over a dozen base stations in-country 90 days from the start of the project. We had systems up and running in parallel with the beginning--not the end--of field testing of the commercial product.
So what to draw from the experience? First, perhaps paradoxically, is the importance of a process. We started with an apparently insoluble dilemma: how do you build out a network now when the steps needed to do that haven't been finalized through the new product introduction process? The decision to run the NPI and network build-out projects in parallel was only possible because we knew what we were deviating from in order to get the job done. Of course it was more work; in some cases, we had to do things twice. But it allowed us to "overlay" the network build-out project on the NPI project without disrupting either effort.
Look for evidence that people understand your questions, and what you’re trying to achieve. Asking “what’s the product?” seemed like an obvious question to me… except that the answers I got showed me that people didn’t really understand what I was asking. Being more clear—“when we have all parts of the product in the shipping box… what’s in the box?” got the question to a level where the answers I got in return helped me move the product concept forward. As another example, asking if we had all the logistics and supply chain issues resolved was too vague a question; decomposing the question into a series of process stages helped everyone understand where we were for each component, where we were stuck, and what would be needed to remove the roadblock.
Be prepared to take some time for the team to gel. It was completely clear to me what we needed to do from the first minute of the first team meeting I held. So it would have been easy to get frustrated at the seeming lack of progress: “just do what I say” ran through my head more than once. What I had to remind myself was that I was enacting the “zero step” in the process—getting the team to come together as a team, understand the goal, and understand how we would work individually and collectively to get the job done. Once I had the US team going, I had to repeat the process with the in-country team.
Use your actions to enlist functional leaders to your goals. The Engineering Manager came to me after a few meetings and told me he now understood the approach and what I was trying to accomplish. I was able to enlist his support on a personal as well as task level, which meant that I could count on him to act in my best interests when meeting with his team. The more support you can engender, the more you can make your goals everyone’s goals, and get the benefit of everyone’s effort.
Hopefully you've found something of use here. The next time someone exhorts you to "think outside the box" do it. But first make sure you understand what's in the box.