Управление проектами. Правильный путь для начинающих

– Анализ. Приоритизация рисков.

– Планирование. Планирование графика устранения рисков.

– Мониторинг и контроль. Поддержка плана реализации проекта и списка рисков в актуальном состоянии, контроль устранения.

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

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

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

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

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

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

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

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

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

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

Этап «Закрытие»

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

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

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

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

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

1.4. Что делает проект успешным?

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

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

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

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

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

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

– Новая задача обычно должна вводиться только во время планирования Спринта (Sprint).

– Новая задача, которая имеет приоритет над текущей задачей, требует раннего завершения текущего Спринта и возврата к планированию нового Спринта.

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

В Скраме итерации (спринты) представляют собой фиксированный блок работ (задач).

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

Все это правильно, лишние работы ведут к провалу или, как минимум, незапланированным расходам бюджета проекта, но есть потребности бизнеса, которые игнорировать нельзя. В связи с этим предлагается модификация 1 и 2 пунктов из списка выше. Если новая задача срочная и ее нужно реализовать прямо сейчас, то стоит оценить ее, посмотреть, хватает ли запасов времени (мы же закладываем время на риски в каждую задачу и делаем буфер в конце спринта), чтобы можно было добавить задачу в спринт без проблем. Если запасов времени не хватает, то необходимо посмотреть, какую задачу можно убрать и на ее место поставить новую, главное, чтобы продолжительность была такой же и клиент согласовал это. Более подробно Скрам (Scrum) стоит рассматривать отдельно.