Ваш браузер устарел. Рекомендуем обновить его до последней версии.

КАТЕГОРИИ


 

Эффективность

-----------------------

Карьера

-----------------------

Руководителям

-----------------------

  

Изображение средств диагностики

Проверка уровня проектного управления. Диагностический инструмент для проектных команд.

БЕСПЛАТНО

 

 

Изображение коробки вводного курса Управления проектами

Управление проектами.

Вводный курс.

БЕСПЛАТНО

 

 

Заставка мастер-класса "Управление ожиданиями"

Управление ожиданиями клиента.

Мастер-класс (видео).

БЕСПЛАТНО

 

 

Факторы успеха IT проектов

Новогодняя акция. Скидка на обучающие курсы.

Факторы успеха IT проектов

Опубликовано 05.09.2014

Если по окончании неуспешного проекта попытаться выяснить причины неудачи, вы получите список очень конкретных событий, которые помешали воплощению ваших замечательных планов. Например: заказчик в середине проекта изменил требования, заболел ведущий разработчик, подрядчики подвели и т.п. Разнообразие уникальных причин затрудняет их систематизацию и устранение. Создается впечатление, что это сплошной форс-мажор, с которым ничего нельзя сделать. Некоторые дыры затыкаются, но как говорится: "на каждый чих не наздравствуешься". А поскольку трудно понять, что нужно изменить в процессе, последующие проекты продолжают давать не самые лучшие результаты. Эта статья поможет понять, что больше, а что меньше влияет на успех и провалы проектов. Это позволит сконцентрировать внимание и ресурсы на более значимых факторах улучшения вместо того, чтобы тратить деньги и время впустую. 

Что означает "успешный проект" 
Прежде чем говорить об успехе следует определиться в том, что называть успешным проектом. Я встречал компании, в которых успешными считаются все проекты, на которых удалось заработать. В других - критерием успешности является установленная норма прибыли. В-третьих - соблюдение сроков и бюджета. В четвертых - решение поставленной бизнес-задачи. В статистических опросах встречается даже такой вариант успешности проекта: "принес удовольствие всем участникам". Я буду считать критерием успешности следующую обобщающую формулировку: Достижение цели проекта в рамках согласованных ограничений. Поскольку целями проекта может быть что угодно: достижение определенного ROI, создание инструмента, улучшение обслуживания клиентов и т.п., будем считать, что в ходе проекта все эти цели превратили в требования к функциональности. Проекты, которые превысили бюджет, опоздали по срокам или не поставили требуемый функционал, условно назовем "проблемные". Откровенно провальными будем считать проекты, которые были остановлены или были доведены до конца, но их результаты не были использованы. 
Исследования Standish Group, основанные на анализе 50000 проектов показывают следующую статистику:

Показательно, что за последние 8 лет процент успешных проектов вырос всего на 10%, а доля провальных проектов практически не изменилась. 


Что отличает успешные проекты 
Самый главный фактор - размер проекта. Если мы посмотрим, какой вклад в вышеприведенную статистику вносят крупные проекты, мы получим следующую картину: 
 

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

  1. Поддержка спонсора проекта. Спонсор или владелец проекта - это не должность. Это роль, которая, как правило, предполагает полномочия выделения ресурсов на проект и ответственность за его результаты для бизнеса. Это человек - принимающий стратегические решения для проекта.
  2. Вовлеченность пользователей. Пользователи - это те, кто будет использовать продукт или решение, которое является результатом проекта. Под вовлеченностью имеется в виду фокусирование на реальных и наиболее значимых потребностях пользователя. Для этого нужно правильно идентифицировать ключевых пользователей, наладить хорошие отношения и коммуникацию с ними, регулярно получать обратную связь.
  3. Оптимизация объема работ. Имеется в виду грамотная оценка и правильная приоритизация. Здесь опять же важен предыдущий фактор. Из нижеприведенной диаграммы видно, что примерно половина всей создаваемой функциональности обычно оказывается не нужна пользователям:

     4.  Квалифицированная команда.

     5.  Профессионализм руководителя проектов. Его способности, знания и практический опыт.

     6.  Гибкий процесс. В небольших проектах чаще используются Agile подходы, однако, как мы видим, в данном случае, выбор методологии не особо влияет на результат:

 

 

      7.  Ясные бизнес-цели. Команда должна быть сфокусирована на них.

      8.  Эмоциональная зрелость команды (включая спонсора и руководителя проекта). Это способность контролировать свои эмоции, общаться в позитивном ключе.

      9.  Администрирование. Правила, формальные требования, отчетность, финансовый контроль и т.п.

    10.  Инструменты и инфраструктура. В эту категорию включены управление ресурсами, управление требованиями, управление портфелем проектов, управление качеством, ПО управления и разработки.


Если присмотреться, то этот список состоит из двух типов факторов, которые условно можно назвать: "люди" и "обстоятельства". К первому типу я отношу влияние спонсора и руководителя проекта, а ко второму - все остальные. Конечно, если смотреть на обстоятельства, как на некую данность, в условиях которой приходится работать, то такое построение факторов в один ряд - может быть оправдано. Однако, одно из качеств хорошего руководителя - проактивность. Он не плывет по течению, он влияет на обстоятельства или формирует их. Вот что я имею в виду, рассматривая каждый из вышеприведенных факторов в отдельности: 

Фактор

"Обычный" PM

Хороший PM

1

Работает самостоятельно, не отвлекая руководство от более важных дел. Отправляет требуемые отчеты.

Рассматривает спонсора проекта, как высокооплачиваемого члена команды. Вовлекает его в принятие важных решений. Управляет его ожиданиями. Договаривается и передоговаривается.

2

Не лезет к пользователям, после того, как с них сняты показания требования. Любое их вмешательство, расценивает как помеху проекту. Из способов общения предпочитает переписку. Если никто не требует, доставку делает только в конце проекта.

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

3

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

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

4

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

Знает плюсы и минусы каждого сотрудника. Учитывает не только квалификацию, но и стоимость каждого специалиста. Недостаток квалификации учитывает, как риск и управляет им. Развивает членов своей команды,  даже если команда непостоянная.

5

Считает себя достаточно квалифицированным. Ошибки совершает редко и только малозначительные. Героически "тушит пожары". Много работает сверхурочно. По этой причине не имеет времени на чтение  профессиональной литературы и пр.

Считает себя недостаточно квалифицированным. Постоянно прокачивает себя, читает книги, обучается, перенимает опыт коллег. Ищет причины своих ошибок в себе, делает выводы и не повторяет ошибок.

6

Использует принятый в компании подход к разработке.

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

7

Считает целью проекта: сделать фичи и заработать денег. Целью каждого члена команды - хорошо сделать свои таски.

Понимает какую бизнес-проблему необходимо решить. Решает ее. Доносит проблему и суть решения, до каждого члена команды.

8

Если не может найти общий язык с человеком - считает его дятлом. Умеет заставить себя слушать. Вежлив со всеми. В случае личностного конфликта в команде - переадресует его руководителю или HR.

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

9

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

Принимает участие в формировании действующего порядка.

10

Использует те инструменты, которые приняты в компании.

Использует те инструменты, которые соответствуют решаемой задаче. Способствует внедрению более эффективных инструментов.



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


Использованные источники: 
Standish Group. Chaos Manifesto 2013 
Плетенев А.П. Курс "Практическое управление проектами"

 


* Поскольку в данном случае денежный показатель используется для отражения объема работ и сложности проекта, для Российских проектов можно считать аналогично крупными проекты с трудозатратами порядка 10 млн. руб.