Ситуация:

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

Вывод:
Всегда проверяйте стоимость всех ли работ включена в договор. Работы должны быть не только включены в договор, но у них должна быть указана стоимость, либо должно быть указано, что они входят в стоимость договора и не оплачиваются отдельно.

Ситуация:
Вы - менеджер проекта по приведению процессов и документов компании в соответствие с вступившими в силу требованиями федерального закона. Закон касается такой специфической темы как персональные данные (ФЗ №152). Поскольку в компании нет достаточной экспертизы (знаний) для самостоятельного определения и реализации всех необходимых мер, был проведен тендер среди компаний, специализирующихся на информационной безопасности. При подписании договора с победителем тендера, понимая важность управления содержанием проекта, вы уделили особое внимание пунктам, касающимся результатов работ, и теперь у вас есть список результатов с их кратким описанием. Вы начинаете выполнять проектные работы и параллельно уточнять вопросы, касающиеся результатов работ, в том числе тех, которые еще только предстоит выполнить.

Вывод:

Факт занятости менеджера проекта со стороны подрядчика на других проектах нужно обязательно учитывать при планировании коммуникаций. Наиболее вероятно, что вы будете писать письма утром, по приходу на работу, как делают большинство людей, а ответ (если на проекте нет критических проблем) получать вечером, уже в нерабочее время, т.к. днем менеджер проекта будет занят у другого клиента. Таким образом, минимальное время ответа от менеджера проекта со стороны подрядчика будет составлять сутки. Обычно это не является критичной проблемой, но нужно быть готовым, что ответ на простейший вопрос может занять время.

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

Вывод:

При управлении коммуникациями в международном проекте нужно всегда учитывать особенности менталитета участников. В приведенном примере это бросается в глаза, однако, иногда это менее очевидно (например, когда общаетесь с незнакомым сотрудником) и тогда представление о темпераменте, присущем национальности может помочь вам выбрать правильный тон, слова, и более полно донести до собеседника свою мысль.

Ситуация:
Вы - менеджер проекта внедрения информационной системы в компании со стороны заказчика. Вы прошли стадию выбора системы и подрядчика и у вас уже есть победитель тендера, с которым заключен контракт. До момента подписания контракта вы общались с представителем подразделения продаж, однако после подписания договора вам назначен менеджер проекта. Вы начинаете работы по внедрению системы. В процессе внедрения возникает множество спорных моментов, требующих обсуждения и принятия решений. Решение одного из таких вопросов по проблеме внедрения затянулось на месяц. Когда же вы почти убедили менеджера проекта в рациональности предложенного вами решения проблемы, оказывается, что он не имеет полномочий принимать решения, ведущие к увеличению стоимости проекта и вам необходимо переговорить с другим сотрудником. Вы, разумеется, проводите эти переговоры и в течение недели решаете данный вопрос, но проект уже выбился из графика.

Вывод:

Всегда фиксируйте в контракте, в плане управления коммуникациями, в общем плане проекта или другом проектном документе организационную структуру проекта, а также ответственность и полномочия участников проекта. Вам, как менеджеру проекта, необходимо понимать с кем и какие вопросы можно решать. Если бы в данном примере вы заранее знали, что вопросы цены решает другой сотрудник, вы могли бы изначально пригласить его на совещание и потратить всего одну неделю вместо пяти для решения проблемы внедрения. Зачастую менеджер проекта с противоположной стороны эскалирует проблемы позднее, чем можно было бы, что приводит к задержкам проекта.

Ситуация:
Вы руководитель проекта внедрения ERP системы со стороны заказчика. Систему вам помогает внедрять компания - системный интегратор, выбранная по результатам проведенного конкурса. Проект подходит к успешному завершению. В связи с хорошим управлением стоимостью проекта, вам удалось, несмотря на реализацию многих рисков, уложится в бюджет, чем вы очень гордитесь. В настоящий момент, настраиваются различные справочники в системе, а также осуществляется миграция данных из старой системы в новую. Далее, запланирован этап тестовой эксплуатации, после чего система будет переведена в промышленную эксплуатацию. По завершении миграции данных из старой системы, скорость выполнения некоторых операций снизилась в десятки раз. Пользователи системы считают подобную производительность неприемлемой, а работу в системе невозможной. Вы начинаете спор с подрядчиком по поводу приемлемой производительности системы. Подрядчик признает низкую производительность системы, но считает, что оптимизация производительности вашей ERP системы не входит в контракт, соответственно, либо оптимизацию выполняет заказчик, либо подрядчик за дополнительный бюджет, причем не маленький. Когда закончится данный спор - не известно.

Вывод:

Прописывайте в контракте пункты об ожидаемой производительности системы в измеримых, проверяемых показателях. Система может перестать работать стабильно или начать работать медленно даже при относительно небольших объемах данных, поэтому даже если вы уверены, что на ваших объемах данных производительность ERP системы будет высокой, постарайтесь все-таки включить приемлемые для вас показатели производительности в контракт.

Ситуация:
Вы руководитель проекта внедрения ERP системы. Для помощи вам во внедрении вы наняли подрядчика, компанию системного интегратора. Ваш проект рассчитан на полтора года. Уже прошло девять месяцев. В самом начале проекта, для успешного управления коммуникациями и рисками, вы начали вести реестр вопросов и реестр рисков, которые спустя девять месяцев содержат в себе порядка двухсот вопросов и около ста рисков. Большинство вопросов из реестра вопросов было сформулировано пользователями, либо другими заинтересованными лицами. Часть из вопросов все еще открыты, как и некоторое количество идентифицированных рисков. Вы пытаетесь получить на ответы на все оставшиеся вопросы от нанятого подрядчика и внешних консультантов. Остается всего три незакрытых вопроса, которые зарегистрированы от пяти до семи месяцев назад. Вопросы касаются проблем реализации в системе положения по мотивации сотрудников продающего подразделения компании. На поиск ответов на эти вопросы, вы тратите много времени и сил, но ответы никак не удается найти. Еще через месяц, случайно встретившись с инициатором данных вопросов, вы выясняете, что для него они уже потеряли актуальность т.к. положение по мотивации кардинально изменилось и находится на утверждении у генерального директора. Вы могли бы не искать ответы на неактуальные вопросы.

Вывод:

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

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

Вывод:

Вы поступили правильно, что начали вести подробный реестр поставщиков. Причин для вопросов по участию/неучастию в тендере со стороны руководства может быть множество. Начиная от обеда с кем-либо из партнеров и заканчивая внутренним аудитом. Вы не сможете запомнить все причины участия/неучастия компаний, поэтому ведите список участников тендера с подробным указанием истории коммуникаций. В данном случае, вполне может оказаться, что вы приглашали данную компанию к участию в тендере, но по каким-то причинам получили отказ. Вы сможете оперативно найти нужную информацию в реестре поставщиков и ответить на все вопросы.