Основы проектной деятельности Лекция 4

Другие планы и шаг назад

Шаг назад

Разработанный нами ранее сценарий планировании пройден.

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

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

Другие элементы плана

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

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

Управление изменениями

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

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

Управление конфигурациями

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

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

Более того, сотрудник должен ЗНАТЬ, какой документ последний и как это проверить. Изучая, скажем, реестр рисков - читатель должен быть уверен, что видит перед собой актуальный перечень, что, пополняя его - он не делает «пустую работу» (если где-то хранится более свежая версия, уже заполненная на ту же тему кем-то другим).

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

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

План закупок

Вспомним про возможность, использования подрядчиков на проекте.

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

Занимайте активную позицию по отношению к другим службам. Заранее узнавайте- как устроен процесс закупок и поиск подрядчиков, и сколько времени он может занять. Помните, если «они» провалят вам закупки – это будет проблема ВАШЕГО проекта, а значит и ваша ответственность.

Готовимся к запуску работ

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

Время браться за работу!

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

Выходы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(это происходит всегда, вопрос только в продолжительности).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не бойтесь сообщать «плохие новости» заранее, опасайтесь делать из них сюрприз при закрытии проекта.

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

Управление ожиданиями - процесс, который длится весь проект, однако основной главный его эффект проявляется в фазе закрытия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выходы:

- Запросы на изменения

- Изменения плана управлением проекта

- Отчеты о выполнении

- Продукт проекта

- Запросы на изменения