Мозговой штурм: запускаем проект - как оценить продолжительность?

Brainstorm

Добрый менеджмент

Приглашенные эксперты отвечают на каверзные вопросы о планировании сроков.

Сегодняшние эксперты - Дмитрий Письман, Сергей Васильев и Тимофей Левицкий, работают в менеджменте и консалтинге больше 6 лет. Консалтинговая составляющая интересна, т.к. оценивать срок проекта с нематериальным результатом и нечеткими требованиями - нелегко.

Попросим коллеги представиться и сказать пару слов о себе и «привычных» проектах.

Тимофей Левицкий (Т.), сфера деятельности - управленческий консалтинг. Обычно мне приходится работать в проектах длительностью от 6 до 18 месяцев, в которых конечный продукт исключительно важен для бизнеса – как правило, является критическим для реализации стратегии роста. Типичный результат – «работающая система» (обычно – в смысле «организационная система», не техническая).

В моих проектах сроки, как правило, субъективно важнее стоимости или уровня дефектов. Если, например, ERP-система не запускается в конкретный квартал (точнее «целиться» в моих проектах не нужно), предприятие несет существенные потери. Проект может от этого и полностью потерять смысл.

Дмитрий Письман (Д.), сфера деятельности – ИТ-менеджмент, бизнес- и системный анализ.

Главное направление моей деятельности - продуктовая заказная разработка. Продолжительность сильно зависит от задачи. При сопровождении и развитии систем, проект может длиться от 1-2 недель до нескольких месяцев. При разработке систем – проекты, обычно, длятся от полугода до двух лет. Как правило, наиболее важным для проектов являются сроки. Особенно это касается информационных систем, оказывающих существенное влияние на способность заказчика работать. Другое, наиболее существенное ограничение – команда. А вот содержание и качество – наиболее управляемы (в наших проектах «самолеты без внутренней отделки салона и кресел могут начать летать и выполнять свои задачи»; «кресла» будут установлены потом).

Сергей Васильев (С.), сфера деятельности – консалтинг.

Работаю консультантом в консалтинговой компании в городе Сидней, Австралия.

Основная масса проектов связана с разработкой и внедрением программного обеспечения. Средняя продолжительность проектов - от 2-х до 6-ти месяцев. Сроки критичны всегда. Если заказчика не волнуют сроки, то, как правило, его не волнует и результат. Как следствие возникает вопрос - Зачем мы здесь? Более того, если сроки не критичны и не соблюдаются, то это явно не проект, а состояние.

Что ж, - эксперты представились. Время вопросов! Поехали!

1. Перечислите, пожалуйста, методы, которые Вы чаще всего используете для оценки продолжительности проекта (в порядке убывания).

Т.

  • Главный метод – планирование «от потребных сроков» («обратным счетом» получаем необходимые ресурсы).
  • Второй – классика (рисуем на диаграмме Гантта).
  • Третий – это экспертная оценка на основе сравнения с лучшими образцами. Например, известно, что адаптировать сотрудника к сложной должности можно в лучшем случае за 3 месяца.

Д.

На ранних стадиях проработки проекта – метод сравнения с аналогом (он же грубый экспертный метод или, как его иногда называют, если нет близкого аналога – «пальцем в небо»).

В остальных случаях - декомпозиция работ и их оценка (в том числе и интервальная или PERT). Такой план периодически уточняется по ходу проекта.

Есть проекты, в которых планирование не производится вообще. Обычно определяется только крайний срок получения результатов (обычно это либо небольшие проекты, либо исследовательские с высочайшей степенью неопределенности).

С.

Здравый смысл, экспертные оценки проектной команды (тех, кто будет делать проект), опыт аналогичных проектов выполненных в прошлом.

2. Какие у вас любимые / основные источники информации при планировании продолжительности проекта?

Т.

Любимые источники – оценка таких экспертов, которые много раз «это» уже делали. Практика показала, что они (в моей области) существенно не ошибаются.

Д.

  • Собственный опыт (знание предметной области, команды, заказчика и используемых в проекте технологий).
  • Экспертное мнение (при наличии эксперта, который может дать адекватную информацию).
  • База знаний по ранее сделанным проектам (при наличии информации).

С.

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

3. Если вас попросят оценить проект по написанию продолжения романа «Войны и мир» в двух томах коллективом из трех авторов – как вы оцените его продолжительность если...

Т.

…если бы на выполнение оценок у вас была половина дня?

Получить у экспертов данные по средней производительности писателей, спланировать на основе этих данных.

…если бы на выполнение оценок у вас был месяц?

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

Д.

…если бы на выполнение оценок у вас была половина дня?

Три метода:

  • Попробовать найти руководителя аналогичного проекта или информацию по аналогичному проекту по написанию книги.
  • Позвонить авторам и попробовать узнать у них.
  • Позвонить в издательства и спросить.
  • + если у меня есть опыт таких проектов, то к этим трем добавится моя оценка.
  • + в зависимости от понятности мне задачи, я заложу резервы по времени и бюджету от 30% до 300%.

…если бы на выполнение оценок у вас был месяц?

Ранее описанные действия я бы дополнил оценкой рисков (выявил бы заинтересованных лиц, определил бы ключевые риски и их влияние, проверил доступность авторов у меня или на рынке труда).

Все действия по планированию выполнил бы в несколько итераций, постепенно уточняя.

С.

В любом случае – для данного проекта в данной постановке вопроса начал бы с уточнения вводных:

  • Что такое продолжение романа "Война и мир"?
  • Действительно продолжение? Может новая версия (нужно переписать на новый лад)?
  • Каков желаемый объем документа? Каковы рамки по срокам? Качество (допустимы ли ошибки (грамматические, пунктуационные и т.д.)? Для какой аудитории пишем?
  • Насколько важен слог? Должен он быть максимально приближенным к оригиналу? Если да, то нужен автор оригинала, а это ограничение? И т.д.
  • Дальше – по ситуации.

4. Какое самое большое открытие для себя Вы сделали в части планирования проектов за всю свою профессиональную карьеру?

Т.

Самое большое открытие было – что управление рисками вносит такие поправки в планы проектов, что сроки меняются иногда в полтора-два раза.

Д.

Я бы его описал так известной фразой: «Серебряной пули нет!».

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

С.

ВСЕ руководители проектов делают ошибки при планировании, но не все способны эти ошибки решать "на лету", управляя ожиданиями Заказчика.

Невозможно дать четкую оценку ни с первого, ни со второго и даже ни с третьего раза - процесс планирования продолжается до самого окончания проекта.

5. Вспомните свою самую большую (повлекшую наибольшие последствия или ярче всего Вам запомнившуюся) ошибку в планировании проектов?

Т.

Самая большая ошибка была такая: я считал исполнителя (крупную компанию) априори способным справиться с задачей, а он не справился вообще. Это было немалым шоком. Результатом для меня была серьезная карьерная катастрофа.

Д.

Наибольшие курьезы возникают на этапе планирования или от воздействия рисков.

Самая запомнившаяся ошибка, с которой довелось столкнуться – это ошибка продавца в предварительной оценке трудоемкости проекта от более детальной (аналитики + РП) в 25 раз!

С.

Как ни странно не было таких...

6. Поделитесь чем-то, что считаете наиболее ценным (по теме планирования проектов) в одном или нескольких абзацах.

Т.

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

Проводите полноценный ФОРМАЛЬНЫЙ анализ рисков.

Отстаивайте реалистичные сроки и будьте последовательны: каждый проект, который вы по конъюнктурным соображениям взяли в работу с нереальными сроками – это накопление профнепригодности или в виде стресса при попытке добиться успеха «не смотря на», или в виде проваленных проектов.

Д.

Планы пишутся, не только для того, чтобы им следовать, но и чтобы их менять!

С.

К планированию проекта можно приступать тогда, когда цели проекта сформулированы и согласованы как минимум на уровне "Да, мы строим ВОЕННЫЙ самолет! Ни вертолет и ни корабль, а именно САМОЛЕТ! Для перевозки ТОЛЬКО десанта! Инструкция пользователя должна быть в наличии!" На это нужно потратить несколько дней (а может даже и недель) сидя вместе с Заказчиком. Планирование - это процесс определения ПУТИ (а в ходе проекта его корректировка) для достижения ЦЕЛИ. Если цель проекта была изменена - это уже совсем другой проект. В консалтинге не стоит руководствоваться лозунгом "Нас невозможно сбить с пути, нам все равно куда идти!"

Спасибо, коллеги, за то что нашли время!

04.05.2011