Реализация проекта. Лекция Контроль исполнения пр. Лекция Контроль исполнения проекта
 Скачать 494.23 Kb.
|
|
Лекция «Контроль исполнения проекта» Введение После того, как процесс планирования проекта завершился, и необходимые одобрения получены, можно распечатывать план работ и созывать команду для старта их реализации. Кажется, план готов и остается только последовательно выполнять по нему работы. Однако на этапе реализации проекта настоящая работа команды только начинается: приходится непосредственно выполнять поставленные задачи, решать возникающие трудности, координировать и сопоставлять задачи внутри команды, оценивать и принимать неизбежно появляющиеся изменения, информировать о ходе проекта заинтересованных лиц и т.д. Прежде всего, для принятия каких-либо решений в рамках проекта нужно понимать статус проекта: что уже было сделано, что еще предстоит сделать, а что стоит и переделать. Поэтому в проектной деятельности выделяют процесс мониторинга и контроля. Такой процесс позволяет заинтересованным сторонам понять текущее состояние проекта, какие были предприняты шаги, какие намерения так и остались намерениями, а также построить прогноз в отношении достижения целей проекта (в том числе прогноз по расходованию денежных средств, соответствия расписанию и содержанию). Мониторинг и контроль работ проекта — это процесс отслеживания, проверки и ведения отчетности о ходе исполнения для достижения целей исполнения, определенных в плане управления проектом. Возникающие задачи в рамках процесса мониторинга и контроля можно условно рассматривать с двух сторон: со стороны команды проекта и со стороны выполняемых ими работ. 1. Команда проекта Для успешной реализации проекта важно, чтобы вся команда проекта была в курсе текущей ситуации в проекте, чтобы любой член команды мог свободно сообщать о возникающих трудностях и предлагать собственные решения, а не только критиковать и перекладывать ответственность за проект. После того, как будет выбран режим коммуникаций, распределена ответственность, необходимо выстроить систему информирования о текущем состоянии проекта, в том числе систему отчетности и контроля. 2. Работы проекта Работы проекта могут быть выполнены по-разному, с разным качеством, и не всегда члены команды готовы приложить достаточно усердия и стараний без напоминания. Но если итог не будет удовлетворять поставленным требованиям, то проект с большой вероятностью будет провален. Кроме того, в процессе выполнения могут возникать новые задачи, которые не были учтены на этапе планирования; выполняемые задачи могут оказаться на порядок сложнее, чем представлялось в начале проекта; могут поменяться внешние условия и т.п. Ведь проект – как живой организм. Соответственно, необходимо отслеживать соответствие между получаемыми результатами и требованиями к ним, и стремиться, чтобы поставленные задачи были решены с должным качеством. Процесс отслеживания соответствия зависит, прежде всего, от типа проекта и команды проекта: сверка может проходить на общем собрании команды проекта, может быть выполнена единолично руководителем проекта, могут быть организованы промежуточные встречи-приемки с Заказчиком и т.д. 1. Какие действия предпринимаются на этапе реализации? Руководитель проекта может: Координировать действия всех участников проекта: налаживать необходимые связи между участниками проекта, обеспечивать вовремя необходимые ресурсы, назначать на новые задачи исполнителей и т.д. Оценивать прогресс выполнения работ проекта по различным показателям (время, стоимость, качество, содержание) и инициировать по результатам оценки корректирующие или предупреждающие действия (например, назначать новых исполнителей, корректировать план работ). Информировать как команду проекта, так и других заинтересованных лиц о ходе выполнения проекта и появляющихся изменениях в нем. Отслеживать возникающие изменения в проекте, планировать и организовывать их выполнение, выявлять и анализировать новые риски. Каждый член команды проекта может: Выполнять назначенные на него задачи согласно обозначенным требованиям (к содержанию, к срокам). Отчитываться о ходе выполнения задач: сколько уже выполнено, сколько еще осталось сделать. Вовремя информировать о возникающих трудностях, предлагать решения об их устранении. Инициировать изменения, как к требованиям к результату проекта, так и к организации всего проекта. Принимать участие во встречах команды проекта. 2. Информирование заинтересованных лиц Представьте ситуацию, когда Заказчик или другое влиятельное лицо находится в информационном вакууме и не имеет достоверной информации о ходе проекта. Что он думает о проекте и как он принимает тогда решения? И такая ситуация точно не будет способствовать успешному достижению целей проекта. Поэтому лучше изначально решить, кому и какую информацию о ходе проекта предоставлять, чтобы понимание стало верным. Как гласит одно из следствий из закона Чизхолма (Chisholm's Laws): «Всё, что может быть понято неправильно, будет понято неправильно». Кто именно должен понимать статус проекта, кого стоит информировать о ходе проекта? 1. Руководитель проекта. Именно он отвечает за весь проект, ему принимать важные решения, касающиеся проекта. Соответственно, руководитель проекта должен обладать полной информацией о ходе проекта. 2. Команда проекта. Для успешной реализации проекта важно, чтобы любой член команды понимал, что происходит в проекте, какие ему необходимо выполнять задачи, и как эти задачи могут повлиять на проект. Основываясь на этой информации, команда проекта сможет сообщать о возникающих трудностях и изменениях, предлагать решения. О вариантах настройки коммуникаций было рассказано в лекции «Коммуникации в проекте». 3. Заказчик и другие заинтересованные лица. Информирование с заданной периодичностью заинтересованных лиц помогает удерживать их вовлеченность в проект и управлять их ожиданиями, а значит позволяет повысить вероятность поддержки проекта и минимизировать их сопротивление. Для более точного определения адресатов удобно использовать матрицу заинтересованных сторон, о которой шла речь в лекции «Разработка требований к результату». Кстати, по мере развития проекта состав заинтересованных сторон и уровень их вовлечения могут меняться, и это стоит учитывать. Вовремя доставленная и адекватная информация о проекте напрямую способствует успеху. Важно, чтобы была выстроена адекватная система информирования о текущем состоянии проекта, в том числе система отчетности и контроля. Такая система позволит не только оперативно принимать решения, но и снизить вероятность возникновения конфликтов, как внутри команды проекта, так и с другими заинтересованными лицами из- за недопонимания. Для небольших проектов достаточно выстроить режим еженедельного информирования (звонок по телефону, встреча, отчет по электронной почте или в мессенджере), для более крупных проектов можно дополнительно использовать программные средства наподобие систем управления проектами или задачами (Trello, Notion, JIRA, Planfix, Megaplan, LeaderTask и др.). Более подробно поговорим об отчетах далее. 3. Отчетность в проекте Отслеживание статуса проекта заключается в сборе фактических данных, таких как даты начала и завершения задач, количество потраченных часов и денег, и в оценке предполагаемых сроков, трудозатрат и денег для оставшихся задач. Формат отчета об исполнении выбирается в зависимости от того, для кого он предоставляется: для руководителя проекта, для команды проекта, для заказчика или других заинтересованных лиц. В соответствии с адресатом отчета выбирается также и периодичность предоставления, например, ежедневно, еженедельно, ежемесячно или по запросу. Главное, чтобы работа руководителя проекта и команды проекта не свелась только к заполнению отчетов! Формат отчета может быть как простым, так и детально проработанным. В простом отчете может содержаться следующая информация об исполнении: выполнена задача или нет (% выполнения задачи); сколько осталось дней до завершения текущей задачи; возможные смещения по срокам или стоимости будущих задач. В расширенных отчетах может дополнительно содержаться следующая информация: выполненные задачи за определенный период и их показатели (срок, стоимость, ресурсы); прогнозные значения показателей будущих задач или проекта в целом; анализ выполненных работ; сводная информация о рисках проекта; сводная информация об изменениях в проекте; другая значимая информация, которая рассматривается и обсуждается. Оценка выполнения работ проекта может производиться с разной периодичностью, в зависимости от требуемой точности, например: контроль в моменты окончания работ (0% – работа не выполнена, 50% – работа в процессе выполнения, 100% – работа выполнена); контроль в заранее определенных ключевых точках проекта (контроль по вехам); регулярный оперативный контроль с заданной периодичностью (например, ежедневно, еженедельно). Существует два основных подхода к подготовке отчета членами команды проекта: со стороны задач и со стороны назначений ресурсов. Выбор подхода зависит от принятых в организации стандартов, типа проекта, важности подсчета потраченных трудозатрат, в том числе количества свободного времени для обновления данных в плане работ и т.д. А) Идея подхода обновления информации по ресурсам заключается в том, что команда проекта отражает как фактические трудозатраты на назначенные задачи, так и предстоящие в своих периодических отчетах. Такой подход обеспечивает более точную картину о состоянии проекта, но требует достаточно больших затрат времени руководителя проекта и команды проекта. Обычно такой подход используется, когда выплаты сотрудникам зависят от потраченных часов, скорости работы. Тогда процент завершения по трудозатратам обозначает долю фактически отработанных часов по отношению к запланированным часам. Пример 1. Отработав на задаче 16 часов из 40, вы получите 40% завершения по трудозатратам, хотя задача могла длиться и 3 дня, и 5 дней, и 10 дней, и так далее. Пример 2. Допустим, сотрудник прислал отчет, что он выполняет задачу, запланированная длительность которой была равна 5 дней. Он потратил 24 часа на решение этой задачи и выполнил половину (% завершения по трудозатратам равен 50). Тогда руководитель проекта сможет построить следующий прогноз по выполнению задачи при восьмичасовой рабочей неделе: осталось потратить 24 часа, т.е. 3 дня; всего задача займет 6 дней, значит превышение длительности – 1 рабочий день. Б) Смысл подхода обновления информации по задачам состоит в том, что собираются данные о фактической и оставшейся длительности, о датах начала и окончания задачи. Такой подход менее трудоемок, но и является менее точным. При таком подходе процент завершения показывает долю фактической длительности выполненной части работы по отношению к запланированной длительности работы. По сути, это значение показывает – насколько выполнена работа с точки зрения запланированной длительности. Пример 3. Допустим, вы отработали 3 дня из девятидневной задачи, тогда % завершения будет равен 30, несмотря на фактическое количество потраченных часов. Также и с проектом, отработав по проекту 18 дней из 120, вы получите 15% завершения всего проекта. В зависимости от типа проекта и потребностей участников в качестве инструментов для составления отчетов могут использоваться следующие: текстовые и табличные редакторы (MS Word, Evernote, MS Excel, Google Docs, Google Sheets и т.д.); информационные системы управления проектами (MS Project, OpenProj, Oracle Primavera, др.); системы постановки задач (MS Outlook, Trello, Jira, Планфикс, Битрикс, Notion, др.). 4. Изменения в проекте В процессе реализации проекта неизбежно появляются изменения: оказывается, что задачи занимают больше времени, чем планировалось; Заказчик на основании увиденных промежуточных результатов формулирует требования более четко, иногда внося значительные корректировки; стоимость ресурсов может изменяться во времени; у членов команды может не хватить квалификации для решения назначенных задач или попросту они могут заболеть. Получается, что изменения могут касаться любых аспектов проекта. Все изменения объясняются тем, что проектная деятельность – уникальна, невозможно предвидеть на стадии планирования все обстоятельства. Поэтому изменениями необходимо управлять, чтобы проект мог достичь своих целей в разумные сроки и бюджет! Согласно [Мазур]: изменение в проекте – это замещение одного решения другим вследствие воздействия различных внешних и внутренних факторов при реализации проекта. Все изменения в проекте можно условно разделить на две категории: изменения, которые не требуют особых согласований, и изменения, которые «быстро» внести в проект не получится. В первом случае предположим, что задача выполняется на несколько дней дольше, чем планировалось изначально. Тогда руководитель проекта оценивает возможности и доступные ресурсы, и выбирает то решение, которое лучше всего подойдет для возвращения графика работ в нужное русло (может передать работу другому сотруднику или назначить еще одного сотрудника, договориться о сверхурочном выполнении и т.д.). Во втором случае, к примеру, если Заказчик просит внести весомые изменения в разрабатываемый продукт, то без согласования с командой проекта, спонсором и другими заинтересованными лицами не обойтись. Соответственно, при получении запроса на изменение необходимо оценить, насколько это изменение затрагивает окружение проекта и кто его должен согласовать, если выявится такая необходимость. В таком случае схема утверждения изменения включает: Техническое одобрение: оценка необходимости, возможности внести изменения и степени его воздействия. Финансовое одобрение: анализ затрат/выгод. Бизнес-одобрение: соответствие целям проекта, одобрение конечными пользователями вносимых изменений. Значительную часть времени руководителя проекта занимает обработка запросов на изменение и отбор тех изменений, которые имеют смысл для проекта и принесут пользу. Поэтому руководитель проекта с одной стороны должен обладать определенной гибкостью, а с другой стороны он является гарантом того, что план работ, содержание и бюджет проекта не изменятся без необходимых одобрений. Процесс управления изменениями помогает обеспечить баланс между гибкостью и жестким контролем. Иногда выставляют следующие приоритеты для изменений проектов: Низкий — изменение желательно, но его внедрение может быть отложено. Обычный — нет срочности, но откладывать не стоит. Высокий — изменение необходимо для устранения серьезной ошибки, затрагивающей большое число пользователей. Наивысший — необходимо наиболее эффективным образом провести изменение, поскольку оно влияет на бизнес в целом. Кто может инициировать изменения? Выступить с предложением по изменению в проекте может любое заинтересованное лицо: и Заказчик, и Спонсор, и Команда проекта. Однако не все изменения принимаются к реализации. Рассмотрим подробнее, какие предпринимаются шаги по управлению изменениями. 1. Запрос на изменение отправляется руководителю проекта. Важно: запрос предоставляется в письменном виде (в свободном изложении или в форме, которая определена в организации). 2. Команда проекта рассматривает запросы и оценивает их (потенциальные последствия для проекта, стоимость их реализации и т.д.). В зависимости от категории запроса решение о включении в проект принимается сразу или отправляется на согласование с другими заинтересованными лицами. 3. После утверждения запроса на изменение вносятся необходимые корректировки в документы, которые затронуло данное изменение. Дальше они становятся частью проекта, и работа идет свои чередом. Хорошей практикой является ведение списка рассматриваемых изменений, он пригодится для ретроспективного анализа по итогам проекта. Какие шаги может делать руководитель проекта при внесении изменений? 1. Манипулирование ресурсами: Замена ранее планировавшихся исполнителей на других, обладающих нужной компетенцией и имеющихся в наличии. Наращивание ресурсов (привлечения ресурсов со стороны, расширение собственных ресурсов предприятия). Выполнение задач сверхурочно, материальное стимулирование. 2. Работа со временем: Смещения задач за счет временного резерва следующих задач. Выполнение задач параллельно. Продление срока завершения проекта. 3. Изменение качества продукта (работа с содержанием): Снижение качества продукта проекта (исключение каких-либо требований к продукту, замена технологии, материалов и т.п.). Замена продукта проекта на аналогичный и другие меры. Выбор мер зависит от сути изменений, которые вносятся в проект, от команды проекта, от договоренностей с Заказчиком и других причин. |