Дутые бюджеты, утраченные спонсоры, сбои в работе средств связи, изменение требований — вот лишь некоторые сюрпризы, способные провалить проект или донельзя усложнить его исполнение. У каждого руководителя проекта есть своя история о том, как ему пришлось выпутываться из безвыходного положения
Однако каждый кризис дает возможность для роста. Менеджеры проектов утверждают: «Чем жестче окажется урок, тем лучше он усваивается». Четыре менеджера, пожелавшие остаться неизвестными, рассказали нам свои поучительные истории, надолго запомнившиеся их героям.
Потеря бдительности
Проект. Крупная компания, специализирующаяся на услугах в области информационных технологий, заключила договор с государственной организацией на выполнение весьма серьезного проекта в области логистики. Участвовали около 60 человек.
В чем была ошибка? В ходе согласований сотрудники компании-подрядчика тщательно рассчитали стоимость работ, с тем чтобы выполнить задание в срок и получить прибыль. Стоимость примерно на 14% превышала сумму, выделенную правительством, однако людям, которые вели переговоры, было тем не менее поручено ее объявить.
Без ведома менеджера проекта сотрудники коммерческого отдела сократили число участников проекта и за счет этого предложили новую, уменьшенную сумму.
Главная проблема. «День нашего торжества стал одновременно и самым черным днем в моей жизни, — вспоминает менеджер проекта. — Мы отстояли сумму и были в восторге от того, что получили этот солидный проект. Позже, когда все успокоились, я прочитал то, что мы представили на самом деле, и понял, что сделать это не смогу. С тем количеством людей, которых мне предписывалось привлечь в соответствии с контрактом, поставленные задачи были недостижимы!»
Что было дальше? «Надо было что-то делать, — вспоминает он. — Принять удар на себя, работать без прибыли или даже в убыток себе, зато достичь поставленной цели и снискать уважение клиента? Или же попробовать как-то выпутаться из создавшегося положения?»
Фирма-подрядчик приняла решение увеличить расходы на персонал в соответствии с исходными расчетами, при этом отказавшись от прибыли. К счастью, в дальнейшем клиент выдвинул дополнительные требования, что позволило менеджеру проекта обосновать привлечение «лишних» людей, клиент же пошел на увеличение расходов, благодаря чему проект все же принес компании небольшую прибыль.
Мораль. «Менеджер проекта отвечает за весь проект от начала и до конца, — резюмирует наш собеседник. — Если он на какой-либо стадии перестал контролировать процесс, как произошло со мной, его может ждать большой сюрприз».
Ошибки в расчетах
Проект. Входящая в список Fortune 100 компания, производящая товары массового спроса, решила разработать стандартный комплект бизнес-приложений для головного офиса, совместимых с 2000 годом, для объединения информации, собираемой в пяти странах Европы. Участвовали 200 человек.
В чем была ошибка? Несмотря на попытки учесть культурные особенности региона, возникли проблемы из-за американских стереотипов в отношении Европы. «Я всегда полагал, что Европа — место, где смешались многие национальности, однако на деле никакой Европы не существует, — говорит менеджер проекта. — Есть отдельные страны, в определенные исторические периоды не ладившие друг с другом».
Попытки стандартизировать систему превратились в задачу, не имеющую решения. «В ходе процесса согласований мы не смогли обнаружить ничего, что объединяло бы все без исключения страны», — комментирует наш собеседник.
Проект финансировался и осуществлялся в большей степени специалистами по ИТ, чем предпринимателями, и предприниматели, как утверждает менеджер проекта, по-настоящему не вникли в проблему.
Кроме того, в критический момент спонсор из отдела ИТ покинул компанию.
Сотрудники проекта постоянно курсировали между США и Европой. Подобная нагрузка на работников и членов их семей привела к частым увольнениям.
Главная проблема. «Черным для нас стал день, когда мы узнали, что наш спонсор по ИТ, который владел целостной картиной проекта, уходит из компании», — рассказывает менеджер проекта.
Что было дальше? В конце концов, системы разных стран были объединены, Новый год встречен без неприятностей и проект имел огромный успех. Однако достичь более высокого уровня стандартизации так и не удалось, а расходы, если учитывать человеческий фактор, оказались непомерно высоки.
Мораль. Вывод первый касается ошибок в расчетах. «Одной осведомленности о существовании культурных особенностей недостаточно! Этот фактор должен учитываться при управлении коллективом, — считает менеджер проекта. — Единственное, что может объединить различные европейские культуры, — американец, который расскажет, как надо действовать».
Вывод второй — спонсоры рождаются из предпринимателей, и говорить с ними нужно языком управленца, а не языком графиков, диаграмм и таблиц.
И наконец, вывод третий — отнеситесь как можно более внимательно к своим сотрудникам.
Недопонимание ведет к провалу
Проект. Крупная торговая компания приобрела начинающую фирму с целью создания своего представительства в Web. 20 сотрудникам из двух компаний предстояло интегрировать базовую систему на мэйнфрейме и бизнес-средства Web.
В чем была ошибка? Группа из торговой фирмы и Web-команда оказались разделены как географически, так и идеологически. «Они работали с устаревшей системой на мэйнфрейме. У них практически не было опыта Web-разработок, — поясняет менеджер Web-проекта. — У нас же не было опыта работы с большими машинами».
Налаживание эффективного взаимоотношения «стало первой трудностью, с которой мы не смогли справиться», — продолжает наш собеседник. В итоге — разочарование от результатов совместной работы.
Обсуждение технических требований прошло гладко, и стороны разошлись писать свою часть кода. Однако менеджер проекта вспоминает: «Люди из Web-проекта были очень загружены, а мы не удосужились взять на себя часть работы».
Это стало очевидно за два дня до начала совместного тестирования. Тогда-то и разразился гром. «Коллеги прислали тетрадку с записями на Cobol, мы не могли поверить своим глазам», — вспоминает менеджер проекта. В тетрадке описывался формат файла для мэйнфрейма, очень сильно отличавшийся от того, о котором, по мнению сотрудников Web-проекта, шла речь шестью неделями ранее.
Главная проблема. «Мы были буквально потрясены, узнав перед тестированием, что практически не продвинулись вперед», — говорит менеджер проекта.
Что было дальше? Достигнут компромисс, в результате которого обе стороны внесли определенные изменения в свою работу. «Переговоры не были долгими, — говорит менеджер проекта, — поскольку и они и мы понимали, что шестью неделями ранее не задали друг другу принципиально важных вопросов».
Мораль. Будьте очень-очень осторожны в общении. «Всегда задавайте вопрос дважды, — рекомендует наш знакомый. — Будьте настойчивы, старайтесь найти общий язык с коллегами».
Опасность нечетких требований
Проект. Надо было произвести обычное конвертирование файлов в системе подсчета дохода с продаж, которое позволило бы автоматически извлекать данные из поступающих файлов и отправлять в другие системы, в частности, системы подготовки отчетов и поддержки принятия решений. Проект был рассчитан на три месяца при участии пяти человек.
В чем ошибка? Ошибочными были все требования к проекту. Это сразу же стало ясно, как только система подготовки отчетов в поисках фрагментов информации обратилась к полям данных, которых не было в поступающих файлах. Группе надо было создать целые подсистемы для извлечения данных и правильного их форматирования.
Однако, когда дело дошло до выработки новых требований, коллектив превратился в строителей Вавилонской башни. Поскольку никто не мог правильно задокументировать требования, они постоянно менялись и объем работ возрастал с каждым днем. «Простой» проект, который предполагалось сделать впятером за три месяца, в конце концов растянулся на год с лишним и потребовал усилий 30 человек.
Главная проблема. Роковым оказался день предполагаемого завершения проекта. Одна часть системы должна была обрабатывать ежедневную выручку клиента, соответственно с ней надо было работать каждый день. Когда был запущен первый цикл, на его завершение потребовалось две недели, но и после этого там обнаружилась масса ошибок.
Что было дальше? Шесть месяцев ушло на то, чтобы «уложить» ежедневный цикл в 24 часа, однако ошибки в программе еще оставались. Коллектив потратил много ночей на исправление ошибок и переписывание кода, многие уволились. Приложение, полученное в итоге, оказалось удачным.
Мораль. «Не жалейте времени на то, чтобы вникнуть во все требования и задокументировать их, тогда вы справитесь с заданием с первого захода», — советует менеджер проекта.