Меня долго занимал один вопрос. Почему внедрение средств управления проектов в России сложнее, чем на западе? Недавно я понял, что причина в не отделении проектной организации от других видов бизнесов.
Чтобы понять роль инструментов «ведения проектов» и «сотрудничества в проектах» (collaboration tools) достаточно понять место проектов в конкретном бизнесе. Как выглядит идеальная структура проектно-ориентированной организации?
Когда основным процессом производства являются «проекты», то каждый проект, как живой организм, включен в более широкий контекст бизнеса. В этом «широком» контексте можно выделить:
- CRM и продажи
- Финансовая поддержка проектов
- Юридическая поддержка проектов
- HR, служба персонала
- Ведение «рабочей среды», environment. То, чем занимается офис-менеджер
- IT-служба, основная цель которой в данном случае - продуктивность проектов.
- Общение с подрядчиками, аутсорсинг, фрилансеры
- Общение с клиентами
Естественно, бизнес в свою очередь включен в намного больший контекст государства, рынков и других элементов. Мы их не будем рассматривать.
Команда как внутренняя структура проекта
Итак, внутренняя структура проекта - это его команда. Команда состоит из
- Экспертов
- Поддерживающего персонала
- Менеджера проекта
Эксперты - это основная движущая сила проекта. Собственно, те, которые вкладывают свои знания и усилия для создания продукта. Это могут быть программисты, архитекторы, маркетологи, консультанты, в зависимости от отрасли бизнеса.
Поддерживающий персонал это те люди, которые делают всю работу, без которой основной продукт «экспертов» нельзя
назвать товаром и продать. В разработке ПО, например, это тестировщики или технические писатели.
В организациях с матричной структурой как эксперты, так и поддерживающий персонал зачастую заняты, кроме конкретных проектов еще и в «поддерживающей» деятельности бизнеса. То есть участвуют и в проектах, и в операционной деятельности всей компании.
Система ведения проектов? Место!
Так каково же место систем поддержки проектного процесса? Что она должна обеспечивать? В такой схеме это
- взаимодействия «внутреннего» круга проекта между собой
- управление проектом
- минимально необходимые взаимодействия с «внешним» кругом
Наиболее важны отношения с клиентом и подрядчиками, вплоть до включения их в команду проекта (в случае customer on-side или фриланса). Поэтому соединения с этими двумя «внешними» секторами обычно становятся частью самого проекта. Цели внедрения отдельной системы для ведения проектов очевидны. Это максимальное использование потенциала команды и фокусирование их на одной цели. Увеличение производительности, скорости и качества проектов. За счет использования как инструментов общения, так и методологий управления проектами.
Опять сложности
Возвращаясь к основному вопросу. В чем же сложность внедрения? Сложность в том, что зачастую в системы ведения проектов стараются «впихнуть» и обслуживание внешнего круга, то есть задачи любого из поддерживающих направлений. Это естественно, ведь стандарты автоматизации существуют на данный момент только для финансов, и частично для CRM / продаж. Таким образом, инструменты ведения проектов используются для процессов не внутри проектов.
Какие именно «мостики» должны соединять систему ведения проектов, и внешние службы? Обычно это соединение или в форме «контактов» от отдела продаж, или «инцидентов» для офис-менеджера, или «отчетов» для финансового отдела и HR.
«Мостики» и работа всех служб в одной среде - возможны. Но разделение «проекты - службы» должно быть четко видно хотя бы руководителям при решении о внедрении системы. И тогда можно ответить на вопрос, что же именно стоит автоматизировать в первую очередь. И как все связать в интегрированную среду.
Ффух! Разобрался! Чего и вам желаю.