Документирование команды проекта
Задокументировав объёмы работ, мы понимаем что и как будем делать в проекте. И теперь нужно расписать, кто это будет делать, т.е. задокументировать команду проекта, а вместе с командой определить и остальные человеческие ресурсы проекта, да и все другие ресурсы, требуемые для выполнения намеченных объёмов работ.
Документирование команды происходит от общего к частному, и для начала нам нужно разобраться, какие вообще ресурсы нам потребуются.
Так вот, берём список операций и определяем ресурсы, необходимые для каждой работы этого перечня. Ресурсы могут включать людей, финансы, сооружения, оборудование, материалы, сырьё, инфраструктуру и инструменты. Для того, чтобы каждый раз "не изобретать велосипед", желательно создать единую иерархическую структуру ресурсов верхнего уровня для всех своих проектов и оформить её в виде шаблона. Потом просто открывать шаблон, удалять лишние группы ресурсов, а оставшиеся нужные детализировать под требования конкретного проекта. Использование шаблона иерархической структуры ресурсов позволяет вовремя (ещё на этапе подготовки проекта) вспомнить, какие ресурсы мы ещё не предусмотрели для проекта. Так уж устроен человеческий мозг, если перед глазами промелькнёт упоминание о том, что нам может понадобиться в проекте, мы вспомним об этом, а если не промелькнёт - то узнаем о том что забыли, только во время выполнения работы, и будем как угорелые носиться и добывать нужный нам ресурс.
Используя доступную информацию, мы рассматриваем ресурсы совместно с показателями производительности, основанными на навыках и компетентности людей, производительности машин и механизмов, или характеристиках материалов. Результаты должны быть зафиксированы документе "Требования к ресурсам" с указанием размера или объёма ресурса, качества и источника происхождения, а также сроками начала и окончания использования ресурса в проекте.
Требования к ресурсам определяют типы и количество ресурсов, требуемых для каждой операции в пакете работ. Степень детализации и специфичности описаний требований к ресурсам может различаться в зависимости от отрасли, в которой выполняется проект и масштаба самого проекта.
Требования к ресурсам - это хорошо. Для малых или регулярно повторяемых проектов этого документа даже достаточно, чтоб организовать поставки ресурсов в проект. Но в больших проектах часто возникает ситуация, когда логист, комплектовщик или поставщик, спрашивает ПМ-а, мол, у тебя тут написан "такой-то ресурс", а как ты планировал его раздобыть? Вот для этого мы и делаем ещё один документ, который называется "План ресурсов", описывает способ выполнения требований к ресурсам и может включать в себя обоснование оценки каждого ресурса, а также допущения по типам ресурсов, их доступности и требуемому количеству.
В состав Плана ресурсов входят следующие разделы:
Таким образом, мы в общем описали все ресурсы, необходимые для проекта, и процесс их получения в проект, но проекты исполняют люди! Ни компьютеры, ни документы, ни процессы, ни машины и механизмы, а именно ЛЮДИ! А слаженная работа команды проекта и участие в проекте ключевых заинтересованных сторон – залог успешного выполнения проекта, достижения ожидаемых результатов и принятия этих результатов заказчиками.
Так давайте задокументируем команду нашего проекта!
Поэтому начинаем с документирования организационной структуры, т.е. выявления и описания всех членов команды и других лиц, непосредственно участвующих в работах по проекту. Хотя этот процесс включает в себя назначение обязанностей и полномочий в рамках проекта, наша тема включает только документирование, и мы остановимся только на документальном закреплении этих обязанностей и полномочий, которые могут быть определены на уровне проекта, пакетов работ или конечных работ.
Ты, конечно же, по помнишь, что костяк команды мы уже оформили на этапе старта проекта, здесь мы углубляем и расширяем нашу команду всеми известными на данный момент ролями, и, при необходимости, создаём дополнительные Приказы о назначении персонала и Трудовой контракт. Подробнее об этих документах читай в статье "Документирование проекта на старте". Так как проекты, как правило, выполняются в постоянно изменяющихся условиях, процесс формирования команды проекта обычно выполняется непрерывно на протяжении всего проекта.
Организационная диаграмма проекта – это графическое представление состава команды проекта и отношения между её членами. В зависимости от потребностей проекта она может быть официальной или неофициальной, подробной или обобщенной. Используется эта диаграмма для определения команды проекта, количества персонала, задействованного в проекте; выравнивания персонала в расписании, а также для разработки Плана коммуникаций в проекте.
А вот теперь самое интересное! На данный момент у нас уже оформлены Иерархическая структура работ, Организационная диаграмма проекта и, связывающая их, Матрица ответственности.
Всё это - красивые рисунки и таблички, красноречиво говорящие о высоком уровне зрелости системы документирования в компании, но сами по себе не несущие никакой пользы проекту. И тут на сцену выходит реально работающий документ, который связывает все предыдущие документы с живым человеком, который в нашем проекте будет выполнять некую роль. Причём это не один документ, это ворох документов под общим названием "Ролевые инструкции", а количество документов в этом ворохе равно количеству ролей в нашем проекта.
Данный документ представляет собой текстовое описание роли и готовится на каждую роль, исполняемую командой проекта и обозначенную в Организационной диаграмме проекта. Информация об ответственности, полномочиях, компетенции и квалификации приводится обычно в общих чертах. Роли в проекте могут быть определены как для отдельных лиц, так и для групп. Эти лица или группы могут быть сотрудниками нашей компании или внештатниками и подрядчиками. Заполненные ролевые инструкции передаются соответствующим участникам проекта и являются для них микро-уставом по реализации их микро-проекта в составе нашего большого проекта.
Цель данного документирования - чтоб у каждого пакета работ был однозначный владелец, и чтобы все члены команды имели четкое представление об их роли, ответственности и полномочиях.
А теперь представь, что ты описал ответственность и полномочия для каждой роли. Более того, согласовал эти ролевые инструкции друг с другом, т.е. если в полномочия одной роли входит, например, требовать предоставления информации и консультаций от другой роли, то в обязанности этой "другой роли" необходимо внести это "предоставление". Таким образом проектный менеджер организовывает "круговую поруку" проекта, где каждый каждому что-то обязан и имеет полномочия получать. В итоге у руководителя проекта высвобождается куча времени на действительно важные вопросы проекта, а не на разруливание мелких противоречий во взаимоотношениях команды.
Документирование команды происходит от общего к частному, и для начала нам нужно разобраться, какие вообще ресурсы нам потребуются.
От общего...
Продолжая декомпозировать WBS мы должны дойти до списка операций. О самом списке операций, я подробно расскажу в статье "Документирование длительности проекта"; хочется посвятить этому процессу именно отдельную статью, поскольку для данного документирования применяется особый инструмент, типа Microsoft Project. Сейчас отмечу только одно: список операций - один из ключевых документов в планировании проекта. На основе этого списка определяются ресурсы проекта, создаются график и бюджет проекта.Так вот, берём список операций и определяем ресурсы, необходимые для каждой работы этого перечня. Ресурсы могут включать людей, финансы, сооружения, оборудование, материалы, сырьё, инфраструктуру и инструменты. Для того, чтобы каждый раз "не изобретать велосипед", желательно создать единую иерархическую структуру ресурсов верхнего уровня для всех своих проектов и оформить её в виде шаблона. Потом просто открывать шаблон, удалять лишние группы ресурсов, а оставшиеся нужные детализировать под требования конкретного проекта. Использование шаблона иерархической структуры ресурсов позволяет вовремя (ещё на этапе подготовки проекта) вспомнить, какие ресурсы мы ещё не предусмотрели для проекта. Так уж устроен человеческий мозг, если перед глазами промелькнёт упоминание о том, что нам может понадобиться в проекте, мы вспомним об этом, а если не промелькнёт - то узнаем о том что забыли, только во время выполнения работы, и будем как угорелые носиться и добывать нужный нам ресурс.
Требования к ресурсам определяют типы и количество ресурсов, требуемых для каждой операции в пакете работ. Степень детализации и специфичности описаний требований к ресурсам может различаться в зависимости от отрасли, в которой выполняется проект и масштаба самого проекта.
В состав Плана ресурсов входят следующие разделы:
- Иерархическая структура ресурсов, идентифицированных и оформленных специально для данного проекта.
- Матрица ответственности – структура, приводящая организационную структуру проекта в соответствие с иерархической структурой работ, и помогающая назначить каждому пакету работ ответственное лицо или команду.
- Кадровое обеспечение проекта, позволяющее ответить на ряд вопросов, возникающих при планировании команды проекта, такие как:
- Будут ли люди выделятся из числа сотрудников компании или привлекаться со стороны?
- Должны ли члены команды работать в офисе или они могут работать удалённо?
- Во сколько обойдётся привлечение людей с необходимой квалификацией?
- Какую помощь руководителю проекта могут оказать отдел персонала и функциональные подразделения компании?
- и т.п.
- Календари ресурсов, описывающие необходимые сроки для членов команды проекта, индивидуально или коллективно, а также определяющие, когда должны начаться мероприятия по набору команды и какие ресурсы потенциально доступны в то время, когда запланированы операции.
- План высвобождения ресурсов, который определяет способ и время освобождения членов команды и другие ресурсы, что полезно как проекту, так и членам команды. Когда ресурсы высвобождаются из проекта, расходы, связанные с этими ресурсами не влияют на проект, что позволяет снизить стоимость проекта. Моральное состояние членов команды лучше, когда не происходит передёргивание ресурсов из одного проекта в другой, а все переходы заранее спланированы.
- План обучения персонала, включающий пути помощи членам команды в получении необходимых компетенций и сертификатов, которые будут приносить пользу проекту.
- Признание и поощрения, содержащие критерии для поощрений и описание планируемой системы их использования, что способствует развитию и укреплению желаемого поведения. Установление чётких периодов распределения поощрений гарантирует, что признание и поощрение не будет забыто. Поощряться должно только желательное поведение. Люди мотивированы, если они чувствуют, что их ценят в компании, и это подтверждается наградами полученными ими.
- Соответствие, содержащее описание стратегий выполнения нормативных актов, государственных законов, а также других установленных правил отбора и найма персонала.
- Безопасность, содержащая описание политик и процедур, которые защищают членов команды от угроз безопасности.
Шаблоны документов по общему описанию ресурсов:
|
Так давайте задокументируем команду нашего проекта!
... к частному
На долю руководителя проекта выпадают задачи управления командой, её развития, улаживания внутренних конфликтов, а также управления ожиданиями заинтересованных сторон — он фактически принимает роль посредника между командой и стейкхолдерами. Поэтому необходимо добиться исполнения всех обязательств от всех сторон, вовлечённых в проект. Роли, обязанности и полномочия соответствующие проекту, должны быть определены в соответствии с его сущностью и сложностью и с учетом кадровой политики компании.Поэтому начинаем с документирования организационной структуры, т.е. выявления и описания всех членов команды и других лиц, непосредственно участвующих в работах по проекту. Хотя этот процесс включает в себя назначение обязанностей и полномочий в рамках проекта, наша тема включает только документирование, и мы остановимся только на документальном закреплении этих обязанностей и полномочий, которые могут быть определены на уровне проекта, пакетов работ или конечных работ.
Ты, конечно же, по помнишь, что костяк команды мы уже оформили на этапе старта проекта, здесь мы углубляем и расширяем нашу команду всеми известными на данный момент ролями, и, при необходимости, создаём дополнительные Приказы о назначении персонала и Трудовой контракт. Подробнее об этих документах читай в статье "Документирование проекта на старте". Так как проекты, как правило, выполняются в постоянно изменяющихся условиях, процесс формирования команды проекта обычно выполняется непрерывно на протяжении всего проекта.
Организационная диаграмма проекта – это графическое представление состава команды проекта и отношения между её членами. В зависимости от потребностей проекта она может быть официальной или неофициальной, подробной или обобщенной. Используется эта диаграмма для определения команды проекта, количества персонала, задействованного в проекте; выравнивания персонала в расписании, а также для разработки Плана коммуникаций в проекте.
Всё это - красивые рисунки и таблички, красноречиво говорящие о высоком уровне зрелости системы документирования в компании, но сами по себе не несущие никакой пользы проекту. И тут на сцену выходит реально работающий документ, который связывает все предыдущие документы с живым человеком, который в нашем проекте будет выполнять некую роль. Причём это не один документ, это ворох документов под общим названием "Ролевые инструкции", а количество документов в этом ворохе равно количеству ролей в нашем проекта.
Данный документ представляет собой текстовое описание роли и готовится на каждую роль, исполняемую командой проекта и обозначенную в Организационной диаграмме проекта. Информация об ответственности, полномочиях, компетенции и квалификации приводится обычно в общих чертах. Роли в проекте могут быть определены как для отдельных лиц, так и для групп. Эти лица или группы могут быть сотрудниками нашей компании или внештатниками и подрядчиками. Заполненные ролевые инструкции передаются соответствующим участникам проекта и являются для них микро-уставом по реализации их микро-проекта в составе нашего большого проекта.
Цель данного документирования - чтоб у каждого пакета работ был однозначный владелец, и чтобы все члены команды имели четкое представление об их роли, ответственности и полномочиях.
Шаблоны документов для описанию команды проекта:
|
Итого
С точки зрения документирования, итог планирования ресурсов и команды проекта выглядит следующим образом:- Требования к ресурсам и План ресурсов, дающие полное описание того, какие ресурсы понадобятся для проекта, и каким образом они будут получены в проект.
- Организационная диаграмма проекта и Описание ролей, документирующие команду проекта и определяющие полномочия и обязанности членов команды.
- Приказы о назначении персонала и Трудовые контракты, легализующие роботу сотрудников в компании в целом и над проектом в частности.
- Шаблоны всех этих документов можно получить/полистать здесь:
- ОСУП.ЧР.Комплект по PMBOK (5th edition).
- ИСО21500:Ресурсы по ISO 21500:2012.
- Полный пакет шаблонов, созданных на основе PMBOK (5-й редакции) можно получить здесь: ОСУП.Комплект.v5
- Полный пакет шаблонов, созданных на основе ISO 21500:2012 можно получить здесь: ИСО21500:Комплект
- Все примеры и шаблоны документов портала PMDoc, связанные с управлением человеческими ресурсами различных проектов, можно получить здесь: Человеческие ресурсы.
Оставьте комментарий