Подводные камни проектной работы. Менеджмент
Авторы Наши партнёры Наши проекты: IT WorldIT-WeeklyIT Contact
IT-Manager Allcio Manager
Вход
X

Логин

Пароль

Запомнить

Забыли свой пароль?

Подводные камни проектной работы

Лента новостейИТ в бизнесеУправление

Подводные камни проектной работы

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

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

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

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

Мне больше подходит определение из ISO 10006 (правда, с небольшими изменениями), нежели из PMBOK.

Проблема номер один

Вы определили задачи проекта, согласовали его со своим руководством (а если вы CIO, то и у гендиректора) и получили добро на разработку концепции. Тут-то и поджидает вас первая проблема. На этапе концепции инвестор (генеральный директор) потребует от вас определения сроков исполнения и стоимость проекта за «всё и сразу». А ведь очень часто эти данные нельзя получить  сиюминутно, не проведя дополнительных изысканий, которые тоже требуют финансирования.

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

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

Проблема номер два 

Менеджер проекта и команда исполнителей разговаривают на разных языках. Отсюда – «разночтение» ожидаемого результата. С данной проблемой я сам столкнулся, когда занимался разработкой ПО и заказал ТЗ на проект для дальнейшего проведения тендера. 

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

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

Проблема номер три 

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

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

Проблема номер четыре 

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

После того как вы определили все роли, проведите опрос всех заинтересованных участников проекта, а главное – пользователей, на которых ориентирован конечный продукт. Может оказаться, что их всё устраивает и в данном вопросе ничего нового внедрять не нужно.

Проблема номер пять 

Хочется взять большой проект и внедрить всё и сразу! Конечно, люди в большинстве своем максималисты. Но в проектной работе это сыграет с вами злую шутку. Нужно понимать, что инвестиции должны возвращаться как можно скорее. Например, внедрение ERP можно разделить на несколько этапов. Причем каждый этап стоит ранжировать, ответив на вопросы: 

  • как быстро этот объем может быть внедрен;
  • сколько инвестиций потребуется;
  • как быстро последует видимый эффект от внедрения.
***
В заключение совет: не стоит автоматизировать хаос, у вас это не получится. Наведите порядок и только потом принимайтесь за автоматизацию тех или иных процессов — проект пойдет гораздо быстрее. А главное – внедряйте то, что быстро окупается! Тогда инвестор вам скажет спасибо.

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

Теги: управление проектами, контроль качества, мотивация, практики, командообразование

Журнал IT-Manager № 08/2014    [ PDF ]    [ Подписка на журнал ]

Об авторе

Альберт Саяпов

Альберт Саяпов

ИТ-директор ресторанного холдинга Welcome Group


мероприятия

| 07.12.2017
XIII Пиринговый форум

Краснопресненская наб.,12.

Также смотрите

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

Журнал IT-Manager: № 09/2017

Последние новости

Фоторепортажи

Мероприятия

<<<< Ноябрь >>>>
Пн Вт Ср Чт Пт Сб Вс
303112345
6789101112
13141516171819
20212223242526
27282930123