Управление ИТ-проектом. Эффективная система «с нуля» в любой организации

2010 г.

Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации

Селиховкин Иван
Санкт-Петербург – 2010

Глава XII. Выполнение и контроль работ по проекту

Входы:

Окончательный «план управления проектом»

Запускаем работы

Запуск работ – не более чем наша «отмашка» команде проекта: «начинаем». С точки зрения заказчика – проект давно уже идет. Да и мы с командой успели немало поработать (в рамках планирования).

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

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

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

Далее мы разберем, чем занят менеджер проекта на данной стадии.

Дело 1. Отслеживать выполнение работ

Главная задача ПМ – удержать проект в треугольнике. В фазе начального планирования мы приложили немало усилий, чтобы уточнить его границы (сформировали ИСР, расписание и бюджет).

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

Сбор показателей прогресса

Специализированное ПО, которое мы используем для ведения ИСР, расписания и бюджета – обычно удобно использовать для «отметок о прогрессе». Однако не заставляйте команду использовать его, если не уверены, что так будет удобнее ВСЕМ! Всегда можете запросить отчет по электронной почте, а результат самостоятельно ввести в программу (или поручить это помощнику).

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

Порой, члены команды сопротивляются любым отчетам (что предсказуемо, ведь они прекрасно понимают – за свои оценки потом придется отвечать перед ПМ). Кроме того, достоверность оценок на ИТ-проектах всегда является предметом споров (как можно измерить умственную, творческую работу? как, занимаясь написанием или отладкой программного обеспечения с уверенностью утверждать, что проделано, скажем, 30% или 80% от общего объема?).

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

Проектные практики предполагают несколько вариантов «измерения прогресса»:

Вариант 1. – «спросить в лоб». Это наилучший способ. Он предполагает, что член команды сам сообщает вам, какой объем работ он выполнил к настоящему моменту (будь то оценка в % или в иных, удобных ему показателях).

Вариант 2. – «правила». Данный подход предполагает использование определенного правила для измерения всех незавершенных работ (например, « 20/80» или «0/100»), чтобы «хоть как-то измерять неизмеримое». Это худший способ – избегайте его, по возможности, и используйте лишь как последний способ «что-то измерять».

Так, при использовании правила «20/80», – как только работа начата, мы сразу считаем ее выполненной на 20% (и можем внести соответствующие пометки в свое расписание). Мы не отслеживаем реальный прогресс и ни о чем не спрашиваем исполнителя. Лишь, получив от него уведомление, что работа завершена – добавляем 80% в свой график и считаем работу оконченной.

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

Пример – метод «ожидаемой стоимости задач» (estimated activity value), который, на основании ряда индексов и диапазонов, позволяет определить – насколько эффективно проект соблюдает расписание и бюджет.

Анализ показателей и внесение корректив в расписание

После сбора показателей мы определяем, будет ли проект успешен, если ситуация не изменится. Если по нашим данным проект перестает укладываться в треугольник – корректируем планы.

Методы сетевого анализа расписания, описанные нами в главе X чрезвычайно эффективны для того, чтобы наверстать время (помните, некоторые из них раздувают риски и стоимость проекта).

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

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

Анализ показателей и внесение корректив в предельную стоимость проекта

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

Переоценка рисков – метод, позволяющий высвободить неиспользованные ресурсы проекта, тем самым сократив его предельную стоимость. Резервы, заложенные в рамках Плана А и Плана Б (см. главу X) можно высвобождать и использовать, если рисковое событие так и не реализовалось (скажем, прошла дата, после которой наступление риска уже невозможно). Тем самым нередко удается «вернуть» в проект необходимое количество финансовых ресурсов.

Дело 2. Управлять рисками

Управление рисками осуществляется в течение всего проекта, до его закрытия.

Работа ведется на основании реестра рисков, который мы сформировали в главе X. С его помощью:

отслеживаются триггеры риска и приводится в действие План Б (силами «хозяев рисков»)
выявляются новые риски (силами команды и прочих заинтересованных лиц)
переоцениваются старые рисков (силами команды)

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

Дело 3. Управлять изменениями

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

Изменения призваны обеспечить проекту «самонаведение» на цель (внося корректировки в «траекторию» – в состав работ). Но в чрезмерном количестве они приводят к обратному эффекту – исчерпав ресурсы проект вовсе «не долетает» до цели.

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

оценить соответствует ли требование целям проекта (базовым положениям устава и/или концепции проекта). Если выявлено несоответствие – требование отклоняется.
оценить предполагаемое влияние работ по реализации требования на проект (если проект останется в треугольнике – то следующий шаг 4, если нет – то 3).
определить, возможно ли «уложить» реализацию требования в треугольник, и что для этого потребуется (нужно ли сжатие расписания или быстрый проход, сильно ли возрастут риски и т.п.).
обсудить результаты с командой, при необходимости – со спонсором и принять совместное решение о включении / отклонении требования
оповестить заказчика, пользователей и прочих заинтересованных лиц о принятом решении (положительном или отрицательном).

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

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

Дело 4. Управлять ожиданиями заказчика

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

Конечным результатом деятельности команды проекта (под вашим руководством) должна быть успешная сдача продукта.

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

Реальность, обычно, оказывается принципиально иной. Во время «приемки работ» к продукту предъявляется внушительный список претензий (устранение которых требует много времени и ресурсов), сама сдача растягивается на месяцы или годы. Некоторые пользователи настроены враждебно, они официально или скрыто саботируют внедрение продукта. Доработанный совместными усилиями продукт остается невнедренным, в организации о нем со временем забывают, а ваша компания, с трудом закрыв проект, окончательно теряет в лице заказчика будущего клиента.

Причин, почему реальная картина, как правило, так редко похожа на «идеальную» – множество. Но одна из наиболее вероятных – неправильная работа с требованиями.

Представляйте процесс «сдачи продукта» с самого первого дня. Используйте тот же прием, что и в управлении рисками – спрашивайте себя «что будет, КОГДА придется сдавать проект».

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

Однако ожидания клиента имеют склонность меняться в ходе проекта. Люди забывают, о чем вы с ними договорились. Они продолжают размышлять на тему проекта – и у них рождаются новые идеи. Пользователи продукта – вообще отдельная категория. Вы работаете ради них, без их поддержки продукт не станет полезным (а проект – успешным).

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

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

Дело 5. Мотивировать и развивать проектную команду

Мотивируем сотрудников

Мотивация – серьезный аспект управления проектами. ПМ должен иметь возможность влиять на членов команды. Для этого нужно понимать, «что держит каждого из членов команды на проекте» и правильным образом использовать эти знания.

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

Не забывайте и о «нематериальных» методах стимулирования. Никто не отнимет у вас возможности объявить благодарность (стоит держаться общего правила: «ругать лично, хвалить публично»).

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

Развиваем команду

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

Однако и руководитель проекта вносит свой вклад в развитие коллектива. Его задача – тим-билдинг.

Тим-билдинг – организация эффективной командной работы.

Во-многих организациях этот термин дискредитирован корпоративными вечеринками или нелепыми (с точки зрения многих сотрудников) тренингами.

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

Обратите внимание на еще один, важнейший аспект тим-билдинга – совместное планирование. Мы неоднократно использовали этот прием в ходе первоначального планирования проекта, и стоит продолжать это делать в течение всего проекта. Вовлечение членов команды в формирование ИСР, расписания и прочих элементов плана значительно повышает эффективность их взаимодействия.

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

Дело 6. Отчитываться о выполнении проекта

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

Проявите инициативу. Предложите спонсору форму простого ежемесячного отчета (например, в формате графика вех – см. главу VIII). Держите его в курсе событий.

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

Выходы:

Запросы на изменения
Изменения плана управлением проекта
Отчеты о выполнении
Продукт проекта
Запросы на изменения

Глава XIII. Закрытие проекта

Входы:

устав
концепция проекта
продукт проекта

Закрытие проекта – это процесс в самой «голове удава». Проект близок к окончанию. В этой фазе нам предстоит:

Провести сдачу-приемку продукта (проект закончен для заказчика)
Высвободить ресурсы (проект закончен для спонсора)
Задокументировать и сделать доступной всю важную информацию по проекту (проект закончен для ПМ)

Проводим сдачу-приемку продукта

Этот процесс мы проводим для заказчика.

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

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

Процедура «приемки» бывает чрезвычайно разнообразной. Основные ее положения должны быть зафиксированы в «концепции проекта» как результаты поставки и критерии приемки. Иногда, результаты и критерии описывают кратко, а, порой – очень развернуто (например, в отдельном документе – «программа и методика испытаний»).

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

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

Очень часто в комиссию включают конечных пользователей. Чем лучше выстроены ваши отношения с ними к моменту сдачи работ – тем выше ваши шансы на прием.

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

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

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

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

Высвобождаем ресурсы

Высвобождение ресурсов – это закрытие проекта с точки зрения его спонсора. Именно в этот момент ваша организация перестает тратить деньги на проект.

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

Важно понимать, что некоторые ваши сотрудники могли быть выделены на некое определенное время (не на весь проект), и уже давно переключились на прочие задачи (по договоренностями с «хозяевами ресурсов»). Совершенно не обязательно, что команда в полном составе должна дожидаться окончания приемки продукта, морально вас поддерживая и ни чем другим не занимаясь. Но, высвобождая ресурсы, вы подаете сигнал всем членам команды и их боссам – «мы закончили». «Хозяева ресурсов» теперь могут окончательно выкинуть ваш проект из головы. Вы не появитесь у них на пороге с просьбой «дать снова того же программиста через недельку на месяц-другой, ибо сдача затянулась и нужны доработки».

То же самое касается и техники (например, тестовых серверов, если таковые использовались в вашем проекте). Оповестите вашего администратора, пусть он знает, что теперь «ваша» техника может быть доступна другим менеджерам проектов.

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

Сохранить информацию по проекту

Сохранение информации по проекту – это закрытие проекта с точки зрения менеджера проекта.

Лучшие практики и «извлеченные» в ходе выполнения проекта уроки – важнейший актив вашей компании.

Вспомните, как вы запускали проект. Мы условились, что вам пришлось «с нуля» формировать перечень и шаблоны документов, выбирать методики оценок, нащупывать тот или иной способ выполнения работ.

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

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

Не пишите много, сконцентрируйтесь только на важной (с вашей точки зрения) информации.

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

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

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

Выходы:

документы, подтверждающие приемку продукта
скорректированные шаблоны типовых документов
извлеченные уроки

Глава XIV. Что дальше?

В данной книге мы рассмотрели лишь общие положения методологии PMI. Развивайте свои знания в этой области – изучите PMBoK в оригинале, проведите сравнение с другими широко распространенными подходами к проектному менеджменту (перечислены в главе III).

Мы не касались прикладных навыков менеджера (лидерства, коммуникативности и прочих) – на эту тему изданы сотни книг и периодических изданий. Осваивайте их по мере необходимости.

Изучите методологическую специфику управления программами и портфелями – рано или поздно вам придется столкнуться с управлением несколькими, как-то взаимосвязанными проектами.

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

Удачи вам в ваших проектах!