Каждый руководитель проекта иногда делает ошибки. Одни ошибки приводят к тяжелым последствиям для проекта или для одной из заинтересованных сторон, другие ошибки проходят незаметно или легко нивелируются. Проработав более десяти лет в роли руководителя проекта по обе стороны контракта, я в данной статье хочу поделиться личными наблюдениями о часто встречающихся ошибках руководителя проекта со стороны исполнителя в проектах автоматизации процессов и внедрения автоматизированных систем.
Это не наше
Зарисовка из жизни.
Начало проекта. Команды заказчика и исполнителя обсуждают взаимодействие, состав работ, примерный план работ, уточняют рамки проекта. Руководитель проекта заказчика просит исполнителя разработать календарный план-график работ с учетом тех работ, которые должен выполнить и сам заказчик. Заказчик готов активно помогать в составлении данного план-графика в части работ со своей стороны, но работы исполнителя он естественно спланировать не может. Руководитель проекта от исполнителя сообщает, что «проект – это только то, что мы должны сделать, а остальное мне не интересно»
В чем ошибка данной позиции и к каким последствиям это может привести? Большинство проектов внедрения автоматизированных систем требует не только разработки программного обеспечения, но и выполнения других задач:
- закупки оборудования для развертывания системы;
- возможных организационных изменений в подразделениях;
- проведения обучения пользователей;
- разработки внутренней нормативно-методической документации;
- и др.
Все эти задачи входят в рамки проекта. И без их выполнения проект не может считаться завершенным успешно. Даже если подрядчик разработал программное обеспечение, проект на этом не закончился. И, чаще всего, программное обеспечение не будет принято в эксплуатацию пока не будет развернуто оборудование и проведено обучение пользователей.
Поэтому руководителю проекта от исполнителя настоятельно рекомендуется принимать во внимание общий план-график проекта и обязательно привязывать свои работы к ключевым вехам общего плана. Это поможет правильно составить договор (план-график работ по договору) и избежать в дальнейшем проблем со сдачей-приемкой выполненных работ. Например, для начала работ по интеграционному тестированию необходимо, чтобы оборудование было уже развернуто и настроено, а системы, с которыми требуется интегрироваться, были доработаны в соответствии с планом.
Совет 1
«Проект – это не то, что делаете только вы. Проект – это все, что включено в содержание (scope) заказчиком. Принимайте во внимание те работы смежников и сроки их завершения, которые влияют на возможность выполнения ваших работ, особенно на их приемку»
В каждой избушке свои погремушки
Зарисовка из жизни.
Подходит время проведения приемки системы. Проводится встреча, для обсуждения подробностей проведения данного мероприятия. Исполнителю рассказывают о том, что собирается комиссия, проводится проверка всех функций системы в соответствии с методикой испытаний и тестовыми сценариями, а также проверяется всё, что касается информационной безопасности, восстановления системы после сбоя и другие нефункциональные требования, которые ранее выдвигались. Для исполнителя явилось сюрпризом то, что он участвует в испытаниях в активной роли – именно его задача последовательно демонстрировать все шаги, ронять систему и восстанавливать и т.д. А также сюрпризом явилось то, что данное мероприятие может занять 2-3 полных дня (они себе в план столько не закладывали).
В чем ошибка руководителя проекта исполнителя и что нужно сделать, чтобы ее избежать?
Думаю, всем известна поговорка «В каждой избушке свои погремушки». В каждой организации свои принятые правила и регламенты приемки систем в эксплуатацию. Мне встречались очень простые и формальные испытания, когда проходят по основному функционалу и подписывают Акт о вводе в опытную эксплуатацию, а затем получают большое количество ошибок и недовольных пользователей на опытной эксплуатации. Мне встречались испытания, которые проводились полностью в соответствии с ГОСТ34, Программа и методика испытаний содержали проверку абсолютно всех требований Технического задания, и эта проверка реально проводилась, включая даже проверку времени восстановления системы из резервных копий после «поломки» сервера.
Чтобы избежать сюрпризов на различных этапах проекта, а не только на этапе приемки, в случае, если для данного исполнителя это первый проект с данным заказчиком, настоятельно рекомендуется на старте проекта выяснять у заказчика все нормативные и регламентные документы, в соответствии с которыми проводится разработка и внедрение автоматизированных систем, а также договорная работа, согласование изменений, порядок оплаты и многое другое. Вы можете узнать для себя много нового и неожиданного, даже если вам кажется, что вы уже всё на свете видели.
Совет 2
«Помните о том, что в каждой избушке свои погремушки. Задайте заказчику вопрос «а как у вас происходит…?». Вы можете узнать что-то очень важное для планирования своих работ и оценки их трудоемкости».
За время пути собачка могла подрасти
Зарисовка из жизни
Проект находится на стадии завершения разработки Технического задания, проходит рабочее согласование. Исполнителю поступает замечание к разделу «Требования к документированию». В состав разрабатываемых документов требуют включить дополнительно еще пять различных документов, к тем «стандартным», которые исполнитель включил сам с учетом своего опыта. А в раздел «Требования по подготовке к вводу в эксплуатацию» вдруг просят включить подготовку обучающей презентации для пользователей.
Сколько копий сломано на теме «плывущего» объема работ. Исполнители обвиняют заказчиков в растущих аппетитах, заказчики обвиняют исполнителей в том, что они не уточнили требования… Можно ли найти тут правду, кто же виноват и что делать?
Причины роста объема требований, как показывает практика, действительно можно условно разделить на две группы:
- новые требования заказчика или существенные изменения ранее выставленных требований.
- упущенные исполнителем работы или неправильно понятые, а значит и неправильно оцененные, требования;
По субъективным ощущениям обе эти причины встречаются приблизительно с равной частотой.
Инструменты и методы работы с изменяющимися требованиями или появлением новых давно известны и описаны. Это запрос на изменение и при необходимости оценка трудоемкости/стоимости. В дальнейшем данные изменения, при наличии такой возможности, контрактуются, заключаются Дополнительные соглашения, либо, в случае невозможности увеличения стоимости проекта, ведутся переговоры с заказчиком об исключении других менее важных требований, для включения новых. Также для снижения рисков изменяющегося содержания (scope) проекта рекомендуется применять гибкие методологии, если это возможно с данным конкретным заказчиком на данном проекте.
Более тяжелым случаем для руководителя проекта исполнителя является ситуация неправильно понятых, недооцененных требований или выявление упущенных ранее работ. В такой ситуации доказать заказчику, что это новое требование, практически никогда не удается и даже попытка доказать это может привести к конфликту.
Как избежать данной ошибки или нивелировать ее последствия для исполнителя?
Один из самых очевидных методов – как можно раньше и как можно подробнее уточнять все требования заказчика. В первую очередь – это качество работы аналитика исполнителя. Это его основная задача.
Еще один способ раннего уточнения требований – прототипирование или макетирование. Простой «кликабельный» макет экранных форм зачастую творит чудеса и помогает выявить пропущенные нюансы требований и ожиданий пользователей.
Третий способ – это закладывание на стороне исполнителя временного резерва и управленческого резерва в бюджет проекта. Заложить резерв по времени на выполнение проекта – это то, что должен делать каждый руководитель проекта. При этом возможность сформировать резерв бюджета практикует не каждая компания и данный подход к управлению рисками проекта возможен далеко не всегда.
Еще один способ предотвращения возникновения проблем с упущенными работами – это ведение внутри компании исполнителя реестра таких работ.
Например, очень часто исполнители упускают следующие работы:
- подготовка и настройка среды тестирования на стороне заказчика, или подготовка инструкции для администраторов по настройке среды тестирования;
- настройка ролевого доступа до начала пользовательского тестирования у заказчика; многие недооценивают суровость служб информационной безопасности заказчика;
- проведение обучения пользователей или подготовка обучающих материалов (презентаций, видео-уроков, электронного курса и т.д.);
- проведение подготовительных работ перед переводом системы в промышленную эксплуатацию: настройка и тестирование интеграции с боевыми, а не тестовыми контурами других систем заказчика; снятие различных «заглушек», которые использовались при тестировании и другие работы.
Сбор такой информации и ведение базы знаний по ним в компании-исполнителе – существенно облегчает жизнь руководителей проектов и позволяет более качественно планировать состав работ на каждом проекте. Если в вашей компании такая база знаний не ведется, возьмите инициативу в свои руки – ведите свой реестр, поделитесь с коллегами, попросите поделиться их.
Совет 3
«Чтобы контролировать содержание проекта применяйте методы раннего прототипирования, уточнения требований, ведите реестр типовых работ на проектах внедрения для каждого конкретного заказчика».
Ожидания
Зарисовка из жизни
Очередная статус-встреча с исполнителем. Руководитель проекта исполнителя докладывает о результатах за истекший период и о планах на следующий период. Выясняется, что работа, срок завершения которой прошел 2 дня назад до сих пор не выполнена и будет закончена только через 2 дня. Заказчик возмущен. Возмущен не тем, что работа до сих пор не завершена, а тем, что он об этом узнает только спустя 2 дня от обещанного ранее срока.
Под управлением ожиданиями заказчика чаще всего понимают управление ожиданиями от результатов проекта, его продукта.
И крайне редко в понятие управления ожиданиями включают ожидания заказчика по процессам выполнения проекта.
Ситуация, описанная в зарисовке из жизни встречается настолько часто, что создается впечатление, что руководители проектов разучились управлять этим типом ожиданий или не считают это нужным.
К чему приводит такая ситуация? К возрастающему недоверию заказчика к команде исполнителя и непосредственно руководителю проекта исполнителя, к впечатлению, что руководитель проекта исполнителя не управляет проектом и командой, не знает, что у него происходит и в целом не профессионален. Мне известны случаи, когда в такой ситуации заказчик требовал сменить руководителя проекта исполнителя. Один случай привел к разрыву контракта и смене компании-исполнителя.
Как избежать подобных ситуаций? Рецепт максимально простой: держите слово. Если срок сорван по объективной причине, и вы выявляете этот факт до наступления этого срока – а чаще всего именно так и бывает – предупредите заказчика заранее. Сообщите причины сдвига сроков и новый срок. Но этот новый срок нужно выдержать всегда.
Ниже я перечислила ситуации, которые вызывают раздражение и последующее недоверие заказчика и которых следует избегать.
- Позднее сообщение об изменении срока выполнения задачи, особенно после наступления данного срока.
- Отсутствие отслеживания выполнения поручений, полученных во время различных рабочих встреч и статус-митингов.
- Неоднократный перенос сроков выполнения одной и той же задачи по причине недооценки трудоемкости. Неправильно оценили один раз – верим. Три раза – уже считаем некомпетентностью.
- «Скрылся в тумане». Исполнитель получил задачи и исчез на месяц их выполнять.
Совет 4
«Не скрывайтесь в тумане. Будьте максимально открытыми и держите постоянный контакт с заказчиком. Управляйте его ожиданиям от процессов управления, а не только от результатов».
И в заключение хочу пожелать всем учиться на ошибках других, делиться собственными выученными уроками с коллегами и не забывать, что главная наша задача — customer satisfaction.
Татьяна Белова