Project Cocooning

The fact that a program has its own objective(s), budget, organization,resources, and management is not a reason it should exist as a island within the organization, having no contact with the rest of the organization. A remarkable phenomenon is that many teams isolate themselves in their own cocoons, having little contact as possible with what is—for them—outer space. This phenomenon is not surprising if you consider the following:

• The declaration and labeling of the program automatically creates the separate identity for the implementation team as opposed to the rest of the organization. Even though the organization needs to take ownership of the program and adopt its identity, this only happens long after go-live (assuming you are succesful).
• Competent implementation teams like being competent. They are not interested in moments of truth based on interactions because every sign of skepticism puts most of them at the edge of their comfort zones.
• Resistance is mostly countered with resistance. The implementation team will very soon state that it is not a charity initiative or a complaints desk.

Project cocooning is a natural reaction in an atmosphere where you ask for feedback and all you get is complaints that have nothing to do with the subject. Due to a lack of interaction creativity or qualitative meeting techniques, a lot of teams close out and start designing by gut feeling. It should be obvious that this behavior only pushes the problem on to a phase where it will be even more painful.
_______________
My thanks for this article go out to Siegfried Caems – my partner in crime – for coming up with this original terminology.