Управление корпоративными проектами — централизованное или децентрализованное: технический документ

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

Чтобы загрузить этот технический документ в формате Word, воспользуйтесь ссылкой Управление корпоративными проектами — централизованное или децентрализованное.

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

Управление корпоративными проектами — централизованное или децентрализованное

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

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

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

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

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

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

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

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

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

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

  1. Идентифицировать проблему.

  2. Подобрать решение.

  3. Определить, следует ли автоматизировать решение и, если да, то каким образом.

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

  1. Выбрать автоматизированное решение.

  2. Создать проблему при развертывании решения.

  3. Устранить эту проблему, определив схему применения автоматизированного инструмента к решению.

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

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

За эти годы мне приходилось рекомендовать все возможные типы автоматизированных решений. Конечно же, Project Server — это один из вариантов, но я также рекомендовал использовать сочетание Microsoft Project Pro и SharePoint Server. В других случаях я предлагал комбинацию Excel и Outlook или сочетание расписаний сторонних разработчиков с Project.

Однажды мне даже пришлось порекомендовать использовать большую демонстрационную доску. Честное слово. С этой организацией я сотрудничал много лет. Человек, о котором идет речь, занимался недвижимостью, и ему нужно было возобновить долгосрочные договора аренды. Когда я спросил, в чем проблема, оказалось, что все дело в планировании. Этот сотрудник пропустил несколько важных сроков и был уверен, что с помощью средства для управления корпоративными проектами можно решить проблему. Клиент обратился с просьбой настроить распространение отчетов среди нескольких руководителей высшего звена, чтобы в будущем не пропускать важных сроков. "Сколько будет пользователей?" — спросил я. "Только я", — был ответ. "Сколько таких проектов будет одновременно?" — задал я второй вопрос. Клиент сказал: "Семь или восемь". "А сколько промежуточных сроков вам нужно отслеживать по каждому проекту?" "Это очень сложно. Для каждого проекта предусмотрено примерно шесть сроков", — сообщил он.

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

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

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

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

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

Об авторе

Крис Вандерслуис (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.

×