Шесть правил успеха ИТ-проектов

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

Тем не менее, согласно последним опросам компании Accenture, всего 29% ИТ-проектов считаются успешными. В среднем 56% превышают бюджет, а 84% выполняются не в срок. В результате десятилетних исследований и реализации методологии управления проектами, можно сказать, что вероятность успеха проектов в сфере информационных технологий сегодня такая же, как  в те времена, когда компьютеры занимали всю комнату.

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

Правило #1: используйте принцип бритвы Оккама

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

Уильям Оккам - английский философ 14-го века. Альберт Эйнштейн перефразировал его, сказав: "Все должно быть сделано как можно проще, но не слишком просто". Примените их советы - разбейте большие проекты в маленькие, более простые проекты и этапы. Начертите каждый этап согласно его способности привнести вклад в общий бизнес.

Данный подход имеет несколько преимуществ:

1. Требования упрощены. С более тесными ограничениями сбор требований концентрируется на самых важных. Остальные же стоит учитывать на будущее. Таким образом, требования более понятны, а между ними будет прослеживаться  четкая связь - поэтому их реализация будет облегчена.
2. Четкая концентрация легко достигается при работе на более  мелких, простых этапах  .
3. Путь к успеху также будет прост, если вы будете чаще представлять заказчикам результаты каждого, даже самого небольшого этапа, чтобы они видели то, что они получат за  свои деньги, время и труд.
4. Более мелкими этапами легче управлять, проверять на качество и соответствие, исправлять, модифицировать и улучшать по ходу изменения требований к факторам среды разработки.
5. Проекты, которые разделены на этапы, легче приостановить по мере изменения условий бизнеса. Сотрудники смогут с легкостью продолжить свои действия позже.

Правило #2 : имейте постоянный резерв

Методология критической цепи (Critical Chain Project) предлагает уделять 20% ваших ресурсов на резервное планирование проекта. Многие финансовые организации готовы уделять 10-15% ресурсов в качестве резервов для больших проектов. В своей книге Slack (2001) Том Де Марко указывает на то, что для достижения наибольшей эффективности людям необходимо 20% времени для бездействия во время рабочего дня.

Как ни странно, но многие руководители проектов уделяют 20% резерва на расписание и 10% - на мелкие расходы в бюджете, но не оставляют людям ничего. Тем самым, несмотря на возможные изменения в проекте и его масштабе, вероятность успеха уже  как бы сокращена на треть.

Это все можно решить при помощи математики: до того, как вы  утвердите бюджет или план проекта, установите 6-часовой рабочий день (20% для резерва) и 15 дней в месяце на проект (учитывая выходные, болезни, собрания и т.д.) - другими словами, 90 часов работы над проектом в месяц для каждого члена команды.

Правило #3: Prioritise the Soft-Side

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

1. Управление трениями между командами проекта, так как  проекты быстро могут стать политически усложненными. Уменьшив политические трения между членами команд, руководитель снижает риск задержки или изменения масштаба проекта.
2. Нахождение нужных людей  - от членов проектной команды до пользователей.
3. Принятие окончательных решений, касающихся внутренних проблем проекта. Когда существуют ограничения на деньги, время и ресурсы, обстановка не столь благоприятна для успеха проекта.
4. Концентрация на достижении конкретных целей проекта. Проекты все чаще насыщены изменениями, ошибочными ожиданиями, самолюбием и т.д. со стороны членов проекта, клиентов и спонсоров. Руководитель проекта должен постоянно  задаваться вопросом "зачем". Требуйте ответов на все вопросы относительно изменений, дополнительных целей и ведите проект ближе к завершению. В конце концов, бизнес нуждается в успешно завершенном проекте.
5. Регулярное выполнение проверки качества, плана, бюджета и ожиданий всех, кто заинтересован. Не стоит детально исследовать все, но кое-что стоит изучить более досконально - выберите 3 случайные части и углубитесь в их изучение, задавая от 5 вопросов по каждому.

Правило #4: общайтесь для обеспечения подотчетности

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

• Цели проекта
• Вовлеченные сотрудники
• Временные рамки (и текущий статус)
• Затраты и распределение (то есть, "кодировка интерфейса покупки ")
• Время собраний
• Документы требований
• Контрольный перечень команд проекта

Вы также можете опубликовать оригинальное экономическое обоснование проекта.

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

• "Когда же мы получим выгоду от данного проекта?"
• "Сколько это будет нам стоить ?"

Используйте правило "5-15": обновление не должно стоить вам более 15 минут, а читатель не должен затратить больше 5 минут на ознакомление.

В-третьих, установите среду общения для членов команды, к примеру  - обмен сообщениями. Это жизненно важно в случае, если команды работают удаленно или же меняются в течение 24 часов. Цель такого общения проста - все должны быть осведомлены.

Правило #5: применяйте критерий Парето

В 1800–х гг. Вильфредо Парето открыл, что маленькая часть любого действия производит большинство результатов. Теперь это называется правилом 80/20, или же принцип Парето, а его применение в мире информационных технологий жизненно важно. Данный принцип интуитивно применяется каждый раз, как вы слышите слово "сойдет".

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

Существует два метода определения тех усилий, которые приносят 80% результатов:

1. Спросите ваших клиентов и команду о том, какие усилия производят больше всего прибыли ? Будьте суровы - убирайте или откладывайте любое тривиальное задание, которое не имеет прямого отношения к выгоде бизнеса от проекта.
2. Развесьте цели проекта в вашем офисе, при презентациях, на вашем веб-сайте проекта и т.д., и обращайте внимание на них при каждом вопросе или изменении. Спрашивайте себя о том, как это улучшит  благополучное завершение вашего проекта.

Правило #6: используйте два тестирования бета-версии

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

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

После того, как проектная команда смогла выявить все проблемы в первом бета-тестировании, соберите вторую команду  - пользователей из каждого отдела. Предпочтительнее выбрать  двух пользователей с каждого отдела - одного, связанного с ИТ-отделом, а другого - не связанного . Второй представляет собой одну пятую пользователей, которые предоставят вам 80% результатов.

На заметку

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

John Avellanet