A few years ago, I was working with the product development group of a technology company. I asked one of the managers how information flowed between the various groups involved in bringing a new product to market.
“It’s simple”, he said. “The main groups involved are marketing, R&D and manufacturing. Each group has their own workspace that is surrounded by a 5m high brick wall. Marketing write down what they think the customer wants on a small piece of paper, tie it to a spare brick, and throw it over the wall into the R&D area. If they are lucky, it hits someone on the head and attracts their attention.
R&D then develop something that they think will be useful, write the design details on another small piece of paper, attach it to a brick and thrown over the wall into manufacturing. Manufacturing try and work out from the limited information that R&D has given them what the product is supposed to be, conclude it can’t be made, write abusive comments on the back of the piece of paper and throw back into R&D. R&D reply.
Whilst this debate is going on, marketing are writing a series of increasingly desperate notes which they tie to ever larger rocks and throw into both the R&D and manufacturing areas in a desperate attempt to find out what is going on. And so it continues!”
A cynical view perhaps, but one forged in the heat of real-world experience. I have spent a lot of my career in product development teams, or managing product development project portfolios, and that is exactly what it can feel like from the inside.
It seems that wherever different groups of people need to work together to deliver some specific outcome, there will be problems of understanding and cooperation. The problem of sharing across organisational boundaries seems to occur in every size of business, in every industry sector, and with every organisational culture. Sometimes it’s easier, sometimes it’s harder, but the problem is always there.
So where does the problem come from, and what can we do about it? The origin lies in the shared skills and experience of the different groups. Any group of people who work together regularly will share a set of beliefs, a set of assumptions and a language. The subtleties and nuances of these are unique to each group.
Each group has different accountabilities, and measures success in a different way. When discussing the project they use words and concepts that may be private to that particular group, or might have unique meanings. So when R&D produces a design and passes it over to manufacturing, the two groups are actually seeing something very different. No matter how precisely defined and well written the product specification and design are, there is no guarantee it will be understood by the receiving group.
At about the same time I was being told the story by a frustrated manager, Prof Paul Carlile introduced me to a very powerful concept that helps you understand the problem and take action to overcome it; the boundary object.
A boundary object is an artefact that sits in the interface between two or more groups, and is a piece of shared knowledge and understanding.
A boundary object can be almost anything. It can be a report, a physical prototype, a design or a business process. Whatever it is, it must have some specific properties.
Rules for boundary objects
- It must be co-invented and collectively owned. All the relevant groups must be involved. A boundary object cannot be created by one team and passed to another. That triggers misunderstanding and ‘not invented here’ thinking.
- If it is going to be collectively owned it should be created in ‘neutral’ territory. If one group hosts the work, it subtly and progressively becomes theirs. Find a workspace outside the participants.
- Choose objects that are persistent. Boundary objects need regular use. They should be poked and prodded, revised and appealed to.
- Make sure they have real meaning to all the participating groups. Something only important to one team is still important, but it is not a boundary object.
Types of boundary objects
Boundary objects can be many different things. Anything that can aid understanding and can be jointly developed. Examples include:
- Physical prototypes
- Mathematical models
- Technology roadmaps
- Co-developed mindmaps
- Reports on opportunities or challenges
- Process maps
- Value chains
- ….
A real-world example
A chemical company manufactured a standard commodity product sold at a high purity and against a very tight specification. The product was made at several sites, and as the business grew they needed to supply customers from multiple sites. Unfortunately, they discovered that the product from different sites did not behave the same in the hands of the customer, even though all products met the same specification.
This was a problem, so we brought to the manufacturing managers all the sites together to try and understand what was happening.
The discussions became very heated very quickly. Everyone knew exactly how to make the best quality product. They had been doing it for years. Everyone knew all the answers; unfortunately, the answers varied wildly.
We calmed them down and got them to stop thinking about winning the argument, and instead to assume that everyone was right Perhaps the fact that they all gave different answers would be a clue to the problem.
We got them to interview each other about how they made the product. We covered one wall of the meeting room with paper, and gradually mapped out all the factors, influences and relationships that people were identifying.
It quickly became clear that although they all thought they were making the same product, each site was using slightly different raw materials, processed in slightly different equipment, using slightly different methods, and sold to different customers who were using it for different purposes. The products really were different!
Once everybody understood this, we began to build a very different map of how the decisions taken during manufacturing affected the ultimate product performance and quality. Several process development projects were set up to exploit this new understanding, and the company gained considerable flexibility in its manufacturing operations.
Even though all these people came from the same functional background, and spoke the same technical language, the history and experience of the different manufacturing sites had created a different set of assumptions and understandings about this relatively straightforward manufacturing process.
So the next time you have a problem that looks like groups of people, who should be working together, throwing messages tied to rocks over high walls ask a simple question. Are there good boundary objects mediating knowledge and information transfer between these people? If not, create some!
This post is based on a longer article originally published in Knowledge Management Review, 2005, 8, 12-15