В процессной деятельности, где все операции продуманы еще в прошлом веке и выполняются всеми одинаково, проблем с коммуникациями не возникает: сказано сделать по пункту 17 инструкции – так и сделают. В проекте, значительная часть содержания которого создается впервые, никакого 17-го пункта нет. Есть только знание одного разработчика, лишь частично воплощенное в созданном компоненте (коде, чертеже, макете, документации) и непонятное остальным без дополнительных пояснений. Любые проблемы в коммуникациях между аффилянтами проекта приведут к тому, что передаваемые знания будут восприняты в искаженном виде, а следовательно, повлекут за собой целую цепочку ошибок.

Как мы уже знаем из принципа «все люди разные», аффилянты проекта отличаются друг от друга сильнее, чем кажется. Любое из этих отличий может привести к коммуникационным проблемам. Человек с более высоким статусом вряд ли будет прислушиваться к тому, что говорит нижестоящий. «Технарь» выйдет из себя, пытаясь понять, чем, с точки зрения «гуманитария», отличаются две практически одинаковые картинки, а «гуманитарию» мгновенно станет скучно при виде простейшей для «технаря» блок-схемы процесса. Человек, привыкший обстоятельно формулировать свои мысли в письменном виде, вряд ли сможет сказать что-то вразумительное на совещании, и наоборот, прекрасный оратор потеряется, если заставить его вместо общения в чате писать докладные записки. В обычной жизни в этом нет ничего плохого, на то люди и разные; но в проекте любые проблемы в коммуникации – это сбой в передаче информации, создающий риск затягивания сроков.

Вот почему в DaShe включен набор методов управления коммуникациями, обеспечивающих доведение их до уровня, позволяющего успешно завершить проект.