Я – руководитель Проектного офиса. В мои обязанности входит планирование всех проектов, которые инициируются в компании. Сейчас проектов у нас порядка пятнадцати, но подход, о котором пойдет речь ниже, я использую практически без изменений. Важно также сказать, что я не являюсь экспертом в предметных областях наших проектов – для этих целей у нас назначается руководитель проекта, который хорошо понимает: как из требований Заказчика и ресурсов Спонсора сделать нужный продукт. Но наши РП не очень хорошо разбираются в процессах управления проектами. И потому здесь требуется помощь Проектного офиса.
Логистическая компания планирует открыть новый склад. Реализация проекта позволит выполнить условия, предъявляемые крупным клиентом к географии присутствия, а также снизить логистические издержки компании по доставке и хранению товара в соседних регионах. Сейчас начало июня. Проект должен быть завершен к середине сентября. Необходимо за 2 недели описать содержание проекта, разработать расписание, определить бюджет и все необходимые ресурсы для выполнения проекта. Все документы должны быть согласованы участниками проекта, а также ресурс – менеджерами.
нужны для планирования всех параметров проекта. Конечно, главные участники – руководитель проекта и Заказчик. Часто эти персоны – высокооплачиваемые топ-менеджеры (т.н. «Генералы»), которые умеют мыслить абстрактно и комплексно, но в детали погружаться не очень любят. «Генералов» я обычно не приглашаю на стартовую встречу, а обхожусь только их заместителями (т.н. «адъютантами»).
Также я всегда задаюсь вопросом: кто является источником информации для нашего будущего проекта? Это сложнее. Перечень лиц, которые могут в разное время предоставлять информацию для проекта, может быть достаточно большим и размытым. Поэтому я определяю только тех сотрудников, которые предоставят мне информацию, достаточную для описания содержания проекта. Позже, при разработке плана проекта, я смогу более полно определить ресурсы и их потребность в информации.
В проекте открытия склада ключевым вопросом функционирования склада является персонал, который должен быть подобран и нанят в новом регионе. Сколько времени занимает этот процесс и какие условия должны быть выполнены, определит отдел по работе с персоналом. Значит, запишем его руководителя. Также в проекте должен быть перемещен автотранспорт из соседнего региона. Сколько единиц транспорта, при каких условиях и как они будут перемещены, должен определить начальник транспортного отдела. Значит, его вносим в список участников планирования. И так далее. У меня
получился следующий список:
Кого решил не приглашать:
Определить содержание проекта – задача не из простых. Документирование всех параметров будущего проекта требует кропотливости и дотошности. Готовьтесь к тому, что разговор с вашими визави примет форму допроса. Я не пользуюсь никакими средствами автоматизации по простой причине – они задерживают работу при мозговом штурме. А времени у меня мало. Я использую только бумагу и ручку.
Группа в сборе. Я объясняю группе цель своего присутствия – помочь распланировать будущий проект. Объясняю, что я не имею такого опыта, как мои собеседники и потому мне потребуется их помощь. Начинаем выстраивать иерархическую структуру работ (ИСР, она же СДР, она же WBS). Конечно, мои участники не знают об этих вещах, но это не обязательно. Задаю свои вопросы:
и т.п.
Очевидно, что многие вопросы однотипны и спрашивают об одном и том же. Это нормально. Наверное, так хороший следователь проводит допрос свидетеля. Я обобщаю результаты в крупные и понятные для меня объекты. Важно, чтобы я понимал, как проект будет выполняться в дальнейшем и смог донести это до участников. Рисуя крупные блоки на листе, я постоянно дополняю их вторым и третьим уровнем декомпозиции, но не особенно заморачиваясь на структуре.
Я постоянно произношу вслух ключевые слова, которые отображаю на диаграмме, чтобы все участники следили за моими мыслями. Поощряю новые идеи и главное – новые объекты на диаграмме. Вычеркнуть – проще простого. Но проекты в моей практике «валятся» из-за недостаточной проработки рамок. Итого, в верхний уровень декомпозиции попали:
Не забываю выписывать вопросы к Заказчику. Выбросил листик, поэтому по памяти:
И т.п.
На профессиональном языке это – «допущения» проекта, т.е. факторы, которые мы приняли истинными при планировании. Если что-то из этих условий изменится, то проект не будет выполнен в установленный срок.
Показываю ИСР нашей группе: «Это – содержание нашего проекта. Мы должны установить взаимосвязи между блоками, назначить ресурсы и определить длительности выполнения задач. Тогда мы узнаем сроки выполнения каждой работы. Вы можете идти на 15-минутный перерыв».
Во время перерыва я с руководителем проекта оперативно вношу все задачи в MS Project в виде задач, структура которых совпадает с диаграммой (слегка подкорректированной). Заодно проверяем все формулировки: задача должна звучать как задача, а не процесс; результат должен быть понятен руководителю проекта и исполнителю.
Команда проекта (а по факту это она и есть) снова в сборе. Я включаю проектор и объясняю, что произошло за последние 15 минут. А далее простые вопросы к группе:
И т.п.
На профессиональном языке это называется установить «последователей» для задач. Это очень неинтересная работа. Но поделать нечего.
Определяем «предшественников» задач аналогичным способом. Методичность в этой работе – залог вашего здоровья в будущем. Умело используйте типы связей между задачами, чтобы правильно трактовать заявления участников: «Да она вообще может делаться в любой момент!». Или «Делается параллельно всему проекту!». Кстати, могу попасться задачи, которые на завершение проекта не влияют. Демонстративно вычеркиваем их.
Параллельно определению связей назначаем ответственных за исполнение. Мне важно видеть реального исполнителя, а не «стрелочника» и «маршрутизатора». Также не люблю, когда предлагают «виртуального» сотрудника типа «Разработчик». У каждой задачи в проекте должны быть Фамилия, Имя, Отчество и домашний адрес!
Маленький технический нюанс. В моих сетевых графиках всегда есть две вехи: «Начало проекта» (у нее предшественников нет) и «Проект завершен» (у нее нет последователей). Такая организация сетевого графика позволяет двигать дату начала проекта на любое время и прогнозировать завершение всех работ. Я переношу «Начало проекта» на две недели вперед после формального утверждения проекта. Это обезопасит меня от бюрократических проволочек.
И еще. Есть такое модное слово «риск». Обычно, я не морочу людям голову такими словами – персонал и так волнуется при виде менеджера, который записывает каждое их слово и быстро раздает задачи и сроки. Я немного смягчаю обстановку, вводя резервы в те задачи, где однозначно будут «тормоза». Например, при передаче информации или согласовании. Визуальное отображение резервов возле своих задач успокаивает участников. Конечно, это неправильно, что сотрудники видят сроки с резервами. Но, во-первых, в итоговой рассылке резервов они не увидят, во-вторых, каждого интересует только свой состав задач и сроки их выполнения. А доверие команды в данном случае для меня важнее.
Наша первая версия расписания не укладывалась в 2 месяца. Иными словами, если бы мы хотели завершить проект вовремя, то начинать нужно было в апреле. Последняя метафора особенно хорошо действует на команду. Улыбаются. Начинаем двигать задачи:
Конечно, не всегда оптимизировать можно. Но у нас получилось. За неделю до планового открытия филиала завершаются все «обязательные работы» (с учетом резервов конечно). Нормально. Получилось.
В моем проекте Заказчик был недалеко и мы его пригласили для ответа на накопившиеся вопросы. Но это можно было не делать, а общаться в переписке. Повезло. Конечно, большой пользы от личного присутствия мы не получили, но зато у команды было ощущение завершения чего-то значимого.
Остались формальные процедуры, которые определены Проектным офисом (т.е. мной). Я разрабатываю Устав (благо информации у меня предостаточно), делаю рассылки ресурс-менеджерам, собираю подтверждения и вношу незначительные коррективы в названия работ, в их последовательность, иногда в структуру. Изменений не много, потому что принципиальные вещи мы учли, но подразделения все равно хотят «подстраховаться» свою ответственность.
Вся работа по разработке проекта заняла у меня неделю. Состоялось 3 встречи общей продолжительностью 10 часов. Утверждение проекта состоится завтра. Говорят, что у нас появились «новые вводные». Но это уже «Управление изменениями». Об этом позже.
P.S. Написано знакомым, зовут его Александр Кольцов. Если кому не жалко — могут поделиться с ним инвайтом.
Линк на его блог
Входная задача и информация о проекте
Логистическая компания планирует открыть новый склад. Реализация проекта позволит выполнить условия, предъявляемые крупным клиентом к географии присутствия, а также снизить логистические издержки компании по доставке и хранению товара в соседних регионах. Сейчас начало июня. Проект должен быть завершен к середине сентября. Необходимо за 2 недели описать содержание проекта, разработать расписание, определить бюджет и все необходимые ресурсы для выполнения проекта. Все документы должны быть согласованы участниками проекта, а также ресурс – менеджерами.
Подготовка к планированию. Определение команды проекта
нужны для планирования всех параметров проекта. Конечно, главные участники – руководитель проекта и Заказчик. Часто эти персоны – высокооплачиваемые топ-менеджеры (т.н. «Генералы»), которые умеют мыслить абстрактно и комплексно, но в детали погружаться не очень любят. «Генералов» я обычно не приглашаю на стартовую встречу, а обхожусь только их заместителями (т.н. «адъютантами»).
Также я всегда задаюсь вопросом: кто является источником информации для нашего будущего проекта? Это сложнее. Перечень лиц, которые могут в разное время предоставлять информацию для проекта, может быть достаточно большим и размытым. Поэтому я определяю только тех сотрудников, которые предоставят мне информацию, достаточную для описания содержания проекта. Позже, при разработке плана проекта, я смогу более полно определить ресурсы и их потребность в информации.
В проекте открытия склада ключевым вопросом функционирования склада является персонал, который должен быть подобран и нанят в новом регионе. Сколько времени занимает этот процесс и какие условия должны быть выполнены, определит отдел по работе с персоналом. Значит, запишем его руководителя. Также в проекте должен быть перемещен автотранспорт из соседнего региона. Сколько единиц транспорта, при каких условиях и как они будут перемещены, должен определить начальник транспортного отдела. Значит, его вносим в список участников планирования. И так далее. У меня
получился следующий список:
- руководитель проекта (обладает требованиями Заказчика к новому складу, выполнял схожую работу в прошлом)
- начальник отдела по работе с персоналом (подбор и найм сотрудников, безопасность офиса)
- юрист (вопрос лицензий, печатей, изменений в Уставе)
- начальник транспортного отдела (перемещение и оформление транспорта).
Кого решил не приглашать:
- финансистов (у них не так много работы, а в проекте у них нет каких-то «специфических» задач)
- ИТ-шников (аналогично финансистам. Мы знаем их требования: хочешь сервер – заявка, хочешь оргтехнику – план размещения персонала)
- Заказчика. Почему? Во-первых, он – «Генерал» (см. выше). Во-вторых сформулировал свои ожидания достаточно, чтобы можно было начать планирование. В-третьих, такой категории удобней отдельно задавать вопросы и получать ответы, чем таскать на совещания. Все возникшие к нему вопросы я выписываю на отдельный лист.
Планирование проекта. Часть 1. Определение содержания
Определить содержание проекта – задача не из простых. Документирование всех параметров будущего проекта требует кропотливости и дотошности. Готовьтесь к тому, что разговор с вашими визави примет форму допроса. Я не пользуюсь никакими средствами автоматизации по простой причине – они задерживают работу при мозговом штурме. А времени у меня мало. Я использую только бумагу и ручку.
Группа в сборе. Я объясняю группе цель своего присутствия – помочь распланировать будущий проект. Объясняю, что я не имею такого опыта, как мои собеседники и потому мне потребуется их помощь. Начинаем выстраивать иерархическую структуру работ (ИСР, она же СДР, она же WBS). Конечно, мои участники не знают об этих вещах, но это не обязательно. Задаю свои вопросы:
- Из каких результатов состоит наш проект?
- Какие условия позволят нам сказать, что проект завершен?
- Какие ключевые результаты хочет видеть Заказчик после завершения проекта?
- Назовите 3-5 самых важных результата проекта?
- Какие объекты (документы, оборудование, сотрудники) будут переданы Заказчику после завершения проекта?
и т.п.
Очевидно, что многие вопросы однотипны и спрашивают об одном и том же. Это нормально. Наверное, так хороший следователь проводит допрос свидетеля. Я обобщаю результаты в крупные и понятные для меня объекты. Важно, чтобы я понимал, как проект будет выполняться в дальнейшем и смог донести это до участников. Рисуя крупные блоки на листе, я постоянно дополняю их вторым и третьим уровнем декомпозиции, но не особенно заморачиваясь на структуре.
Я постоянно произношу вслух ключевые слова, которые отображаю на диаграмме, чтобы все участники следили за моими мыслями. Поощряю новые идеи и главное – новые объекты на диаграмме. Вычеркнуть – проще простого. Но проекты в моей практике «валятся» из-за недостаточной проработки рамок. Итого, в верхний уровень декомпозиции попали:
- Здание
- Персонал
- Юридическое оформление филиала
- Оборудование для склада
- Оборудование для офиса
- Автоматизация
- Транспорт
- Бизнес-процессы
- Безопасность склада и офиса
- Изменения в бюджете
Не забываю выписывать вопросы к Заказчику. Выбросил листик, поэтому по памяти:
- Мы считаем, что новый объект здания склада должен обладать следующими свойствами (перечисляем). Правильно?
- В качестве автоматизации будет использоваться только текущая конфигурация 1С.
- Перемещение товара из других складов в рамках проекта?
- Заключение договора с крупным поставщиком в рамках проекта?
И т.п.
На профессиональном языке это – «допущения» проекта, т.е. факторы, которые мы приняли истинными при планировании. Если что-то из этих условий изменится, то проект не будет выполнен в установленный срок.
Показываю ИСР нашей группе: «Это – содержание нашего проекта. Мы должны установить взаимосвязи между блоками, назначить ресурсы и определить длительности выполнения задач. Тогда мы узнаем сроки выполнения каждой работы. Вы можете идти на 15-минутный перерыв».
Во время перерыва я с руководителем проекта оперативно вношу все задачи в MS Project в виде задач, структура которых совпадает с диаграммой (слегка подкорректированной). Заодно проверяем все формулировки: задача должна звучать как задача, а не процесс; результат должен быть понятен руководителю проекта и исполнителю.
Планирование проекта. Часть 2. Определение последователей и предшественников задач
Команда проекта (а по факту это она и есть) снова в сборе. Я включаю проектор и объясняю, что произошло за последние 15 минут. А далее простые вопросы к группе:
- Задача с кодом х.х. Какие задачи не могу выполняться, пока она не завершена?
- Для каких задач предоставляет информацию задача с кодом х.х.?
- Для каких задач задача с кодом х.х. является «входом»?
И т.п.
На профессиональном языке это называется установить «последователей» для задач. Это очень неинтересная работа. Но поделать нечего.
Определяем «предшественников» задач аналогичным способом. Методичность в этой работе – залог вашего здоровья в будущем. Умело используйте типы связей между задачами, чтобы правильно трактовать заявления участников: «Да она вообще может делаться в любой момент!». Или «Делается параллельно всему проекту!». Кстати, могу попасться задачи, которые на завершение проекта не влияют. Демонстративно вычеркиваем их.
Параллельно определению связей назначаем ответственных за исполнение. Мне важно видеть реального исполнителя, а не «стрелочника» и «маршрутизатора». Также не люблю, когда предлагают «виртуального» сотрудника типа «Разработчик». У каждой задачи в проекте должны быть Фамилия, Имя, Отчество и домашний адрес!
Маленький технический нюанс. В моих сетевых графиках всегда есть две вехи: «Начало проекта» (у нее предшественников нет) и «Проект завершен» (у нее нет последователей). Такая организация сетевого графика позволяет двигать дату начала проекта на любое время и прогнозировать завершение всех работ. Я переношу «Начало проекта» на две недели вперед после формального утверждения проекта. Это обезопасит меня от бюрократических проволочек.
И еще. Есть такое модное слово «риск». Обычно, я не морочу людям голову такими словами – персонал и так волнуется при виде менеджера, который записывает каждое их слово и быстро раздает задачи и сроки. Я немного смягчаю обстановку, вводя резервы в те задачи, где однозначно будут «тормоза». Например, при передаче информации или согласовании. Визуальное отображение резервов возле своих задач успокаивает участников. Конечно, это неправильно, что сотрудники видят сроки с резервами. Но, во-первых, в итоговой рассылке резервов они не увидят, во-вторых, каждого интересует только свой состав задач и сроки их выполнения. А доверие команды в данном случае для меня важнее.
Планирование проекта. Часть 3. Оптимизация расписания
Наша первая версия расписания не укладывалась в 2 месяца. Иными словами, если бы мы хотели завершить проект вовремя, то начинать нужно было в апреле. Последняя метафора особенно хорошо действует на команду. Улыбаются. Начинаем двигать задачи:
- 2 месяца на поиск персонала – много! Не обязательно искать всех сотрудников последовательно. «Параллелим» работы без особого риска для проекта;
- Выделяем в проекте 2 вехи: склад готов к обслуживанию клиента («обязательные» работы) и проект завершен («необязательные» работы, которые могут быть сделаны позже). Мы сможем объяснить Заказчику, что открыть склад для клиента важнее и часть результатов будет получена месяцем позже.
- Удаляем некоторые ненужные взаимосвязи и т.п.
Конечно, не всегда оптимизировать можно. Но у нас получилось. За неделю до планового открытия филиала завершаются все «обязательные работы» (с учетом резервов конечно). Нормально. Получилось.
В моем проекте Заказчик был недалеко и мы его пригласили для ответа на накопившиеся вопросы. Но это можно было не делать, а общаться в переписке. Повезло. Конечно, большой пользы от личного присутствия мы не получили, но зато у команды было ощущение завершения чего-то значимого.
Планирование проекта. Завершение
Остались формальные процедуры, которые определены Проектным офисом (т.е. мной). Я разрабатываю Устав (благо информации у меня предостаточно), делаю рассылки ресурс-менеджерам, собираю подтверждения и вношу незначительные коррективы в названия работ, в их последовательность, иногда в структуру. Изменений не много, потому что принципиальные вещи мы учли, но подразделения все равно хотят «подстраховаться» свою ответственность.
Вся работа по разработке проекта заняла у меня неделю. Состоялось 3 встречи общей продолжительностью 10 часов. Утверждение проекта состоится завтра. Говорят, что у нас появились «новые вводные». Но это уже «Управление изменениями». Об этом позже.
P.S. Написано знакомым, зовут его Александр Кольцов. Если кому не жалко — могут поделиться с ним инвайтом.
Линк на его блог
