Управление сроками проекта

Волна по каплям принятых сдвигов по ресурсам

0

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

Каждый из таких ресурсных сдвигов – капля. Там два часа, там час, там пол дня, ну приболел на день-два. Капля сама по себе в большом проекте с запасом времени – это ничего. Но если работают риски и на проект  начинает литься дождик из таких капель – вы можете не рассчитать (или вам могу просто не дать) такие резервы. К конце проекта из каплей сложется огромный объем который прорвет плотину буферов и снесет руководителя проекта со срокам сдачи проекта.

Поразительно – но даже согласованные и благославленные сдвиги ресурсов высшим руководством в конце концов не спишутся. О них руководство через месяц точно забудет – для них это будет все рутина принятых мимолетных решений. А вот через месяц ваш проект и ваш сдвиг со сроками будет им резать глаз.

Что можно делать в такой ситуации?

  1. Записывать все изменения в ресурсах и их влияние. По возможности получать согласование такой записи – или хотя бы прикреплять к ней то что можно считать согласованием (например, письмо от руководителя).
  2. По каждому изменений – в какой форме оно бы не поступало - отписываетесь коротким письмо на руководителя с обратной связью – что вы приняли измение и что вы напоминаете про эффект данного изменения на проект.
  3. Доводите информацию об изменениях в статусе проекта.
  4. Не принимайте изменения которые противоречат уставу проекта или стратегии определенной спонсором проекта. Если это конфликт – решайте его. Если не можете – вовлекайте спонсора проекта.
  5. Постарайтесь найти способ компенсировать выдернутые ресурсы – возможно вы сможете найти замену человек или договориться про увеличение его ресурса времени на ваш проект позднее

 

Методы оценки

0

Сегодня наш эксперт, Евгений Петров, начал обсуждение методов оценки в проекте

Экспертная оценка:

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

Оценка по Аналогам:
- оценка сверху вниз
- на основании предыдущих выполненных задач
- проекты и задачи похожи по сути, а не по внешнему виду
- оценщик, участвовал в предыдущем проекте
- отсутствует детальная информация по проекту

Параметрическая оценка:
- Одну башню ставить 1 месяц, в проекте 10 башен, значит проект займет 10 месяцев (нужно добавить резерв)
- Как это ни смешно, по количеству строк кода в программе :)

Оценка по трем точкам (Оптимист, Реалист Пессимист):
- триангуляция, PERT

Анализ резервов:
- Оценка вероятности. При 10% вероятности задержать проект на 10 недель, добавляес к проекту 1 неделю.

Воздушная атака на неопределнность оценок

0

В проекте при необходимости оценки работ можно столкнуться с ситуацией когда необходимо дать оценку проекта – а опыта выполнения данных задач нет и достоверных оценок тоже нет. Если вам повезло и это несколько десятков типичных задач разной сложности и вы можете позволить себе их попробовать - то следует выполнить пилот перед получением оценки.

Вот что по этому поводу советует из своего опыта руководитель проектов Киевстар Евгений Петров:

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

Что сделали:
1) Разделили мигрируемые данные на 3 категории (простой, средний, сложный);
2) Провели пилот. Несколько специалистов проводили миграцию разной сложности контента, скажем по 2 единицы каждой сложности. Данные усреднили по исполнителям. Получились оценки длительности миграции каждого типа сложности контента. Например Простой 1 день, средний – 2, Сложный – 5 дней.
3) Умножив оценку на количество, получили общий объем трудозатрат
4) Назначаем ресурсы, получаем длительность
5) Закладываем резерв после оценки рисков:
- переменная загрузка специалистов
- больничные
- инструменты миграции могут сбоить
- и т.д.
6) Коммуницируем спонсору и заказчику риски, договариваемся, что будем делать в случае их наступления
7) Начинаем работать!”

Из своего опыта работы по аналогичному сценарий могу добавить что после пункта (2) был сделан вывод что мы можем рассмотреть варианты

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

Выравнивающие задрежки

0

В Microsoft Project 2010 есть инструмент выравнивающих задержек. С помощью него мы указываем особые виды задержек между задачами – задержку между задачами и задержку назначения ресурса на задачу с целью выравнивания загрузки ресурсов. Многие руководители проектов не знают про этот инструмент и применяют вместо него лаги между задачами. Однако с точки зрения логики проекта – это разные задержки и говорят они о разной природе задержек.

Давайте посмотрим какое определение задержкам дается на сайте Microsoft:

В поле «Выравнивающая задержка» отображается время, в течение которого определенная ранее дата начала задачи или назначения будет задержана в результате выравнивания загрузки ресурса. Выравнивающая задержка задачи выражается в единицах астрономической длительности, а выравнивающая задержка назначений — в обычных единицах длительности. Фактически сведения в данном поле ресурса не отображаются, просто данные соответствующих полей назначения «Выравнивающая задержка» становятся доступными.

Обратите внимание на то что выравнивающий резерв при назначении на задачу может сдвинуть срок задачи на выравнивание. При этом вы увидите картину когда календарная длительность задачи будет 3 дня, а проектная – 2 (выравнивающий резерв на назначение был установлен в 1 день – 8 часов).

Пример:

Оценки с размахом. Как нам оценить такую задачу?

0

В вашем проекте есть задача по которой эксперт дает такую оценку: задача эта дня на 3-4, но если будут сложности то может понадобиться дней 6-7, не меньше как часа 3-4 в день успею поковыряться. Но если будут серьезные проблемы то может недели две а то и вовсе не знаю сколько. При серьезных проблемах у нас нет гарантии скорости ответа и готовности ответа от вендора.

Как нам оценить такую задачу?

Путь особого внимания

0

Критический путь – драйвер конечного срока проекта. Единственная возможность раньше выполнить проект или просто держаться цели срока проекта – это лучшим образом выполнять задачи на критическом пути. Из треугольника проекта сроки проекта чаще всего находятся в наибольшем фокусе.

Common sense подсказывает что мы должны наилучшим образом планировать критический путь проекта. На что следует обратить внимание:

  • А стоят ли у нас на критическом пути лучшие ресурсы?
  • Можем ли мы выполнить параллельно задачи стоящие последовательно на критическом пути?
  • Можем ли мы увеличив ресурсы на задачи на критическом пути сделать их быстрее?
  • Чем покрыты риски которые влияют на задачи на критическом пути?
  • Какой путь может стать критическим?

Спрашивайте про отсутствие

0

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

Неизвестное отсутствие ключевых участников проекта как со стороны заказчика так и внутри команды проекта – это риск существенного сдвига сроков. И этот риск один из наиболее часто срабатывающих практически в любой период. Летом отпуска – более прогнозируемое. Зима – люди могут заболеть в любой момент, наибольший риск – эпидемии.

Отсутствие может быть самое разное. Для каждого из типов отсутствия стоит предпринимать разные действия:

  • Отпуск - получайте данные у HR но обязательно сверяйте с сотрудником и его руководителем. Часто встречается ситуация когда отпуск в кадрый подает за год, а потом планы на отпуск меняются.
  • Командировка - уточняйте как у сотрудника так и у его руководителя
  • Обучение - уточняйте как у сотрудника, у его руководителя и у HR. Есть такие виды информации которые могут знать только HR (их планы по обучению сотрудников), только сотрудник (его личные планы по обучению), руководитель (договаривается об обучении сотрудников с тренером)
  • Личные события (свадьба, лечение, небольшие отсутствия, посидеть с ребенком) – у сотрудника.
  • Болезнь - уточните как человек часто болеет. Есть такие люди которые болеют пару дней в году, а есть такие – которые 3-4 раза по неделе за зиму. Уточните есть ли дети и как часто они болеют

 

400% запас на Черных лебедей

0

Отличная статья про IT проекты “Черные лебеди” вышла у Александра Черникова

Простая метрика на основе статистики черных лебедей для оценки прочности организации перед лицом IT проектов:

«Любая компания, рассматривающая большие технологические проекты, должна спросить себя, достаточно ли она сильна, чтобы в случае необходимости увеличить бюджет проекта на 400%».

Хорошо управляемый объем работ

0

До какого уровня структуры работ мы должны опускаться для организации ежедневного контроля. Проблема в балансе между микроменеджментом и объемом работ который слишком большой и тем самым размытый для контроля.

Если мы определим в структуре работ много элементов с объемом в 4-6 часов которые будут включать по несколько задач на час-два – мы упремся в микроменеджмент. И он похоронит руководителя проекта и проект вместе с ним.

С другой стороны – если мы нарежем нижний уровень структуры работ блоками по 200 и более часов и всего пару задач по 50 часов то мы потеряемся в том что происходит и слишком поздно узнаем о срыве сроков на несколько дней а то и на неделю.

Оптимальным являются элементы работ которые содержат около 5 задач (плюс-минус 1-2), в среднем по 6-12 часов каждая. То есть задачи на выполнение которых надо 1-2 дня. Т.е. от 30 до 100 часов.

Обязательства, задачи и факт

0

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

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

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

Go to Top