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

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

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

Поэтому заказчик поставил нам следующую задачу: типизировать все активности, чтобы

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

Чтобы было легче ориентироваться, мы использовали российскую модель сложности проектов, которая выделяет четыре основные группы факторов:

Набросав подходящие факторы сложности, мы перешли к следующему шагу мозгового штурма: определению параметров.

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

Нам же важно было определить параметры, которые могут объективно измерить факторы сложности и которые будут универсальны для большинства потенциальных ИТ-проектов.

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

В итоге мы пришли к параметрам, которые отражают величину факторов сложности и являются критериями определения проектов в компании:

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

Поясню: для определения проекта мы выбрали параметр “бюджет” – если его стоимость превышает 10 млн. руб., то выбранную активность потенциально можно отнести к проекту. Однако не все активности дороже 10 млн.руб. являются проектами, и поэтому этот параметр необходим, но его одного будет недостаточно.

А вот такого параметра, как “размер ущерба при нереализации” или “стратегическая значимость”, вполне достаточно одного, чтобы выбранная активность определялась как проект.

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

Чтобы проверить, что наш подход к типизации работает, мы добавили в наш калькулятор 10 потенциальных проектов заказчика: два из них оказались непроектами.

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

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

Мы не рекомендовали использовать калькулятор без принимающего финальное решение о типизации проектов экспертного совета, потому что критерии калькулятора универсальны и в 10-15% случаев механизм может выдать ошибку, если речь идет, например, о нестандартном уникальном проекте.

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

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

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

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

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

Если у вас возникли сложности с методологией управления, записывайтесь на бесплатную 60-минутную “Сессию ясности” здесь.

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