Как сделать провальный проект успешным? Почему провалился проект "новороссия"

Проработав длительный срок в IT-сфере, начинаешь понимать, что как бы ты ни хотел, часть проектов проваливается. По оценкам некоторых экспертов, количество таких проектов доходит до 60%. Перефразируя классика, можно сказать, что все успешные проекты успешны одинаково, а каждый провальный - провален по-своему. В каждом случае можно найти свою ключевую причину провала. Вот некоторые из них:

1. Нереальные проектные сроки и бюджет

«…менеджера по маркетингу вряд ли особенно волнует реалистичность предлагаемого им плана и бюджета, поскольку его основная цель - получить комиссионное вознаграждение или доставить удовольствие своему боссу» . Эдвард Йордан, «Смертельный марш».

2. Непрофессионализм участников проектов

«Все компании, предоставляющие услуги в ИТ, становятся жадными и пытаются расти быстрее, чем могут находить талантливых людей…» . Джоэл Спольски, «Джоэл о программировании».

3. Политические интриги вокруг проектов

«…отличительной чертой безнадежных проектов является настолько сильное влияние политики, что она может свести на нет все усилия выполнить хотя бы какую-нибудь работу». Эдвард Йордан, «Смертельный марш».

4. Изменчивость требований к системам в ходе выполнения проектов

«Одной из самых распространенных причин неуправляемости проектов являются изменчивые требования». Роберт Гласс, «Факты и заблуждения профессионального программирования».

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

Этапы развития провального проекта

Сроки предоставления технического задания начинают затягиваться. Беспокойства нет – это бывает.
Техническое задание представлено на согласование. У Заказчика возникает легкое недоумение - в документах слишком много «воды», часть требований не соответствует тому, что обсуждалось с проектной командой. Начинается процесс согласования. Все полны решимости быстро устранить недочеты.
Процесс согласования технического задания затягивается. Появляются первые признаки беспокойства в связи с нарушением сроков. К этому относятся с пониманием, ведь важны не документы, а сама система.
Подошел срок поставки первого релиза системы, который Исполнитель должен установить на оборудование Заказчика. Исполнитель сообщает, что все готово, но нужно подождать еще пару дней.
Установка системы идет полным ходом, но пока безрезультатно. Систему должны были установить еще две недели назад.
Сроки согласования ТЗ давно прошли, но это уже не очень волнует. Озабоченность связана с тем, что никак не удается наладить систему.
Система установлена, но работает плохо. Часть функционала не реализована совсем, часть реализована не так, как ожидалось, и все равно не работает из-за большого количества ошибок. Недовольство Заказчика нарастает.
Устанавливаются новые релизы системы, но каждый следующий релиз работает не лучше предыдущего. Протоколы встреч уже не ведутся. Встречи превратились во взаимные претензии. О том, что техническое задание до сих пор не согласовано, уже никто не вспоминает.
Составляются длинные списки ошибок системы, которые нужно устранить. Новые релизы системы содержат исправления новых ошибок, но обнаруживаются старые ошибки, которые были исправлены ранее в предыдущих релизах.
Исполнитель требует начала опытной эксплуатации системы и подписания актов приемки, но пользователи отказываются работать в системе, так как она им не нравится и часто падает.
Акты приемки этапа разработки технического задания подписываются с обещанием Исполнителя исправить все позднее.
Запаздывание проекта уже составляет 30% - 50%. ТЗ согласовывается задним числом.
Установлены, наконец, все компоненты системы. Основные критические ошибки исправлены, но работать в системе невозможно из-за неудобства функционала.
Заказчик просит переделать функционал. Исполнитель не соглашается без дополнительной оплаты, так как функционал разработан согласно ТЗ. Заказчик отказывается принимать систему. Идет долгий период непонимания, что делать с системой.
Происходят изменения на стороне Заказчика (меняются люди/процедуры/процессы и тому подобное). В связи с произошедшими изменениями становится понятно: чтобы хоть как-то начать работать в системе, ее нужно переделать в соответствии с произошедшими изменениями. Заключается дополнительное соглашение на доработку системы. Чтобы не потерять лицо, руководство договорилось объявить о новом этапе проекта.
Идет длительный этап доработки. Сроки превышены уже в два раза. Сотрудники Исполнителя и Заказчика устали от проекта, но не знают, как его прекратить. На проекте меняется руководитель проекта Исполнителя и часть проектной команды. Новая проектная команда заново собирает требования.
Заказчик понимает, что существующая система работать не будет. Старая технология работы кажется уже не такой плохой, по сравнению с новой системой. Заказчик максимально тормозит внедрение системы, не зная как выйти из этого внедрения.
Идет долгий процесс переговоров. В результате стороны договариваются о приемке системы. Размер денежного вознаграждения Исполнителю существенно снижен. Акты закрываются. Провал не нужен ни одной из сторон, поэтому по молчаливому согласию проект считается успешным.
Выходит пресс-релиз об успешном внедрении системы.

Вот он, наконец, долгожданный финал. То есть вроде бы не провал. Но мы-то знаем…

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

«Как сказал мне старый раб перед таверной:
"Мы, оглядываясь, видим лишь руины".
Взгляд, конечно, очень варварский, но верный».
И.Бродский

А ведь было бы гораздо эффективнее направить усилия на благородное дело - сохранение средств родной компании при сохранении собственного здоровья и душевного равновесия. Иными словами – не пытаться спасти проект, а, наоборот, утопить его как можно раньше. Уверен, что вы уже знаете или догадываетесь, как это сделать.

Что необходимо сделать, чтобы провалить проект наиболее результативно.

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

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

Поставьте нереально сжатые сроки проекта.
Определите максимальное количество проектных документов, требующих согласования.
Составьте предельно длинный список сотрудников, согласующих проектную документацию с вашей стороны.
Затягивайте согласование технического задания. Отказывайтесь подписывать проектные документы, ссылаясь на несоответствие ГОСТам, внутренним стандартам вашей компании, слабую детализацию или несоответствие бизнес-процессам.
Постоянно изменяйте требования к системе.
Чаще проводите ротацию сотрудников вашей проектной команды и предметных специалистов.
Если почувствуете, что проектная работа, тем не менее, начала стабилизироваться, попросите заменить проектную команду Исполнителя по причине срыва сроков этапов проекта. Начните вновь, с пункта 1.

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

Удачи на проектах!

В начале 2010 года компания Microsoft выпустила новую операционную систему, рассчитанную на мобильные устройства — WindowsPhone 7. Она создавалась как прямой конкурент для лидирующих на рынке Android и iOS.

HTC Смартфон HTC Titan на ОС Windows Phone 7

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

Но с самого старта системы ее преследовали неудачи, связанные со спорными решениями руководства и все возрастающим давлением со стороны конкурентов.

Одной из основных проблем стал минималистичный дизайн Metro UI. Аскетичные плитки одного из дюжины цветов, которые превращались в длинное и ненаглядное полотнище на главном экране, были откровенно говоря «на любителя». На экране блокировки уведомления отображались только от некоторых приложений, а уже привычной для Android пользователей шторки с быстрыми настройками и уведомлениями вообще не было.

Вторая большая проблема — многочисленные ограничения по «железной» части и недостаток необходимых функций, которые уже прочно вошли в арсенал прямых конкурентов. Так, долгое время в системе просто отсутствовала возможность сделать скриншот экрана, изменить размер плитки на меньший, а уведомления на самих «тайлах», которые должны были стать главной «фишкой» ОС, работали плохо.

Последним «гвоздем в крышку гроба» этой мобильной системы стал очень скудный магазин приложений.

Разработчики многих популярных программ, вроде Instagram, не спешили портировать свои продукты на WindowsPhone, а если и делали это, то приложения зачастую отставали по функционалу своим «братьям» на других ОС. Google намеренно не выпускала пакет своих приложений для этой системы, и такие продукты как YouTube, Gmail, Карты и пр. оставались прерогативой Android и iOS до самого конца.

Даже в лучшие свои годы WindowsPhone не дотягивала по показателям доли рынка до двухзначных показателей, а по состоянию на начало 2016 года сегмент WindowsPhone оценивался менее чем в 1% рынка смартфонов.

Все это привело к тому, что с октября 2017 года Microsoft официально прекратила разработку новых версий мобильной ОС Windows, то есть фактически отказалась от своего проекта навсегда. Постепенно пользователи более старых версий WindowsPhone лишаются важных функций, например, push-уведомлений, так что в будущем техподдержка этой операционной системы скорее всего полностью сойдет на нет.

Во всем виноват Twitter?

На рынке интернет-сервисов и мобильных приложений уже сложилась маленькая традиция — если приложение покупают владельцы Twitter, то оно скоро уйдет в небытие. Так сложилось с сервисом Vine, который был создан для записи и публикации коротких зацикленных видеороликов, такую же судьбу пророчат приложению для стриминга Periscope. Действительно ли виноват Twitter в бедах этих продуктов?

Depositphotos

К сожалению, Vine и Periscope просто проиграли войну за пользователей другим приложениям, которые предоставили больше возможностей и изначально имели более крупную аудиторию.

В случае с Vine хладнокровным убийцей стал Snapchat, который, по иронии судьбы, сейчас тоже испытывает трудности с лояльностью пользователей, а Periscope выдавили Facebook Live и Instagram с их прямыми трансляциями.

Практика показала, что пользователи отдают предпочтение сервисам, которые объединяют в себе много возможностей, дают «все и сразу». В том же Facebook можно осуществлять все социальные активности — будь то переписка, размещение разного контента, ведение сообществ и пр. С введением функций, аналогичных имеющимся в Vine и Periscope, в «базовые» социальные сети, необходимость вышеперечисленных приложений просто отпадает сама собой.

Не разглядели проблем

Далеко не все продукты «корпорации добра» выходят успешными. Так, проект Google Glass так и не выбрался из стадии тестирования журналистами, которое проходило еще в 2012 году. Причин, которые послужили провалом для этого амбициозного проекта было несколько.

Seth Wenig/AP

Первая и основная — продукт был еще очень сырым. После красивой презентации с парашютистами, которые снимали свой полет на новый гаджет, прошел целый год. Первые журналисты, оставившие предзаказ на «умные» очки за $1500, наконец получили свои экземпляры и тут же написали неутешительные для Google обзоры.

Автономность устройства была просто смешной, сами очки нагревались при работе, что доставляло дискомфорт, а вдобавок и выглядели они слишком «гиковскими», что не давало чувствовать себя уверенно на публике.

По слухам, сооснователь компании Google Сергей Брин настаивал на немедленном выпуске в свет еще не законченного продукта, чтобы получить достаточное количество отзывов для работы над ошибками.

Стратегия оказалась не совсем удачной. Так как в розничных магазинах Google Glass приобрести было невозможно, создался нездоровый ажиотаж среди довольно большого количества заинтересованных людей, а уже ажиотаж породил завышенные ожидания от такого совсем не дешевого продукта.

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

Горечь поражения со вкусом черники

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

David Manning/REUTERS Исполнительный директор RIM Торстен Хайнс презентует новый BlackBerry в 2012 году

Как отмечают аналитики, проблемы компании начались еще в 2007 году, в год выхода первого iPhone. Apple сразу же взяла курс на совершенствование программного обеспечения, в то время как BlackBerry, которая тогда еще называлась RIM (Research in Motion), была скована рамками ограничений. Руководство компании в лице Майка Лазаридиса и Джеймса Балсилли полагали, что куда важнее развитие в сторону тактильного удобства клавиатуры и безопасности.

До 2009 года компания RIM продолжала активно расти и приносить высокие прибыли, однако начиная с 2010 года и по сей день положение на рынке только ухудшалось. Операционная система смартфона BlackBerry очень сильно уступала конкурентам в лице iOS и недавно появившемуся Android. Магазин приложений был очень скуден, а пользователи были не готовы отдавать предпочтение безопасности взамен удобству использования и функциональности.

Злую шутку с компанией сыграла ее уверенность в бизнес-сегменте и уверенность в преданности своих поклонников.

Для подавляющего большинства виртуальная сенсорная клавиатура оказалась гораздо удобнее и быстрее, а сам формат смартфона — телефона без физической клавиатуры и с большим экраном оказался самым жизнеспособным.

Последним рывком для компании стал перевод смартфонов на операционную систему Android и отказ от разработки собственной, однако и эта попытка оказалась безуспешной.

На февраль 2017 года доля рынка, занимаемая BlackBerry, оценивается в 0%, что говорит о безоговорочном поражении этой компании на рынке смартфонов.

Старый друг лучше новых двух

Рынок мобильных систем полон историй об амбициозных и не очень проектах, которые стремились побороть гегемонию со стороны iOS и Android, но по разным причинам у них ничего не вышло.

Ubuntu — это операционная система на базе ядра Linux, которая должна была выйти на рынок мобильных устройств с интересной концепцией, а именно с мультиплатформенностью. Разработчики планировали, что на всех типах устройств, будь то ПК, планшет или смартфон, система должна выглядеть одинаково, масштабируясь под конкретную диагональ дисплея.

Ubuntu Превью телефона на Ubuntu OS, версия для разработчиков

Проблемы начались уже на стадии разработки: дизайн был очень непривычным и интуитивно непонятным, магазин приложений был пуст, тогда как AppStore и PlayMarket насчитывали уже сотни тысяч программ, а самая большая проблема — так и не удалось найти производителей «железа», которые бы выпустили линейку устройств для новой операционной системы.

Пользователи также были не заинтересованы в новой системе, о чем свидетельствует провал краудфандинговой программы.

Второй неудачник — FirefoxOS. Разработчики популярного браузера стремились выпустить на рынок новую «операционку», которая была построена по принципу веб-интерфейсов, где большинство функций работает благодаря наличию интернет-соединения, а от смартфона не требуется большой производительности. Руководство Mozilla выбрало сверхбюджетный сегмент смартфонов для конкурирования с Google, и это была основная ошибка компании.

Mozilla Превью телефонов на Firefox OS, версия для разработчиков

FirefoxOS сразу же стала восприниматься как второстепенная ОС для стран третьего мира, что сильно подорвало ее репутацию. Вдобавок Google оперативно представила проект Android One, который выигрывал по всем фронтам, начиная от поддержки и заканчивая магазином приложений. Так и не сумев справиться с проблемами, проект FirefoxOS был закрыт в 2015 году.

Как понять, что ваш бизнес-проект под угрозой? Как его спасти и что сделать, чтобы свести к минимуму риск неудачи? Об этом в своей книге «How to Save a Failing Project: Chaos to Control» рассказали: Ральф Янг - специалист по управлению проектами, автор четырёх книг на тему разработки технических требований; Стивен Брэйди - IT-специалист по управлению проектами и Дэннис Нэгл - инженер, программист, специалист по IT-архитектуре.

Итак, вот порция полезных антикризисных советов, которые помогут в наступающем году предпринимателям, чувствующим «слабость в бизнесе».

Почему проекты иногда проваливаются?

Не всегда бизнес-проекты завершаются удачно. Причин может быть много. Главные из них:

● Очевидно недостижимые цели.

● Неверная оценка затрат.

● Слабый контроль качества.

● Чрезмерный оптимизм и неоправданно завышенные цели проекта при планировании.

● Неэффективное управление проектами. По статистике, около 75% всех IT-проектов либо выполняются дольше запланированных сроков, либо завершаются неудачно.

● Слишком упрощённый подход к планированию. Чтобы получить нужные результаты, недостаточно просто составить график, расписать бюджет и следить за выполнением плана. Приступая к новому проекту, руководители должны описать те продукты, которые нужно создать проектной команде. Необходимо следить за тем, чтобы проект по ходу выполнения не расширялся новыми дополнениями.

«Чаще всего выполнение проекта длится в два раза дольше и обходится в два раза дороже запланированного»

Признаки того, что проект под угрозой

1. Нарушены сроки.

2. Снизилась эффективность выполнения.

3. Участилась доработка готовых продуктов.

4. Руководство связывает успех проекта с несколькими опытными сотрудниками, а не с командой в целом.

5. Темпы работы над проектом снижаются, если заказчик часто меняет требования и выдвигает новые.

6. Отсутствует запасной план действий.

7. Частые перестановки в составе команды.

Но на самом деле многие ошибки, которые угрожают проекту, можно исправить.

Методы спасения проекта

1. Оперативно корректировать недочёты

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

2. Сформировать у участников проекта одинаковое видение конечного результата

Причиной провала проекта может стать плохо организованный обмен информацией между участниками проекта. Особенно если они по-разному видят цели и задачи. Пример: в известной IT-компании плохая внутренняя организация стала причиной проблем в работе над проектом с бюджетом в 250 миллионов долларов. В нём участвовала основная команда и 15 вспомогательных групп. Менеджеры групп общались только со своими подчинёнными и не обменивались информацией с основной командой. Результат: компании пришлось заново планировать работу, чтобы улучшить обмен информацией и координацию между вспомогательными группами и основной командой. Проект удалось спасти благодаря тому, что у всех его участников сформировалось одинаковое видение конечного результата.

3. Определить объём работ и необходимых ресурсов

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

Следует учитывать, что:

● 1/10 часть времени, отведённого на проект, будет потрачена на предварительное планирование, а также последующее обсуждение текущих проблем и корректировок плана.

● План должен включать описание модели выполнения рабочих процессов, описание параметров каждой задачи.

● Весь объём запланированных работ нужно разбить на несколько задач, сроки выполнения которых измеряются в часах (а не в месяцах, неделях или днях).

4. Повторное выполнение задач

Некоторые задачи потребуют повторного выполнения. Однако частые доработки (особенно на заключительных стадиях) чреваты выходом за рамки бюджета и нарушением сроков.

5. Отслеживать проблемы в зачатке, на ранних стадиях

Один из «звоночков», на который нужно оперативно реагировать - ошибка в графике проектных работ. Чтобы её обнаружить, выясните, сколько времени и ресурсов на самом деле нужно сотрудникам для выполнения конкретных задач. После этого сравните полученные цифры с первоначальными расчётами. Выявление и исправление недочётов на ранних этапах проекта поможет свести к минимуму финансовый ущерб от ошибок в планировании.
К поздним признакам того, что у проекта серьёзные проблемы относят ухудшение психологического климата в команде и проявление клиентами недовольства результатами.

«Самая частая причина провала проектов - неспособность понять, чего на самом деле хочет заказчик»

Человеческий фактор, или «Кадры решают всё»

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

«Доработки, особенно на поздних этапах проекта, становятся главной причиной нарушения сроков и перерасхода бюджета»

Как руководителю добиться слаженного взаимодействия в команде:

1. Еженедельно собирать коллектив для обсуждения хода работы, оценки эффективности командных усилий. При необходимости - для обсуждения корректировки плана проекта.

2. Если какой-то сотрудник своим поведением подрывает моральный дух команды (например, игнорирует общую для всех модель рабочих процессов), предложить ему исправиться или покинуть команду.

3. Научить членов команды признавать и исправлять свои ошибки, не скрывая и не отрицая их. Менеджеры должны личным примером показывать команде, что важно беспристрастно оценивать результаты труда и постоянного улучшения рабочих процессов.

Разделение проекта на этапы

● Итогом выполнения любой задачи должен быть материальный продукт. Например, при строительстве жилого дома такими продуктами будут чертежи, отчёты о соблюдении графика работ, а также само построенное здание. В грамотно составленном плане результаты выполнения должны выражаться в виде цифр (например, в штуках или страницах).

● Подсчитайте затраты и установить нужные стандарты качества. Разумеется, требования к качеству зависят от важности этих результатов для проекта в целом. Например, просчёты в чертежах будут иметь гораздо более серьёзные последствия, чем ошибки в написании фамилий сотрудников в протоколах совещаний.

● Неспособность точно спланировать объём проектных работ ведёт к нарушению сроков выполнения проекта. Чтобы избежать этого, составьте подробный перечень всех задач, которые нужно будет выполнить для достижения результатов проекта. Он поможет специалистам по планированию подобрать членов команды с подходящими навыками.

● Все работы по проекту можно отнести к категории либо управленческих, либо технических. Результатом станет внешний продукт для клиента и внутренний продукт для компании. Компания приступает к реализации проекта с «внутренними» ожиданиями по затратам и прибыли. У клиента же «внешние» ожидания связаны с тем, как выполнение проекта отразится на его бизнесе. Например, строительные организации, прежде чем взять в работу проект здания, обязаны согласовать его с регулирующими органами.

● Чтобы иметь полное представление о ходе выполнения работы, опишите проект в виде нескольких несложных задач, каждая из которых требует небольшого времени. Когда план состоит из нескольких подэтапов, в него легче вносить изменения. Имея точные графики, менеджеры проекта получают возможность быстро подстраиваться под требования клиентов и обосновывать затраты времени и денег.

Ведение документации и обмен информацией

● Чтобы снизить риск провала проекта, составьте мини-графики для выполнения каждого подэтапа.

● Документально оформите все рабочие процессы, выполняемые командой. Постоянно следите за точностью их выполнения. Документы с описанием процессов в дальнейшем можно использовать для инструктирования новых членов команды.

«Если не корректировать план проекта, он быстро утратит актуальность и команда останется без ориентиров в работе»

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

● Незаметное расширение рамок проекта - одна из самых сложных проблем, возникающих в ходе его выполнения. Причиной такого расширения может быть частое внесение изменений в план работ. Чтобы избежать этого, сосредоточьтесь на главной задаче проекта и следите за тем, чтобы не отвлекаться от её выполнения.

Как снизить риск провала IT-проектов

Повысить шансы на успех у проектов по разработке IT-продуктов помогут следующие меры:

● Снижайте уровень сложности проектов.

● Откажитесь от соблюдения излишних требований.

● Выполняйте задачи согласно порядку их приоритетности.

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

● Старайтесь не допускать, чтобы на заключительных этапах в конкретных компонентах создаваемого продукта при тестировании обнаруживались проблемы.

● Тесно взаимодействуйте с пользователями продукта, чтобы представлять, как они формулируют свои потребности. Нежелание выяснять реальные запросы пользователей коммерческого ПО - одна из самых распространенных причин провала проектов в IT-индустрии. Лучше перепроверить, все ли элементы ПО, включённые в список для разработки, действительно нужны пользователям.

● Установите стандарты качества нужно уже на самых ранних этапах выполнения работ. Распределите возможные проблемы с качеством по категориям, присваивая каждой приоритет. Наиболее важными нужно заниматься сразу.

● Разработчикам программного обеспечения важно иметь возможность оперативно выявлять и устранять ошибки в программном коде. Чем раньше обнаруживаются эти ошибки, тем ниже оказываются итоговые издержки на проект.

P.S. Ещё немного информации по теме в нашем блоге.

9 ошибок, которые могут свести на нет все усилия по сокращению потерь

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

1. Бездумное внедрение классической японской системы «пять сигм» (5S: сортировка на полезное и бесполезное, соблюдение порядка, содержание рабочего места в чистоте, стандартизация, совершенствование). Часть этих элементов может стать актуальной на поздних этапах, а может и вообще не понадобиться. Более жизнеспособной альтернативой классической концепции 5S на практике оказывается подход, при котором выявляются существующие проблемы и все усилия направляются на их устранение.

2. Отказ от обучения персонала принципам улучшений. Сотрудникам, участвующим в проектах улучшений, предлагается самим выйти «в поле», увидеть проблемы и придумать, как их решить. Так практикуется в Японии, японские консультанты советуют это и российским предприятиям. Трудность в том, что неподготовленный человек, особенно если он долго работает в данной организации, проблем не видит. Все как всегда, люди заняты, процессы выполняются. Но это не значит, что проблем нет, это говорит лишь о том, что сотрудник их не осознает. И, следовательно, не сможет их решить. В результате проект бережливого производства затягивается, а консультанты надолго обеспечиваются работой (и стабильным доходом). Поэтому рекомендуется начинать процесс улучшений с обучения персонала его принципам. Люди должны понять, как выявлять и решать проблемы, и только после этого их можно бросать в бой. Спешке здесь не место, но в итоге результаты все равно появятся быстрее. В США я наблюдала подход, прямо противоположный японскому: четко прописанные сроки проекта, бюджеты и плановые результаты держали его участников в повышенном напряжении, что тоже иногда негативно сказывалось на результатах.

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

4. Пренебрежение материальной мотивацией. В Японии за участие в проектах повышения эффективности сотрудникам не платят. Предполагается, что это их непосредственная обязанность. Возможно, и российские предприятия когда-нибудь придут к этому, но пока реальность такова, что без понимания личной выгоды персонал не будет деятельно участвовать в сокращении потерь. Люди должны четко знать, как они смогут дополнительно заработать, и этот стимул пока остается наиболее сильным.

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

6. Неправильный выбор консультантов. Программы повышения эффективности и сокращения затрат часто требуют привлечения экспертов. Но не любых, а тех, кто был «в поле» и может предоставить документированные результаты своей работы. Избегайте теоретиков и выбирайте практиков.

7. Перекладывание ответственности на консультантов. Самый лучший сторонний эксперт не сделает за руководство и сотрудников их работу. Его задача – довести проект изменений до заранее оговоренной стадии и передать в руки инициативной группы внутри компании.

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

9. Боязнь оптимизации численности персонала. Повышение эффективности и снижение издержек должны приводить к пересмотру штатной численности. Логично, что более эффективное производство нуждается в меньшем количестве людей. Но часто компании не готовы идти на сокращения. В итоге все усилия уходят в песок: производительность труда не повышается (так как работников больше, чем необходимо), зарплата не растет, мотивация лучших сотрудников падает, процесс изменений останавливается.

Понравилась статья? Поделитесь ей

Распечатать статью