Проектный офис: что это и чем он занимается в холдинге?
Статья из корпоративной газеты
Согласно определению «Проектный офис» – это подразделение, которое контролирует все проекты холдинга и отвечает за развитие проектного управления. Таким образом, прежде чем перейти к задачам и функциям Проектного офиса, мы должны разобраться: что понимается под «проектом» и что такое само «проектное управление»?
Что скрывается под термином «проект»?
Под «проектом» наш холдинг понимает мероприятие, которое:
- ограничено временем (не менее 3-х месяцев);
- ограниченно бюджетом;
- и требует участия сотрудников из нескольких компаний.
Последняя часть определения особенно важна. Управлять деятельностью, которая не выходит за рамки компании можно и «традиционными» методами: поставить задачу различным службам, а потом контролировать ее выполнение. Но как управлять работами, если сотрудники находятся в различных компаниях и не подчинены друг другу в регулярной деятельности? Здесь на помощь приходят методики проектного управления.
Что такое управление проектами?
Проектное управление – это набор методов и приемов, которые позволяют добиваться завершения сложных и рискованных задач в установленный срок, в рамках бюджета и получать результат с требуемым качеством. О том, какие методы управления должны быть применены, как нужно планировать проект и по каким параметрам его контролировать – знает Проектный офис и его сотрудники.
Приведу пример проекта, который сейчас выполняется в холднге. Для автоматизации управленческого и бухгалтерского учетов был инициирован проект «Автоматизация учета». Это мероприятие попадает под определение «проект» потому что:
- длительность проекта 14 месяцев и проект имеет фиксированный срок завершения (февраль 2011 года – срок сдачи годового баланса);
- для мероприятия утвержден бюджет (покупка оборудования, стоимость привлечения стороннего разработчика и даже премия для команды проекта);
- и главное – для реализации этого проекта требуется привлечь специалистов из различных компаний (финансисты, бухгалтеры, ИТ-эксперты).
Так какие задачи выполняет Проектный офис в реализации таких мероприятиях и не только? Об этом речь пойдет ниже.
Определить проекты к инициации и добиться их запуска
Сегодня успешно выполнять проекты (в срок, в бюджет и с требуемым результатом) – уже недостаточно. Стратегические цели и ограниченные ресурсы заставляют руководителей выбирать:
- какие проекты должны быть запущены обязательно,
- какие только при наличии возможности,
- а какие проекты лучше отложить «до лучших времен».
За формирование т.н. «Портфеля проектов» отвечает Проектный офис. Мы ежегодно составляем список проектов, которые потенциально могут быть инициированы, проводим анализ их сроков, стоимости, а также взаимосвязей. Предложенный Портфель проектов передается на рассмотрение Совета Директоров для принятия решения о судьбе каждого из проектов-кандидатов. Так в итоговый список попадают самые значимые и перспективные проекты, которые должны быть выполнены в следующем году.
Определить список проектов, планируемых к запуску – это половина работы. Важно добиться, чтобы все запланированные к выполнению мероприятия были инициированы, т.е. прошли через ряд обязательных этапов. По каждому проекту должны быть разработаны все необходимые для запуска документы: описание целей и результатов, бюджет, расписание работ и пр. Сформировать требуемый комплект документов, помочь руководителям проектов пройти все необходимые процедурные этапы, гарантировать, что все параметры проектов обоснованы – ответственность Проектного офиса.
Предоставлять достоверную информацию обо всех проектах, выполняющихся в холдинге
Предоставлять руководству компаний достоверную и своевременную информацию о состоянии каждого проекта – ответственность Проектного офиса. Представьте себе, что в компании одновременно выполняется от 10 до 20 проектов, которыми руководят менеджеры из различных подразделений и компаний. В «традиционной» модели управления руководству, чтобы разобраться в текущем статусе каждого проекта, необходимо опросить каждого из менеджеров. Это несколько затруднительно, если учитывать, что:
- каждый менеджер проекта интуитивно старается скрыть недостатки «своего» проекта;
- каждый менеджер использует свой собственный формат отчета;
- менеджер не знает, что другие проекты влияют на ход выполнения его проекта (например, ценные ресурсы могут быть недоступны;
- недостаточный опыт управления проектами может привести к искажению информации, невозможности посмотреть на ситуацию сверху.
Проектный офис является независимым источником информации о выполнении всего Портфеля проектов в целом и ходе каждого проекта в частности. Чтобы понимать и правильно оценивать фактический ход работ проекта, Проектный офис принимает участие во всех совещаниях, участвует в принятии решений, помогает руководителям проектов в ведении документации. Один раз в две недели Проектный офис готовит отчет для Заказчика о состоянии проекта, в котором указывает:
- какие изменения произошли в проекте за последний отчетный период;
- статус получения ключевых результатов проектов;
- информация об освоении бюджета;
- вопросы и проблемы, требующие участия Заказчика;
- и др.
Единая для всех проектов форма отчета, несомненно, упрощает восприятие информации менеджерами.
Также один раз в две недели Проектный офис информирует Спонсоров о состоянии всего Портфеля проектов. В отчете обобщается информация о ходе всех проектов, а также описываются факторы, которые негативно могут повлиять на весь Портфель в целом. Своевременность и беспристрастность предоставленной информации – один из главных факторов доверия к Проектному офису.
Обеспечить выполнение проектов
Проекты редко (почти никогда) выполняются в соответствии с планом. Причин этому можно назвать несколько:
- некачественное планирование на этапе инициации;
- внешние негативные факторы (риски)
- изменения в проекте;
- низкая исполнительская дисциплина команды проекта;
- отсутствие опыта управления проектами.
Проектный офис имеет возможность снизить влияние каждого из перечисленных факторов:
- Расписание проекта разрабатывается опытным планировщиком, который имеет опыт подобной работы и может предложить наиболее адекватную модель реализации. Расписание проекта обновляется еженедельно с помощью руководителя проекта, изменения доводятся до команды проекта.
- Управление факторами, которые могут привести к негативным последствиям для проекта («рисков»), обеспечивается Проектным офисом с использованием современных методик и даже систем автоматизации. Благодаря тому, что Проектный офис принимает участие во всех проектах, у него есть возможность отслеживать влияние одного проекта на другой и предотвращать подобные ситуации.
- Иногда постановка проектной задачи меняется по инициативе Заказчика. Это связано с необходимостью сделать результаты проект максимально полезными для бизнеса. Проектный офис отвечает за то, чтобы не допустить бесконтрольного изменения содержания проекта и превышения срока завершения и бюджета проекта.
- Каждый участник проекта регулярно получает список своих задач, информацию о выполнении работ другими сотрудниками, а также отчет о статусе проекта. В случае возникновения проблем или конфликта интересов, Проектный офис предпринимает все меры к сглаживанию ситуации и дальнейшему продолжению работ.
- Для повышения знаний руководителей проектов об управлении проектами, Проектный офис регулярно проводит обучение менеджеров (об этом речь пойдет ниже). Положительный и негативный опыт реализации проектов документируется и доводится до всех руководителей. Это позволяет накапливать знания и применять их в следующих проектах.
Центр обучения технологиям управления проектами
Самостоятельное изучение корпоративных стандартов по управлению проектами, а тем более и просто сторонних методик, является малоэффективным. Для того, чтобы каждый менеджер понимал особенности проектной деятельности, роли главных участников проектов, владел такими понятиями как «жизненный цикл проекта», Проектный офис регулярно проводит обучение технологиям управления проектами. Подготовка менеджеров проводится на основе решения реальных кейсов и практических задач, что гарантирует итоговый результат. Каждая пройденная тема заканчивается списком из пяти проверочных вопросов, а по итогам обучения менеджер сдает тест из 30 вопросов по всему материалу.
Важно, что менеджеры изучают не только саму дисциплину, но и ее применение и особенности в холдинге. Вот пример одного из вопросов: «В ходе проекта Заказчик настаивает на необходимости включить в проект результат, который не вошел в Устав проекта. Ваши действия…». Варианты ответов:
А) Внесете изменения в Устав, потому что Заказчик отвечает за формулирование требований и приемку результатов проекта;
Б) Откажите Заказчику, так как Устав проекта утвержден Советом Директоров и его изменение не входит в компетенцию Заказчика;
В) Подготовите Запрос на изменение проекта, в котором опишите требуемое изменение, проведете работу по оценке влияния изменения на параметры проекта;
Г) Вынесите рассмотрение вопроса на Совет Директоров.
Принять участие в обучении управлению проектами может каждый менеджер нашего холдинга. Для этого достаточно просто обратиться к руководителю Проектного офиса.
Удачи вам в ваших проектах.
Саша, я когда читаю твои посты мне регулярно приходится держать в памяти специфику вашей деятельности. Я как-то говорил, что разработка софта, которой мы занимаемся — по определению проектная деятельность. Поэтому часть подобных вопросов даже не задается.
Но у меня вопрос есть: Ты пишешь, что разработка плана проекта разрабатывается профессиональным планировщиком. Этот планировщик является экспертом в предметной области, по которой он разрабатывает план проекта? Т.е. на сколько хорошо он знает последовательность работ?
Кроме того, ты выше указывал одну из причин некачественного выполнения проектов: некачественное планирование на этапе инициации;
Это не противоречие?
Плюс к этому. Ты пишешь, что есть проблема того, что проект идет не по плану. Ты считаешь это проблемой? 🙂 В том же PMBoK планирование идет методом “набегающей волны”. Т.е. вслед за разработкой софта PMI также осознал, что весь проект с самого начала спланировать не всегда возможно в деталях. Что важнее — результат или следование плану?
Привет. Да у нас специфика на лицо:
– все проекты внутренние (есть только 1 проект с участием внешнего контрагента);
– руководители проектов назначаются из числа функциональных менеджеров;
– заказчиков проектов приходится искать, прежде чем начать проект;
– управлять проектом и отвечать за весь пакет работ, а не только за свой участок – пока слабо работает;
– и многое другое.
1. Технология производства продукта (состав работ и их последовательность) мне понятна в большей части проектов (кроме ИТ, об этом ниже). Умение задавать вопросы и провести “перекрестный допрос” РМ вместе с конечным исполнителем позволяет составить весьма правдоподобное расписание. С ИТ – сложнее. И не только потому, что ИТ-проекты отличаются от бизнесовых, но и в силу личных особенностей наших ИТ-шников. В таких проектах главное – правильно предусмотреть передачу ответственности и информации в ходе проекта. Это и есть основа расписания.
2. Хм… Противоречие. План проекта был? Был. На основе его можно было сделать проект? Можно было. Все его подтвердили? Все. Почему не сделали? Плохо планировали. А что у вас в жизни все по-другому? ;-).
В одном проекте у нас на 100% сменился состав разработчиков. Плохо планировали, я считаю.
В другом проекте ключевое предположение, что наш Контрагент заинтересован в выполнении проекта также как и мы, оказалось ошибочным. Плохо планировали.
В другом проекте – сдвиг на 4 недели в апреле привел к тому, что в июле мы попали на период отпусков. Плохо планировали.
Это все риски, которые возникли в наших проектах. Но все равно это – некачественное планирование. Есть к чему стремиться.
3. Здесь все в кучу.
3а. Плохо не само отклонение от плана (технологии получения результата), а от сроков получения результата (контрольных вех). В бизнесе сроки проекта – ключевой аспект и 80% всех бонусов. Проекты выполняются для развития бизнеса и торможение в развитии может привести к о-о-чень серьезным потерям в деньгах.
3б. Метод набегающей волны, как ты помнишь – технология, по которой близлежащие работы детализируются до конкретных пакетов работ и задач, а работы, выполнение которых намечено на далекую перспективу, планируются с относительно неглубоким раскрытием. Этот метод любят наши ИТ-шники, забывая, что сроки проекта при этом не переносятся и не изменяются! Вы можете использовать любой метод планирования, но однажды названный срок этот метод не должен сдвигать. Планируй, закладывай резервы, но срок проекта должен быть выдержан. Как ты себе представляешь, на вопрос “Когда будет открыт новый склад?” получить ответ “Мы пока распланировали только поиск помещения и расчет физических операций, которые должен осуществлять склад. Но срок завершения проекта назвать не можем”?
Приходи ко мне на тренинг по управлению проектами. Суббота 10 июля, 9:00. С точки зрения самой дисциплины ты вряд ли получишь что-то новое, но спецификой проникнешься, я уверен. Послушаешь вопросы, которые мне задают. Будет интересно.
Пришлось потрудиться над ответом:
2. Мне кажется, что ты в кучу сваливаешь качество планирования и качество предсказаний. 🙂 И связано это не только с качествами планировщика и проектировщика, но также и со спецификой отрасли. Так в строительной отрасли довольно типовые проекты планируются уже с точностью 2-3%. В разработке софта хорошо если держится в пределах 15%. Причем точность +\- 15% это считается fucking magic.
Как было написано в одной хорошей книжке: «Большинство руководителей проектов по созданию ПО проделывают приемлемую работу по предсказанию задач, которые должны быть выполнены, и слабую работу по предсказанию задач, которые может потребоваться выполнить.» Виной всему тот самый айсберг, верхушку которого мы видим.
3. Но при этом есть выход. 🙂 Действительно метод набегающей волны может не отменять дат сдачи продукта. Но давай рассматривать эту задачу с другого ракурса.
Проектный треугольник состоит из 3х ключевых ограничений:
* Ресурсы (и их стоимость — Resources)
* Время — Сроки (Schedule)
* Объем выполняемой работы (Scope)
Маленькое лирическое отступление: В этом уровнении отсутствует качество… Считается, что оно зафиксировано. 🙂
Можем ли мы зафиксировать все 3 грани ограничений? Нет. Фиксируются 2е, 3я плавает. В fixed price проектах фиксируются Сроки и Объем. Ресурсы — это проблема исполнителя. Важно, чтобы в к определенной дате был поставлен требуемый объем продукта. Что нужно для того, чтобы знать точный Scope? Полное и не изменное ТЗ. На идеальное ТЗ требуется времени столько же сколько и на его воплощение. Даже если в 2 раза меньше — это все равно ужасно много. Почему? Потому что когда оно будет написано в него опять надо вносить изменения. Ага.
Если не приводить еще цепочку рассуждений могу резюмировать, что разработка софта — это не точная наука. Это наука сродни торгам на бирже, где причинно-следственные связи иногда бывают понятны только после произошедшего события. Эту работу можно изменять только эмпирическим путем.
Эмпирический подход + постоянное изменение требований — вот тебе и невозможность дать точные сроки выполнения задания. 🙂 НО! Только в случае если мы зафиксировали Scope и Schedule. Т.е. сам этот подход вообще не дает возможности использовать эмпирику. 🙂
А теперь зафиксируем Schedule (!) и Resources. Т.е. определенной командой мы должны успеть к определенному сроку сделать “что-то”. Т.к. это “что-то” постоянно меняется, то и не будем мучаться детальным ТЗ. Работу и требования к программному продукту будем фиксировать и детализировать раз в месяц (или 2 недели). Работая четкими итерациями и известной командой через 2 месяца будем обладать эмпирические накопленной информацией о скорости разработки именно этой команды! В конце каждой итерации будем выпекать готовый продукт. Каждый готовый продукт будем показывать заказчику и спрашивать — то ли это то, что он хотел.
Остается вопрос: “Будет ли к сроку готово все, что было изначально запланировано в Scope?” Скорее всего нет, потому что:
1. Сам Scope поменяется по ходу воплощения.
2. Будем выбирать наиболее приоритетные фичи — поэтому все не реализованое будет либо украшательства, либо чья-то блажь.
По науке это называется инкрементная итерационная разработка, заложенная, как фундамент современенных Agile методик и практик.
Что дает: к назначенным срокам существует готовый продукт с 70-80-90% заявленной функциональности.
Юрий, в фиксед-прайс мы действительно фиксируем в контракет сроки и объем работ, но чем пожертвует скорее всего заказчик в таком проекте, если в срок не будет выполненный плановый объем работ?
Опыт показывает, что сроками.
Таким образом, у меня напрашивается такой вывод:
если заказчик во главу угла ставит содержание проекта, а бюджет и/или сроки готов пересматривать – используем жесткие методологии. Если в проектном треугольнике заказчиком проекта фиксируются бюджет и сроки, а содержание заказчик готов пересматривать – используем agile.
привет, коллеги )