Нарушаем законы ведения проекта? Результат предсказуем!

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

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

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

Работы сдаются отдельно, а завершение проекта и подписание актов должно идти по общему результату. Как говорится, “к пуговицам претензии есть?” А вот к целому костюму, почему-то есть.Клиента такой подход тоже сильно напрягал, поскольку ему нужно постоянно взаимодействовать с несколькими независимыми исполнителями по каждому участку работ, а руководитель проекта периодически недоступен.

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

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

Слегка поругались с клиентом, поскольку ни он сам ни исполнители до конца не поняли кто что должен делать, и кто за что отвечает (мы помним, что руководитель проекта разрывался сразу между несколькими важными проектами). И при подписании актов все эти разногласия вылезли наружу. А я еще раз убедился в том, что законы ведения проектов одинаковы для всех, независимо от величины, и если их нарушать, то, как я уже писал здесь>>, вероятность неудачного исхода повышается многократно.

Оставить комментарий

Ваш email не будет опубликован. Обязательные поля отмечены *

Вы можете использовать это HTMLтеги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>