Как не завалить ИТ-проект?
Все знают о том, что значительная доля ИТ-проектов заканчивается неудачей. Причины этих неудач различны, но все, кто занимался этой проблемой сходятся в одном: тщательная подготовка снижает риски неудач.
Вопрос в том, что делать во время этой подготовки? Как правильно подготовить проект так, чтобы он удачно завершился?
Почему проекты терпят неудачи?
Традиционно считается, что нужно запланировать все шаги, расписать задачи и все будет хорошо. Однако, если проанализировать неудачные проекты, станет ясно, что практически во всех была проведена такая предварительная работа и все было тщательно спланировано.
Главная причина неудач ИТ-проектов — это НЕ недостаточно детальные планы. Подавляющее большинство проектов терпят неудачу из-за недооценки сопротивления изменениям. Потом, при разборе полетов, это квалифицируют как «человеческий фактор».
Специфика каждого ИТ-проекта состоит в том, что он реализует нематериальную идею. В ходе каждого проекта создается новый, уникальный продукт, бизнес-процесс или еще что-то… Важно то, что до окончания проекта точные параметры конечного продукта никому доподлинно не известны. Это обуславливает высокую степень неопределенности.
Вторая особенность ИТ-проектов состоит в том, что они всегда влекут за собой изменение способа, порядка или условий работы людей. Ведь это люди работают с программами на компьютерах. То есть подавляющее большинство ИТ-проектов приводят к необходимости организационных изменений.
Эти два фактора: высокая неопределенность вместе с неизбежностью организационных изменений и формируют сопротивление изменениям. Оно возникает всегда, в любом ИТ-проекте, в любой компании. Значимость этого сопротивления тем выше, чем большее число людей этот проект затронет. Влияние сопротивления изменениям на ИТ-проект всегда велико.
Преодолейте сопротивление до начала изменений
Я уже писал ранее о природе сопротивления изменениям и о том, как это сопротивление преодолевать.
Вкратце напомню несколько важных вещей:
- в основе сопротивления изменениям лежит психология человека, а не злой умысел, поэтому сопротивление неизбежно;
- преодоление сопротивления состоит в создании правильной мотивации для быстрого прохождения этапов кривой изменений, приказать жить по-новому нельзя
Поскольку ИТ-проекты, чаше всего, затрагивают большое число сотрудников компании, сила сопротивления изменения становится тоже большой и для ее преодоления нужно приложить много усилий. Чтобы не провалить проект, на момент начала организационных изменений, у него должны быть заинтересованные сторонники, которые послужат примером для других и позволят снизить сопротивление изменениям. Сторонники — это не только команда внедрения ИТ-подразделения, их круг должен быть шире и заняться формированием этого круга нужно на самом старте проекта.
Идея достаточно проста: вовлечь ключевых сотрудников в работу по подготовке проекта, так, чтобы основные негативные факторы влияния изменений они пережили «на бумаге», в ходе подготовки проекта. Тогда в активной фазе, когда изменения будут происходить на самом деле, они будут более подготовленными и вместо сопротивления дадут дополнительную поддержку.
Почему такое возможно?
Если вспомнить кривую изменений, то резкий провал после объявления об изменениях вызван низкой информированностью и неясностью будущего — это приводит к рефлексии и снижению производительности. Если человек подготовлен и уже имеет какое-то представление о будущем, понимает свою роль в этом процессе, то вместо рефлексии 1, 2 и 3 этапов изменений он сразу попадет в 4 этап — начнет приспосабливаться к меняющимся условиям, принимая во внимание действия и реакции окружающих. Таким образом, будучи заинтересованным в изменениях, он становится паровозом процесса, а не балластом.
Графически это можно проиллюстрировать так:
В ходе правильно организованного процесса подготовки проекта, каждый из участников рабочей группы моделирует и примеряет к себе будущие изменения: отрицает предложения коллег, держится за собственный опыт, спорит и так далее, тем самым он переживает все стадии процесса изменений, без самих изменений. Он становится более подготовленным к моменту начала преобразований и готов к негативным реакциям его коллег — он сам их переживал и нашел аргументы в пользу изменений. Это позволяет в значительной степени снизить сопротивление.
Что делать на практике?
Теория — это хорошо и красиво, а как этого добиться на практике? Для этого, во время подготовки проекта, нужно следовать очень простым рекомендациям.
1. Определите кто заказчик
Не бывает успешных ИТ проектов без Заказчика (именно так, с большой буквы). Заказчик — это тот, кто на вопрос «Вам нужны результаты этого проекта?», всегда ответит «Да!» и простыми словами, очень быстро сможет объяснить, что это за результаты и какую пользу принесут.
Если вы ИТ компания и реализуете проект для внешнего заказчика, то Заказчик, вроде как априори есть. Но это не всегда так. Часто бывает, что заказчиком по договору выступает ИТ служба, которая является исполнителем внутри компании.
У каждого ИТ проекта обязательно должен быть Заказчик, а лучше несколько, из функциональных, не ИТ подразделений. Это резко увеличивает шансы проекта на успех. Будет очень здорово, если начало проекта будет закреплено приказом и поставлено в план работ не только ИТ департамента.
2. Декларируйте цели
У проекта должны быть ясные цели. Это кажется очевидным, но вопрос «а зачем мы все вместе этим занимаемся» не всегда находит ответ. Нужно закреплять на бумаге конкретные и измеримые цели. Не «повышение эффективности работы», а «уменьшение времени обработки…». Это очень важно, так как именно достижение целей служат основой для поддержки проекта со стороны его участников.
3. Соберите команду
Это обычная практика, когда ИТ-проекты готовят сами ИТ-шники, они мучают всех вопросами «что вам нужно», потом долго пишут ТЗ, потом это ТЗ выполняют и результат бывает никому не нужен. На эту тему есть масса карикатур и публикаций. Чтобы этого не было, нужно чтобы команда подготовки проекта состояла из руководителей отделов и/или ключевых сотрудников тех подразделений, которые будут пожинать плоды автоматизации. ИТ-шники на этапе подготовки должны выступать как эксперты, как методологи, но не как ведущие проект.
4. Фиксируйте образ будущего
В подавляющем большинстве, цель ИТ проекта — изменение какого-то бизнес процесса либо отдельных процедур. То есть заведомо предполагается, что работа людей изменится. Точно изменится ответственность за ввод и использование информации, изменятся порядки. Очень часто команда внедрения или «руководство», то есть драйверы процесса изменений, считают это само собой разумеющимся: «Ну это ведь и так понятно, что работать нужно будет по-другому», говорят они.
Но ведь это «нужно будет по-другому» и есть самое страшное для сотрудников. Очень важно погрузить участников процесса изменений в будущее — вместе с ними придумать и описать как будет организована работа, какие у них будут новые инструменты, как они будут передавать друг другу бумажки и так
далее. Важно, чтобы изменения сначала были пережиты при моделировании и описании бизнес-процессов, а не при их реальном изменении. Это критически снижает сопротивление изменениям.
5. Найдите пользу для всех
«Как будет лучше?», «Что для вас важно?», «Чего нельзя допустить?», «Как вы считаете?» — это главные вопросы, которые руководитель ИТ проекта должен задавать участникам группы внедрения и сотрудникам задействованных в проекте подразделений на этапе моделирования будущего — описания бизнес-процессов. Каждый из участников группы должен самостоятельно найти и зафиксировать для себя то, какую пользу проект принесет именно ему — это обеспечит успех ваших преобразований.
6. Не ленитесь писать
«То, что написано пером, не вырубить и топором» — народная мудрость.
Считайте, что того, что не зафиксировано на бумаге не существует. Если вы придумали суперпроцесс, сидели, все жарко спорили, кивали, но вы не потрудились документально зафиксировать его в понятной всем форме — будьте уверены, через день все о нем забудут и следующее обсуждение вы начнете с чистого листа — как будто ничего не было! Поэтому, если вы хотите, чтобы ваши идеи не пропали — записывайте, документируйте!
7. Не думайте за других
Не считайте, что вы что-то знаете лучше других. Если вы считаете, что то, что вы придумали будет удобно и полезно — убедитесь с этом, не откладывайте до внедрения. Не нужно делать людям сюрпризы — расскажите о том, что вы придумали, объясните, как все будет происходить и внимательно выслушайте оценку. Не спорьте, даже если оценка будет не той, которую вы ожидали. Просто примите это к сведению и сделайте необходимые поправки в проект. Важно, чтобы
люди получили в результате внедрения то, что они ожидают! Только в этом случае, они будут оказывать поддержку.
8. Принимайте решения
Уход от принятия решений — частая ошибка ИТ-менеджера. Если Вас спрашивают: «Как ты считаешь, как лучше?», не отвечайте в стилистике «Ну… это как тебе будет лучше, так и лучше…». Скажите ваше мнение, уверен, оно у вас есть.
9. Планируйте внедрение вплоть до фиксации результата
Очень простое правило: «Сделано» — это не значит «Я сделал», это значит: «Мне сказали, что то, что я сделал полезно».
Про это много говорят, но мало кто утруждает себя получить подтверждение того, что результат проекта востребован и принес кому-то пользу. А это очень важно. Поэтому, планируя проект нужно не ограничиваться разработкой и приемкой, а закладывать также время и ресурсы на оценку результата Заказчиком.
Заранее подумать вместе с ним о том, как он будет оценивать результат.
10. Напишите отчет
Даже если вас не просят и у вас так не принято, напишите отчет по окончании проекта. Во-первых, это явно даст знать о том, что он завершился. Часто этой точки очень не хватает. А во-вторых — это будет явной декларацией результатов проекта, которым нужно будет дать оценку. Ведь если нет результата — то нет и оценки.
На фоне тех титанических усилий, которые пришлось приложить всей компании, чтобы сделать все задуманное, на фоне споров, разочарований и бессонных ночей, цели и задачи проекта часто растворяются, его результаты становятся само собой разумеющимся. И без такой фиксации результатов участники проекта могут остаться неудовлетворенными своей работой.
Кратко опишите цели проекта, дайте свою оценку достигнуты они или нет. Проведите анализ достижений и неудач, Напишите о том, что получило каждое задействованное в проекте подразделение, дайте оценку изменениям, отметьте участников проекта, выделите тех, кого хотите отметить особо. Отправьте отчет группе внедрения и своему руководителю, даже если у вас в компании так не принято — вы увидите насколько положительный это даст результат.
© Megamozg
