Цели проекта и частые ошибки при их определении

Цели проекта и частые ошибки при их определении

28 марта 2023

  • Автор: Анна Лаврова

  • Сложность: нормально

  • Время: 6 мин

«Вижу цель — не вижу препятствий» — эта фраза очень хорошо описывает работу проектного менеджера. Вам нужно помочь клиенту решить его бизнес-потребность. Для этого вы ставите цель, планируете и идете к успеху. Звучит красиво, но на практике не все так радужно. Причина в том, что PM-ы часто неверно определяют цели проекта или вовсе о них забывают. В статье рассмотрим, как определять и планировать цели, и разберем частые ошибки менеджеров в проработке Project Objectives.

Почему важно правильно определять цели проекта

как определять цели проекта

PM постоянно работает со скоупами продукта и проекта:

  • Product Scope определяет, что вы должны разработать и какой результат предоставить заказчику.
  • Project Scope ориентирован на работы.

Это «зачем» по сути и есть цели проекта или Project Objectives, которые в итоге должны сложиться воедино, чтобы помочь бизнесу достичь основную бизнес-цель.

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

Варианты трактовки понятия проекта и его целей из открытых источников:

  • Field & Keller (1998) описывает проект как «организованную работу по достижению заранее определенной цели или задачи».
  • Британский институт стандартов (2000) характеризует проект как «предприятие, задуманное для достижения цели».
  • PMI (2008): «Конец проекта настает, когда цели проекта достигнуты, или когда он прекращен, потому что его цели не могут быть достигнуты». 

Иногда в медиапространстве также используют концепцию целей для определения процесса проджект менеджмента. Например, по мнению Pinto & Kharbanda (1995), «руководство проекта управляет процессами и людьми в достижении целей проекта». Если возьмем трактовку Kerzner (2003), то Project Management — это управление «ресурсами для относительно краткосрочной цели». Morris (1988) же пишет «управление проектом учит, что для достижения желаемой цели проекта необходимо пройти определенный процесс».

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

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

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

Планирование целей в Agile

В старых бизнес-книгах часто можно прочесть, что долгосрочное планирование — это про 10, 25, 50 лет. Особенно, когда речь идет про энтерпрайз. В IT-сфере разрабатывать инициативы на десятилетия вперед в мире быстрых технологий рискованно. То, что актуально на сегодня или завтра, уже послезавтра может быть устаревшим или вовсе забытым. 

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

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

  • Вверху находится главная цель — инициатива условно на год.
  • Дальше идет что-то, что вас приведет к ней. Темы, если речь про требования, или OKR-ы, если говорим о способе формирования цели.
  • Ниже находятся фичи, которые законтрибьютят в OKR-ы.
  • После идут какие-то User Stories, которые добавят в фичи. Здесь как раз смотрим на Sprint Review.
  • В самом низу tasks, которые затем «вложат» в User Stories.

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

Пример планирования

пример планирования

На картинке О — это Objectives, KR —  Key Results. В данном примере нас интересуют именно цели. Они амбициозны, но при этом оставляют место для маневра и числительно подкреплены конкретными показателями. Также мы наглядно видим, где возможна определенная гибкость в работе. Например, если рассмотреть OKR самой компании, видим план по выполнению продаж от 0 и выше — то есть понимаем, что есть главным, а что следующим по порядку.

Система работы с целями OKR эффективна, если вы:

  • разрабатываете большой продукт;
  • не вдохновляетесь целями типа Smart;
  • сотрудничаете со специалистами, которые производят что-то неисчислимое;
  • ставите Goals, которые должны мотивировать. 

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

бизнес и проекты

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

PM Hard Skills_ Planning

Основные ошибки при постановке целей

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

Подмена целей процессом

Например, вы учитесь на курсе PM Hard Skills. Можно определить вашу цель как «Успешное прохождение курса», но зачем? Что вам дадут прослушанные вебинары, выполненные домашние задания и полученный сертификат? Или, например, вы разрабатываете программное обеспечение для бухгалтеров. Можно сказать, что завершение этого процесса — цель вашего проекта, но снова непонятно, для чего все делаете? Если Goals не отвечают на вопрос «Зачем?», ищите другие.

Подмена целей миссией

Часто менеджеры проектов мыслят очень глобально. Например, хотят спасти планету от экологической катастрофы или накормить всех котиков в мире. Это миссия, но не цель проекта. Чтобы спасти кого-то, нужно разработать или улучшить что-то: ПО, процесс, услугу. Уход же к глобальным вещам мешает команде фокусироваться на конкретных действиях, а также непонятно, как менеджер будет контролировать процесс и измерять результат.

Подмена целей финансовыми показателями

Большинство бизнесов, кроме редких исключений, создают продукты для получения прибыли, но «заработать 1 миллион долларов» — это не цель проекта. Этот запрос не отвечает на вопросы «Как это сделать? Как вы в качестве PM-а будете производить контроль?» Цель проекта — это то, что вы как Project Manager отслеживаете каждый день, что можете просчитать и на что повлиять. Единственное исключение, когда «заработать 1 миллион долларов» будет целью проекта, — если вы сможете непосредственно этот процесс отслеживать и контролировать.

Невозможность измерения

Нельзя управлять тем, что нельзя измерить. 

Если ставите цели, вы должны четко понимать, как узнать о ее достижении. Пример из практики: у одной логистической компании проблема в приоритезации файлов, которые обрабатывают менеджеры. IT-команда предложила разработать специальное ПО, которое бы отслеживало и правильно распределяло документы по уровню важности с учетом будущей интеграции в CRM. Вроде все понятно, но как оценить, «пощупать» результат? Прошлая цель не позволяла это сделать, и тогда была сформулирована новая — через три месяца после внедрения ПО увидеть, что больше 90% файлов обрабатываются в нужном приоритете.

В этом примере есть все нужное для определения Project Objectives:

  • что делаем — разрабатываем и внедряем ПО;
  • зачем — для оптимизации процесса работы;
  • как именно измеряем — через три месяца менеджеры обрабатывают больше 90% файлов. 

Итог

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

Анна Лаврова

Agile Coach в Wemanity Belgium. Более 9-ти лет опыта работы в управлении проектами. За это время была в роли PM-а в Outsource, Outstaff, Product, Startup компаниях. Работала с государственными проектами США, запустила несколько стартапов. Сейчас живет в Брюсселе и работает с корпорациями, которые стремятся быть Agile.