Набор инструментов для управления проектами

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

ПРЕДЕЛЬНЫЕ ЦЕЛИ: СТАВИТЬ ИЛИ НЕ СТАВИТЬ?

Насколько легко достижимыми должны быть цели проекта, сформулированные в уставе? Можно ли считать нормальным написание устава, в котором поставлены труднодостижимые цели? Практика показывает, что результаты работы тех, кто ставит перед собой цели, фактически недостижимые, как правило, превосходят результаты работы тех, кто ставит реальные цели. Если вы стремитесь получить результат, ставьте цель на грани возможного. Многие менеджеры проектов фирмы Intel так и поступают: корпоративная культура стимулирует подобное поведение. Что происходит, когда они не достигают поставленной цели? Один из менеджеров сказал: «Никто из здешних руководителей не воспользуется этим для того, чтобы завалить вас. Идея в другом – в том, чтобы всегда стремиться к лучшему и прикладывать максимум усилий. Если вы делаете так, у вас не будет никаких проблем в случае неудачи». Но для всех ли компаний это верно? «Если вы стараетесь достичь очень трудной цели и терпите поражение, это играет против вас при оценке работы. Поэтому все в нашей компании ставят перед собой рутинные цели», – говорит менеджер проекта из традиционной компании. Описанный подход приводит к тому, что менеджеры проектов начинают просто плыть по течению.

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

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

Определение целей проекта. Термины «миссия проекта» и «бизнес-цель» допускают широкое толкование. Чтобы дать команде более конкретные указания, устав должен определить конкретные цели проекта (см. врезку «Предельные цели: ставить или не ставить?»), как минимум задать временные, стоимостные и качественные цели.

Временная цель – это желаемая дата завершения проекта, в нашем случае (см. рис. 5.2) 1 ноября 2002 г. Соблюдения этого срока нужно добиться, израсходовав не более 600 часов работы ресурсов при уровне качества, указанном в спецификации. Например, один из элементов качества, определяемых спецификацией, относится к способу представления информации для руководства, а именно к ежемесячному отчету о ходе исполнения более 20 проектов разработки новых продуктов. Данный элемент качества требует, чтобы чтение и интерпретация отчета отнимали у руководителя не более трех минут. Постановка более трех целей достаточно распространена, как показано на рис. 5.2, где такая цель призвана удовлетворить заказчика.

Отбор участников команды и назначение куратора[14 - В оригинале автор употребляет термин спонсор. Однако контекстуальное содержание данного понятия соответствует принятому в англоязычной литературе термину gatekeeper – куратор проекта. Поскольку в русском языке слово «спонсор» имеет явно иное смысловое наполнение, чем в данной монографии, мы не будем его использовать в русской версии книги. – Прим. ред.]проекта. Одна из целей издания устава – официально объявить имена менеджера проекта и, возможно, членов команды. Однако сразу называть всех участников необязательно. В последнем случае предполагается, что функциональные руководители выделят в проект своих подчиненных после издания устава.

В некоторых организациях назначение кураторов в крупные проекты является обычной практикой. Кураторы выдают указания проектной команде, следят за тем, чтобы функциональные руководители соблюдали обязательства по выделению ресурсов в проект, а также служат связующим звеном между проектом и заказчиком [8]. Как правило, в роли куратора (иногда нескольких проектов одновременно) выступает руководитель высшего звена. В случае проектов меньшей важности на должность куратора может быть назначен руководитель среднего звена. Вне зависимости от того, руководитель какого ранга исполняет обязанности куратора, издание устава проекта – удобный способ официально объявить его имя. Впрочем, следует отметить, что в некоторых организациях не существует кураторов проектов.

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

Информирование поставщиков ресурсов. Все функциональные группы или подразделения в организации, которые обязаны поддерживать проект, должны быть надлежащим образом и своевременно проинформированы о его начале [9]. Следовательно, их необходимо внести в список распространения – список сотрудников, которые получат копию устава. Зачем группам такая копия? Для некоторых из них, например для инженерного отдела, устав – это сигнал к началу работ. Для других получение копии устава означает, что проект стартовал и ему требуется поддержка: допустим, отделу кадров придется нанять программистов баз данных для вашего проекта, а у группы информационных технологий возникнет необходимость ввести в используемое программное обеспечение поддержку работы распределенных команд.

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

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

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

Использование устава проекта

Когда использовать. Применительно к крупным проектам устав применяется с начала формального управления проектами, то есть с начала 1950-х годов. Поскольку крупные проекты потребляют значительные организационные ресурсы, которые берутся из различных функциональных групп, такой подход вполне оправдан. По той же причине устав удобен и в отношении малых кросс-функциональных[15 - Довольно удачный термин. В русскоязычной литературе в таких случаях применяется термин многофункциональный, который в меньшей степени отражает существо данного типа проектов. – Прим. ред.] проектов. Однако для других, не кросс-функциональных малых проектов издание устава – редкость (исключением является ситуация, когда члены функциональных подразделений географически рассредоточены, что случается все чаще). Пример использования устава проекта в работе корпораций представлен во врезке «Необходимость устава».

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

Выгоды. Проекты часто требуют таких организационных мероприятий, которые выходят за функциональные границы. Поскольку при подобном кросс-функциональном подходе руководители «владеют» ресурсами, устав представляет собой удобный способ предписать функциональным группам выделить необходимые ресурсы менеджеру проекта. Чтобы указать это в явной форме, во многих компаниях принята практика перечисления функциональных групп (или их руководителей), которые должны предоставить ресурсы, и имен членов проектной команды. Таким образом фактически определяются конкретные ресурсы, их количество и длительность использования в проекте, а также лица, ответственные за их предоставление. Устав не только подтверждает легальность проекта в организации, но также помогает представить проект, объявив о его начале и целях и официально передав бразды правления менеджеру.

НЕОБХОДИМОСТЬ УСТАВА

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

ПРОВЕРКА УСТАВА ПРОЕКТА

Убедитесь, что вы разработали надлежащий устав проекта. Этот устав должен:

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

• включать в себя все элементы, определяемые форматом устава;

• обеспечивать согласованность элементов.

Преимущества и недостатки. Устав проекта характеризуется следующими преимуществами:

• ясность. Будучи, как правило, лаконичным, устав четко фиксирует основные положения проекта и предписывает выполнение его миссии;

• простота. Устав акцентирует внимание на небольшом количестве основных элементов миссии, оставляя за кадром детали и предотвращая «размывание» содержания.

Основной недостаток устава проекта:

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

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

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

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

Резюме

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

SWOT-анализ проекта

Что такое SWOT-анализ проекта?

SWOT-анализ – расширенная версия классического анализа «сильные стороны, слабые стороны, благоприятные возможности, угрозы» на уровне проекта (не на уровне компании). Цель его проведения – оценить потенциал и окружение проекта и действовать в соответствии с ними [10]. Потенциал проекта, выраженный в виде его сильных и слабых сторон, говорит о том, что данный проект может выполнять правильно, а чего не может. Оценка окружения проекта показывает, какие благоприятные возможности представляет и какими опасностями грозит внешний мир. Информация об окружении проекта вкупе со знанием его потенциала дает командам возможность идентифицировать критические факторы успеха (CSF), определяющие удовлетворение нужд клиента (рис. 5.3). Измерение текущего состояния проекта по этим критическим факторам предупреждает о наличии стратегических разрывов и о необходимости продумать стратегию для реагирования на эти разрывы. Осведомленность о наличии разрывов и четко определенный способ реагирования на них позволяют команде сформировать реалистичное содержание проекта и разработать стратегии, необходимые для достижения цели. Говоря кратко, SWOT-анализ должен лежать в основе планирования содержания и способа выполнения проекта.

Проведение SWOT-анализа проекта

Сбор исходной информации. Для того чтобы SWOT-анализ с самого начала взял хороший старт, необходимо наличие следующей ключевой информации:

• устав проекта и обусловившие его документы;

• голос заказчика.

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

Рис. 5.3. Пример SWOT-анализа проекта

Определение требований заказчика. Проекты выполняются для того, чтобы помочь заказчикам удовлетворить требования по части создания продукта или услуги для их потребителей. Как следствие, процесс восприятия голоса заказчика разработан для того, чтобы предоставить менеджеру информацию о нуждах клиента (см. главу 4). При SWOT-анализе количество требований должно быть ограничено только наиболее важными – теми, которые могут спасти или провалить проект. В нашем примере (см. рис. 5.3) заказчик ясно дал понять, что время выхода на рынок является для него очень важным параметром, и потребовал, чтобы срок выполнения данного проекта был сокращен на 30% по сравнению с обычным для проектов такого типа. Это серьезная проблема для компании и команды, имеющей ограниченный опыт реализации проектов разработки нового продукта в режиме быстрого прохода. Поскольку руководство рассматривает проект как возможность выхода компании на новый рынок краткосрочных контрактов, необходимо, чтобы он увенчался успехом. Но что для этого требуется? Ответ заключается в критических факторах успеха.

Выбор критических факторов успеха. По своей сути критические факторы успеха – это области, в которых компания должна действовать эффективно, чтобы проект был успешным [11]. Такие области способны принадлежать двум различным пространствам. Первое – пространство возможностей проекта, включающее в себя все, что имеет отношение к его внутреннему миру. Второе пространство состоит из всего, что связано с проектом, и обычно называется окружением проекта (см. врезку «Ирония судьбы: даже продавец салат-латука может стать критическим фактором успеха»).

Какие именно области из этих двух пространств станут критическими факторами успеха, определяется главным образом требованиями клиента – тем, что мы назвали голосом заказчика. Сначала следует ответить на вопрос, что нужно сделать в рамках проекта, чтобы удовлетворить требования клиента или превзойти их? Лежит ли корень успеха в отличных навыках проектирования или в огромной лаборатории прототипирования? В нашем примере (см. рис. 5.3) критическим фактором успеха является быстрая разработка продукта. Это очень сложный фактор, требующий синхронизации нескольких составляющих, включая параллельный инжиниринг, программное обеспечение для распределенного проектирования, кросс-функциональные команды, владеющие навыками межличностного общения, и календарное планирование. Разумеется, для быстрой разработки продуктов обычно требуется гораздо больше, но мы пока ограничимся перечисленным.

ИССЛЕДОВАНИЕ ОКРУЖЕНИЯ НА ПРЕДМЕТ ВОЗМОЖНЫХ КРИТИЧЕСКИХ ФАКТОРОВ УСПЕХА И РАЗРЫВОВ

Ниже приводится краткий контрольный список общего характера, в котором перечислены области возможного нахождения критических факторов успеха и связанных с ними стратегических разрывов [1, 3]:

• акционеры;