Подводные камни проектной работы
Автор
Альберт Саяпов
Рано или поздно любой ИТ-директор сталкивается с проектом: это может быть внедрение ERP- или BPM-системы, разработка ПО, а то и целой ИТ-стратегии или что-то другое. И далеко не каждый понимает: а с чего же, собственно, начать, как и кем управлять, а главное — что делать при форс-мажорных обстоятельствах, ведь они неизбежны
Рано или поздно любой ИТ-директор сталкивается с проектом: это может быть внедрение ERP- или BPM-системы, разработка ПО, а то и целой ИТ-стратегии или что-то другое. И далеко не каждый понимает: а с чего же, собственно, начать, как и кем управлять, а главное — что делать при форс-мажорных обстоятельствах, ведь они неизбежны.
К сожалению, от неудач в проекте, а порой и полного провала не застрахован никто. Лично я, пережив подобную ситуацию, понял, что мы просто бываем зашорены в своих взглядах: не осознаем, сколько подводных камней можем встретить на пути и насколько бываем зависимы от мнения топ-менеджеров. Через призму неудачи я и хотел бы показать, какие проблемы могут вас поджидать в проектной работе и как их избежать.
Итак, когда мы создавали систему управления проектами в компании, то изучили множество определений, классификаций и ролей. Выбрали то, что нам подходит. На мой взгляд, определение, которое содержит все свойства проекта, дает полноценное понимание, возможно ли отнести ту или иную задачу к проекту.
Проект — уникальный процесс, состоящий из совокупности скоординированных и управляемых видов деятельности, имеющих начальную и конечную даты выполнения, предпринимаемый для достижения цели, соответствующий установленным требованиям, включая ограничения по времени, затратам и ресурсам.
Мне больше подходит определение из ISO 10006 (правда, с небольшими изменениями), нежели из PMBOK.
Проблема номер один
Вы определили задачи проекта, согласовали его со своим руководством (а если вы CIO, то и у гендиректора) и получили добро на разработку концепции. Тут-то и поджидает вас первая проблема. На этапе концепции инвестор (генеральный директор) потребует от вас определения сроков исполнения и стоимость проекта за «всё и сразу». А ведь очень часто эти данные нельзя получить сиюминутно, не проведя дополнительных изысканий, которые тоже требуют финансирования.
Наверное, единственно верным решением менеджера проекта будет деление процесса на две части: разработку технической документации (здесь и проводятся дополнительные изыскания) и его реализацию. В разработку первой войдут создание концепта, технического задания, прототипирование, этапы разработки, календарный план и бюджет. Это поможет вам избежать:
- завышенных ожиданий руководства и инвесторов;
- сократить финансовые затраты на проект;
- провести верную оценку всего проекта;
- в случае необходимости вовремя остановить проект с минимальными финансовыми потерями.
Проблема номер два
Менеджер проекта и команда исполнителей разговаривают на разных языках. Отсюда – «разночтение» ожидаемого результата. С данной проблемой я сам столкнулся, когда занимался разработкой ПО и заказал ТЗ на проект для дальнейшего проведения тендера.
К сожалению, техническое задание, под которым я понимал документ, описывающий пожелания клиента и методы их реализации, код и другие важные вопросы, касающиеся разработки, не «сошлось» с представлениями исполнителя. Ему казалось, что достаточно создать лишь расширенную версию концепции проекта, глубоко описав в ней пожелания клиента. Но это никак не затрагивало таких вопросов, как пути и способы создания самого продукта, а также возможных прототипов.
В результате нам не удалось сделать верную оценку проекта, а уж тем более провести тендер на выбор разработчика (примерная оценка – плюс-минус миллион-полтора для инвестора — шаг назад и закрытие проекта).
В данной ситуации я, как руководитель проекта, не предусмотрел возможного недопонимания и не прописал итоговый результат в договоре (хотя в нем и были учтены некоторое моменты, впоследствии по нашему требованию реализованные исполнителем). В итоге мы получили лишь объемный документ, описывающий наше желание разработать ПО. Мой совет: не стоит обсуждать подобные нюансы устно, поскольку потом никто никому ничего не докажет, так что смело прописывайте все определения в договор или приложение к нему.
Проблема номер три
Неправильно выбран руководитель проекта. На моей памяти история внедрения ERP-системы на предприятии, руководителем которого стал человек, некомпетентный в вопросах внедрения и разработки ПО, к тому же не имевший опыта работы над решениями подобного масштаба. Помимо этого были совершены и другие ошибки, но я считаю, что именно отсутствие компетентного человека у руля стало причиной провала этого проекта.
Отсюда вывод: всегда подбирайте толкового руководителя проекта. А если видите, что проект, запущенный в компании, находится в вашей компетенции, — возьмите на себя ответственность возглавить его. И всегда включайте в работу над проектом людей знающих – профессионал в своем деле не подведет.
Проблема номер четыре
Отсутствие распределения ролей: нет понимания, кто пользователь конечного продукта проекта. Это приводит к тому, что цели и задачи запланированных работ ставятся некорректно. В результате полученный продукт никому не нужен, поскольку у той группы пользователей, которой он предназначался, никто не удосужился спросить: а что же именно им нужно?
После того как вы определили все роли, проведите опрос всех заинтересованных участников проекта, а главное – пользователей, на которых ориентирован конечный продукт. Может оказаться, что их всё устраивает и в данном вопросе ничего нового внедрять не нужно.
Проблема номер пять
Хочется взять большой проект и внедрить всё и сразу! Конечно, люди в большинстве своем максималисты. Но в проектной работе это сыграет с вами злую шутку. Нужно понимать, что инвестиции должны возвращаться как можно скорее. Например, внедрение ERP можно разделить на несколько этапов. Причем каждый этап стоит ранжировать, ответив на вопросы:
- как быстро этот объем может быть внедрен;
- сколько инвестиций потребуется;
- как быстро последует видимый эффект от внедрения.
***
В заключение совет: не стоит автоматизировать хаос, у вас это не получится. Наведите порядок и только потом принимайтесь за автоматизацию тех или иных процессов — проект пойдет гораздо быстрее. А главное – внедряйте то, что быстро окупается! Тогда инвестор вам скажет спасибо.
Надеюсь, мои советы помогут вам эффективнее управлять проектами, а в случае патовых ситуаций – выйти из них с минимальными потерями.
Опубликовано 10.09.2014