10 ключевых рисков IT проектов

Риски — это неизбежная реальность любого бизнеса. Избежать их полностью практически никогда невозможно. Управление рисками строится на том, чтобы минимизировать вероятный ущерб и повысить эффективность деятельности компании. Алексей Александров, генеральный директор компании SEBEKON, рассказал «Бизнесологу», как управлять рисками в IT-проектах.

Новости бизнеса и подборка кейсов — в вашей почте:

Генеральный директор компании SEBEKON Алексей Александров, эксперт в области разработки сложных web-проектов

Алексей Александров, генеральный директор компании SEBEKON, эксперт в области разработки сложных web-проектов.

— Шеф, я заболел. Работать в ближайшую неделю не смогу.

— Нет, договор на подключение эквайринга мы не заключили еще.

— А давайте сделаем так. Я точно не знаю как, но хочется попробовать.

— Ой, а начальник еще не согласовал дизайн. И вообще он сейчас в отпуске, вернется через две недели.

Знакомо? Все эти фразы — это иллюстрации рисков, которые возникают в любом it-проекте.

За всеми it-рисками, на наш взгляд, почти всегда стоят люди:

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

Если не классифицировать и не оценить риски на подготовительном этапе, то у заказчиков есть большая вероятность либо сильно затянуть сроки внедрения, либо вовсе не получить проект, а у подрядчиков — нарушить сроки или вовсе провалить проект и чувствительно ударить по репутации.

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

Как мы управляем ИТ-рисками
ИТ-риски и их классификация

Как мы управляем ИТ-рисками

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

ИТ-риски, таблица — Управление ИТ-рисками. База рисков и решений по их предотвращению и минимизации в таблице Excel

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

ИТ-риски и их классификация

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

ИТ риски: классификация — Классификация ИТ-рисков

Рамки статьи не позволяют детально рассмотреть все существующие риски, поэтому мы выбрали из своей практики пример проекта по разработке CRM-системы.

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

1. Недостаточная поддержка проекта со стороны заказчика

Степень риска: низкая.

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

Чтобы уменьшить риск, необходимо:

предоставить руководителю проекта необходимые полномочия;
привлечь в рабочую группу (далее: РГ) экспертов с необходимыми для проекта компетенциями.

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

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

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

2. Недостаточная поддержка со стороны пользователей ИТ-системы

Степень риска: средняя.

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

Чтобы уменьшить риск, необходимо:

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

В среднем в проекте бывает 5-6 итераций. Если пренебречь последним пунктом, то подрядчик может допустить ошибки, которые фатальным образом скажутся на функционировании всей системы.

3. Несоответствие реализации бизнес-процессов в системе ожиданиям заказчика

Степень риска: низкая.

Недопонимание бизнес-процессов заказчика подрядчиком может привести к несоответствию реализованной системы ожиданиям заказчика.

Для преодоления данного риска необходимо:

согласовать протоколы встреч с участниками со стороны заказчика.
настроить и провести показ прототипов системы для детализации требований.

4. Расширение функциональных требований в процессе реализации проекта

Степень риска: средняя.

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

Чтобы уменьшить риск, необходимо:

ответственно относиться к выработке требований к системе на подготовительных этапах и согласованию итоговых документов;

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

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

Для преодоления риска следует обсудить расширения и после этого принять одно из решений:

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

5. Недоступность членов рабочей группы

Степень риска: низкая.

Физическое отсутствие одного или нескольких членов РГ может привести к задержке решения вопросов по проекту и к увеличению сроков проекта.

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

6. Изменение состава рабочей группы

Степень риска: средняя.

Смена участников РГ в ходе проекта может привести к нарушению сроков и низкому качеству работ.

Чтобы уменьшить риск, необходимо:

заранее планировать встречи с учетом отпусков и командировок;
мотивировать участников проекта сохранять состав РГ в неизменном виде.

Для преодоления риска необходимо:

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

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

Для подрядчика этот риск связан с рисками 8 и 9. Например, заказчик не предоставил нужные документы и\или доступы к сторонним сервисам. Руководитель проекта перебрасывает разработчиков на другой проект, чтобы у них не было простоя в работе. В итоге, когда доступы получены, разработчики могут быть еще заняты на другом проекте. И тут заказчику либо приходится ждать, когда они освободятся, либо опять ждать, когда другие разработчики вникнут в проект.

7. Изменение бюджета и сроков проекта

Степень риска: низкая.

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

Чтобы уменьшить риск, необходимо:

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

Для преодоления риска необходимо своевременно провести встречи со всеми сторонами и выработать согласованный план действий:

сдвиг плана проекта;
уменьшение объема работ;
перенос работ на другой этап и т.д.

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

Степень риска: низкая.

В случае несвоевременного предоставления заказчиком документов, необходимых для реализации проекта, возможен сдвиг сроков реализации этапа ТЗ и проекта в целом.

Чтобы уменьшить риск, необходимо:

заранее сформировать запрос на предоставление документов в начале разработки ТЗ;
составить график предоставления документов;
включить данные по статусу получения документов в отчет по проекту.

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

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

Степень риска: средняя.

В случае несвоевременного предоставления заказчиком тестовых / боевых доступов к сторонним сервисам, необходимым для реализации проекта, возможен сдвиг сроков запуска.

Чтобы уменьшить риск, необходимо:

сформировать запрос на предоставление доступов в процессе разработки ТЗ;
составить график предоставления доступов;
включить данные по статусу предоставления доступов в отчет по проекту.

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

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

10. Неполнота отражения ожидаемых результатов проекта

Степень риска: средняя.

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

Чтобы уменьшить риск необходимо:

документировать все существенные результаты встреч и совещаний в протоколах или иных документах;
согласовывать в письменной форме протоколы встреч со всеми участниками.

Для преодоления риска необходимо оперативно добавить новую утвержденную и согласованную информацию во все исходные документы и устранить все разногласия.

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

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

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