Логика управления ошибками управление проектами

Директор по стандартам Американского общества управления проектами Вильям Дункан считает, что проектным менеджерам в любой стране и в любой сфере бизнеса необходимы одни и те же навыки. Формированию этих навыков посвящены тренинги, которые он проводит в России по приглашению компании PSM Consulting

«Все ошибки одинаковы, независимо от страны»

Вильям Дункан – один из авторов первых версий стандарта по управлению проектами PMBoK, разработанного Институтом проектного менеджмента США (PMI USA). Долгое время он был директором этого института. Сегодня Дункан – совладелец и директор компании Project Management Partners, работающей в области консультирования и подготовки по управлению проектами. Свои тренинги он основывает на 30-летнем опыте управления и консультирования.

Дункан разработал «процессную модель» управления проектами, которая была использована при разработке международного стандарта ISO 10006. Он также сформулировал модель корпоративной культуры управления проектами. Согласно этой модели, каждая организация, которая стремится быть успешной в проектной деятельности, должна отвечать трем условиям: работать с перспективными проектами, создавать среду, в которой у большинства проектов будет шанс на успех, и содействовать проектным командам в выполнении работы.

– В чем специфика вашего подхода к управлению проектами?

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

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

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

Кроме того, существование международного стандарта позволит не проходить сертификацию проектным менеджерам при перемещении из одной страны в другую.

– Каковы основные ошибки управления проектами в России?

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

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

Многие проектные менеджеры, отвечая на вопрос о цели проекта, говорят, например: «Наша задача – построить завод». Но, по сути, они не называют реальной цели – зачем им этот завод. А если ты не понимаешь назначения проекта, ты автоматически принимаешь неверные решения.

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

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

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

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

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

В итоге компания начнет искать пути сокращения расходов на выполнение проекта. Скорее всего, это будет происходить за счет изменения характеристик продукта.

А это уже третья ошибка управления проектом. Многие менеджеры стремятся в первую очередь не выйти за рамки бюджета и соблюсти сроки, но не следят за качеством продукта. Один из моих клиентов так и говорил: «Я не понимаю, зачем улучшать управление проектом, если нам и так удается его выполнить вовремя».

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

Например, напротив нашего офиса стоит здание, которое возвели совсем недавно, но уже видно, что при строительстве старались сэкономить. В результате у них уже отвалилась кровля, хотя прошел всего год.

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

«Это все равно что учить грамоте»

– Как за короткий срок научить человека управлять проектами?

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

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

– Но ведь все проекты разные. Как можно все свести к единому алгоритму?

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

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

– Какие стадии развития проекта вы разбираете?

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

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

«Мы моделируем не проблемы, а реальные ситуации»

– Как имитировать реальную обстановку для участников тренинга?

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

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

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

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

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

Источник: mybiz.ru

Ткаченко Елена

Логика управления проектами

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

2. У
   проекта обязательно имеются одна
   или несколько целей.

3. Достижение
   целей проекта может быть реализовано
   различными способами. Для сравнения
   этих способов необходимы критерии
   успешности
   достижения поставленных целей.

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

5. Запланированные
   цели
   и качество
   служат основными ограничениями при
   рассмотрении и оценке различных
   вариантов.

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

7. К
   основным рычагам управления можно
   отнести ресурсы
   проекта и используемые технологии.
   Кроме этих основных существуют и
   вспомогательные средства, предназначенные
   для управления основными. К таким
   средствам можно отнести контракты и
   организацию работ.

Жизненный цикл проекта и фазы проекта

Начало
жизненного цикла проекта совпадает по
времени с началом проекта, а его окончание
– с завершением проекта.

Наиболее
традиционным является разбиение проекта
на
четыре крупных этапа:
разработка
концепции проекта(постановка), планирование
(разработка), реализация(исполнение) и
завершение(закрытие проекта) (рис. 1).

Рисунок
1 – Жизненный цикл проекта

1. Концепция проекта.

Разработка
концепции проекта, по существу
подразумевает функцию выбора проекта.

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

2. Разработка (Планирование).

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

Что
надо сделать?

Кто
сделает это?

Как
это будет сделано?

Когда
это должно быть сделано?

Сколько
это будет стоить?

Что
нам нужно чтобы сделать это?

Именно
на этапе планирования используются
компьютерные системы для управления
проектами, предоставляющие руководителю
проекта набор средств для разработки
формального плана.

Как
правило, план проекта не остается
неизменным, и по мере осуществления
проекта подвергается постоянной
корректировке с учетом текущей ситуации.

3. Реализация (Осуществление).

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

На
правильном ли мы пути?

Если
нет, что нужно сделать?

Следует
ли изменить план?

4.
Завершение.

Рано
или поздно, но проекты заканчиваются.
Проект заканчивается, когда достигнуты
поставленные перед ним цели.

Что
сделано хорошо?

Что
следовало бы улучшить?

Что
мы узнали нового?

Процессы
управления проектами

Для
реализации различных функций управления
проектом необходимы действия, которые
именуются процессами
управления проектами.

Процессы
управления проектами могут быть разбиты
на шесть основных групп (рис. 2):

1.
процессы инициации;

2.
процессы планирования;

3.
процессы исполнения

4.
процессы анализа;

5.
процессы управления;

6.
процессы завершения.

Рисунок
2 – Процессы управления проектами

Процессы
инициации

Данный
процесс представляет собой принятие
решения о начале выполнения проекта.

Процессы
планирования

Процесс
определения целей и критериев успеха
проекта и разработка рабочих схем их
достижения

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

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

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

Процессы
планирования представлены
на рисунке 3.

Рисунок
3 – Процессы планирования

Этапы
планирования

1. Разработка
   формулировки миссии, целей и задач
   проекта.

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

Заказчик
проекта
– главная сторона, заинтересованная в
осуществлении проекта и достижении его
результатов.

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

Формулировка
миссии должна отвечать на три вопроса:

Что
мы делаем?

Для
кого мы это делаем?

Как
мы делаем это?

Когда
формулировка миссии разработана, можно
определить цели проекта. Цели намного
более конкретны, чем миссия.

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

Два
важных вопроса при установлении целей:

Каков
желаемый результат?

Как
вы узнаете, когда достигли желаемого
результата?

В этой статье расскажем как команда Alto справляется со срывами сроков. Материал будет полезен руководителям, менеджерам проектов и всем, кто испытывает трудности с соблюдением дедлайнов.

Согласно исследованию компании Hewlett-Packard 96% IT-проектов в России завершаются не вовремя. Это одни из самых низких показателей в Европе. В то время как в Швеции этот показатель равен 64%. Когда такое количество проектов срываются по срокам, вы начинаете искать решение этой проблемы.

Первое, что необходимо понять — любая задача относится или к проектам или к процессам. Процессы — это повторяющиеся процедуры. Тогда как проекты — это запуск новых продуктов. Например, проект — это разработка сайта или запуск веб-приложения. А процесс — обработка входящих заявок с сайта.

Процессы выполняют по инструкции с минимальными изменениями. Например, алгоритм работы может выглядеть так:

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

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

Мы в Alto еще не нашли волшебную таблетку для решения этой проблемы. Скорее всего её и не существует. Как и нет в мире такой компании, где все проекты заканчивают вовремя. Проектная работа — это хаос. Поэтому все что нужно — это понять, как работать среди этого.

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

Причины по которым команды срывает сроки:

1. Ошибки при оценке задач

Человеку свойственно быть оптимистичным при оценке задач. Даже если эта оценка основана на прошлом опыте. Например, если последняя задача заняла 24 часа. Сотрудник подумает, что в этот раз сможет сделать аналогичную задачу за 22 часа. Опираясь на идею, что теперь у него больше знаний и опыта. На практике этот оптимизм часто приводит к срыву срока.

Причины оптимистичны оптимистичной оценки включают:

Как давать реалистичную оценку

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

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

Метод 1. Оценка по трем точкам

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

Для оценки по трем точкам есть формула:

Метод 2. Декомпозиция.

Этот подход требует, чтобы вы оценивали каждую отдельную задачу, а затем объединяли в общую оценку. Главное преимущество декомпозиции в том, что она укрепляет уверенность сотрудника в сроках.

Метод 3. Создание резервов.

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

Есть несложная формула, как рассчитать резервы.

Рассмотрим на примере. Представьте, что у вас на проекте есть риск того, что заказчик затянет согласование дизайна. Вы анализируете, какое влияние имеет этот риск. Допустим, на согласование уходит 3 дня. Вероятность, что заказчик затянет согласование – 30%. Это ваша экспертная оценка, которая опирается на ваш опыт. Если это случится, тогда повышается вероятность сорвать сроки. Используя формулу, получаем:

Резерв = 30% х 72 часа = 21,6 часа

Получается, что на этот риск можно заложить 22 часа.

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

Именно поэтому рисков должно быть много — хотя бы 20. Если у вас будет 2-3 риска, то резервов не хватит, чтобы все компенсировать.

2. Ошибки при управлении изменениями

Каждый кто работал с digital-проектами сталкивался с ситуацией, когда клиент просит внести незапланированные правки. При этом аргументируя это тем, что здесь работы на 10 минут. В итоге таких правок за время проекта может быть сотни. Как результат этого — просроченный дедлайн.

Решение проблемы:

Проговорите какой объем изменений на проекте возможен. Например, определите количество итераций дизайна или допустимое отклонение по часам без изменения срока.

Убедитесь, что клиент понимает, как это будет выглядеть на практике. Для этого объясняйте на примерах, а также фиксируйте все в договоре. А именно пропишите количество дополнительных правок, которые доступны клиенту. Обычно хватает 2-3 итерации правок.

Это значит, что клиент должен собрать как можно больше правок при каждой итерации. Например, в первом письме попросил изменить цвет кнопок, а через 4 дня прислал еще письмо с правками для карточки товара. В этом случае это будут две разные итерации правок.

Все что клиенту нужно сделать, так это собрать все эти правки в одном письме. Только тогда это считается одним циклом правок. Поэтому объясните клиенту, что их письма с правками должны быть как можно более объемными..

3. Проблемы в коммуникации и ожиданиях

Представьте себе следующий разговор с программистом:

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

Как правильно сообщить об ожиданиях

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

Вот три способа как можно проверить, что ваша команда понимает свои сроки.

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

Если вы ставите задачи в мессенджере или через почту, то ее легко могут забыть, посчитать неважной или неверно истолковать ваши слова. Например, если вы напишите: «Мне нужно сделать это к концу недели». Сотрудник может воспринять это как просьбу, а не как жесткий крайний срок.

Именно поэтому рекомендуем вести все задачи в сервисе для управления проектами.

Мы в Alto используем Trello. Она интуитивно понятная и при определенных настройках позволяет фиксировать время на задачу, показывать отчеты.

Способ 2. Получите обратную связь

Это самый простой способ убедиться, что вас правильно поняли. Для этого попросите сотрудника повторить обозначенный срок.

Давайте пересмотрим приведенном выше диалог с учетом этого способа.

В итоге вы бы сразу узнали об этом до того, как сроки будут сорваны.

Способ 3. Внедрите периодические проверки

Добавьте периодические проверки в свой график. Так вы достигнете двух целей:

Это поможет вам выявить потенциально слабые места и не прибегать к микро-управлению вашей командой.

4. Ошибки при подготовке к проекту

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

Давайте рассмотрим, какие могут быть ресурсы проекта.

5. Недостаточная компетенция исполнителей

По данным отчета The Boston Consulting Group (BCG) почти 45% сотрудников в России не соответствуют занимаемой ими должности. В США этот показатель равен 33,5%, а в Германии — 37,2%.

Задача руководителя в этой ситуации — подбирать специалистов соразмерно задаче или наоборот. То есть менеджер должен сопоставить сложность проекта и возможности исполнителя.

Что делать если сотруднику не хватает компетенций:

6. Демотивация команды

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

Персональная демотивация

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

Давай разберем несколько ситуаций

Здесь можно найти решение если рассмотреть несколько смысловых слоев. На первом человек говорит про Битрикс и Node.js. На втором смысловом слое — хочет попробовать новое. Поэтому если хотите замотивировать этого сотрудника — дайте возможность сделать что-нибудь новое. Если такой возможности нет — создайте. Придумайте небольшой проект, где такая возможность появится

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

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

Командная демотивация

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

Когда вам дают проект длиною в год — это демотивирует. Здесь легко потерять заряд энергии, который у вас был в начале проекта.

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

Итог кратко

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

Если вы научитесь их предсказывать — это 95% успеха. Остальные 5% — это внешние обстоятельства, на которые мы не всегда можем повлиять.

Напоследок оставим несколько полезных ссылок:

Последние публикации:

Число ошибок растет как снежный ком. Большая часть из них объясняется недостатками планирования или сбоями в процессе организации взаимодействия (между отдельными участниками проекта или проектной командой и ее спонсорами). Ошибки могут привести и к фатальному исходу. С другой стороны, имеется возможность их избежать. И кому, как не поставщикам решений и консультантам по вопросам управления проектами, лучше других должны быть известны наиболее распространенные ошибки. (Им же следует и предложить пути выхода.)

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

Просчеты, связанные с персоналом

Ошибка № 1: Проекту не хватает ресурсов и квалифицированных исполнителей.

Проявление: Наличие квалифицированных исполнителей имеет критически важное значение. Наряду с этим в числе наиболее существенных ошибок, связанных с управлением проектами, следует отметить неверное распределение ресурсов. Отсутствие грамотных специалистов может погубить проект. «Ключевое условие успешной реализации проекта — тщательный подбор людей, обладающих требуемой квалификацией, — отметил Джоэл Коппельман, генеральный директор компании Primavera, специализирующейся на разработке программного обеспечения управления проектами. — Решение даже самых нужных и важных задач по организации планирования не может застраховать нас от дефицита талантов».

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

«Существует масса организационных моделей, — отметил Ричард Скэннелл, один из основателей компании GlassHouse Technologies, предоставляющей консультационные услуги, связанные с построением ИТ-инфраструктуры. — Но я никогда еще не видел, чтобы хорошо работало абсолютно все. На вопросы, касающиеся распределения ресурсов, к сожалению, не существует простого ответа».

«Необходимо добиваться синхронизации проектов и человеческих усилий, — считает Коппельман. — Одним из возможных выходов здесь может стать учреждение должности менеджера по распределению ресурсов между проектами, который будет отвечать за справедливую привязку специалистов требуемого уровня квалификации к тому или иному проекту».

Скэннелл предлагает формировать «команды тигров», члены которых освобождаются от своих традиционных обязанностей на год или больше ради участия в конкретном проекте. Кен Чени, директор центра HP Software’s PPM Center, рекомендует распределять ресурсы на уровне проекта, не опускаясь до конкретных задач, поскольку сделать это гораздо труднее.

Если у вас возникают трудности с поиском квалифицированных исполнителей для реализации проектов, можно попытаться освободить ресурсы, отказавшись от тех из задач, которые не связаны тесно со стратегией ведения бизнеса. Имеет смысл оценить целиком портфель проектов, над которым трудятся сотрудники ИТ-службы, выделив компоненты, имеющие критически важное значение. «Приостановив выполнение этих проектов и перераспределив ресурсы в пользу тех задач, которым отводится более существенная роль, вы добьетесь более весомого успеха для организации в целом», — подчеркнул Чени.

Ошибка № 2: Нехватка опытных руководителей проектов.

Проявление: При отсутствии грамотного руководителя проекты могут быстро выйти из-под контроля.

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

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

Процедурные ошибки

Ошибка № 3: Управление проектами осуществляется при отсутствии стандартных, повторяющихся процедур.

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

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

Дуглас Кларк, генеральный директор компании Metier, поставляющей решения в области управления портфелями проектов, для определения содержания и границ проекта, сроков выполнения его отдельных этапов, порядка распределения ресурсов и взаимодействия с заинтересованными лицами рекомендует использовать повторяющиеся процедуры. «Этими вещами следует заняться в первую очередь, потому что именно
от них вы сможете получить наибольшую отдачу», — пояснил он.

Ошибка № 4: Слишком большое число процедур, ограничивающих ваши возможности.

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

Фуми Кондо, управляющий директор консультационной компании Intellilink Solutions, однажды была свидетелем интересного разговора между разработчиком программ и руководителем проекта. Разработчик заявлял, что функционал приложения можно расширить, не прилагая никаких дополнительных усилий. Руководитель проекта убеждал разработчика не добавлять никаких новых функций, потому что пользователи об этом не просили. «Тогда я посоветовала им следующее: ступайте к пользователям и посмотрите, действительно ли им нужны эти функции, — вспоминала Кондо. — Не вижу ничего плохого в том, чтобы предоставить клиентам больше того, что они ожидают, если при этом вы не выходите за рамки бюджета и установленных сроков».

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

Ошибка № 5: Изменения не соответствуют содержанию и границам проекта.

Проявление: Бюджет проекта устойчиво растет. То же самое происходит и со сроками.

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

Ошибка № 6: Отсутствие актуальной информации о состоянии проектов.

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

Решение: Программное обеспечение.

Ошибка № 7: Игнорирование возникающих проблем.

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

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

Планируемые недочеты

Ошибка № 8: Игнорирование необходимости определения содержания и границ проекта.

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

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

Ошибка № 9: Отсутствие понимания зависимостей, существующих между проектами.

Проявление: Проекты не существуют в изоляции. Как правило, они связаны с другими проектами, которые реализуются параллельно. И когда руководители проектов допускают просчеты при оценке зависимостей между различными задачами (например, если специалисты, принимающие участие в реализации одного проекта, вдруг срочно нужны для выполнения других работ), возникают задержки. Подобные простои могут негативно повлиять на все проекты.

Решение: При планировании реализации проектов необходимо учитывать зависимости между ними. А раскрыть эти зависимости вам поможет общение с заинтересованными лицами и диаграммы, описывающие ход реализации проектов.

Ошибка № 10: Игнорирование законов Мерфи.

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

Одна из фирм, вошедших в состав компании GlassHouse Technologies, решила перенести свой мэйнфрейм в новый центр данных. Всю субботу ИТ-группа занималась разборкой мэйнфрейма, чтобы на следующий день переместить его в новый ЦОД. А когда в воскресенье сотрудники ИТ-службы занялись перевозкой, на пути у них выросли участники гей-парада, перекрывшие все возможные выезды. Обойти их не было никакой возможности. Пришлось возвращаться в старый ЦОД и начинать все сначала. Недостатки планирования привели к тому, что персоналу ИТ-службы пришлось выполнить гораздо больший объем работ, чем предполагалось изначально.

Решение: В рамках планирования проекта проведите оценку рисков. С помощью мозгового штурма, в котором должны участвовать члены вашей команды, постарайтесь выявить факторы, мешающие реализации проекта или замедляющие ее ход, заставляющие расширять рамки ранее определенного бюджета, а также препятствующие выполнению сформулированных требований. Затем продумайте способы снижения указанных рисков. «Остановившись на некоторое время и оценив существующие риски, можно составить весьма полезный список, — заметил Коппельман. — Это не займет много времени, но зато поможет получить представление о возможных подводных камнях, прежде чем они возникнут на вашем пути».

Ошибка № 11: Дефицит времени, выделяемого на управление изменениями.

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

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

Ошибка № 12: Незавершенность графика проектов.

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

Решение: По мнению Кларка, самый быстрый способ составить график проекта — это определить все необходимые мероприятия (содержание и границы проекта, предъявляемые к нему требования, процедуры тестирования и внедрения) и конкретные сроки их выполнения в соответствии с окончательными сроками реализации проекта. Составить такие графики вам поможет программное обеспечение управления проектами.

Проблемы взаимодействия

Ошибка № 13: Нереальные сроки проекта, которые ИТ-специалисты не в состоянии изменить.

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

По словам Кларка, представители ИТ-служб прилагают немалые усилия, для того чтобы привести сроки, установленные генеральным директором, в соответствие с реальностью. Однако все их усилия порождают лишь новые осложнения и еще больше затрудняют реализацию проекта в заданные сроки.

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

Ошибка № 14: Недостатки взаимодействия со спонсорами проекта и заинтересованными в его реализации лицами.

Проявление: Предложенная техническая реализация не отвечает ожидаемым требованиям.

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

«Возможна также ситуация, при которой одна из сторон в процессе взаимодействия изъясняется на языке, совершенно непонятном другой стороне, — заметила Кондо. — В конце концов раздосадованные ИТ-специалисты восклицают: “Но ведь мы обо всем этом говорили. Почему же полученный результат не удовлетворяет конечного пользователя?”»

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

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

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

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

«Мы говорили о различных подходах к тестированию, о вариантах с привлечением представителей клиента и без, — вспоминала Кондо. — Мы разъясняли, почему так важна обратная связь с пользователями, какой должна быть входная информация и сколько времени потребуется на ее ввод. В результате люди поняли, почему процесс тестирования отнимает так много времени».

Meridith Levinson. The 14 Most Common Project Management Mistakes. CIO.com. 07/23/2008

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

Ошибка №1: Вы выбрали не того project-менеджера

Бывает, что на этапе распределения обязанностей большинство усилий уходит на поиск исполнителей проекта, а не его руководителя. Менеджера зачастую отбирают по
критерию
«свободен от поручений», а не «подходит по компетенциям». Таким образом, неверно выбранный или не имеющий необходимого опыта руководитель может
запросто
загубить полученный проект.

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

Ошибка №2: В вашей команде отсутствует мотивация

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

Решение: Project-менеджер, в первую очередь, должен собрать всю команду вместе. В том числе и сотрудников, работающих на удаленной основе (с помощью
skype или
других интернет-сервисов). Руководитель обязан подробно рассказать о проекте и выступить перед сотрудниками так, чтобы взбодрить и замотивировать их на усердную
работу.

Ошибка №3: Ваш проект никто не контролирует

«Нет начальника – значит нет постоянного отчитывания. Полная свобода действий» –, можете подумать вы. Как раз это и плохо. Без работы под наблюдением
высшего
руководства нет стимула держать себя в тонусе.

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

Ошибка №4: Вы берете на себя сразу несколько проектов

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

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

Ошибка №5: В вашей команде не налажена коммуникация

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

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

Ошибка №6: У вас нет четкой конечной цели проекта или вы меняете ее в ходе работы

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

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

Ошибка №7: Вы неверно рассчитали время для реализации проекта

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

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

Ошибка №8: Вы не идете на уступки

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

Решение: Посмотрите на проект со стороны. Подумайте, не нужно ли в нем что-то изменить. Это не значит, что нужно постоянно что-то менять – просто будьте
открытыми к
предложениям со стороны, если они пойдут на пользу проекту.

Ошибка №9: Вы не систематично отслеживаете изменения в проекте

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

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

Ошибка №10: Вы руководите каждым шагом своих сотрудников

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

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

Ошибка №11: Вы нечетко распределили обязанности в команде

Важно, чтобы в команде никто не дублировал обязанности другого и выполнял сугубо свою работу. Бывает, что сотрудники, желая помочь, берутся еще и за «не свои»
задачи. В
результате они не только плохо выполняют чужую работу, но и не успевают делать свою.

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

Работая над проектом, представьте, что конкретно сделает его идеальным, и стремитесь именно к этому. Когда вы поймете, что ваш проект все-таки стал самым
масштабным, самым
стильным или самым полезным, вы будете уверены, что все сделали правильно.

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

Если мы не указали еще какую-то ошибку по управлению проектами, которая известна вам, напишите об этом в комментариях и расскажите, как ее можно избежать.