Проектные провалы: что пошло не так?

Проектные провалы: что пошло не так?

Кейс №1

Помните историю про Microsoft Bob? Ели нет, то напомним.

В 1995 году Билл Гейтс запустил проект по созданию удобного для непрофессионального пользователя интерфейса для Windows 95. Результатом проекта стал пользовательский интерфейс, представленный в виде коттеджа, разные комнаты которого представляли разные приложения: «Комната для создания электронных таблиц», «комната для редактирования писем», «комната для отправки почты» и т.д. Интересно, правда? Однако, разработанный интерфейс в итоге оказался очень запутанным , иногда пользователь не мог найти «выход» из комнаты и перейти в другую. Проект по разработке длился 3 года, однако, в итоге был создан продукт, не имеющий своего потребителя.

В чем ошибка проектного менеджмента? Как можно было спасти деньги, потраченные на разработку и избежать проектного провала?

В 2001 году в США,  в рамках встреч проектных команд под названием «Lightweight Methods Summit», был разработан Agile Manifest, в основе которого лежат принципы:

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

Мог бы Agile манифест, если бы он был создан раньше, помочь избежать проектный провал интерфейса Microsoft Bob?

Скорей всего да. Вот что могло бы предотвратить такую ситуацию.

Кейс  №2

Рассмотрим исторически впечатляющие проекты с впечатляющим перерасходом средств.

Задумайтесь о цифрах:

• Суэцкий канал: перерасход средств: в 19 раз
• Сиднейская опера: в 14 раз
• Лайнер Конкорд: в 11 раз
• Панамский канал: в 3 раза

Этого ли хотели инвесторы? Скорее всего, нет.

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

• Метро в Майами, США – в год открытия пассажиропоток составил 15% от прогнозируемого
• Наземное метро в Бангкоке – пассажиропоток 50% от плана
• Московский монорельс – около 11 тысяч пассажиров в год, что несомненно, мало для мегаполиса.

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

Как можно было бы избежать потерь в проектах и снизить риски неполучения желаемого эффекта?

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

Кейс №3

Любой проект можно сравнить с конструктором в коробке.

Представьте, что вы- проектный менеджер. Вам подарили коробку, с надписью «проект».

1. Первый шаг- распаковать коробку, узнать что там внутри, к какому результату вы должны прийти.
2. Второй шаг – внимательно рассмотреть детали, узнать как они должны быть связаны между собой.
3. Третий шаг- выделить время на сборку конструктора, возможно это будет самолет. Допустим, модель самолета сложная, вам потребуется 5 недель, если подгонять детали аккуратно, без переделок.
4. Четвертый шаг- начать сборку самолета.

Классический подход к управлению проектами (другие названия:  каскадный или waterfall) подразумевает последовательность в проектных фазах. Классический подход походит, если среда проекта имеет низкую степенью неопределенности, результат в конце предсказуем и его свойства/характеристики понятны начале проекта. Проект «в коробке»- редкое явление сегодня.

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

И в классическом, и в Agile походах важно уложиться рамки бюджета. Поэтому лидер проекта чаще всего использует гибридный способ управления проектом.  Это позволяет зафиксировать общую организацию проекта в соответствии с классическим подходом, например создать сетевую диаграмму проекта (Program Network) и иерархическую структуру компонентов проекта (WBS), а управление этими компонентами вести по Agile через планирование и реализацию бэклогов и спринтов продукта.

Больше примеров и кейсов мы рассматриваем на тренинге: «Управление проектами: практикум»

Хотите научиться достигать 100% результата проектов с соблюдением сроков и бюджета?

Узнайте о возможностях обучения в Академии бизнеса Б1