Решение EPM: централизованное или децентрализованное?
Эта статья является частью нашей коллекции "Из окопов". В ней описывается, как организациям необходимо понять проблемы, которые они пытаются решить при принятии решения о внедрении системы управления проектами. Иногда развертывание централизованной системы управления проектами может оказаться не лучшим решением.
Чтобы скачать версию этой статьи в Word, см. раздел EPM-Централизованный или Децентрализованный?.
Дополнительные статьи см. в технических документах "Из окопов".
EPM — централизованная или децентрализованная?
Я был сторонником управления корпоративными проектами с тех пор, как я впервые вошел в индустрию управления проектами в начале 1980-х годов. Тогда вы думаете, что я всегда буду голосовать на стороне централизованного управления проектами, но это не всегда так. Давайте обсудим на минуту, что мы имеем в виду под управлением корпоративными проектами.
EPM может означать много разных вещей для разных людей. В других статьях этой статьи я уже говорил о том, как развертывание EPM может быть сосредоточено на управлении документами для одной организации и интегрированных расписаниях для следующей. Однако в основе управления корпоративными проектами лежит идея о том, что люди должны взаимодействовать друг с другом в упражнении по управлению проектами. Это означает, что руководитель проекта и (или) команда по управлению проектами не работают полностью независимо. Но означает ли это, что единственным способом достичь этого "взаимодействия" является централизованная система планирования проектов? Не обязательно. Для некоторых организаций задача управления проектами может заключаться в невозможности составления сводных отчетов по управлению проектами на уровне предприятия из-за того, что все проекты управляются на нерегламентированной основе. В этом случае EPM может быть достигнут только за счет использования стандартов проекта, которые совместно используются всем сотрудникам по управлению проектами. Лучше всего этого можно добиться с помощью центрального пула шаблонов, учебных материалов, документов и стандартов отчетов, которые могут использовать все пользователи. Возможно, достаточно простого сайта SharePoint.
В некоторых организациях проблема управления проектами может быть неэффективным личным расписанием из-за отсутствия связи между ресурсами о том, над чем они работают и каково их следующее внимание. В этом случае EPM может быть достигнут за счет улучшения командной и межкомандной коммуникации. Эти инструменты могут быть простыми, как общий календарь, обмен мгновенными сообщениями или общий портал, где пользователи могут перечислить свои приоритеты.
В некоторых организациях задача управления проектами заключается в том, чтобы просто получить прогресс в проектах разработки программирования. Если это так, то инструментов, уже имеющихся в продукте, например Visual Studio Team Services, может быть достаточно. В проектах программирования часто обнаруживается, что многие задачи могут быть выполнены практически в любом порядке, поэтому строгость планирования критического пути может даже не соответствовать типу выполняемой разработки.
Я помню, как несколько лет назад работал с отделом технического обслуживания авиакомпании. Персоналу было разрешено выбирать свои собственные графики в начале каждого месяца, и если это не было скоординировано (как это часто бывает), можно было приехать, чтобы управлять сменой, только чтобы узнать, что никто не работает. Их задача управления проектами не была "Когда работа будет завершена?" Это было "Кто-нибудь придет на работу?" В этом случае EPM был достигнут путем реализации средства планирования смен.
Даже если задача EPM сосредоточена на расписаниях проектов, не сразу очевидно, что развертывание централизованной системы управления проектами является единственным или лучшим решением. Стоит спросить, какое взаимодействие между собой должны иметь сотрудники по управлению проектами. Если они должны регулярно сотрудничать для разрешения конфликтов ресурсов, чтобы узнать, какие другие приоритеты в организации выдвигаются, или увидеть, как ход выполнения одного проекта повлияет на другой, то, глядя на такое средство, как Project Server, имеет смысл, но часто я в конечном итоге взаимодействую с организациями, которые даже не задавались этим вопросом.
В некоторых организациях мы находим небольшое количество планировщиков и большое количество ресурсов. Даже в организации хорошего размера это может быть структура в зависимости от отрасли и типа выполняемых проектов. Не так давно я встретился с организацией, которая была уверена, что они выбрали правильное решение для их EPM задачи. Они попросили меня сформулировать решение, но, как обычно, я попросил, чтобы они сначала сформулировать свою проблему управления проектом.
К тому времени, когда они были сделаны описывать свою среду на белой доске было очевидно даже для них, что решение, которое они выбрали, не собирается решить их проблему.
В этом случае проблема связана с отсутствием хода выполнения проекта, о чем сообщает большой пул субподрядчиков. Клиент решил, что ей действительно нужно будет навязать время и тип выставления расписания своим субподрядчикам. Директор программы был неугомело. "Мы никогда не сможем получить это в контрактах субподрядчика", сказали они. К счастью, присутствовал сотрудник финансового отдела. "Вы знаете", этот человек ответил, "предложение, которое требует от них заполнить расписание по нашему выбору, уже находится в договоре субподрядчика". Проблема решена.
Идея пройти через проблему, прежде чем прийти к решению, один я говорю о часто здесь, но это трудно принять. Логическое мышление будет диктовать, что порядок определения автоматизированного решения будет следующим:
Определение проблемы
Определение решения
Определите, следует ли (и, если да, то как) автоматизировать решение.
Автоматизированные демонстрации решений на веб-сайтах, видео и в других местах заставляют нас забыть об этом. Конечно, мы не ищем решение, если у нас нет какой-либо проблемы, но автоматизированные решения выглядят настолько убедительными, что в конечном итоге мы делаем это:
Выбор автоматизированного решения
Создание проблемы при развертывании решения
Решение этой проблемы путем определения способа применения автоматизированного средства к решению
Попробуйте вспомнить, в чем была исходная проблема
Новая проблема становится развертывание решения в течение довольно некоторого времени, а затем недель, месяцев, или даже пару лет в пути кто-то из высшего руководства спрашивает, когда исходная проблема будет решена, и все смотрят друг на друга довольно удивлены. Это было легко забыть о.
На протяжении многих лет я рекомендовал все виды возможных автоматизированных решений. О, Project Server был одним из вариантов, конечно, но я также рекомендовал сочетание Microsoft Project Pro и SharePoint Server. Я рекомендовал использовать сочетание Excel и Outlook. Я рекомендовал использовать сторонние расписания с Project.
Я даже однажды рекомендовал использовать большую белую доску. Честным. Организация была одна, с которым я занимался бизнесом в течение многих лет. Человек, о которой идет речь, был в роли недвижимости и должен был продлить долгосрочную аренду недвижимости. Когда я спросил, в чем проблема, это явно проблема планирования. Человек пропустил несколько сроков, которые были важны, и был уверен, что корпоративное средство управления проектами исправит проблему. Организация уже попросила, чтобы отчеты были распространены среди нескольких руководителей, чтобы будущие сроки не были пропущены. "Сколько пользователей будет?" Я спросила. "Только я", ответил он. "Сколько из этих проектов есть за раз?" Я спросил: "Семь или восемь", ответил он. "И сколько из этих вех сроков вы управляете для каждого проекта "Это очень сложно. Есть около полдюжины сроков для каждого из них", сказал он мне.
Мне уже было ясно, что мы не должны устанавливать большую централизованную систему EPM для этого бедняжки.
"Почему бы просто не положить большую белую доску в вашей кабине и использовать некоторые цветные маркеры для различных вех?" Я спросила. "Вы можете использовать синий для первого, зеленый для второго, красный для последнего и т. д.
Он взял обильные заметки, очарованный концепцией. Я покинул фирму, зная, что я не продал никаких услуг или продуктов в тот день, но что я оставил человека разочарован тем, что он не может развернуть систему, которую он предусмотрел. По дороге домой мой телефон зазвонил в машине. Это был он. "Не могли бы вы объяснить различные цвета для белой доски?" Спросил он.
Выяснить, какие проблемы вы пытаетесь решить, прежде чем разрабатывать решение, и прежде чем вы выберете, как его автоматизировать, не просто сэкономить деньги. Это может сэкономить огромное количество времени, затрачиваемого на работу с элементами организации, у которых не было проблем, требующих решения в первую очередь.
Если проблемы, которые вы пытаетесь решить, лучше всего решить с помощью централизованного корпоративного программного обеспечения для управления проектами, то ничего другого не будет делать, но внимание, которое вы получите, сформулировать проблему, поможет даже там. Команда развертывания может создать метрики успеха, которые позволяют объявлять проект успешным при устранении проблем. Централизация или децентрализование? Управление корпоративными проектами можно реализовать с помощью любого из этих способов.
Об авторе
Крис Вандерслуис (Chris Vandersluis) — президент и основатель канадской компании HMS Software( Монреаль), сертифицированного партнера Майкрософт. Он имеет степень экономики в Университете Макгилла и более 30 лет опыта в автоматизации систем управления проектами. Он является давним членом Института управления проектами (PMI) и помог основать отделения Монреаля, Торонто и Квебека группы пользователей проекта (MPUG). Публикации, для которых Крис написал, включают Fortune, Heavy Construction News, Computing Canada magazine, PMNetwork PMI, и он является регулярным обозревателем Project Times. Он преподает расширенное управление проектами в Университете Макгилла и часто выступает в функциях ассоциации по управлению проектами в Северная Америка и по всему миру. HMS Software является издателем системы хронометрирования, ориентированной на проекты TimeControl, и с 1995 года является партнером по решению проектов Майкрософт.
С Крисом Вандерслуисом можно связаться по электронной почте по адресу: chris.vandersluis@hms.ca
Если вы хотите прочитать дополнительные статьи Криса Вандерслуиса, связанные с EPM, см. на сайте руководства по EPM HMS (https://www.epmguidance.com/?page_id=39).