Рабочая сессия командообразования

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

- обсудить все текущие проблемы, связанные с проектом обновления,

- назначить лиц, ответственных за разрешение возникших проблем,

- согласовать сроки разрешения проблем.

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

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

Результаты рабочей сессии

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

1. Привести в соответствие ожидания Заказчика и предложение Поставщика.

2. Согласовать общее направление дальнейшего движения.

3. Определить, способна ли система удовлетворить нужды Заказчика.

4. Устранить барьеры и обеспечить открытую коммуникацию и взаимную поддержку дальнейших действий.

5. Прояснить вопросы, возникшие у всех сторон, и согласовать способы их урегулирования.

Никакие электронные сообщения, совещания, рабочие сессии, демонстрации и обзор проекта не смогли выявить то, о чем Заказчик думал, но таки ни разу и не сформулировал. «Скрытая повестка» состояла в том, что Заказчик чувствовал, что его ожидания не оправдываются (пункт 1). Было выражено сомнение в том, что система вообще способна удовлетворить нужды Заказчика (пункт 3). И еще Заказчик чувствовал, что имеются барьеры, препятствующие открытой коммуникации (пункт 4). Ни один из этих пунктов до сего момента не проявлялся.

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

1. Поставщику необходимо выполнить анализ состояния дел в отрасли и определить, соответствует ли его система отраслевым стандартам в части общей функциональности и экономической эффективности.

2. Необходимо оценить соответствие базовой функциональности системы отраслевым стандартам. Далее следует выполнить анализ разрывов и представить его результаты Управляющему комитету проекта для принятия решения.

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

4. Дальнейшие шаги будут определены, исходя из результатов анализа.