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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об авторе


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

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

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


ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru


Другие материалы рубрики

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

Мероприятия


01.11.2016 — 03.11.2016
Десятый релиз международной выставки ProAV технологий Integrated Systems Russia 2016 состоится в Москве, в центральном выставочном комплексе «Экспоцентр», с 1 по 3 ноября. Юбилейный проект обещает быть насыщенным не только с точки зрения инновационных технологий и решений, которые представят ведущие мировые производители, российские дистрибьюторы и интеграторы, но и с точки зрения новых проектов и деловой программы.