Я — Роман Резников, работаю в Project Management Office компании SoftServe. Одно из направлений моей работы — развивать компетенцию Service Manager и подходы в компании по работе с сервисными проектами (SLA-проекты, support, etc.). В этой статье я сделаю краткий сравнительный обзор двух источников best practices. Это позволит вам сориентироваться, что стоит добавить в свой арсенал PM’а.
В чем проблема
Для большинства проектных менеджеров (даже Agile) классическим источником best practices для ведения проектов является PMBoK. Те, кто хоть раз заглядывал в PMBoK, помнят, что проект ограничен по времени, уникален, имеет четкий скоуп. Но если посмотреть на большинство проектов в ІТ, особенно в сфере ІТ-аутсорсинга — чаще всего это T&M или Dedicated Team, — то такая форма кооперации больше похожа на сервис. По сути, мы предоставляем клиенту услугу, сервис разработки программного обеспечения, а настоящим проектом можно считать, скорее, Fixed-Price. Так что если у вас с клиентом контракт, по которому вы предоставляете ресурсы, а не конкретный результат, смело можно считать его сервисом. Не то чтобы PMBoK в таком случае вам не подходил, но это означает, что стоит обратить внимание и пристально изучить еще один источник знаний — ITIL (особенно такие разделы, как Service Level Management, Capacity/Availability Management, Request Fulfilment и Incident Management).
PMBoK — американский национальный стандарт управления проектами, который описывает лучшие практики управления проектами. То есть для ограниченного во времени объема работ, который направлен на создание уникального продукта, услуги или результата. Согласно PMBoK, сервис относится к операционной деятельности (не является проектом), а значит, практики PMBoK на него не распространяются (но никто не запрещает их применять).
Как раз такой вид деятельности покрывают практики из ITIL. ITIL (IT Infrastructure Library) — это наиболее широко используемый и общепринятый подход к управлению ІТ-услугами во всем мире. ITIL был разработан относительно независимо от управления проектами, воплощает несколько ценных идей управления и включает проверенные процедуры, которые могут быть полезны также для практики управления проектами.
Сравнение процессов
PMBoK представляет best practices в виде 49 процессов, каждый из которых состоит из набора входов (Inputs), выходов (Outputs), инструментов и методов (Tools and Techniques). Пример процесса из PMBoK:
ITIL построен схожим образом, но все же отличается по структуре. Согласно оглавлению основных книг (Core library), в ITIL 26 процессов, однако существуют и так называемые подпроцессы, например Service capacity management или Component capacity management, которые лишь коротко описаны в составе процесса Сapacity management, не имея стандартной для ITIL структуры описания процессов. Кроме того, в ITIL есть виды деятельности, упоминаемые в тексте как процессы, но не имеющие отдельного описания вообще. Общая структура процесса в ITIL:
Как видно, структура процесса в ITIL чем-то похожа на процесс из PMBoK. Из общего у процессов это входы и выходы, техники и методы, в ITIL, собственно, это и называется процессом. Отдельно в ITIL выделяют исполнителей процесса и контроль за процессом, в то время как контроль и мониторинг выделены в PMBoK в отдельную группу процессов. Так выглядит общая картина процессов:
Как видно из таблиц, процессы в ITIL сгруппированы по 5 стадиям жизненного цикла сервиса (Service Strategy, Service Design, Service Transition, Service Operation, Continuous Service Improvement). Помимо 26 процессов описывается еще 4 функции. В PMBoK больше процессов и чуть сложнее их структура. 49 процессов объединены в 5 групп процессов (Initiation, Planning, Executing, Monitoring and Controlling, Closing); помимо этого, 49 процессов классифицированы по областям знаний. Часто группы процессов путают со стадиями жизненного цикла проектов, но это ошибочно. Из-за этого есть предвзятое отношение к PMBoK = Waterfall, что тоже неверно.
Таким образом PMBOK группирует процессы в матрицу для удобства навигации. В ITIL и PMBoK нет одинаковых процессов, но есть похожие. К примеру, менеджмент изменений (Change management) в ITIL и интегрированный контроль изменений (Integrated change control) в PMBoK.
| Интегрированный контроль изменений (Integrated change control) в PMBoK | Менеджмент изменений (Change management) в ITIL |
| Согласно PMBoK, интегрированный контроль изменений — процесс анализа всех запросов на изменения, их одобрения и управления изменениями поставляемых результатов, а также предоставления информации об их состоянии.
В ходе этого процесса происходит анализ всех запросов на изменение результатов, а также утверждение или отклонение изменений. Ключевая выгода данного процесса состоит в том, что он позволяет учитывать документированные изменения в проекте, уменьшая риски проекта, которые часто возникают в связи с изменениями, внесенными без рассмотрения. Процесс интегрированного контроля изменений проводится с самого начала проекта и вплоть до его завершения, он является ответственностью руководителя проекта. Запрос на изменение может подать любая заинтересованная сторона, вовлеченная в проект. Хотя изменения могут быть инициированы устно, они обязательно должны быть зарегистрированы в письменной форме и переданы в систему управления изменениями и/или управления конфигурацией. Каждый документированный запрос на изменение должен быть либо одобрен либо отклонен ответственным лицом, обычно спонсором или руководителем проекта. При необходимости в процесс интегрированного контроля изменений включается совет по контролю изменений (CCB) — формально созданная группа, ответственная за изучение, оценку, одобрение, отсрочку или отклонение внесения изменений в проект, а также за фиксацию соответствующих решений и информирование о них. Одобренные запросы на изменения могут потребовать создания новых или пересмотра старых оценок стоимости, последовательностей операций, дат расписания, потребностей в ресурсах и анализа альтернатив реагирования на риски. Эти изменения могут потребовать внесения поправок в план управления проектом или в другие документы проекта. | В книге Service Transition, которая входит в библиотеку ITIL, менеджмент изменений описывается как процесс контроля жизненного цикла всех изменений и принятие необходимых изменений с минимальными негативными последствиями для ІТ-сервисов.
Ключевая выгода данного процесса в том, что он позволяет вносить изменения в ІТ-сервисы, чтобы они отвечали требованиям бизнеса. Все изменения должны быть оценены, записаны и утверждены. В менеджмент изменений не входят изменения в бизнес-процессы. Изменением считается любая модификация или удаление любого компонента, который может оказать влияние на ІТ-сервис. Запрос об изменении обычно имеет стандартную, заранее утвержденную форму (RFC). ITIL выделяет 3 вида изменений:
Для авторизации изменений утверждается группа (CAB — Change Advisory Board), которая помогает менеджеру изменений оценить, приоритизировать и утвердить изменения. Все члены группы должны обладать авторитетом и необходимым опытом, чтобы оценить изменение. Отдельно создается группа по утверждению срочных изменений (Emergency Change Advisory Board). Такая группа часто собирается в срочном порядке для оперативной оценки срочных изменений. |
Как видно из описания, взятого из официальных источников, оба процесса имеют много общего. Оба требуют предварительной оценки перед внедрением любого изменения, тщательного документирования; оба предполагают процедуру утверждения, которая может осуществляться как специально выделенной группой людей (CCB в PMBoK или CAB и ECAB в ITIL), так и отдельно взятым человеком (руководитель проектов или спонсор в PMBoK и менеджер изменений в ITIL).
Интегрированный контроль изменений (Integrated change control) в PMBoK:
Таким образом, можно заметить, что подходы в PMBoK и ITIL довольно схожи.
Различия
Рассмотрим несколько подходов, которые различают эти два стандарта. Они помогут нам по-другому взглянуть на некоторые вещи.
User vs Customer
ITIL различает заказчиков и пользователей. Заказчик определяет требования, заказывает проект, оплачивает его и утверждает (принимает) результаты проекта, в то время как пользователи используют результат проекта на ежедневной основе, не имея реальных полномочий для принятия решений (но они могут оказать влияние на заказчика). Обычно заказчик является лидером организации, а пользователи — ее членами. Заказчик и пользователь могут иметь разные интересы. Руководство PMBoK в настоящее время не дифференцирует эти роли. В действительности эти две роли часто путают между собою или применяют общий к ним подход, что часто является ошибкой.
Incident Management & Request Fulfilment
Проект по своей природе не предполагает, что мы получаем новые порции требований или запросы где-то в середине проекта. Точнее, такое может случиться, но каждый такой запрос должен пройти через Integrated Change Control — процесс, в результате которого должны получить модификацию baseline’ов проекта (scope baseline, quality baseline, schedule baseline and cost baseline). В общем, процедура непростая. Но как же быть, когда мы работаем по Scrum или Kanban? Мы получаем новые порции работы каждую итерацию, а то и чаще. Как правильно поступать с такими запросами и обрабатывать их, можно подсмотреть в ITIL в разделах Incident Management и Request fulfilment.
Problem Management
И ITIL, и PMBoK предлагают инструментарий для идентификации и решения проблем (хотя термин problem оба стандарта видят немного по-разному). PMBoK богат набором различных техник и инструментов, которые помогут эффективно работать с проблемами на проекте. Примеры таких инструментов:
- Контрольная карта.
- Диаграмма Парето.
- Гистограмма.
- Контрольный лист.
- Диаграмма Исикавы.
- Расслоение (стратификация).
- Диаграмма рассеяния.
Довольно часто на практике при анализе проблем (как правило, на ретроспективах) я использую диаграмму Исикавы/"Рыбьей Кости" (Fishbone Diagram)
На рисунке представлен такой пример с двумя уровнями костей. Красным цветом обозначен
Работа с диаграммой Исикавы проводится в несколько этапов:
- Выявление и сбор всех факторов и причин, каким-либо образом влияющих на исследуемый результат.
- Группировка факторов по смысловым и причинно-следственным блокам.
- Ранжирование этих факторов внутри каждого блока.
- Анализ полученной картины.
- «Освобождение» факторов, на которые мы не можем влиять.
- Игнорирование малозначимых и непринципиальных факторов.
Еще один полезный инструмент для работы с проблемами, с которым можно ознакомиться на страницах PMBoK, это афинити-диаграмма (affinity diagram), или KJ Method. По сути, это дополнение к мозговому штурму, когда все собранные факты и идеи организовываются в кластеры в зависимости от связей между ними. Эта техника хорошо подходит для воркшопов: необходимо собрать нужных stakeholders, которые имеют отношение к данной проблеме; запастись большим количеством разноцветных стикеров, которые являются «атомами» фактов или идей, которые вы собираетесь объединить в различные группы.
Дальше несколько простых шагов:
| Шаг | Фаза | Описание |
| 1. | Идентифицировать проблему | Определите свою проблему или общую тему. Пример: почему уровень удовлетворенности клиентов снижается? |
| 2. | Собрать идеи | Перечислите соответствующие факты, данные, идеи, мнения, касающиеся предмета, и поместите их на стикеры или запишите на доске |
| 3. | Найти связи между ними | Обратите внимание, какие из этих заметок или карточек похожи, и расположите их в соответствии с шаблонами, основанными на этих сходствах |
| 4. | Сгруппировать идеи в кластеры | Пометьте каждую группу похожих заметок или карточек ярлыком для каждой группы Affinity. Это могут быть аспекты рассматриваемой проблемы. Определите приоритетность проблем, которые были выявлены |
| 5. | Проанализировать результат | Посмотрите на созданные группы и факты/идеи, связанные с каждой идеей. Какие идеи это дает в отношении проблемы, изложенной вначале? Предлагает ли это потенциальные решения? |
| 6. | Поделиться результатами | Поделитесь результатами со всеми заинтересованными сторонами |
В PMBoK, инструменты, которые позволяют эффективно работать с проблемами, не вынесены в отдельные процесс или область знаний, а распределены по другим областям знаний (большинство — в Quality Management). В ITIL это отдельный процесс. Управление проблемами — еще одна важная глава, обсуждаемая в разделе «Сервисная поддержка» ITIL®. Цель этого процесса — «минимизировать негативное влияние инцидентов и проблем на бизнес, вызванных ошибками в ІТ-инфраструктуре, и предотвратить повторение инцидентов, связанных с этими ошибками». Проблема является неизвестной основной причиной одного инцидента или более. Известная ошибка — это успешно диагностированная проблема (известная основная причина), для которой были найдены временный обходной путь или постоянное решение.
Контроль проблем как часть ITIL направлен на преобразование проблем в известные ошибки, чтобы выяснить причину инцидентов, в то время как контроль ошибок отвечает за устранение известных ошибок с использованием процесса управления изменениями.
Этапы контроля проблемы:
- идентификация и регистрация проблемы;
- классификация проблемы;
- исследование, диагностика проблемы и анализ первопричины (определение неизвестной основной причины проблемы).
Функции контроля ошибок:
- идентификация и запись ошибок;
- оценка ошибок;
- устранение ошибок записи (это точка, в которой будет подан запрос на изменение для постоянного разрешения);
- закрытие ошибок и прогресс разрешения монитора.
Одним из преимуществ ITIL по сравнению с PMBoK для ІТ-проектов является то, что он ориентирован на ІТ, в то время как PMBoK не имеет профилизации (не считая software extension to PMBoK Guide). В ITIL можно найти полезные рекомендации по Information Security и Release and Deployment Management. Те же процессы, что есть в PMBoK, к примеру Knowledge Management или Change Management, также более релевантны для ІТ.
PMBoK и ITIL имеют соответствующие сертификации, детали можно почитать тут. Также в Украине действует комьюнити сертифицированных PMP-специалистов.
Выводы
Подводя итоги, стоит отметить, что у PMBoK и ITIL схожий подход к некоторым вопросам, но они имеют разные сферы применения. Для проектов с фиксированной ценой и скоупом (Fixed-Price) PMBoK является более подходящим источником практик. Для проектов, которые имеют SLA, проекты поддержки (Support, Maintenance) ITIL более релевантен. Большинство проектов, которые работают по Kanban, могут найти много полезного в Service Operations (одна из книг, которая входит в библиотеку ITIL). ITIL также широко применяют IT-отделы крупных компаний, Service Design и Service Strategy отлично подходят для запуска новых IT-сервисов. А вот уже разработка и реализация нового сервиса может быть осуществлена в рамках проекта, где будут применяться практики из PMBoK. Передача этого сервиса от разработки к поддержке и непосредственная поддержка сервиса и его улучшение также описаны в ITIL.
В проектах, в зависимости от их специфики, можно использовать практики как из PMBoK, так и из ITIL. В ІТ-проектах, которые часто используют гибкие (Agile) подходы для решения отдельных вопросов, которые не предписаны в том же Scrum или Kanban, можно смело пользоваться процессами, предлагаемыми PMBoK или ITIL, смотря на то, что лучше подходит. К примеру, процесс управления рисками может быть построен согласно рекомендациям PMBoK, а управление инцидентами — согласно ITIL. Стоит иметь оба набора Best Practice в своем арсенале, чтобы в нужный момент использовать нужный инструмент.
Надеюсь, эта статья натолкнет вас на новые идеи по управлению вашими проектами.