Метрики успеха проекта: выполнение проектов в срок и в рамках бюджета
Если вы попросите пять разных людей дать определение «провалу проекта», вы, скорее всего, получите пять разных ответов. Это связано с тем, что неудача проекта является субъективной, определяется как критериями успеха проекта, так и метриками, используемыми для оценки его эффективности во время и после его завершения.
Один проект можно считать успешным, если он придерживается запланированных сроков, другой — если он остается в рамках своего первоначального бюджета, а третий — если он избегает расползания объема. Но если бы кто-то другой оценивал успех по соответствующему уровню удовлетворенности клиентов, и эти проекты не соответствовали ожиданиям клиентов, каждый из них также можно было бы назвать провалом.
Поскольку неудача субъективна, важно включить критерии успеха в план проекта, и еще более важно, чтобы все заинтересованные стороны были согласованы с одним и тем же определением успеха.
Несовпадение приводит к недопониманию, недовольству и, в конечном итоге, к разделению команд на разрозненные структуры — рецепт неэффективности.
Но если все заинтересованные стороны работают вместе для достижения одной и той же цели и договариваются о том, какое ограничение отдать приоритет перед другим, то каждый проект будет успешно приносить пользу.
В этой статье мы рассмотрим пять критериев успеха, которые обычно используются для измерения успеха или неудачи проекта, и выделим инструменты, которые можно использовать для отслеживания производительности .
Перейти к:
Как измерить успех проекта
1 Область применения
Объем — это предполагаемые результаты проекта и работа, которая должна быть выполнена для достижения этих результатов. В нем излагаются конкретные цели, результаты, функции и т. Д., Которые, как ожидается, будет реализован в рамках проекта, а также задачи, сроки и затраты, которые потребуются для их достижения.
Если у вас нет полностью определенной области в начале проекта, тогда объем не должен быть вашим основным критерием успеха. Имейте в виду, что ключевой отличительной чертой Agile является отсутствие полностью определенных требований перед запуском, поэтому Agile-проекты должны использовать другую метрику.
Когда вы увеличиваете объем проекта, вы также должны увеличивать бюджет и / или время. Слишком часто при расширении объема работ заинтересованные стороны хотят добавить требования после того, как проект находится в стадии реализации, но не хотят идти на компромисс по поводу других ограничений.
ЧЕМ РИСК: в прошлом году 52% проектов испытали сокращение масштабов, согласноотчету Института управления проектами (PMI) за 2018 год «Пульс профессии».
Как отслеживать объем работ: во время планирования проекта работайте с заинтересованными сторонами, чтобы создать структурную декомпозицию работ, которая:
- Определяет все требования к проекту
- Делит требования на более мелкие результаты
- Обрисовывает в общих чертах задачи, необходимые для достижения результатов (и ключевые ресурсы *)
- Оценивает время, необходимое для выполнения каждой задачи
- Определяет критический путь проекта
* Ресурсы играют важную роль в понимании масштабов вашего проекта. Вы должны знать пропускную способность вашей команды, использование ключевых ресурсов и то, как ставки оплаты влияют на бюджет.
Как только вы поймете критический путь и то, как ограничения ресурсов влияют на план проекта, вы можете использовать диаграммы Ганта для визуализации проекта.
Просмотр проекта, изложенного в календаре, — отличный способ заставить все заинтересованные стороны понять масштаб проекта и то, как конкретные требования выполняются в течение отведенного времени и бюджета.
Диаграммы Ганта также служат инструментом отслеживания проектов; менеджеры могут использовать их, чтобы следить за производительностью и следить за тем, чтобы проекты выполнялись в запланированном объеме.
Диаграмма Ганта Wrike с описанием запуска линии органической косметики ( Источник )
2. Расписание
График — это график вашего проекта. Он включает в себя не только дату вашего последнего закрытия (или запуск продукта, в зависимости от обстоятельств), но также важные вехи и сроки выполнения задач на этом пути.
Наиболее частая причина того, что проекты превышают первоначальный график, — это переутомление сотрудников. По данным Gartner, вместо того, чтобы ожидать, что сотрудники отдадут проекту 100%, признайте, что на самом деле они могут посвящать проектам только 33% своего доступного времени.
В статье «Планирование емкости ресурсов для руководителей PPM: просканируйте перед тем, как пойти » (полный отчет доступен клиентам Gartner) аналитики Роберт Хэндлер и Мбула Шон говорят:
«Принуждение людей переходить от одного занятия к другому, не связанного с ним, из-за чрезмерных обязательств требует затрат от 20 минут до двух часов с точки зрения эффективности и результативности работы над проектом».
Чтобы избежать перерасхода графика, вам нужно спланировать провисание — или плавание — в вашей временной шкале и своих ресурсных возможностях.
Если график является вашим наиболее важным критерием успеха, и вы замечаете, что график начинает смещаться, вам необходимо увеличить свой бюджет, чтобы привлечь больше людей, чтобы помочь окупить потерянное время, или уменьшить масштаб проекта, чтобы достичь того, что вы можете, последний срок.
ЧЕМ РИСК: В прошлом году 48% проектов не были завершены в соответствии с первоначальным графиком, согласноотчету PMI Pulse of the Profession за 2018год .
Как отслеживать расписание: существует множество инструментов, которые могут помочь вам отслеживать расписание вашего проекта, включая диаграммы Ганта и календари . Но важно помнить, что вам также необходимо отслеживать ограничения ресурсов.
Конкретные ключевые показатели эффективности, которые необходимо отслеживать и которые помогут придерживаться графика проекта, включают:
- Процент выполненных задач
- Просроченные проектные задачи
- Пропущенные вехи
- Индекс выполнения графика : освоенная стоимость (EV) / плановая стоимость (PV)
Просмотр задач и использования ресурсов в TeamGantt ( Источник )
3. Бюджет
Бюджет — это то, сколько будет стоить ваш проект. Сколько вы планируете потратить на выполнение объема работ? Какие средства вы вкладываете в проект?
Когда проекты превышают свой первоначальный бюджет, это почти всегда результат плохого планирования. Вам необходимо определить все возможные расходы (заработная плата, материалы, дизайн, тестирование и т. Д.), Оценить стоимость каждой позиции, а также спланировать, что что-то пойдет не так.
Чтобы избежать перерасхода средств, важно запланировать непредвиденные обстоятельства в своем бюджете не только для учета непредвиденных затрат, но и на случай, если ваши оценки окажутся неточными.
Большинство экспертов сходятся во мнении, что в бюджеты проектов следует добавлять от 10 до 30% непредвиденных расходов. А если проект имеет высокий статус, вам может потребоваться дополнительный бюджет реагирования на риски.
Бюджет неразрывно связан с другими критериями успеха, упомянутыми здесь. Если это ваше основное ограничение (как это часто бывает), и ваши фактические затраты начинают превышать запланированные, вам необходимо пойти на компромисс в отношении графика, объема и / или удовлетворенности клиентов, чтобы выйти на уровень безубыточности.
ЧЕМ РИСК: В прошлом году 43% проектов не были завершены в рамках своего первоначального бюджета, согласноотчету PMI Pulse of the Profession за 2018год .
Как отслеживать бюджет. Чтобы точно отслеживать бюджеты, вам понадобятся автоматизированные инструменты , а не электронные таблицы. Рассмотрите возможность создания базы данных о расходах, которая поможет вам более точно оценить стоимость проекта в будущем.
Конкретные ключевые показатели эффективности, которые необходимо отслеживать и которые могут помочь вам сохранить бюджет проекта, включают:
- Плановая стоимость
- Действительная цена
- Освоенная стоимость
- Индекс эффективности затрат : освоенная стоимость (EV) / фактическая стоимость (AC)
Просмотр аналитики производительности времени и материалов (T&M) в Mavenlink ( Источник )
4. Достижение бизнес-целей.
Достижение бизнес-целей — это то, как ваш проект работает в сравнении с его экономическим обоснованием . Достигла ли она ожидаемых выгод (как материальных, так и нематериальных)? Обеспечил ли он ожидаемую окупаемость инвестиций (ROI)?
Ввиду быстрых темпов изменений, вызванных цифровизацией, нередки проблемы или цели бизнеса, которые изначально побуждали проект со временем сдвигаться или вообще исчезать. Избыточные проекты тратят время, деньги и ресурсы — к тому же они не приносят ничего ценного для вашей организации.
ЧТО В РИСКЕ: Согласноотчету PMI Pulse of the Profession за 2018 год, 31% проектов не достигли своих первоначальных бизнес-целей и бизнес-намерений.
Как отслеживать достижение бизнес-целей: у вас, скорее всего, очередь проектов, ожидающих зеленого света. Прежде чем какая-либо инициатива получит одобрение, попросите межведомственный комитет проанализировать экономическое обоснование, чтобы убедиться, что оно по-прежнему соответствует целям организации.
Вопросы, которые нужно задать, включают:
- Уникален ли проект?
- Как оценивается проект по отношению к бизнес-целям? (Это высокий, средний или низкий приоритет?)
- Каков профиль риска и доходности? (Высокий риск, высокая доходность, низкий риск, низкая доходность)
Затем, когда проект находится в стадии реализации, периодически сравнивайте намерения с бизнес-потребностями, чтобы убедиться, что проект в конечном итоге принесет пользу.
Примерная матрица, показывающая проекты, приоритетные по бизнес-целям
5. Удовлетворенность клиентов
Удовлетворенность клиентов — это степень, в которой результаты проекта соответствуют ожиданиям или превышают их. Это включает в себя качество результатов, общее качество обслуживания клиентов, обслуживание клиентов и взаимодействие между внутренними и внешними заинтересованными сторонами на протяжении всего жизненного цикла проекта.
Эта метрика успеха критически важна, и тем не менее она часто оказывается наиболее уязвимой. Имеет ли значение, выиграете вы на один или на 100, если выиграют оба? Это зависит от проекта и других критериев успеха.
Однако имейте в виду, что согласно опросу Accenture Global Consumer Pulse, 52% клиентов сменили поставщика в прошлом году из-за плохого обслуживания . А после переключения 68% не вернутся.
ЧЕМ РИСК: Согласно отчету Gartner о ключевых показателях ИТ за 2018 год (доступен клиентам Gartner), 26% внутренних участников проекта (от ИТ-директоров до ИТ-персонала) не считают, что они в достаточной мере удовлетворяют ожидания клиентов, оценивая свое восприятие клиентов. удовлетворение как «ожидания не оправдались» или «несколько разочаровывают».
Как отслеживать удовлетворенность клиентов: есть несколько способов сбора и анализа отзывов клиентов, в том числе:
- Прослушивание в социальных сетях
- Опросы клиентов (включая открытые ответы, а не только числовой рейтинг)
Проведение опроса об удовлетворенности клиентов в Nextiva ( Источник )
Вывод
«Быстро, дешево или хорошо — выберите два».
Эта пословица о железном треугольнике популярна не зря. Он по-прежнему применяется — и, вероятно, вернее, чем когда-либо, — с добавлением дополнительных ограничений, связанных с удовлетворением требований заинтересованных сторон и достижением бизнес-намерений.
На раннем этапе планирования определите, какие ограничения проекта наиболее важны для вашего проекта, и сделайте их определяющими критериями успеха.
Самое главное, убедитесь, что каждая заинтересованная сторона ориентирована на успешную реализацию этого показателя и помогает поддерживать его.
Как еще вы оцениваете успешность проектов? Есть ли другие критерии успеха, которые вы используете для оценки производительности? Расскажите в комментариях ниже.
Ищете программное обеспечение для управления проектами? Ознакомьтесь со списком лучших программных решений для управления проектами Platforms .
9 факторов успеха проекта
Планирование и ведение ИТ-проектов представляет собой весьма сложный процесс, но успех или неуспех каждого ИТ-проекта вне зависимости от его размера и сложности контролируется сравнительно небольшим количеством факторов. Эти факторы выведены и подтверждены сложной эволюцией управления ИТ.
Итак, успех проекта определяется немногими факторами. Разумеется, распознание этих факторов и управление ими не гарантирует успеха проектов. Понимание факторов и роли, которую они играют в успешном управлении проектами, — одно, а грамотное управление этими факторами — другое. В связи с тем, что управление факторами успеха еще не стало неотъемлемой частью практики управления проектами, слишком многие проекты в определенной степени страдают несостоятельностью.
Заметьте, мы говорим именно о «несостоятельности» проектов, а не о «неуспехе», «провале», чтобы избежать ассоциации с полным крахом проектов и колоссальными затратами. Существует огромный спектр несостоятельности проектов, связанный с самыми разными процессами. Это, например, проекты, которые вышли за рамки сроков или бюджетов, но в конце концов стали полностью функциональны. Есть еще множество проектов, которые успешно внедрены, но оказались не вполне соответствующими ожиданиям заказчиков. Бывают случаи, когда после «успешного» внедрения приложения оказывается, что оно недостаточно хорошо функционируют в данных конкретных условиях, или для данных условий слишком сложно, требует много времени для выполнения критичных задач и т. д.
Девять факторов, которые контролируют успех или несостоятельность ИТ-проектов:
1. Соответствующий уровень обязательств перед проектом со стороны топ-менеджмента компании.
2. Адекватное финансирование проекта.
3. Грамотные проектные требования и спецификации.
4. Внимательное создание полномасштабного плана проекта.
5. Оценка рисков проекта и потенциальных проблем, связанных с этими рисками.
6. Соответствующее планирование непредвиденных затрат и чрезвычайных обстоятельств.
7. Обязательства всех вовлеченных сторон.
8. Честные отчеты о статусе проекта и о потенциальных проблемах, которые возникают по мере продвижения проекта.
9. Объективная оценка возможности организации следовать проектному курсу.
Обязательства руководства компании
Часто менеджмент компании одобряет ИТ-проекты, которые несут в себе потенциально серьезные проблемы для предприятия, не понимая, какому риску они подвергают предприятие. ИТ-директор должен соответствующим образом информировать старшее управленческое звено о возможных проблемах, связанных с проектом. Однако часто эйфория по поводу подписания проекта и выделения фондов заставляет страхи отступить. Менеджмент компании с помощью ИТ-директора или без него из своего опыта должен понять, что проект необходимо отклонить или приостановить по крайней мере до тех пор, пока все сложные вопросы не будут решены.
Есть и другая сторона вопроса. Старшее управленческое звено компании должно понять, что важно не только подписание проекта к выполнению, но и определенный уровень обязательств по мере выполнения проектов в течение всей жизни проекта. Когда все видят и понимают, что ИТ-проект находится под пристальным контролем управления компании, все вовлеченные стороны в гораздо большей степени фокусируются на проекте. Крайне важно, чтобы руководящие менеджеры, ответственные за определенные части проекта, продолжали держать руку на пульсе по мере его выполнения. К сожалению, очень часто случается, что после подписания проекта к выполнению его полностью оставляют на ИТ-отдел. В этом случае проект в опасности. Поведение руководства компании в отношении ИТ-проекта еще называют SMC-фактором (Senior Management Commitment) успеха проекта.
Адекватное финансирование проектов
ИТ-проекты часто требуют существенных финансовых вложений. Однако финансы сами по себе не являются панацеей, и доступ к большому количеству денег не гарантирует успеха проекта. Организации должны понимать, что время, аппаратное и программное обеспечение, а также человеческий фактор — все компоненты, составляющие ИТ-проект, — дороги. До начала проекта необходимо потратить достаточно много времени на то, чтобы проанализировать стоимость компонентов проекта. Хотя хороший начальный анализ затрат проекта может и не привести к точной цифре, процесс должен обеспечить понимание затрат, ассоциированных с проектом. Как только получены более-менее реальные цифры, в эти затраты надо еще интегрировать разумное количество фондов на непредвиденные обстоятельства.
Но дело не только в грамотной начальной оценке стоимости проекта. Эти оценки затрат по проекту должны быть сделаны, но их результаты не должны рассматриваться как окончательные. Оценка финансовых затрат на ИТ-проект должна быть продолжительным и гибким процессом. Затраты на проект следует пересчитывать несколько раз по мере выполнения проекта и новые цифры представлять менеджменту компании. Топ-менеджмент компании должен рассмотреть эти изменения бюджета проекта без какого-либо негативного предрасположения. Перемены всегда выявляют истинную сущность происходящего. Например, спонсоры проекта могли запросить дополнительный функционал, не предусмотренный в начале проекта, что повлекло за собой увеличение общей стоимости проекта (к слову, примерно в 70-80% ИТ-проектов, связанных с автоматизацией бизнес-процессов, именно так и происходит). В реальности часто случается, что руководитель ИТ-проекта самостоятельно без санкции топ-менеджмента увеличивает промежуточные затраты, добавляет новую функциональность, но эти добавления не выплывают наружу до конца проекта. Если, конечно, при таком подходе проект вообще удается довести до конца. Промежуточные оценки затрат на проект помогают переоценить масштаб проекта и часто безболезненно снизить затраты до приемлемого уровня. Каков бы ни был результат пересмотра, при таком подходе есть возможность сделать определенные изменения, приемлемые для бизнеса. А по мере продвижения проекта в какой-то момент истинный масштаб проекта будет выявлен, и руководитель проекта сможет определить стоимость проекта более точно.
Проектные требования и спецификации
Для успеха проекта необходимо понять, что будет сделано в проекте и чего делаться не будет. Большинству руководителей ИТ-проектов знакома ситуация, когда функциональные заказчики начинают говорить, что функциональность, которая ранее была не нужна, вдруг оказывается срочно необходимой. Это обычно приводит к нарушению намеченного плана работ и является результатом недостаточной предварительной работы с функциональными заказчиками.
Более того, даже если требования и спецификации хорошо продуманы и задокументированы, по мере продвижения проекта все равно возникнут непредвиденные обстоятельства и решения. Поэтому важно с самого начала договориться, по крайней мере по поводу крупных модулей системы, и подписать соответствующее соглашение. Требования к проекту и спецификации должны быть одобрены бизнес-отделами, проблемы которых данный ИТ-проект и призван решить.
Максимально полный план проекта
Многие ИТ-менеджеры до сих пор убеждены, что план ИТ-проекта — бесполезная трата времени, хотя уже давно обнаружена зависимость между временем, затраченным на планирование проекта, и успехом проекта. Во-первых, планирование представляет четкое, документированное должным образом сфокусированное представление о проекте. Во-вторых, процесс планирования поднимает вопросы, которые бы не принимались во внимание без планирования. Очень часто все хотят побыстрее приступить к работе без адекватного понимания задач проекта или путей их реализации. В-третьих, умелое планирование формирует уверенность в успехе проекта. Соответственно по мере углубления плана становится легче приступить к проекту. ИТ-директор должен внедрять это положение самым настойчивым образом: планирование является важным компонентом управления проектами, и план должен быть закончен и утвержден, прежде чем проект начнется.
Оценка рисков проекта
До того как проект будет утвержден, необходимо сделать анализ рисков. Определение проектных рисков предполагает понимание рисков двух типов: стандартные риски и риски, связанные с требованиями данного конкретного проекта. К стандартным рискам относятся использование нового ПО, уровень ИТ-навыков в организации, наличие успешно оконченных ИТ-проектов, размер и сложность проекта, готовность организации финансировать проект, уровень доверия между ИТ-отделом и функциональными заказчиками. Риски, ассоциированные с конкретным проектом, включают в себя важность проекта для бизнеса организации (чем более он важен, тем больший риск). Внедрение нового приложения несет в себе больший потенциальный риск для эффективности бизнеса, чем апгрейд существующей системы. К рискам конкретного проекта относят риски, связанные с вендорами, например, возможность вендоров обеспечить оговоренную производительность или необходимость привлечения других вендоров. Обстоятельства внутри вендорской компании могут измениться. Например, на половине проекта вендорская компания может принять решение снять с производства линию аппаратного обеспечения, которая используется для данного проекта. Кроме того, к рискам конкретного проекта относят возможности потери ключевых специалистов.
Планирование чрезвычайных обстоятельств
По мере продвижения проекта всегда возникают сложности. Хотя организация может быть и полностью уверена в успехе проекта, разумно все же допускать вероятность провала. В связи с тем, что такая возможность существует, организация должна создать план преодоления препятствий. Одно из распространенных чрезвычайных обстоятельств — уровень аппаратных средств для поддержания проекта, становящийся вдруг неадекватным, когда проект запускается. Одна из типичных проблем ИТ-проектов, в особенности клиент-серверных, состоит в производительности приложений — она часто оказывается гораздо ниже планируемой. Следовательно, план проекта должен предусматривать возможности увеличения аппаратных ресурсов в случае необходимости. Конечно, никакое планирование не покроет всех возможных чрезвычайных ситуаций. В связи с этим финансирование проектов должно осуществляться гибко и давать возможность дополнительного финансирования затрат.
Обязательства вовлеченных сторон
Очень часто — слишком часто, чаще, чем хотелось бы, — ответственность за ИТ-проект полностью перекладывается на ИТ-отдел. К сожалению, порой ИТ-проекты значительного размера заканчиваются практически без какого-либо вмешательства функциональных заказчиков, потому что заказчики находятся в плену иллюзии: «закончите полностью — тогда покажете». Сотрудники за пределами ИТ-отдела, для которых, собственно, и выполняется проект, отделяют себя от проекта, в котором они кровно заинтересованы. Когда ИТ-проекты идут таким образом, они редко соответствуют запросам заказчиков. Дело не только в заказчиках, организационная вина ИТ-отделов тут тоже есть. Руководители проектов должны понять, что в их собственных интересах выстроить свои процессы, гарантируя максимальное вовлечение заказчиков в процесс работы над проектом. Отсутствие такой организации обязательно снизит коэффициент удовлетворенности. ИТ не должно инициировать никакие проекты без гарантии вовлеченности функциональных заказчиков и необходимого времени для их участия в проекте.
Учитывая возрастающую сложность ИТ-проектов, можно поставить такой диагноз: отсутствие ответственности за проект со стороны функциональных заказчиков представляет собой грубейшее нарушение принципов управления проектами. ИТ-инвестирует много времени и усилий в проекты, и заказчики со своей стороны должны найти способ инвестировать их со своей стороны. Старая парадигма «я плачу деньги — остальное меня не интересует» перестает работать. Топ-менеджмент компании должен организовать процессы таким образом, чтобы все стороны участвующие в проекте разделили ответственность за проект.
Правдивые отчеты о статусе проекта
Аккуратная отчетность по проекту — это звучит просто, но на деле оказывается немалой проблемой. Реальность такова, что отчеты о статусе ИТ-проектов чрезмерно оптимистичны. Главная проблема здесь в том, что приукрашенный отчет гораздо удобнее для всех отделов, так как дает чувство устойчивого прогресса. ИТ-директор часто полагает: недостатки и проблемы проекта будут разрешены по мере его продвижения, и никто ничего не заметит, когда все будет исправлено и проект вернется в колею намеченного расписания. Однако, как показывает практика, если однажды проект выпадает из планового расписания, ситуация без вмешательства топ-менеджмента, как правило, только ухудшается. Чем раньше отчет по проекту покажет проблемы проекта, тем лучше для всего проекта. Конечно, откровенный отчет такого рода создаст известное напряжение как для клиентов, так и для ИТ-отдела. Но определенный уровень напряжения как раз желателен. Он заставит людей разрешать возникшие проблемы на более ранних этапах. Игнорировать проблемы и переносить их разрешение на будущее означает превращать эти проблемы в сложные, трудно преодолимые препятствия.
Держать намеченный курс
Большинство сложностей, с которыми сталкиваются ИТ-проекты, можно преодолеть различными управленческими решениями. По мере того как проблемы возникают, менеджмент будет искать способы уменьшить негативные последствия и устранить источник этих проблем, однако давление, которое развивается в эти моменты, чаще всего изменяет ход проекта.
Варианты решения проблем чаще всего сводятся к одному из следующих:
a) снижение количества поставляемых пользователям возможностей;
b) использование обходного маневра решения проблемы;
c) снижение требований при тестировании подсистем, чтобы не выпасть из графика.
Обходные маневры и снижение стандартов при тестировании исходят из одной и той же идеи — проблема должна быть полностью и корректно решена, но сейчас для этого нет времени. Обходной маневр, как правило, сопровождается обещанием в какой-то момент вернуться к проблеме и сделать все как надо. К сожалению, на практике вероятность возвращения к решению этой проблемы близка к нулю.
Все это показывает, что шаги, которые должны быть предприняты для корректирования ситуации, и их производные в различных частях проекта следует внимательно продумать. Иначе от первоначального плана проекта очень быстро не останется ничего. План проекта должен быть достаточно гибок, чтобы допускать подобные вмешательства.
Как составить план проекта за восемь простых шагов
Четверг. Вечер. Вы знаете, как идут дела у вашей команды, дальнейший план работ намечен. Вы готовы к следующей неделе и впереди у вас прекрасные выходные.
И вдруг начальник приносит вам неожиданную новость. Вам предстоит возглавить новый крупный проект, работать над которым будут несколько команд. Запуск должен состояться уже на следующей неделе. Новость отличная, но над вашими выходными нависла угроза. Вам нужно организовать все как можно скорее. Но когда в проекте принимают участие столько различных сторон, с чего лучше начать?
Процесс составления плана проекта может быть непростым, особенно если речь идет о сложных проектах. По данным Forbes, 25% технологических проектов оканчиваются провалом. Но есть и хорошая новость — вам вовсе не обязательно быть крутым специалистом в управлении проектами или жертвовать своими выходными, чтобы спланировать успешный запуск проекта за минимальное время. Чтобы составить план проекта, достаточно восьми простых шагов.
Как составить план проекта за восемь простых шагов.
Шаг 1. Объясните суть проекта ключевым участникам. Определите цели и заручитесь поддержкой
Первый этап любого проекта сводится к ответам на вопросы «что?» и «зачем?». У ключевых заинтересованных лиц достаточно влияния и полномочий, чтобы чтобы от них зависела успешность проекта, и поэтому их цели обязательно нужно достичь. Даже если выполнить проект вам поручил генеральный директор, вам все равно понадобится его хорошее отношение.
В ходе первоначальных переговоров постарайтесь найти общий язык, сформулировать цели и определить ценность проекта. На первом этапе планирования вам нужно обсудить потребности и ожидания и заложить основу для определения объема работ по проекту, составления сметы и календарного плана. Все эти данные станут надежной платформой для рабочего плана проекта.
Вопросы, которые нужно согласовать с ключевыми участниками:
- Как согласуется проект с целями компании?
- Чего ожидают участники? Что ожидается от них?
- Каким образом будет измеряться успех?
- Какими ресурсами вы располагаете?
- Какие материалы или конечные продукты должны быть созданы при выполнении проекта?
Шаг 2. Составьте список целей, согласуйте OKR и наметьте план
По мнению руководителей высшего звена, отсутствие четко поставленных целей становится причиной срыва 37% проектов. Если у вас нет четкой цели, не будет и связи между требованиями, задачами и сроками, указанными в плане проекта. Но на данный момент у вас уже есть список потребностей основных участников, вы заручились их поддержкой, и пора назначать им цели и ключевые результаты (OKR). OKR — это методика планирования и постановки целей, которая стала известной благодаря таким компаниям, как Intel и Google. Ваш проект должен быть согласован с корпоративными OKR и с OKR вашей команды.
Попытайтесь записать цели проекта на доске планирования проекта и свяжите их с требованиями ключевых участников, которые обязательно нужно удовлетворить. От этой исходной точки начинайте выстраивать структуру, вехи и задачи, необходимые для достижения целей. Вехи могут выполнять роль контрольных точек на протяжении всего проекта и помогать участникам следить за ходом выполнения работ, оценивать прогресс и помнить об ожиданиях.
Шаг 3. Создайте документ с описанием объема работ по проекту
Вы составили предварительный план, согласовали задачи и цели и заручились поддержкой команды. Теперь пришла пора составить описание объема работ по проекту и подробно задокументировать все элементы проекта, перечисленные в пункте 2.
Взгляните на каждый из отчетных материалов и определите серию задач, которая должна быть выполнена для создания данного материала. Для каждой задачи укажите продолжительность ее выполнения, необходимые ресурсы и ответственного исполнителя. Доработайте и запишите все сведения о проекте, чтобы ваши сотрудники смогли пользоваться единым источником достоверной информации. Обеспечьте свободный доступ к этому документу, например, разместив его в системе управления проектами, чтобы предотвратить возможные недоразумения, которые ведут к лишним затратам.
Хотя подготовка документации об объеме работ по проекту должна быть стандартной процедурой, каждый четвертый менеджер проекта, принявший участие в опросе об управления проектами Wellingstone State, признался, что «никогда» не занимался подготовкой таких документов или составлял их «изредка». Создание такой документации даст вам преимущество и поможет всем участникам проекта быть в курсе событий.
Шаг 4. Составьте подробный календарный план проекта
Когда цели, задачи и вехи уже намечены, пора приступить к составлению календарного плана. Диаграмма Ганта — удобный инструмент, позволяющий представить временную шкалу проекта в наглядном виде. Эта интерактивная временная шкала дает полное представление о ходе выполнения проекта, объеме работ и зависимостях.
Зависимости указывают, какие задачи необходимо выполнить до начала других задач. При планировании сроков используйте подзадачи, чтобы разбивать задачи на более удобные элементы. Это упрощает последующее составление отчетов и управление загруженностью команды. Давайте дадим определения:
- Задачи — это отдельные операции, которые необходимо выполнить для достижения целей.
- Подзадачи с длительностью не более пары дней позволяют разбить задачу на более мелкие составные этапы.
- Вехи — крупные этапы или события в ходе проекта, помогающие в разбиении проекта. Вехи можно использовать в качестве контрольных точках на протяжении работы над проектом.
Совет от профессионала. Хотите узнать секрет? Настраивая сроки задач, добавляйте к ключевым задачам буферное время, чтобы у вас была возможность для маневра. Например, если клиенту потребуется дополнительное время для утверждения или участник команды неожиданно заболеет. В идеальном мире некоторые задачи можно сделать за день. Возможно, стоит запланировать для них два дня. Впрочем вовсе необязательно добавлять буферное время к каждой из ваших задач. Взвесьте риски и добавьте его только в том случае, если это имеет смысл. В будущем вы скажете себе спасибо.
Шаг 5. Определите роли, обязанности и ресурсы
Под ресурсами обычно подразумевается персонал, оборудование или деньги, необходимые для выполнения проекта. Выбрав инструменты и получив финансирование, не забудьте и про нужных специалистов. Даже люди, умеющие составлять рабочий план проекта и делавшие это сотню раз, могут недооценить свои потребности в рабочей силе.
Схема распределения ответственности поможет вам определить, кто будет выполнять ту или иную работу по проекту. Это таблица с перечислением всех задач по проекту и указанием ответственных исполнителей (назначенных для выполнения работы), подотчетных (с правом голоса и правом наложить вето), консультантов (участвующих в согласовании или обсуждении работ) и сотрудников, которые ставятся в известность (должны знать о выполненном действии или принятом решении). Шаблон схемы распределения ответственности для скачивания вы найдете по ссылке.
Когда начнете назначать задачи, обязательно учитывайте возможности сотрудников. Четко определите круг обязанностей и ожидания, которые возлагаете на каждого из них. Не забывайте, что 95% сотрудников работают с более чем одной командой или над несколькими проектами. Если эти проекты не согласованы, рабочая загрузка становится для них чрезмерной. Стресс — именно та причина, по которой 50% сотрудников начинают искать другую работу, а 25% увольняются, как показал наш недавний отчет «Эпидемия стресса».
В ходе планирования проекта подумайте, как вы будете фильтровать входящие запросы, влияющие на сроки и смету проекта. Такие инструменты, как Wrike Resource, помогают менеджерам проектов представить в наглядном виде задачи по проекту с точки зрения рабочих процессов команды, позволяя наглядно и гибко сбалансировать рабочую загрузку.
Шаг 6. Определите процессы взаимодействия и проверки
По данным исследования McKinsey, за неделю сотрудники тратят около 20% рабочего времени на сбор и поиск нужной информации. К тому же неэффективное общение и сотрудничество — это две главные причины стресса на рабочем месте. Когда участникам приходится рыться в куче электронных сообщений или постоянно задавать вопросы, чтобы узнать последние новости, от их мотивации не остается и следа.
Вы можете снизить уровень стресса, если будете хранить всю информацию по проекту — материалы, обсуждения, задачи, сроки, новости, отчеты — централизованно, например, в решении для совместной работы. Так вам будет проще следить за ходом работ, обмениваться новостями и вносить исправления. Установите правила для общения в ходе работы над проектом и храните все данные в одном программном инструменте, чтобы у всех участников имелся доступ к информации.
Шаг 7. Составьте план на случай, если что-то пойдет не по плану
Даже если вы крутой специалист и умеете составлять планы проектов, правда в том, что каждый из проектов может преподнести вам неожиданный сюрприз, и именно это делает их интересными. Допустим, вы предусмотрели буферное время при составлении календарного плана, вы убедились, что все участники знают свою роль, и внедрили правила обмена информацией.
Но перед запуском вам все же стоит поискать возможные источники проблем, такие как отпуск кого-нибудь из сотрудников, праздники или привлечение сторонних специалистов. Установите четкую цепочку команд и составьте список ключевых контактных лиц. Заранее обсудите с командой возможные риски, чтобы ваши сотрудники были к ним готовы.
Шаг 8. А вот теперь можно праздновать запуск проекта!
В ходе каждого успешного проекта обязательно проводится установочное совещание. Организуйте встречу с ключевыми участниками и разработайте четкую повестку дня. Ваша цель — донести до всех информацию о целях, ролях, процессах и сроках. В повестку дня должна быть включена вся информация, о которой мы говорили выше:
- Определите цели проекта и пользу, которую он принесет.
- Составьте список материалов, которые будут созданы в ходе проекта.
- Составьте схему связей между требованиями участников и задачами проекта.
- Продемонстрируйте временную шкалу проекта (диаграмму Ганта), чтобы все могли видеть зависимые задачи и ожидаемые даты.
- Опишите роли и обязанности всех участников.
- Объясните, как будет осуществляться взаимодействие в ходе проекта, где искать нужную информацию, например документ об объеме работ, и к кому обращаться с вопросами.
- Обсудите риски и убедитесь, что команда к ним готова.
- И на этом все!
Дополнительный совет. Вам не нужно каждый раз начинать планирование с нуля! Набирая опыт, вы сможете создавать различные шаблоны для планирования проектов определенного типа. Для начала предлагаем воспользоваться этими бесплатными шаблонами плана проекта.
Прямиком к счастливому финалу
Похоже, мы избавили вас от необходимости работать на выходных! Всегда пожалуйста. Теперь у вас есть готовый процесс планирования проекта, а заодно и простой шаблон плана, который поможет привести к успеху ваш следующий проект и все остальные проекты. Возможно, когда все это сложное планирование упростится, работа будет доставлять вам больше удовольствия. Как вы считаете?
Ну а теперь, когда вы освоили составление плана проекта, предлагаем лучшие советы от руководителей, которые помогут вашей команде работать более эффективно.
Laura Quiambao
Laura is a Senior Content Marketing Manager with a passion for using stories to share helpful tips, best practices, and insights. When she’s not writing, she enjoys rock climbing, disc golfing, traveling, and cooking with her husband.
Опубликовать Поделиться Поделиться Отправить
Советуем прочитать
Новости Wrike читается за 3 мин.
Wrike Resource — новый инструмент для управления загруженностью команды
Представляем Wrike Resource, новый мощный инструмент для управления загруженностью
Маркетинг читается за 3 мин.
Пять вредных привычек в маркетинге: как с ними бороться?
Приходилось ли вам мучиться чувством вины из-за того, что ваша повседневная работа
Управление командой читается за 3 мин.
Почему agile-ориентированным компаниям не стоит полностью отказываться от KPI?
Компании, которые работают в среде с быстро и непредсказуемо меняющимися внешними
10 факторов успеха проекта
БЛОГ ЭКСПЕРТА.
Сергей Олифиров, MBA, PMP, DipITOL, бизнес-тренер о проектном управлении.
XXI век называют веком “великих проектов». В эпоху VUCA к проектному менеджменту приковано пристальное внимание и становится все более актуальными образовательные программы по управлению проектами. Активно обсуждаются вопросы, какая методика лучше: waterfall или agile, как правильно организовать работу проектной команды по подходу SCRUM или Канбан. Но мне хотелось бы обсудить другой вопрос. Выбор инструментов и методик очень важен, но самые передовые технологии не гарантируют успех проекта, если, например, проект не является значимым или интересным для руководства компании.
В начале двухтысячных эксперты PMI разработали на основании опроса экспертов и анализа реализации успешных и провальных проектов список критических факторов успеха проекта, присутствие или дефицит которых в проекте может привести к успеху или полной катастрофе.
Эти факторы:
- ясность миссии проекта;
- поддержка со стороны высшего руководства;
- наличие четких планов;
- взаимодействие с Заказчиком;
- учет требований конечных пользователей;
- наличие необходимых технологий;
- наличие квалифицированных исполнителей;
- эффективная система контроля;
- эффективные коммуникации;
- подход к разрешению трудностей.
Проводя последние 12 лет авторский курс «Успешный менеджер проекта» для российских компаний и компаний ближнего зарубежья, мне удалось собрать видение руководителей проектов и топ-менеджеров о том, насколько эти факторы представлены в отечественных проектах. С результатами исследования хочу поделиться с Вами в цикле публикаций.
Немного забегая вперед, хочу сказать, что самый важный фактор успеха проекта — квалификация менеджера проекта и его талант создать благоприятную среду для реализации проекта.