Александр КольцовДобро пожаловать на личный сайт Александра Кольцова – эксперта в управлении проектами, внедрении систем управления предприятием. В разделах “Управление проектами” и “ERP” представлены записи из профессиональной сферы. Также вы можете найти список тренингов, которые читает Александр для заказчиков по всему миру.

В разделе “Хобби” заметки Александра о его личных увлечениях: джаз, фотография, игры разных видов.

Как я планирую проекты

Я – руководитель Проектного офиса. В мои обязанности входит планирование всех проектов, которые инициируются в компании. Сейчас проектов у нас порядка пятнадцати, но подход, о котором пойдет речь ниже, я использую практически без изменений. Важно также сказать, что я не являюсь экспертом в предметных областях наших проектов – для этих целей у нас назначается руководитель проекта, который хорошо понимает: как из требований Заказчика и ресурсов Спонсора сделать нужный продукт. Но наши РП не очень хорошо разбираются в процессах управления проектами. И потому здесь требуется помощь Проектного офиса.

Входная задача и информация о проекте

Логистическая компания планирует открыть новый склад. Реализация проекта позволит выполнить условия, предъявляемые крупным клиентом к географии присутствия, а также снизить логистические издержки компании по доставке и хранению товара в соседних регионах. Сейчас начало июня. Проект должен быть завершен к середине сентября. Необходимо за 2 недели описать содержание проекта, разработать расписание, определить бюджет и все необходимые ресурсы для выполнения проекта. Все документы должны быть согласованы участниками проекта, а также ресурс – менеджерами.

Подготовка к планированию. Определение команды проекта

Приступая к планированию нового проекта, я всегда определяю круг лиц, которые мне нужны для планирования всех параметров проекта. Конечно, главные участники – руководитель проекта и Заказчик. Часто эти персоны – высокооплачиваемые топ-менеджеры (т.н. «Генералы»), которые умеют мыслить абстрактно и комплексно, но в детали погружаться не очень любят. «Генералов» я обычно не приглашаю на стартовую встречу, а обхожусь только их заместителями (т.н. «адъютантами»).

Также я всегда задаюсь вопросом: кто является источником информации для нашего будущего проекта? Это сложнее. Перечень лиц, которые могут в разное время предоставлять информацию для проекта, может быть достаточно большим и размытым. Поэтому я определяю только тех сотрудников, которые предоставят мне информацию, достаточную для описания содержания проекта. Позже, при разработке плана проекта, я смогу более полно определить ресурсы и их потребность в информации.

В проекте открытия склада ключевым вопросом функционирования склада является персонал, который должен быть подобран и нанят в новом регионе. Сколько времени занимает этот процесс и какие условия должны быть выполнены, определит отдел по работе с персоналом. Значит, запишем его руководителя. Также в проекте должен быть перемещен автотранспорт из соседнего региона. Сколько единиц транспорта, при каких условиях и как они будут перемещены, должен определить начальник транспортного отдела. Значит, его вносим в список участников планирования. И так далее. У меня получился следующий список:

  • руководитель проекта (обладает требованиями Заказчика к новому складу, выполнял схожую работу в прошлом)
  • начальник отдела по работе с персоналом (подбор и найм сотрудников, безопасность офиса)
  • юрист (вопрос лицензий, печатей, изменений в Уставе)
  • начальник транспортного отдела (перемещение и оформление транспорта).

Кого решил не приглашать:

  • финансистов (у них не так много работы, а в проекте у них нет каких-то «специфических» задач)
  • ИТ-шников (аналогично финансистам. Мы знаем их требования: хочешь сервер – заявка, хочешь оргтехнику – план размещения персонала)
  • Заказчика. Почему? Во-первых, он – «Генерал» (см. выше). Во-вторых сформулировал свои ожидания достаточно, чтобы можно было начать планирование. В-третьих, такой категории удобней отдельно задавать вопросы и получать ответы, чем таскать на совещания. Все возникшие к нему вопросы я выписываю на отдельный лист.

Планирование проекта. Часть 1. Определение содержания

Определить содержание проекта – задача не из простых. Документирование всех параметров будущего проекта требует кропотливости и дотошности. Готовьтесь к тому, что разговор с вашими визави примет форму допроса. Я не пользуюсь никакими средствами автоматизации по простой причине – они задерживают работу при мозговом штурме. А времени у меня мало. Я использую только бумагу и ручку.

Группа в сборе. Я объясняю группе цель своего присутствия – помочь распланировать будущий проект. Объясняю, что я не имею такого опыта, как мои собеседники и потому мне потребуется их помощь. Начинаем выстраивать иерархическую структуру работ (ИСР, она же СДР, она же WBS). Конечно, мои участники не знают об этих вещах, но это не обязательно. Задаю свои вопросы:

  • Из каких результатов состоит наш проект?
  • Какие  условия позволят нам сказать, что проект завершен?
  • Какие ключевые результаты хочет видеть Заказчик после завершения проекта?
  • Назовите 3-5 самых важных результата проекта?
  • Какие объекты (документы, оборудование, сотрудники) будут переданы Заказчику после завершения проекта?
  • и т.п.

Очевидно, что многие вопросы однотипны и спрашивают об одном и том же. Это нормально. Наверное, так хороший следователь проводит допрос свидетеля. Я обобщаю результаты в крупные и понятные для меня объекты. Важно, чтобы я понимал, как проект будет выполняться в дальнейшем и смог донести это до участников. Рисуя крупные блоки на листе, я постоянно дополняю их вторым и третьим уровнем декомпозиции, но не особенно заморачиваясь на структуре.

Я постоянно произношу вслух ключевые слова, которые отображаю на диаграмме, чтобы все участники следили за моими мыслями. Поощряю новые идеи и главное – новые объекты на диаграмме. Вычеркнуть – проще простого. Но проекты в моей практике «валятся» из-за недостаточной проработки рамок. Итого, в верхний уровень декомпозиции попали:

  • Здание
  • Персонал
  • Юридическое оформление филиала
  • Оборудование для склада
  • Оборудование для офиса
  • Автоматизация
  • Транспорт
  • Бизнес-процессы
  • Безопасность склада и офиса
  • Изменения в бюджете

Следующий уровень не описываю. Его можно увидеть на скриншоте моего черновика.
Черновик WBS (ИСР, СДР)
PS. На скриншоте может быть несколько иная картинка, но это же «черновик». В расписание попадает только правильная структура.

Не забываю выписывать вопросы к Заказчику. Выбросил листик, поэтому по памяти:

  • Мы считаем, что новый объект здания склада должен обладать следующими свойствами (перечисляем). Правильно?
  • В качестве автоматизации будет использоваться только текущая конфигурация 1С.
  • Перемещение товара из других складов в рамках проекта?
  • Заключение договора с крупным поставщиком в рамках проекта?
  • И т.п.

На профессиональном языке это – «допущения» проекта, т.е. факторы, которые мы приняли истинными при планировании. Если что-то из этих условий изменится, то проект не будет выполнен в установленный срок.

Показываю ИСР нашей группе: «Это – содержание нашего проекта. Мы должны установить взаимосвязи между блоками, назначить ресурсы и определить длительности выполнения задач. Тогда мы узнаем сроки выполнения каждой работы. Вы можете идти на 15-минутный перерыв».

Во время перерыва я с руководителем проекта оперативно вношу все задачи в MS Project в виде задач, структура которых совпадает с диаграммой (слегка подкорректированной). Заодно проверяем все формулировки: задача должна звучать как задача, а не процесс; результат должен быть понятен руководителю проекта и исполнителю.

Планирование проекта. Часть 2. Определение последователей и предшественников задач

Команда проекта (а по факту это она и есть) снова в сборе. Я включаю проектор и объясняю, что произошло за последние 15 минут. А далее простые вопросы к группе:

  • Задача с кодом х.х. Какие задачи не могу выполняться, пока она не завершена?
  • Для каких задач предоставляет информацию задача с кодом х.х.?
  • Для каких задач задача с кодом х.х. является «входом»?
  • И т.п.

На профессиональном языке это называется установить «последователей» для задач. Это очень неинтересная работа. Но поделать нечего.

Определяем «предшественников» задач аналогичным способом. Методичность в этой работе – залог вашего здоровья в будущем. Умело используйте типы связей между задачами, чтобы правильно трактовать заявления участников: «Да она вообще может делаться в любой момент!». Или «Делается параллельно всему проекту!». Кстати, могу попасться задачи, которые на завершение проекта не влияют. Демонстративно вычеркиваем их.

Параллельно определению связей назначаем ответственных за исполнение. Мне важно видеть реального исполнителя, а не «стрелочника» и «маршрутизатора». Также не люблю, когда предлагают «виртуального» сотрудника типа «Разработчик». У каждой задачи в проекте должны быть Фамилия, Имя, Отчество и домашний адрес!

Маленький технический нюанс. В моих сетевых графиках всегда есть две вехи: «Начало проекта» (у нее предшественников нет) и «Проект завершен» (у нее нет последователей). Такая организация сетевого графика позволяет двигать дату начала проекта на любое время и прогнозировать завершение всех работ. Я переношу «Начало проекта» на две недели вперед после формального утверждения проекта. Это обезопасит меня от бюрократических проволочек.

И еще. Есть такое модное слово «риск». Обычно, я не морочу людям голову такими словами – персонал и так волнуется при виде менеджера, который записывает каждое их слово и быстро раздает задачи и сроки. Я немного смягчаю обстановку, вводя резервы в те задачи, где однозначно будут «тормоза». Например, при передаче информации или согласовании. Визуальное отображение резервов возле своих задач успокаивает участников. Конечно, это неправильно, что сотрудники видят сроки с резервами. Но, во-первых, в итоговой рассылке резервов они не увидят, во-вторых, каждого интересует только свой состав задач и сроки их выполнения. А доверие команды в данном случае для меня важнее.

Планирование проекта. Часть 3. Оптимизация расписания

Наша первая версия расписания не укладывалась в 2 месяца. Иными словами, если бы мы хотели завершить проект вовремя, то начинать нужно было в апреле. Последняя метафора особенно хорошо действует на команду. Улыбаются. Начинаем двигать задачи:

  • 2 месяца на поиск персонала – много! Не обязательно искать всех сотрудников последовательно. «Параллелим» работы без особого риска для проекта;
  • Выделяем в проекте 2 вехи: склад готов к обслуживанию клиента («обязательные» работы) и проект завершен («необязательные» работы, которые могут быть сделаны позже). Мы сможем объяснить Заказчику, что открыть склад для клиента важнее и часть результатов будет получена месяцем позже.
  • Удаляем некоторые ненужные взаимосвязи и т.п.

Конечно, не всегда оптимизировать можно. Но у нас получилось. За неделю до планового открытия филиала завершаются все «обязательные работы» (с учетом резервов конечно). Нормально. Получилось.

В моем проекте Заказчик был недалеко и мы его пригласили для ответа на накопившиеся вопросы. Но это можно было не делать, а общаться в переписке. Повезло. Конечно, большой пользы от личного присутствия мы не получили, но зато у команды было ощущение завершения чего-то значимого.

Планирование проекта. Завершение

Остались формальные процедуры, которые определены Проектным офисом (т.е. мной). Я разрабатываю Устав (благо информации у меня предостаточно), делаю рассылки ресурс-менеджерам, собираю подтверждения и вношу незначительные коррективы в названия работ, в их последовательность, иногда в структуру. Изменений не много, потому что принципиальные вещи мы учли, но подразделения все равно хотят «подстраховаться» свою ответственность.

Вся работа по разработке проекта заняла у меня неделю. Состоялось 3 встречи общей продолжительностью 10 часов. Утверждение проекта состоится завтра. Говорят, что у нас появились «новые вводные». Но это уже «Управление изменениями». Об этом позже.

Начинаете управление проектами с автоматизации? Готовьтесь к проблемам

Поводом к написанию статьи стал звонок одного моего коллеги, для которого несколько лет назад я внедрял корпоративную систему управления проектами (КСУП). Сейчас его компания занимается девелопментом полного цикла. Собеседника интересовал вопрос: какую систему автоматизации я порекомендую для управления его проектами? Признаюсь, его вопрос застал меня врасплох. “С ходу” я предложил четыре или пять программных продуктов, которые представлены на рынке автоматизации. А затем, спохватившись, задал вопрос, который меня сильно беспокоил: “А зачем вам автоматизация?”. На том конце трубки возникло явное замешательство. Я перефразировал свой вопрос: “Какие проблемы вы бы хотели решить с помощью информационной системы?”. Он признался, что очень хочет получить такую же систему управления, с которой он уже когда-то работал и решил начать с развертывания информационной системы. Немного странно, неправда ли? На самом деле такая ситуация встречается сплошь и рядом.

Договоримся о понятиях. Под информационной системой управления проектами “ИСУП” я понимаю программный продукт или их совокупность, которые автоматизируют процессы управления проектами в рамках всей организации. Настольные средства руководителя проекта, например, MS Project, под это определение не попадают. Иными словами, если ваше внедрение ИСУП – это установка всем пользователям MS Project, то никаких рисков я здесь не вижу. И еще. В качестве отправной точки я выбрал постановку задачи высшим руководством компании: увеличить число успешных проектов в компании. Понятно, что если ставилась явная задача внедрить ИСУП, то проблематика теряется.

Я хочу привести несколько типовых проблем, с которыми сталкиваются организации, начавшие “наведение порядка” в проектах с внедрения информационной системы.

Термин “проект” в организации понимают по-разному, поэтому в ИСУП хранится “все на свете”: мелкие проекты, которые никто не одобрял, регулярные задачи какого-то подразделения, различные версии одного и того же проекта, “подпроекты” большого проекта и т.п. Просматривая Портфель проектов на сервере понимаешь, что организация не получила ту четкую и прозрачную “картинку”, ради которой все и начиналось. А ведь казалось бы проблема в малом – договориться о понятиях.

Внедрение ИСУП обязательно приводит к появлению “техническим” вопросов, которые крайне нежелательны, когда процессы управления еще “сырые” и нечеткие. Сотрудники только приступили к выполнению новых для себя функций, а тут появляются подобные проблемы: “опубликовал проект, но информация на сервере не обновилась”, “мне перестали приходить оповещения”, “я не могу работать с сервером проектов из дома” и т.п. Проектный офис начинает тратить время на чтение форумов, изучение настроек ИСУП, чтение литературы и создание памяток для персонала. Но, признаемся честно: все эти проблемы надуманы, жить с ними можно, а к задаче руководства это не имеет никакого отношения.

Проектные роли и их полномочия не определены. Если организация не договорилась кто и за что отвечает в управлении проектом, то конфликтов не миновать. Руководитель проекта может отсутствовать в принципе (конечно, есть активный “идеолог”, но ответственность за его успех или неуспех он не несет). Заказчик проекта отсутствует (вместо него есть таинственный “куратор”, который отвечает непонятно за что (психолог, наверное ;)).  В такой неразберихе автоматизация явно преждевременна. Роли на сервере проектов розданы по принципу “чтобы было”. Ничего плохого в последнем, наверное, нет. Но согласитесь, что лучше давать руководству только ту информацию, которую оно ищет, а не все подряд. Берегите нервы и время шефа.

Информационная система не поддерживает модель принятия решений в проектах. Я люблю спрашивать менеджеров, как в ИСУП можно посмотреть проекты, которые инициированы, но еще не авторизованы в работу? Как по ним можно увидеть плановый срок разработки Устава или Плана управления проектом? Ответ чаще всего нечеткий или отсутствует. Это означает, что модель принятия решений в компании по проектам не определена или ИСУП ее не поддерживает. Поясните мне, какой смысл в инструменте автоматизации, если мы не договорились как будем принимать решения по проектам?

И в качестве вывода: руководство не доверяет информации, предоставляемой сервером проектов. У руководства сложилось ощущение, что разобраться без посторонней помощи в Сервере проектов оно не в состоянии (вспомните про бардак, который там происходит). А персонал уверен, что “проектное управление” – очередное сумасшествие менеджмента, потому что для выполнения простой работы требуется выполнить много странных действий. В такой атмосфере выращивание культуры проектного управления крайне сложно и рискованно.

Если вы все-таки решились на начать внедрение управление проектами с развертывания ИСУП, то позволю себе несколько рекомендаций:

  • Ответьте сами себе: что в организации скрывается под термином “проект”? Какие проекты должны попадать на сервер? В какой момент времени? Без этой “мелочи” двигаться дальше нет смысла.
  • Договоритесь о главных проектных ролях и определите их ответственность в реализации проекта. Это пригодится при настройке ролей в ИСУП.
  • Используйте простые модели принятия решения. Поддерживайте у руководства ощущение простоты и легкости в работе с системой. Если появится доверие к системе, то и решения будут приниматься на основе сведений, предоставленных ИСУП.
почувствовал

Территориально распределенный проектный офис

Уважаемые коллеги!
Кто-нибудь из Вас сталкивался с организацией проектного офиса, который разбросан, распределен по территориальным структурам?

В этой ситуации я вижу несколько недостатков:
1. Двойное подчинение сотрудников проектного офиса.
. каждый сотрудник подотчетен одновременно и руководителю ПО и руководителю структурной единицы
. хуже всего, если сотрудник ПО там же и получает заработную плату, а я только задачи вешаю
2. Сложность контроля работы сотрудника.
. как быть в курсе той работы, которую он реально выполняет (понятно, что есть E-mail и телефон, и даже командировки, но каждый раз?)
3. Проектный офис не является единоличным хранилищем знаний
. информация накапливается в разных регионах и к нам может и не попасть
. всегда есть соблазн исказить некоторую информацию, чтобы не вызывать подозрений и снижения з/п

Сдал тест на Breinbench

Project Management (2005)

Score 3.73
Percentile Scored higher than 89% of previous examinees
Account Percentile Scored higher than 99% of 1 previous examinees within this account
Proficiency Level: Advanced (Master)

Strong Areas

* Project Integration
* Project Human Resources and Communications
* Project Scope
* Project Costs
* Project Processes

Weak Areas

* Project Risk
* Project Framework

Самое ценное в управлении проектами

На мой взгляд, самое ценное в управлении проектами это накопление опыта.
Столько неудачных проектов было в практике ProjectManagement’а, что пора бы и на ошибках учиться!
У нас каждый проект закрывается отчетом руководителя проекта, обновленной информацией в БД рисков и др. документах.

Могу предложить несколько книг!

Всем привет.
Это мое первое посещение ЖЖ и я надеюсь, что это не напрасно потраченное время.

Могу предложить почитать аудитории несколько книг по Управлению проектами (желательно в обмен) :).
1. “Управление проектами” авторы Шапиро и др. Много научности и обоснованности. Для меня оказалась не интересная.
2. Управление проектами с MS Project 2003 под ред. Д.Смирнова. + CD – прочитал, оказалось уже все это я знаю.
3. Менеджмент IT- проектов под ред. Дж.Филлиса. – я – не IT-шник, оказалось не так интересно.