Сверху вниз или снизу вверх: технический документ

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

Чтобы загрузить этот технический документ в формате Word, воспользуйтесь ссылкой Сверху вниз или снизу вверх: технический документ (Project Server 2010).

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

Сверху вниз или снизу вверх?

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

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

Однако это не так.

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

Управление портфелем: направление "сверху вниз"

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

Панель мониторинга со статусом нескольких проектов

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

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

Управление проектами: сверху вниз и снизу вверх

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

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

Основные этапы проекта, отображаемые на диаграмме

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

Пока все хорошо.

Представление "Диаграмма Ганта" для проекта

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

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

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

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

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

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

Управление задачами: направление "снизу вверх"

Когда дело касается управления задачами, мы склонны мыслить категориями операций, а это чаще всего приводит нас к повестке на каждый день и такому продукту, как Outlook.

Вид списка задач

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

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

Обманчивая схожесть данных

Мы говорим: "Если что-то выглядит как утка и крякает как утка, значит, это должна быть утка". Это верно для уток, но для данных, связанных с задачами, — не всегда.

Рассмотрим эти три уровня проектных данных:

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

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

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

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

Меня часто спрашивают, можно ли перемещать данные из представления портфеля в представление проекта в Outlook и обратно.

Краткий ответ на этот вопрос — да.

Однако у нас в компании есть мантра, которую мы твердим про себя, когда даем технические советы: "Не говори мне, как это сделать. Скажи, зачем мне это делать".

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

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

  3. Мы используем назначения ресурсов, чтобы передать данные задач и назначений каждому пользователю в виде задачи или события календаря Outlook. Пользователям больше не нужно входить в "систему управления проектами". Теперь они видят нужные данные в своих повестках на каждый день. Эти данные выглядят так же, как в списке проектов, и связаны (в направлении снизу вверх) с представлением портфеля.

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

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

Клиенты постоянно просят нас создать структуру именно такого типа. Мы, конечно, можем это сделать, но стоит ли?

Представьте, что на уровне задач один сотрудник берет отгул на первую половину дня, потому что ему срочно нужно к стоматологу, и обновляет данные в Outlook, указав, что не будет доступен сегодня утром. Для него это неприятное событие, но оно может оказать огромное влияние на проект. Система управления проектами определяет, что задача, запланированная на это утро, не будет выполнена сегодня и ее удастся завершить только завтра к обеду. Выполняется проверка критического пути, и все задачи, которые зависят от этой, сдвигаются на четыре часа. Этот эффект может затронуть сотни задач. Возможный результат всего этого — сдвиг даты окончания проекта на полдня. Другие проекты также могут пострадать, ведь исполнителям, работающим с этим проектом, придется переупорядочить свои задачи. В итоге даже представление портфеля немного сдвинется.

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

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

Кроме того, хотя данные выглядят одинаково, их интеграция никогда не выполняется таким образом — именно из-за этого эффекта.

Контекст данных имеет значение

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

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

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

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

Смешивание этих концепций и контекстов без учета возможных последствий может привести к хаосу.

Сверху вниз или снизу вверх?

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

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

Схема рабочего процесса

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

Действительно ли нужно, чтобы алгоритм выравнивания загрузки ресурсов в корпоративной системе управления проектами учитывал визит конкретного сотрудника к стоматологу, или достаточно приблизительных сведений о доступности этого человека?

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

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

Об авторе

Крис Вандерслуис (Chris Vandersluis) — основатель и президент компании HMS Software, расположенной в Монреале, Канада, которая является партнером Майкрософт со статусом Microsoft Certified Partner. Он получил степень по экономике в университете Макгилла и имеет более чем 30-летний опыт работы в области автоматизации систем управления проектами. Он много лет является членом Института управления проектами (PMI) и оказывал содействие в основании местных отделений группы Microsoft Project Users Group (MPUG) в Монреале, Торонто и Квебеке. Крис публиковался в таких изданиях, как Fortune, Heavy Construction News, журнал Computing Canada и PMI PMNetwork, а также ведет колонку в Project Times. Он преподает углубленный курс управления проектами в университете Макгилла и часто выступает на специальных мероприятиях ассоциации управления проектами в Северной Америке и по всему миру. Компания HMS Software является разработчиком системы TimeControl, предназначенной для учета рабочего времени в рамках проектов, и с 1995 г. является партнером со статусом Microsoft Project Solution Partner.

Вы можете написать Крису Вандерслуису по следующему адресу электронной почты: chris.vandersluis@hms.ca

Если вы хотите прочитать другие статьи Криса Вандерслуиса, посвященные управлению корпоративными проектами, посетите сайт EPM Guidance компании HMS (http://www.epmguidance.com/?page_id=39).

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

Были ли сведения полезными?

Спасибо за ваш отзыв!

Благодарим за отзыв! Возможно, будет полезно связать вас с одним из наших специалистов службы поддержки Office.

×