Execution is hard.
There are two sources of this hardness. One is the inherent difficulty of doing something (like climbing a mountain), and the other is the difficulty in organizing a large set of people in a way that things get done.
This second problem, in my experience, is the harder of the two. Getting a large group of people or multiple groups of people to row in the same direction and get something done is prone to all kinds of problems. There is the difficulty of information exchange and understanding – no two people perceive the same bit of information in the same way. There is the difficulty of hierarchy – many people want to be in control at the same time – or no one does; and often there is confusion about who really is in charge. There is the difficulty of shared accountability – people don’t want to be held responsible for errors by others in the group and so they become defensive and competitive when it is more efficient to cooperate.
A lot of these difficulties result from human contact – the boundary problem. Where ever information, responsibility, or accountability crosses team boundaries problems arise.
There are two fundamental approaches to solving the boundary problem.
The first is to make the boundary conditions as explicit as possible. This is a process driven approach in which detailed rules are laid down for each boundary exchange. Process manuals are created, exchanges are documented for future reference, extensive lists are created and followed, long review sessions are held to make sure the processes are being followed. Typically, this approach also requires setting up of special inspection teams whose sole purpose is to make sure rules are followed on all boundaries. Paradoxically then, in this approach one needs to create a few additional boundaries to try and solve the boundary problem.
This has its benefits. Everything is clear and traceable, everyone knows what they are supposed to do. But by its very nature, it does not work in every situation. Since everything has to be written down before the fact, this method is more useful in repeatable projects where you can predict with some certainty how things are going to evolve. For example the steps for constructing a standard bridge are pretty well known and have been evolved over centuries, so a detailed process manual with clear instructions and division of responsibility and accountability will probably work
The method fails, however in projects with a lot of uncertain areas. In innovative or ground breaking work, or even in less innovative work being undertaken by teams unfamiliar with it, this approach has issues. In such cases it is not possible to specify everything in advance and it is precisely these unknowns that are the biggest risk to such projects. Because everything is supposed to be written down in process manuals – if something is missed no one is likely to flag it. Every person will follow his written part of the job and assume that the gaps in his understanding are actually part of someone else’s scope. This is the classic case of “everyone thought someone will do it, and in the end no one did it”.
The second basic approach is to reduce the boundaries. Instead of having a large number of teams and separating them out with clear written instructions on who is supposed to do what, this approach actually lumps people together into a single – or fewer – groups. This has the advantage of getting everyone on the same side and reducing communication complexity. Since there are fewer boundaries, less leakage of information, responsibility or accountability are likely.
The down side of this method is that it is not scalable beyond a certain point. As you lump more and more teams together, the resulting unit becomes so big that it becomes unwieldy and starts having boundary problems of its own within the group.
But this method does have the advantage of being better equipped to deal with large uncertainty. Since everyone is on the same team and the team has one stated goal, everyone is on the lookout for blind spots and unforeseen areas. However this structure can only work when the people put into the same team have a good level of trust with each other; because it counts of people being open with each other and communicating quickly and without fear.
Both methods have their uses, each is equipped to deal with certain types of problems. Each has its place – the trick is knowing when to use what. At the risk of oversimplification the following graphic tries to capture when each approach would be more useful.