показать все 

Часть 1. Определение проектов ИТ, их особенности и место в деятельности организации

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

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

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

Кроме того, как с переездами, так и с ИТ-проектами, постепенно нарабатывается необходимый опыт, и третий проект проходит намного спокойнее и успешнее, чем первый.

Определение проектов ИТ

Прежде всего нам с вами надо определиться, что мы будем считать ИТ-проектом. Скорее всего, когда вы об этом думаете, представляете проект внедрения крупной корпоративной системы. А, например, проект открытия нового магазина, в котором обязательно присутствует и прокладка сетей, и закупка компьютерного оборудования, и установка и внедрение ПО, может ли считаться ИТ-проектом? Скорее всего вы ответите «нет». А если это новый склад интернет-магазина?

Дело в том, что ИТ уже настолько прочно вросли в существование любой организации, что практически каждый проект можно назвать ИТ-проектом, так как там присутствует в большей или меньшей степени ИТ-составляющая. «Что-то тут не так», – наверное, подумали вы. И вы правы, потому что не стоит открытием нового магазина управлять как ИТ-проектом. Впрочем, даже это зависит от ситуации.

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

Поэтому сначала надо определиться с предметом. Я приведу вполне практическое определение, которое мы использовали в холдинге, где я руководила подразделением ИТ: «ИТ-проект представляет собой комплекс мероприятий, из которых не менее 50% по времени или деньгам или человеческим ресурсам связаны с ИТ, в результате которого появляется уникальный, полезный для компании результат. Проект либо длится не менее трех месяцев, либо стоит не менее 100 000 руб., либо в нем принимают участие не менее трех сотрудников разных подразделений организации или не менее семи – причем достаточно одного из вышеперечисленных признаков. ИТ-проектом может быть назначен любой комплекс мероприятий распоряжением генерального директора». Кроме проекта, мы выделяли задачи и изменения и отдельно регламентировали процессы управления первыми и вторыми. Классификацию осуществляли по тем же признакам: время, деньги, команда проекта.

Особенности проектов ИТ

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

Рисунок 1. Наглядное изображение взаимосвязи основных параметров проекта

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

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

Простое соображение: чем сложнее проект, тем больше времени он занимает. За это время как бизнес, так и внутренние процессы организации успевают много раз измениться, и соответственно требования к проекту также меняются. Именно поэтому вопросы управления изменениями такие важные и сложные.

Поэтому, когда говорят или пишут, что проект не достиг ожидаемых результатов, мне всегда хочется спросить: «Каких, кем и когда ожидаемых?» Чаще всего проект как раз достигает тех результатов, которые были запланированы при его запуске тем, кто в тот момент считался Заказчиком проекта. Только слишком часто оказывается, что по окончании проекта эти результаты уже не нужны. Да и Заказчиком, возможно, стал уже совсем другой человек.

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

Как бороться с неустойчивостью результата ИТ-проекта?

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

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

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

Одна из основных сложностей – выявление и сбор потребности в изменениях. Ведь как часто бывает. Идет себе ИТ-проект по намеченному плану, забот у команды проекта хватает, а что, собственно, происходит вокруг, ее не слишком заботит. И вот проект закончен, начинается его сдача бизнес-заказчику, и тут выясняется, что процессы в компании уже изменились и то, что с таким трудом сделали, уже никому не нужно. Поэтому очень важно, чтобы проект ИТ не отрывался от реальности, а развивался в тесном контакте с тем, что происходит в компании и вокруг нее. Именно потому так важно привлечь в команду проекта на роли Спонсора проекта или даже его Руководителя топ-менеджеров бизнес-подразделений. Надо уже на стадии обсуждения проекта объяснить им, что без их участия вероятность бессмысленно потратить на проект время и деньги многократно возрастает.

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

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

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

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

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

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

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

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

Все вышеперечисленное привело к тому, что журнал «БИТ» задумался о цикле статей по управлению проектами ИТ. Вот такому плану мы решили следовать (см. таблицу 1).

//Если вас волнуют эти вопросы и вам интересно их обсудить, то ждем вас в следующих номерах. Чтобы уйти от монотонности монолога к интриге обсуждения, присылайте, пожалуйста, вопросы и комментарии сюда: anshina@mail.ru.

До новых встреч!