The Norm
/
Simultaneous technology innovation and product development
Most advanced technology today requires innovation. Things need to be invented in order to stay at the cutting edge. Things need to be invented on a schedule, which means that teams are forced to predict when they will solve a problem that they may not even know the cause. Sometimes they don’t know what they don’t know, yet are forced to predict when they will have the answer.
At the same time they are “inventing” they have to develop a product. This means taking various technology components and making the all work together to meet the product requirements. In the past, the basic research part was done by another team that didn’t have fixed timelines and could dedicate their time to experimentation; the trial and error process of invention. Their invention timelines where not tied to a go-to-market product project. The product development was done by another more focused team that took the available pieces (available at that time) and commercialized it into a product, with tight time targets to meet.
Now it all happens at the same time. This causes many problems that result in major schedule slips and products that miss the market requirements to be competitive (right time, wrong product). Below is a table of the typical characteristics we have observed, and some of the ways we have solved them. This is a partial list. Each situation is different and the solutions are not plug and play and are complex.
Multiple Sites
So combine the simultaneous invention and development with it being done at multiple locations around the world, in many different time zones. Most projects we work on have sites in Asia, Europe, and North America. Each site has a team managed by the local management hierarchy with their own priorities. “Out of sight and out of mind” is how most of these remote teams operate, disconnected from the main effort and difficult to manage from afar.
Added to the geographical and time zone problems are cultural differences that means that some places are less likely to be open and honest with what is happening. Add in a local hierarchy that you have to work though, and you have a recipe for virtually no communication.
Often teams resort to electronic communication tools that promise to improve communication. They don’t. It is actually much worse today, compared to the days when people faxed memos to each other, wrote paper documents that others actually read, and paged each other on beepers, then actually spoke on the phone to one another. Over-reliance on our modern communication technology is one if the biggest problems we see with remote asynchronous team communication.
The solutions we outline below is another partial list. These are some of the things we do to fix the communication problems.
Multiple Companies
Invention + Development + Multiple Sites + Multiple Companies; what could possibly go wrong? Add in that no one is in charge, but rather the “team” is managing it, which means no one is in charge. Most of these projects are a mess from the start. Lots of meetings and executive pronouncements to kick them off, but very poorly organized when the projects are running. They lack focus and all of the parties have different and sometimes competing objectives.
But this is how most big programs are done today, since no single company has the vertical integration like the multinationals did in the past to be able to do it on their own. Companies need to team up, share IP, share people, outsource, and share capital.
Many times it involves a foreign government entity. The most complex are Chinese joint ventures, in which the partner is actually a Communist government agency (or many agencies). This gets very complicated in terms of IP protection; how it is shared and how it is protected, making open collaboration a problem. We have developed techniques for these programs, as we have worked on a number of mega projects ($10B and above) where the partner of our international client was the government. The chart below does not cover this scenario, maybe this is a subject for another post. These are really hard to fix, but we have solutions that work in this cultural environment.
Some of the multi-site problems and solutions are listed below. It comes back each time to the Core Team; how it is set up and how it is managed, which determines the success of these programs. It is actually the hardest thing to get fixed, because stakeholders are reluctant to make their key people available for enough time to make the project successful. The people that are full time are the people none of the stakeholders want on their own internal projects. Fully dedicated and colocated core teams (with empowered people) are the key to success, but very hard to implement. It really depends on what is at stake for each stakeholder in terms of how much they contribute the the team effort.
Multiple Corporate Stakeholders
Add to all the multi-things above the complexity of many internal corporate stakeholders. This means that there could be multiple product groups, market segment owners, product lines, and so on that all have a stake in what the product a team is developing. They each have their own priorities and requirements, which force the team to be everything to everyone. This is perhaps the greatest cause of schedule delay, as the team attempts to deliver on the impossible, and on time.
Below is a partial list of what these look like and how we have solved them.