Выпуск нового продукта — это риск. Причем неважно, есть у продукта аналоги или это нечто новое. В обоих случаях есть свои риски.
И один из рисков, который их несомненно объединяет — риск, что продукт не полетит, что на него не будет достаточного спроса.
Встает вопрос: а почему на продукт может не быть спроса? Чтобы на него ответить, я изучил причины провала 160 продуктов крупных компаний.
Пара уточнений
1. В поле зрения статьи попали какие-никакие инновационный продукты. Новый вкус газированного напитка — тоже инновация. Так что да, о провале точных копиях существующих продуктов мы говорить не будем, да и это не так интересно.
2. Уроки крупных компаний релевантны. Вероятно, соотношение причин неудач для малых компаний иное. Но сами причины те же и их нельзя игнорировать.
3. Причин провала много. Редкий продукт проваливается по одной причине. Я постарался выделить одну основную причину для каждого из них, но это ни в коем случае не единственная причина.
Две главные причины провалов и все-все-все
Итак, что получилось.
62% всех провалов — это две причины: некачественный продукт и ненужный продукт. Вроде, очевидно. Но если так очевидно, то почему даже крупные компании допускают базовые ошибки, создавая плохие или ненужные товары и услуги?
- Три причины — высокая цена, конкуренция и ошибки в маркетинге — делять третью строчку по популярности.
- В восьми случаях продукт не полетел, потому что представление о бренде не билось с продуктом.
Плохой дизайн был главный преградой к росту четырех продуктов. Замечу, у многих продуктов, попавших в категорию «некачественный продукт», тоже были проблемы с дизайном.
Интересная причина — ранний выход. Это когда продукт опередил свое время и ни потребители, ни технологии не были к нему готовы.
Еще шесть причин встретились по одному разу.
Ну а теперь давайте поподробнее раскроем каждую из причин.
1. Некачественный продукт
Некачественный продукт — понятие растяжимое. Сюда попадают случаи, когда:
- продукт плохо сделан;
- у продукта ограниченный функционал;
- продукт плохо работает.
Эта причина больше других бьет по потребителям, а значит объем негативной реакции прямо пропорционален финансовым затратам на продвижение продукта. Чем больше продаете, тем хуже.
Как мы к этому пришли: недооценка задач потребителей; желание быть первым; желание максимизировать прибыль; переоценка качества продукта; халатное производство.
Пример: SPOT Watch. В 2004 г. Microsoft выпустили революционные умные часы: они показывали погоду, на них приходили сообщения, у них был выход в интернет.
Но и проблем хватало, даже более чем: низкое разрешение экрана и ограниченное количество информации, выводимой на экране, плохая батарея, слишком большой размер, использование FM-сети Microsoft с ее слабой покрытием и интеграцией.
В 2011 г. проект закрыли.
2. Ненужный продукт
Продукт не нужен тогда, когда он решает надуманную проблему или решает совсем не так, как реально хотели бы потребители.
Нередко ненужный продукт — это объединение двух или более продуктов в одном. Или просто то, о чем потребители не просили и просить не собирались. Как Oreo со вкусом арбуза.
Как мы к этому пришли: незнание потребителей; переоценка рынка.
Пример: Oakley Thump. Очки+наушники — такая себе комбинация за $495. Наушники звучали ужасно, памяти у плеера было меньше, чем у конкурентов, да и дизайн оставлял желать лучшего.
И вся история упиралась в простую истину: носить наушники и очки отдельно — это не проблема.
3. Высокая цена
В 99,99% случаев цена имеет значение при выборе товара или услуги. Это не значит, что ваш продукт должен продаваться по той же цене, что и у конкурентов. За лучший продукт компании берут больше денег.
Просто нельзя ту же ценность продавать на 20%, 30%, 40% дороже. Никто не купит.
Как мы к этому пришли: переоценка ценности продукта; неэффективность производственных процессов; низкая эффективность маркетинга.
Пример: Cisco Umi. Домашнее видеооборудование — это мода 2020 г. Десять лет назад, когда Cisco выпустили свою приставку, такой нужды потребители не ощущали и задачу видеосвязи решал Skype — бесплатная программа.
И может Cisco и нашли бы своих потребителей, если бы не цена: $599 за оборудование и $9.95 за ежемесячную подписку.
4. Высокая конкуренция
Нередко, когда я привожу в пример успех крупной компании, мне говорят: «Ну конечно, у них какие возможности!». О чем мои собеседники забывают, так это что у этих компаний есть конкуренты с такими же ресурсами.
Возможно, обширные ресурсы дают шанс на ошибку. Чего они точно не делают — уберегают от конкурентной борьбы.
Как мы к этому пришли: продукт уступает конкурентам по потребительским свойствам; недооценка конкурентов; переоценка собственного продукта; недостаточная дифференциация.
Пример: Microsoft Zune. Еще один продукт Microsoft (я не специально). Zune не был идеальным продуктом, а именно этого требовалось, чтобы победить лидера — iPod.
Всего через несколько лет после появления Zune, Apple заменил свой главный продукт на iPhone. Ну а дальше вы знаете.
5. Ошибки в маркетинге
- Для небольших компаний главная ошибка в маркетинге поправимы: вложили не в тот канал в этом месяце, вложим в правильный в следующем.
- Для крупных компаний с их бюджетами и долгосрочным планированием ошибки в маркетинге — это убийство продукта.
- Как мы к этому пришли: неверное позиционирование; неверно выбранные маркетинговые каналы; недостаток коммуникации с потребителем.
Пример: BIC for Her. В BIC решили, что сделать ручки для девушек — это хорошая идея и все поймут, что они хотели донести.
Но посылы «идеальный аксессуар», который «подойдет к твоему стилю» никому не понравились и BIC обвинили в сексизме.
Очевидно, ручки просуществовали недолго.
6. Релевантность продукта бренду
Диверсификация — вещь хорошая. Вы расширяете охват, находите новые источники прибыли, снижаете риски. Что не работает — это диверсификация ради диверсификации.
Она работает тогда, когда продукт создается на базе тех же компетенций, что и основной продукт, а категория продукта не противоречит позиционированию бренда.
Как мы к этому пришли: незнание мнения потребителей о бренде; неверное позиционирование; уход от ключевых компетенций.
Пример: S&W Mountain Bikes. Кому как не производителю оружия заняться выпуском велосипедов для простых граждан. Ассоциация у потребителей не выстроилась, потому горные велосипеды Smith & Wesson не взлетели.
7. Плохой дизайн
Есть товары, которые мы покупаем исключительно из-за дизайна. Нередкая история в одежде. А есть товары, потребительские свойства которых меркнут в сравнении с ужасом, произведенным дизайнерами.
Для небольших компаний это не так страшно: переделал продукт пока о нем никто не знает и все. Для крупных корпораций последствия более плачевные.
Как мы к этому пришли: слабые дизайнеры; ошибочное представление о потребительских вкусах.
Пример: Pontiac Aztec. Я недавно рассказывал историю Pontiac Aztec — автомобиля, который убил бренд Pontiac. То, что дизайнерам компании показалось дерзким, покупателям показалось откровенным уродством.
И это при том, что Aztec не был таким уж ужасным автомобилем.
8. Ранний выход
Самое обидное — это придумать и создать инновационный продукт, к которому рынок не готов сейчас, но который найдет своих покупателей в будущем. Мало того, что у вас крадут идею, так еще и зарабатывает на ней кто угодно, но не вы.
Как мы к этому пришли: незнание потребителей; отсутствие product-market fit.
Пример: Iridium. Компания Iridium создала сеть спутников для обеспечения беспроводной связи по всему миру. Но тогда — во второй половине ХХ в. — продукт просто не мог заполучить нужную аудиторию. Вместо планируемых 500 тыс. подписчиков компания привлекла 10 тыс.
Дело кончилось банкротством компании в 1999 г., а на все предприятие она потратила $5 млрд.
9-14. Редкие случаи
По разу встретились следующие причины:
- неверный разворот — как Jawbone, которые переключились с аудиооборудования на умные аксессуары;
- недостаток компетенций — как Nike, которые поняли, что производить фитнес-браслеты — удел технологических компаний;
- негативные отзывы — как Kanoa, которых похоронил один негативный обзор на YouTube;
- ненадежный партнер — как GT Advanced Technologies, которые обещали Apple сапфировые экраны на iPhone;
- бизнес-модель — как MoviePass, которые сделали посещение кинотеатров настолько доступным, что не могли с этого заработать;
- менеджмент — как Nokia, которые создали интересный телефон N9, не получивший должной поддержки у высшего менеджмента.
Эти причины — редкость в контексте нашего обзора, но не для обычного бизнеса.
Вероятность провала есть у любого продукта
Что я рекомендую вынести из этой стать?
Первое — успех нового продукта предсказать нельзя. Никто не мешает делает прогнозы, строить планы продаж и все такое. Насколько планы совпадут с реальностью — вопрос. Не все из рассмотренных нами продуктов выглядели как однозначные неудачи с первого дня существования.
Второе — продуктовые провалы случаются не только в сфере высоких технологий. Десятки напитков провалились из-за вкусовых свойств (некачественный продукт), не меньше медиа исчезло из-за неспособности привлечь аудиторию (ненужный продукт) или агрегаторов из-за проблем с монетизацией (бизнес-модель).
Третье – нет ничего важнее знания клиентов. Какую проблему хотят решить потребители, насколько ваш продукт ее решает и почему потребители предпочитают ваше решение — ключевые вопросы, без которых нельзя запускать продукт и надеяться на успех.
Почему срываются проекты и как этого избежать: базовые принципы проектного менеджмента
Региональный маркетолог Wrike Яна Котруца рассказала, почему срываются планы работ по проекту и дала советы, как этого избежать.
https://www.youtube.com/watch?v=YTWz1pw6DoM
Представьте ситуацию. На совещании руководство объявляет о предстоящем мероприятии для клиентов. Эта новость застала команду врасплох, потому что все проекты были спланированы перед началом нового квартала, а бюджет утвержден. У проекта четкий дедлайн — на подготовку заложено всего 2 месяца.
Расскажу, с какими трудностями сталкивается команда при срочных проектах и как их решить.
Коллективная ответственность — это не всегда эффективно. Если сотрудники не понимают, кто поможет решить проблему и к кому можно обратиться с вопросом — проект рискует превратиться в хаос.
Как решить. На этапе планирования определите, кто будет ответственным за проект. Главная цель менеджера проекта — выполнить требования заказчика. Определите, по каким показателям будете оценивать успешность проекта, и согласуйте эти критерии с руководством: количество приглашенных гостей, число новых сделок и другие показатели.
Не так просто предугадать, на каком этапе проекта может произойти сбой. Но как правило всегда есть болевые точки, которые могут повлиять на результат. Поэтому лучше иметь под рукой план Б и понимать, как можно преодолеть возможные препятствия.
Как решить. Определить риски, которые могут возникнуть. Разбейте проект на стадии с выделением рисков на каждой из них и найдите ключевые элементы, которые могут все испортить.
В нашем случае, например, это могут быть риски, связанные с разработкой многочисленных дизайнов для мероприятия: раздаточные материалы, баннеры, оформление помещения, в котором будет проходить конференция.
Если они будут готовы в последний момент, то есть вероятность, что подрядчики не смогут вовремя все сделать или качество печати не оправдает ожиданий. Поэтому заранее обсудите с дизайнерами объемы работ и сроки.
Даже хороший план может провалиться, если не контролировать развитие проекта, особенно когда над ним работают более пяти человек.
Как решить. Собирать нужную информацию вручную трудоемко и энергозатратно, поэтому используйте сервисы, которые помогут в этом. В идеале можно использовать диаграмму Ганта, которая отображает актуальную информацию в режиме реального времени со всеми сроками и вехами. В случае организации мероприятия, проект будет выглядеть так:
На диаграмме Ганта видно, кто и за какую часть проекта отвечает: составление списка гостей, согласование итогового количества приглашений для клиентов и так далее. Если у вас есть цепочка зависимых задач, вы можете изменить сроки их выполнения.
- Профессия с нуля: курс даёт всю необходимую базу для работы в роли руководителя проекта
- Упор на практику: каждый студент работает минимум с 4 различными проектами
- Сопровождение: оперативная поддержка опытных кураторов и преподавателей
Согласно исследованию Института управления проектами (PMI), 21% проектов срываются из-за недостающих или ограниченных ресурсов.
Именно поэтому роль менеджера проекта очень важна. При составлении плана работ он учитывает все необходимые ресурсы и возможности своей команды.
Если уже на этапе планирования становится понятно, что сотрудники не справляются с поставленными задачами, то часть работы лучше отдать на аутсорс и подумать, как можно распределить ресурсы.
В ином случае есть риск эмоционального выгорания сотрудников или полной потери мотивации.
Как решить. Увеличивать или сокращать количество ресурсов в зависимости от потребностей. Не начинать проект при недостатке ресурсов.
Так можно контролировать загруженность сотрудников
Когда сведения по проекту хранятся не централизованно, приходится искать нужную информацию в электронных переписках, мессенджерах. А еще хуже, если информация была передана в разговоре с коллегой и нигде не зафиксирована.
Мы тратим самый ценный ресурс — время сотрудников, которое уходит на обобщение информации вместо решения задач. Чтобы этого избежать, нужно определиться, где хранить все данные, помогающие отследить ход выполнения проекта.
Как решить. Создайте отдельный канал в Slack, для оперативной связи и мгновенного обмена сообщениями. Добавьте в него всех участников рабочей группы, отвечающих за реализацию проекта.
Вы можете отметить любое важное сообщение звездочкой и оно автоматически сохранится в закладках. Очень удобно, что у Slack есть и мобильная версия — это позволит всегда находится в курсе последних событий.
Составляйте протоколы совещаний — подготовьте повестку и тему обсуждения и пригласите всех участников, чтобы не было эффекта «сломанного телефона» и все были в курсе последних новостей. Во время встречи фиксируйте все принятые решения, а после нее составьте вопросы для обсуждения на следующем совещании. Обязательно поделитесь протоколом с вашей рабочей группой после встречи.
Также не забывайте проводить ретроспективы с командой по результатам работы.
Синхронизация процессов в различных командах дает нужный контекст и прозрачность, так как не нужно тратить время на обобщение информации. Именно поэтому используйте инструмент для совместной работы, который поможет следить за выполнением проекта и позволит своевременно вносить корректировки.
Как решить. Выберите инструмент для управления проектами. Это упростит взаимодействие и повысит эффективность работы.
Вся информация по проекту будет храниться в одном месте и в любой момент к ней можно будет получить доступ.
Менеджер проекта сможет выгрузить отчет и видеть динамику работ, а у команды исчезнет необходимость в разрозненных инструментах, так как все сведения, можно будет получить в один клик.
Итак, менеджер проекта должен:
- Собрать с заказчика требования и определить критерии успеха проекта.
- Не забывать о ресурсном планировании.
- С вниманием относиться к работе с рисками.
- Проводить промежуточные ретроспективы и встречи с командой.
- Следить за ходом проекта и своевременно вносить корректировки.
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
10 главных причин провала проектов
Предлагаем вашему вниманию часть статьи, которую подготовил консультант по управлению проектами JPStewart Associates Джим Стюарт для портала https://project-management.com/.
Будучи консультантом по управлению проектами в JPStewart Associates, я обнаружил, что многие проекты провалились уже на начальном этапе.
Причины провала проектов в большинстве своем были схожими, поэтому исходя из собственного опыта, я составил список из десяти причин, почему проекты терпят неудачу.
И хотел бы поделиться некоторыми идеями, как можно решить возникшие проблемы на пути реализации проектов.
#1 – Scope Creep
Scope Creep (перевод: расширение области определения проекта, расползание его границ: ситуация, когда масштаб проекта продолжает увеличиваться, причем обычно неконролируемо, в процессе разработки).
В целом, это все, что вы собираетесь и, наоборот, не собираетесь делать в рамках проекта.
Поэтому, когда вы точно выяснили, что представляет собой проектная работа, вам необходимо зафиксировать это в иерархической структуре работ (WBS) и, тем самым, защитить себя от незапланированных изменений.
Таким образом, запланированные изменения менеджер проекта будет вносить через панель управления изменениями, если потребуется выпустить новый график, план управления рисками или бюджет. В противном случае вы вряд ли достигнете своей цели, расстроите руководство и клиента.
#2 – Перераспределенние ресурсов
Зачастую очень ограниченное количество участников работает одновременно над слишком многими проектами. В связи с этим кажется, что менеджеры совершенно не контролируют время своих сотрудников.
Члены команды должны сами определить, над какими проектами и когда они будут работать.
При этом лучше, чтобы менеджеры проектов встречались еженедельно, чтобы обсудить загрузку ресурсов, возможно, с применением электронного графика для отслеживания.
#3 – Плохие коммуникации
- Если руководитель проекта не является однозначным коммуникатором, в рядах команды может возникнуть хаос и путаница.
- Дополнительно по теме: Как включить команду в работу над проектом?
- #4 – Плохое управление со стороны стейкхолдеров
Стейкхолдеры имеют личную заинтересованность в том или ином проекте, что может быть как во благо, так иногда и в ущерб проекту. Работа менеджера заключается не только в выявлении всех заинтересованных сторон проекта, но и в умении своевременно управлять и взаимодействовать с ними. В этом случае хорошо помогает план управления коммуникациями.
#5 – Ненадежные оценки
Оценки очень часто являются просто предположениями членов команды, которые стремятся рассчитать продолжительность выполнения задач на основе того, сколько времени им потребовалось для этого в прошлый раз.
Это может оказаться как правильным, так и ошибочным. И во втором случае может привести к некорректному графику и повышает риск срыва сроков.
Хронологические записи, оставшиеся от предыдущих проектов, помогают решить эту проблему.
#6 – Нет управления рисками
Менеджер проекта обязан предвидеть заранее, что может пойти не так. После выявления рисков он вместе с командой должен решить, как реагировать (например, смягчать или избегать) на них по мере возникновения.
#7 – Проектная культура не поддерживается
Однажды меня попросили проконсультировать компанию, в которой я обнаружил, что неподготовленный секретарь занимался сложным проектом, в рамках которого велось 20 электронных таблиц Excel.
В этом случае у руководства явно не было понимания, что для управления проектом с помощью специальных инструментов необходимо наличие обученного персонала.
А это, в свою очередь, зависит от уровня зрелости и культуры проектного менеджмента в компании.
#8 – Случайный руководитель проекта
Это похоже, но не совсем то же самое, что пункт #7. Здесь часто возникают ситуации, когда преуспевающего технического специалиста (разработчика программного обеспечения, химика и т.д.
) повышают до проектного менеджера и отдают в его ведение те типы проектов, из которых он только что пришел.
Проблема в том, что эти специалисты, чаще всего, не проходят нужную подготовку по управлению проектами и им не хватает необходимых для этой работы навыков. И поэтому они часто терпят неудачу, несмотря на предыдущие успехи.
#9 – Отсутствие сессий стратегического планирования
- Это позволяет участникам не только вместе работать над артефактами проекта (график, WBS), но и стать настоящей командой, усиливая работу над проектом.
- Дополнительно по теме: Роль коммуникаций с командой в системе проектного управления
- #10 – Мониторинг и контроль
Многие проджект-менеджеры создают план-график работ и редко (или даже никогда не) обновляют его. А если и делают это, то произвольно вносят процент выполнения, который берут порой просто из воздуха. Важно фиксировать фактические данные, такие как дата начала проекта, выполненные задачи и оценка оставшейся работы.
Мы рассмотрели 10 причин неудач проектов, которые не стоит упускать из вида, особенно начинающим свой путь в управлении проектами. Знание этих моментов, своевременное их устранение и качественная подготовка к процессу реализации проектов поможет избежать многих проблем в проектном менеджменте и сделать его эффективным инструментом для развития и реализации стратегических планов компании.
Оригинал статьи
Причины провала ИТ-проектов
Примерно 10 лет назад от одного из успешных бизнесменов, в компании которого я руководил проектом внедрения КСУП (о том, что это – подробнее читайте здесь), я услышал такую фразу: «Бизнес сидит на игле у ИТ».
Меня заинтересовало ее объяснение, и оно было примерно таким: «Мы не можем не автоматизировать наш бизнес, потому как конкуренты это сделают ранее нас и станут эффективнее нас, и, с другой стороны, мы боимся это делать, т.к.
вероятность успеха ИТ-проекта крайне низка».
- С тех пор меня интересует вопрос о том, какова вероятность того, что проект внедрения информационной системы завершится в плановый срок, в плановый бюджет и при этом будут реализованы все запланированные функции?
- Отчет, который в 2014 году выпустила компания The Standish Group, предоставляет нам следующие данные для анализа:
- Из 8 380 проектов по разработке и внедрению программных продуктов успеха добились лишь 16,2%, в категорию «спорные» проекты попало 52,7%, а в категории провальных проектов (от реализации которых отказались) оказалось 31,1%.
- Для целей исследования в этом отчете все ИТ-проекты были разделены на три группы:
- «успешные проекты» — проект завершен в срок, в бюджет, реализованы все возможности и функции, которые первоначально были запланированы;
- «спорные проекты» — проект завершен и работает, но плановый бюджет или срок был превышен, либо реализованы не все функции, которые первоначально были запланированы;
- «провальные проекты» — проект был отменен и так и не дошел до финиша.
Как часто превышается бюджет ИТ-проекта и на сколько % от планового значения? На этот вопрос отчет дает нам следующий ответ:
| Превышение бюджета | % проектов |
| Менее 20% | 15,5% |
| 21 — 50% | 31,5% |
| 51 — 100% | 29,6% |
| 101 — 200% | 10,2% |
| 201 — 400% | 8,8% |
| Свыше 400% | 4,4% |
Как видим, почти в четверти проектов, из тех, что попали в группу спорных или провальных проектов, бюджет был превышен более чем в 2 раза (свыше 100% от планового).
А теперь посмотрим, как сильно отклоняются от планового срока ИТ-проекты:
| Превышение срока | % проектов |
| До 20% | 13,9% |
| 21 — 50% | 18,3% |
| 51 — 100% | 20,0% |
| 101 — 200% | 35,5% |
| 201 — 400% | 11,2% |
| Свыше 400% | 1,1% |
А вот по срокам ситуация куда более серьезная – почти в половине проектов (47,8%), попавших в группу спорных или в группу провальных, сроки были сорваны более чем на 100% от плановых.
И теперь узнаем какая доля от запланированного функционала программного продукта была реализована в проекте. Эта цифра имеет смысл только для категории спорных проектов, т.к. неудачные проекты так и не дошли до логического завершения:
| % реализованных функций | % проектов |
| Менее чем 25% | 4,6% |
| 25 — 49% | 27,2% |
| 50 — 74% | 21,8% |
| 75 — 99% | 39,1% |
| 100% | 7,3% |
В группе спорных проектов более четверти из них были завершены с получением лишь 25-49% от первоначально запланированных функций программного продукта. В отчете также есть данные о том, что в среднем был реализован 61% от первоначально запланированных функций для данной категории проектов.
Не знаю, как Вам, а мне интересно было узнать мнение руководителей ИТ-проектов относительно причин успеха их проектов. Ниже перечислены факторы успеха и доля респондентов, указавших их:
- Вовлечение пользователей — 15,9%
- Поддержка высшего руководства — 13,9%
- Ясное изложение требований — 13,0%
- Правильное планирование — 9,6%
- Реалистичные ожидания — 8,2%
- Небольшие этапы проекта — 7,7%
- Компетентный персонал — 7,2%
- Ownership — 5,3%
- Ясное видение и цели — 2,9%
- Трудолюбивый, сфокусированный персонал — 2,4%
- Другое — 13,9%
В аналогичном отчете The Standish Group за 2015 год в списке появились новые факторы успеха ИТ-проекта, которых не было в списке за 2014 год, например:
- Эмоциональная зрелость — совокупность основных характеристик поведения людей при совместной работе.
- Использование Agile процесса – обозначает то, что команда и владелец продукта умеют работать по одному из Agile подходов.
Как видим, в 2015 году респонденты в явном виде указали на то, что использование Agile-подхода для ИТ-проекта стало одним из факторов его успеха.
Самое интересно при изучении статистики проектов, на мой взгляд, — это понимание причин того, почему проект не стал успешным. По мнению респондентов отчета список этих причин для спорных проектов следующий:
- Отсутствие вовлечения пользователей — 12,8%
- Неполные требования и спецификации — 12,3%
- Изменение требований — 11,8%
- Отсутствие поддержки высшего руководства — 7,5%
- Технологическая некомпетентность — 7,0%
- Нехватка ресурсов — 6,4%
- Нереальные ожидания — 5,9%
- Нечеткие цели — 5,3%
- Нереальные плановые сроки — 4,3%
- Появление новой технологии — 3,7%
- Другое — 23,0%
Понятное дело, что в исследовании The Standish Group не участвовали ИТ-проекты компаний-заказчиков из Беларуси.
Имея опыт руководства проектами автоматизации бизнеса белорусских компаний, могу отметить, что ключевые факторы провала таких проектов в нашей стране во многом совпадают с приведенным выше списком.
Ниже представлена моя точка зрения на список причин провала проектов автоматизации бизнеса, без претензии на его истинность:
- Нечеткие цели ИТ-проектов.
Это проявляется на уровне самих формулировок целей проекта, к примеру, целью ИТ-проекта объявляют такую: «Внедрить ERP-систему». У меня много вопросов к этой формулировке цели:
- Что мы понимаем под ERP?
- Как мы поймем, что мы внедрили эту систему?
- Какова бизнес-выгода от внедрения?
- За какой период будем измерять бизнес-выгоду?
Следующий уровень, который скорее всего будет не проработан при старте проекта – это описание ожидаемых результатов проекта. Ну и совсем слабой в большинстве проектов будет проработка требований к результатам проекта. (подробнее читайте здесь)
- Отсутствие со стороны компании-заказчика проекта команды проекта
Я имею ввиду команду, которая имеет полномочия и ответственность принимать решения по содержанию проекта.
Несколько раз я встречал в проектах автоматизации ситуацию, когда со стороны компании-заказчика нет ни одного человека, кто переживал бы за результаты проекта и при этом имел власть принимать решения по списку требований и их приоритетам, и нес бы ответственность за принимаемые решения.
- Неполные требования к программному продукту.
Большинство заказчиков ИТ-проектов из числа белорусских компаний не готовы платить за полноценный сбор и анализ требований те деньги, которых это действительно стоит.
Это приводит к тому, что оценить проект исполнителю по тем требованиям, которые есть для оценки крайне сложно, и он оценивает прогнозную трудоемкость проекта слишком оптимистично.
Это приводит к следующей причине провала проекта.
- Нереальные плановые сроки
А как их оценить более-менее реально, если требования на старте ИТ-проекта изложены на уровне бизнес-требований или ожиданий? Вот и ошибаются оценщики в разы, при чем в сторону недооценки масштаба проекта.
Проявляется этот фактор в том, что на стороне заказчика хотят сразу сделать идеальный продукт и не принимают позицию, связанную с тем, что пользователям все равно что-то не понравится в программном продукте, поэтому важно максимально быстро запустить ключевой функционал, а потом потихоньку дорабатывать «бантики». По статистике, 20% от оплаченного функционала приобретенной ИТ-системы используются пользователями часто, еще 30% функций используются редко и 50% от приобретенного функционала ИТ-системы не используются практически никогда (подробнее тут).
- Отсутствие поддержки высшего руководства компании-заказчика
Я встречал ситуации, когда при внедрении ERP-систем высшие руководители компании-заказчика даже не были представлены команде исполнителя. О каком вовлечении в проект или поддержке проекта руководством со стороны заказчика может идти речь?
- Команда заказчика и команда исполнителя не работают как одна команда.
- В этом случае проект строится не на отношениях взаимного доверия, а на отношениях антагонизма: заказчик пытается за зафиксированную цену получить от исполнителя максимально много, а исполнитель пытается максимально заработать на некомпетентном заказчике.
- Сотрудники заказчика не принимают важные решения по проекту максимально быстро, а работают в комфортном для них темпе. В результате в проекте возникает потеря времени и команда исполнителя начинает терять интерес к проекту и ищет на время простоя, на какие проекты можно было бы переключиться
- Остальные причины из Отчета также имеют место быть, но на мой взгляд, они не так важны, как перечисленные восемь.
Подводя итоги, что нужно изменить в ИТ-проекте, чтобы максимально повысить вероятность его успеха? Понятно, что нужно решить те проблемы, которые описаны в списке выше.
Но, в первую очередь, нужно изменить отношения заказчика и исполнителя в сторону взаимного доверия и выстраивания единой команды, работающий на общую цель.
Получится создать такую команду – и она с большой вероятностью решит все остальные проблемы.
Тут я вспоминаю один из пунктов манифеста Agile:
«Люди и взаимодействие важнее процессов и инструментов», который я трактую так: «Хорошая команда проекта определит, какие процессы и инструменты ей надо использовать, чтобы достигнуть целей проекта». Agile – это про хорошие команды. Может поэтому в списке причин успеха ИТ-проектов в отчете компании The Standish Group за 2015 год появилась новая причина успеха — использование Agile процесса?
Остались вопросы? Пишите в х к статье.
7 причин провала проекта и как этого избежать
Но почему так много проектов с таким огромным потенциалом заканчиваются провалами?
В какой момент проект считается провальным?
Проект становится неудачным, если он не выполняет то, что требовалось, в рамках согласованного бюджета и времени. Однако в большинстве случаев заинтересованные стороны решают, был ли проект успешным или неудачным, на основании их суждений и удовлетворенности результатом.
- Общие причины провала проекта:
- Некоторые проекты также считаются провальными, если они не соответствуют финансовому прогнозу или не достигают целевого показателя рентабельности инвестиций.(прочитать подробнее можно о ссылке)
- Есть ряд причин, и хорошая новость заключается в том, что вы можете устранить каждое препятствие и добиться успеха в следующем проекте (а также в следующем и последующем) с помощью руководства по управлению проектами, управляя проектами.
- Вот некоторые причины неудач проекта и то, что вы можете сделать, чтобы изменить ситуацию.
7 причин, почему проекты терпят неудачу и как с этим справиться
1. Неясные цели и задачи
Один из способов практически гарантировать провал проекта — начать работу без четких целей и задач проекта. В конце концов, невозможно узнать, добились ли вы успеха, если вы не совсем уверены в том, чего пытаетесь достичь.
Возьмем простой пример на личном уровне. Допустим, вы решили «привести себя в форму». Что это значит?
Хотите сбросить несколько килограммов? Нарастить мышечную массу? Развить выносливость?
Если вы просто начнете тренироваться и / или лучше питаться — что мы все должны делать, если честно, — ваше физическое состояние улучшится, но вы не будете точно знать, добились ли вы успеха. Вам нужны четко определенные цели. Неясные цели в профессиональной жизни также могут привести к неудаче.
Как этого избежать:
Существует несколько популярных структур для постановки целей, таких как цели SMART и CLEAR, но суть в том, что ваши цели должны быть измеримыми и реалистичными.
Не просто говорите, что хотите «похудеть», скажите, что вы хотите похудеть на 15 килограмм за следующие четыре месяца. Это измеримо и реально.
Проекты, которыми вы управляете, более сложны, поэтому еще более важно четко определить свои цели.
2. Отсутствие планирования ресурсов
Планируем сроки. Планируем встречи. Планируем структуру и темы и интерфейсы. Но иногда, в разгар всего этого планирования проекта, мы забываем спланировать наши ресурсы. Это большая причина того, почему проекты терпят неудачу. Управление проектами включает управление ресурсами, часто с учетом других проектов. Большинство из нас знает, что планирование финансовых ресурсов важно.
Вот несколько вопросов, которые вы можете задать при планировании других ресурсов в вашем следующем проекте:
Какие человеческие ресурсы требуются? Какие люди и как долго? Кто-нибудь из них в настоящее время работает над другим проектом или их можно будет отозвать до завершения моего проекта?
Какие средства необходимы? Есть ли у нас офисные помещения, столы, компьютеры, конференц-залы и производственные помещения, необходимые для успеха этого проекта?
На каких сторонних поставщиков мы будем полагаться? Каковы их временные рамки и ограничения?
Каких ресурсов знаний нам может не хватать? Могу ли я пригласить эксперта или провести обучение, чтобы развить у моей команды необходимые навыки управления проектами?
3. Отсутствие видимости проекта и контроль над ним
Независимо от того, насколько хорошо спланирован ваш проект, отсутствие прозрачности может быстро привести к провалу. Очень важно создать систему, которая обеспечивает видимость не только для руководителя проекта, но и для всех членов команды. Видимость включает в себя прозрачность проекта статуса задачи, четкую коммуникацию и хорошее управление документами.
Как этого избежать:
Когда все знают статус каждой задачи проекта, они могут помочь или внести соответствующие коррективы. Он поощряет активную работу и решение проблем. Управление документами не должно быть сложным. Фактически, наличие централизованного цифрового хранилища для всех проектных документов облегчает вашу работу в качестве менеджера проекта, а также способствует наглядности.
4. Пробелы в коммуникации
Само собой разумеется, но общение в управлении проектами является ключевым. Инструменты, которые ваша команда использует для общения, должны быть объяснены и реализованы с самого начала вашего проекта.
Как этого избежать:
Будь то электронная почта, текстовые сообщения, чат или другое сочетание вещей, убедитесь, что все в команде понимают, чего от них ждут, и могут использовать выбранную вами технологию. Помимо метода коммуникации, убедитесь, что вы установили четкие ожидания и руководящие принципы в отношении видов информации, которую необходимо передать.
Узнайте 12 простых способов улучшить командную работу на рабочем месте
5. Отклонение от цели (непостоянство прицела)
Поначалу это кажется таким невинной причиной. Простой запрос клиента на добавление элемента сюда, блестящая идея для расширения услуги там, и, прежде чем вы это узнаете, объем вашего проекта перерос, а ваша команда чрезмерно расширена. Вот и все, произошел полный перевес задач над настоящими требованиями и происходит отклонение от цели.
- Параметры проекта не были четко определены с самого начала или
- существует внутреннее давление со стороны команды или извне со стороны заказчиков или руководителей, чтобы они взяли на себя задачи, которые не были частью первоначального плана проекта.
- Как этого избежать:
Проблема смещения объема работ заключается в том, что оно часто приводит к провалу проекта. Вы не предусмотрели в бюджете время или ресурсы, необходимые для выполнения дополнительных задач, поэтому то, что могло быть ошеломляющим успехом, оборачивается разочаровывающей неудачей.
6. Нереалистичные ожидания
Иногда замаскированные под нереалистичный оптимизм нереалистичные ожидания разрушили многие проекты. Руководителю проекта необходимо иметь четкое представление о том, чего ваша команда может достичь и в какие сроки. Как только вы согласовали свои ожидания с реальностью, вы должны сообщить о них покупателю, а зачастую и своему начальству.
Как этого избежать:
Имея реалистичные ожидания и понимаемые всеми участниками проекта, ваша команда имеет гораздо больше шансов на успешное завершение проекта.
7. Плохое руководство
Лидерство имеет решающее значение и является общей точкой успеха или неудачи. Менеджер проекта не может жаловаться на то, что команда вышла из-под контроля.
И команда не должна оставлять чувство, что они не знают, что делать или чего ожидать от одного дня до следующего — это огромный рецепт неудачи.
Убедитесь, что все знают, чего от них ждут, и возложите на них ответственность за достижение этих целей или выполнение этих задач. Подавайте пример — если вы не опаздываете на собрания, членам вашей команды тоже нет оправдания!
Если вы делаете все возможное, чтобы хорошо руководить командой, но у вас есть члены команды, которые постоянно отстают, не отвечают на отзывы и что-то просто не работает — тогда вы все равно обязаны поднять флаг, который вам нужно заменить члена команды или членов команды и подтолкнуть к этому. Менеджер проекта, который отрицает свое собственное лидерство, не сможет заслужить уважение и поддержку со стороны членов своей команды, и, скорее всего, ему будет труднее управлять кораблем.
Вывод
Оценка и восстановление провалившегося проекта может быть одной из самых сложных задач для менеджера проекта в организации. Однако отдача может быть огромной, поскольку проект, реализованный в результате неудачи, может принести фирме значительную ценность.
Семь факторов, описанных в этом документе, имеют решающее значение для оценки производительности неудачного проекта и планирования корректирующих действий, чтобы сделать проект успешным. Для успеха необходимы все семь факторов.
Когда один фактор становится отрицательным и не исправляется, катастрофа неизбежна.