Project Management Institute

Not invented here

the challenge of multicultural project teams

Managing Director of

9:pm Projektmanagement GmbH, Karlsruhe, Germany

More and more projects are crossing country borders and continents, the world is moving closer together at breathtaking speed due to the progress in technology. At the same time, complexity is growing - new projects not only make use of new technologies but still have to be able to operate the former technology.

What makes project management a hot subject on the one hand is the gigantic challenge for all parties involved on the other: There are ever shorter product development cycles while cost pressure remains high. The following causes at least non-insiders (and the insiders as well) to rub their eyes in astonishment: Software development in India, a contractor in Germany, a customer in the US, and the production in China or Japan. Not an isolated case at all, and rather everyday business, than the famous exception.

How do the parties involved prepare themselves? Well, companies with this type of setup have had enough of catching black eyes and have provided appropriate education programs for their staff: Intercultural conscience, purposeful preparation for the project, investigation of differences to the own situation. There is the group decision in Japan, then the religious particularities in India, then the straightforwardness in Germany, and then again the pragmatism in the US. Being prepared this way is a great achievement, but it is still not very common that employees be prepared in exactly this way.

However, this is not actually the subject matter of our considerations. We shall investigate what causes a considerable share of enterprises and projects either to fail, to fall behind schedule, to become too expensive, or to encounter some sort of other problem, in spite of impeccable preparations - and all this beyond any of the hard influences such as occurred risks or subsequent changes to the project scope.

The following example of a real customer project shows that all the preconditions for a successful project were apparently met. The staff had been trained accordingly, and the team already had international experience. Still, it was not successful. Since the objectives of the project are of no importance in the end for us to analyze the facts (as is the name of the customer), I shall not go into any project details at this point. The key data are as follows:

  • Customer based in the US
  • Contractor based in Germany
  • Software design in India
  • Production in Japan
  • Industry: Automotive
  • Project scope: Software
  • Volume: 10 million USD approx.
  • Timeframe: 3 years
  • Problem 1: Standards from Germany must be rolled out globally (India and Japan)
  • Problem 2: Development deadline has been cut by 30% because the customer, due to market reasons, will not postpone the delivery date

It is hardly surprising that the project eventually faced problems. And this in spite of the experience and the good project approach. It was not a spontaneous project and they had a perfectly responsible project manager. The trouble was rather due to the fact that the standards from Germany had to be delivered concomitantly, as an additional deliverable, so to speak. This decision had been made to meet the customer's demand for a considerable reduction in time. So the answer was (typically German): Standard operating procedures and work instructions - process definitions and changes to them. As well as the belief that “going by the book” alone will guarantee the success and lead to the desired result (considerable cut in time).

Said project has been completed by now and, looking back, we find an interesting insight: A series of problems incurred could be attributed to the “Not Invented Here” (NIH) problem. NIH comes in different shapes and sizes and has various forms. Let's first look at the definition:

Not Invented Here refers to a problem when people in companies continue to ignore existing solutions to problems because it was not created in-house. It is endemic to the computer industry.

In many cases NIH occurs as a result of simple ignorance, as many companies simply never do the research to know if a solution already exists. But equally common are deliberate cases where the engineering staff rejects a solution, typically because they believe they can do better.

“Many millions of man-hours and billions of dollars have been wasted as a result of NIH.” (Wikipedia)

One can say that NIH is a first-rate productivity killer. It causes extra work, extra expenditure, and repeated work on the one hand, plus disharmony, conflicts, and the dreaded project politics on the other.

Let's take a closer look at this phenomenon and try to investigate the causes. Why does it happen? Is it really just ignorance? Why don't we simply and light-heartedly adopt existing work results and develop them further using them as a basis? What makes us refuse to accept other peoples' results and keeps us reinventing the wheel?

However, before dealing with the answers why NIH presents such a problem we shall have to introduce some definitions to facilitate comprehension of the following explanations:

  1. The NIH committer. This term describes the person or group or organization rejecting an existing solution (simply because it was not invented here).
  2. Third party products. This term describes the products that come towards an organization (or a person or a group) from outside and that are rejected by this group.
  3. Proprietary products. These are products preferably used by a person, group, or organization, simply because they were invented here.

Before we get to the various causes, it is necessary to examine the phenomenon again with a view to its effects:

NIH means rejection because some thing (an idea, procedure, tool, etc.) comes from outside. A third party product, period. “Outside” in this context means that there is something “foreign” to it (cf. definition above). The rejection of third party products, or their external influences, respectively, is linear to the amount of pressure by which these are introduced. Or the other way around: The more something is forced onto a person, group, or community, the greater the degree of rejection.

At this point, this is still a triviality. However, rejection does not necessarily imply overt revolution or plain-spoken rejection. Rejection comes in many political forms and sizes, and can influence the project course in a very subtle way. And it is these subtle manifestations of NIH that represent the actual problem. They are not adequately recognized, they are given other names, they are given excuses, and they are not verbalized in the majority of the cases.

However, if the disease is not detected, there is a possibility of curing the wrong symptoms. And everybody knows that there is a lot of treatment being done - but the disease won't go away. It is a “disease” of the people involved, a “disease” of the group, or of the group harmony. It is that home players' pride which alone entails, or should entail, a series of risks on the risk list. Insofar, NIH is a stakeholder problem and is also best addressed from the stakeholder side.

If NIH is such an evil trap, we have to pinpoint the motivations (or combinations of motivations) causing this behavior.

Principally, there are five different motivators:

  1. Ignorance
  2. Arrogance
  3. Fear of heteronomy
  4. Pursuit of autonomy
  5. Claim for power
Ignorance: Well, the easiest solution to this is quite simple: Lack of knowledge. If it is unknown that an engineered solution exists, the work will be done twice. As simple as that. It has nothing to do with being intentional or political. It is plain regrettable and may have to do with insufficient research at the beginning of an enterprise. Or a premature start.
Arrogance: Arrogance means that deep down in their hearts the NIH committers believe that anything coming from the outside (third party products) must be inferior to their proprietary products. The true artists are here, and it is practically a service to all mankind to reinvent the wheel. And invent it right!
Fear of Heteronomy: This means that the NIH committers have to prove they are able to survive on their own, and that reinventing the wheel is a virtual justification of their own existence. Without this trait they would indeed admit that others were better and that eventually the NIH committers were exchangeable and dispensable.
Pursuit of Autonomy: The pursuit of autonomy is very similar to the fear of heteronomy but it is rather stamped by a desire for personal responsibility than by fear. Acceptance of third party products undermines the strong desire for autonomy and results in an existence as a sheer puppet eventually. For this reason, third party products are to be rejected.
Claim for Power: A (possibly covert) claim for power prevails - a situation of competition is about to emerge, or seething already. Acceptance of a third party product would undermine one's own claim for power and eventually culminate in the loss of all authority. To prevent this from happening at all, rejection is the key. The claim for power is the strongest and most dangerous motivator in the NIH business.

It is obvious that NIH not only comes in different forms and sizes (overt disagreement, rejection, mockery, denial, reinvention of the wheel) but can also have different causes (ignorance, arrogance, fear of heteronomy, pursuit of autonomy, and claim for power).

Which doesn't make things easier altogether. Obviously, NIH has different effects and different causes. Can we then just speak of “one” NIH problem? I think, yes. For all these effects have one thing in common: Rejection in the broadest sense, and the resulting consequences.

Consequently, NIH is a collective term and each single case must be investigated separately. However, this is exactly why the risks liable to arise in projects must not be underestimated. In detail:

  1. There are frictions. Are the frictions based on factual issues or could they be caused by NIH?
  2. In case of NIH: Try to find out which motivations are causing it (cf. definition above).
  3. Solve the conflict! Never enforce a solution (and least of all enforce a solution if you were in a position to do so), and never play the problem down.
  4. If the conflict can not be solved (e.g. because fundamental decisions were made for all branches), any solution but sheer forcing is the more favorable alternative. Understanding for either side takes away the fear of those involved - and gives them a chance to campaign for their respective positions.

In summary, we can apply three golden rules to deal with this type of problem:

  1. First of all, be aware that NIH is a problem (for the others).
  2. Pinpoint the motivators (see above).
  3. Act accordingly and do not believe in the dust of time.

Should you be the victim, the NIH committer, the above applies vice versa:

  1. Be aware that the other side is not aware of the problem at all.
  2. Bring up the subject in a factual and disimpassioned way and explain your position.
  3. There ought to be understanding for your position. Determine concrete action and do not undermine the cooperation by subtle rejection.

Of course this is all a matter of culture, a matter of how we deal with each other. Not only nature shows that the model of cooperation alone is the successful one in the end. Corporate Darwinism is the beginning of competition struggles, of fights for existence. Wherever these prevail, NIH must flourish. They are the soil for ego trips and rivalry. And thus evidently cause rejections.

And so, the NIH solution starts on our doorstep - not with the others, not in Asia or South America, but with our own face in the mirror.


Wikipedia Accessed from:

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.



Related Content