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

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

 

Эпиграф

Умный учится на чужих ошибках, а дурак на своих…. (автор неизвестен)

 

  1. «Это не наше»

Зарисовка из жизни.

Начало проекта. Команды заказчика и исполнителя обсуждают взаимодействие, состав работ, примерный план работ, уточняют рамки проекта. Руководитель проекта заказчика просит исполнителя разработать календарный план-график работ с учетом тех работ, которые должен выполнить и сам заказчик. Заказчик готов активно помогать в составлении данного план-графика в части работ со своей стороны, но работы исполнителя он естественно спланировать не может. Руководитель проекта от исполнителя сообщает, что «проект – это только то, что мы должны сделать, а остальное мне не интересно».

В чем ошибка данной позиции и к каким последствиям это может привести? Большинство проектов внедрения автоматизированных систем требует не только разработки программного обеспечения, но и выполнения других задач:

  • закупки оборудования для развертывания системы;
  • возможных организационных изменений в подразделениях;
  • проведения обучения пользователей;
  • разработки внутренней нормативно-методической документации;
  • и др.

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

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

Итак, совет 1. «Проект – это не то, что делаете только вы. Проект – это все, что включено в содержание (scope) заказчиком. Принимайте во внимание те работы смежников и сроки их завершения, которые влияют на возможность выполнения ваших работ, особенно на их приемку»

  1. «В каждой избушке свои погремушки»

Зарисовка из жизни.

Подходит время проведения приемки системы. Проводится встреча, для обсуждения подробностей проведения данного мероприятия. Исполнителю рассказывают о том, что собирается комиссия, проводится проверка всех функций системы в соответствии с методикой испытаний и тестовыми сценариями, а также проверяется всё, что касается информационной безопасности, восстановления системы после сбоя и другие нефункциональные требования, которые ранее выдвигались. Для исполнителя явилось сюрпризом то, что он участвует в испытаниях в активной роли – именно его задача последовательно демонстрировать все шаги, ронять систему и восстанавливать и т.д. А также сюрпризом явилось то, что данное мероприятие может занять 2-3 полных дня (они себе в план столько не закладывали).

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

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

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

Итак, совет 2. «Помните о том, что в каждой избушке свои погремушки. Задайте заказчику вопрос «а как у вас происходит…?». Вы можете узнать что-то очень важное для планирования своих работ и оценки их трудоемкости».

  1. «За время пути собачка могла подрасти»

Зарисовка из жизни

Проект находится на стадии завершения разработки Технического задания, проходит рабочее согласование. Исполнителю поступает замечание к разделу «Требования к документированию». В состав разрабатываемых документов требуют включить дополнительно еще пять различных документов, к тем «стандартным», которые исполнитель включил сам с учетом своего опыта. А в раздел «Требования по подготовке к вводу в эксплуатацию» вдруг просят включить подготовку обучающей презентации для пользователей.

Сколько копий сломано на теме «плывущего» объема работ. Исполнители обвиняют заказчиков в растущих аппетитах, заказчики обвиняют исполнителей в том, что они не уточнили требования… Можно ли найти тут правду, кто же виноват и что делать?

Причины роста объема требований, как показывает практика, действительно можно условно разделить на две группы:

  • новые требования заказчика или существенные изменения ранее выставленных требований.
  • упущенные исполнителем работы или неправильно понятые, а значит и неправильно оцененные, требования;

По субъективным ощущениям обе эти причины встречаются приблизительно с равной частотой.

Инструменты и методы работы с изменяющимися требованиями или появлением новых давно известны и описаны. Это запрос на изменение и при необходимости оценка трудоемкости/стоимости. В дальнейшем данные изменения, при наличии такой возможности, контрактуются, заключаются Дополнительные соглашения, либо, в случае невозможности увеличения стоимости проекта, ведутся переговоры с заказчиком об исключении других менее важных требований, для включения новых. Также для снижения рисков изменяющегося содержания (scope) проекта рекомендуется применять гибкие методологии, если это возможно с данным конкретным заказчиком на данном проекте.

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

Как избежать данной ошибки или нивелировать ее последствия для исполнителя?

Один из самых очевидных методов – как можно раньше и как можно подробнее уточнять все требования заказчика. В первую очередь – это качество работы аналитика исполнителя. Это его основная задача.

Еще один способ раннего уточнения требований – прототипирование или макетирование. Простой «кликабельный» макет экранных форм зачастую творит чудеса и помогает выявить пропущенные нюансы требований и ожиданий пользователей.

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

Еще один способ предотвращения возникновения проблем с упущенными работами – это ведение внутри компании исполнителя реестра таких работ.

Например, очень часто исполнители упускают следующие работы:

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

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

Итак, совет 3. «Чтобы контролировать содержание проекта применяйте методы раннего прототипирования, уточнения требований, ведите реестр типовых работ на проектах внедрения для каждого конкретного заказчика».

  1. «Ожидания»

Зарисовка из жизни

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

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

И крайне редко в понятие управления ожиданиями включают ожидания заказчика по процессам выполнения проекта.

Ситуация, описанная в зарисовке из жизни встречается настолько часто, что создается впечатление, что руководители проектов разучились управлять этим типом ожиданий или не считают это нужным.

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

Как избежать подобных ситуаций? Рецепт максимально простой: держите слово. Если срок сорван по объективной причине, и вы выявляете этот факт до наступления этого срока – а чаще всего именно так и бывает – предупредите заказчика заранее. Сообщите причины сдвига сроков и новый срок. Но этот новый срок нужно выдержать всегда.

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

  • Позднее сообщение об изменении срока выполнения задачи, особенно после наступления данного срока.
  • Отсутствие отслеживания выполнения поручений, полученных во время различных рабочих встреч и статус-митингов.
  • Неоднократный перенос сроков выполнения одной и той же задачи по причине недооценки трудоемкости. Неправильно оценили один раз – верим. Три раза – уже считаем некомпетентностью.
  • «Скрылся в тумане». Исполнитель получил задачи и исчез на месяц их выполнять.

Итак, совет 4. «Не скрывайтесь в тумане. Будьте максимально открытыми и держите постоянный контакт с заказчиком. Управляйте его ожиданиям от процессов управления, а не только от результатов».

И в заключение хочу пожелать всем учиться на ошибках других, делиться собственными выученными уроками с коллегами и не забывать, что главная наша задача — customer satisfaction.