Планирование

Управление по контрольным точкам

0

Часто повторяемым инструментом на последней конференции было управление по контрольным точкам (Milestone Trend Analysis) – как инструмент для топ менеджмента / спонсора проекта.

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

Ключевые точки могут быть как частью проекта так и лежать вне его – быть на уровне программы или портфеля проектов. Для руководителя строится одна или несколько карт контрольных точек – набор связанных по смысле контрольных точек (7+/-2) отложенных по вертикали на плановую дату контрольной точке а по горизонтали – на состояние контрольной точки на отчетную дату.

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

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

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

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

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

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

0

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

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

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

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

0

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

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

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

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

Компоненты информационной среды управления проектами

0

Для более менее крупных проектов мы задумываемся о построении информационной системы для управления проектами. Прежде чем говорить – да у нас есть MS Project – и в северном варианте (Project Server) он будет очень классно покрывать все нужды – не спешите. Давайте рассмотрим основные компоненты такой среды и какие потенциальные компоненты могут подойти.

Коммуникации - сайт проекта, форум, рассылка, группы. Это может быть как сайт на SharePoint так и любая WiKi/Wordpress/LinkedIn группа. Для небольшого бизнеса вполне удобно создавать закрытые группы в социальных сетях и использовать их как готовые платформы для проектных коммуникаций.

Документы проекта – минимум файловый сервер. Лучше всего – сразу SharePoint или аналогичное средство с функционалом управления версиями. Если документы проекта будут готовиться исключить в веб форме – то вам также отлично подойдут Wiki системы. В них очень легко контролировать версии документов (но несколько сложнее научиться писать их с использованием внутренней разметки)

Записи проекта - это различные типы записей – структура работ, запросы на изменения, вопросы, дефекты, риски, требования, тесты, результаты выполнения тестов. Кроме фиксации самих записей важно чтобы работали хотя бы простые workflow по организации работы над записями – это даже крайне желательно. Для управления такого рода записями нужна система с удобным конструктором как новых записей так и процессов, удобными формами. SharePoint в базовой конфигурации для этого не очень хорошо подходит (но вполне терпимо для малых проектов). Хорошим кандидатом сюда – Microsoft Dynamics CRM  2010, SharePoint + Nintex + кастомные решения для организации документооборота. Также могут подойти ваши существующие ERP системы (в них легко создавать новые сущности и формы но менее просто решаются вопросы по автоматизации процессов)

Календарь проекта и Фактические данные – тут рулит Microsoft Project.

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

 

Неправильные 8 часов в день

0

По умолчанию доступность ресурса участника проекта в день 8 часов. Однако можем ли мы оставить данную оценку по умолчанию? Я думаю нет. И тому есть ряд причин.

Эффективная сосредоточенная работа среднего офисного специалиста – за вычетом рабочих совещаний, звоноков телефона, прочтения почты, шуток коллег, отвлечений в Интернете, после обеденной дремы – я не думаю что превыщает 4 часа. Можно накинуть максимум 2 часа на “тупую” работу за чашкой кофе + в наушнкиках после обеда. Все.

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

Следовательно что правильно сделать – заложить во все ресурсы что у них есть в проекте НЕ БОЛЕЕ 6 ЧАСОВ В ДЕНЬ. И это в идеале – когда нет другой операционной работы и других проектов.

Т.е. закладываю 8 часов в день мы себя обманываем на 30% минимум!

Откуда берется работа?

0

Давайте рассмотрим вопрос – откуда берется структура работ? О важности  структуры работ много написано и сказано. На ее основе определяется объем работ и далее стоимость и длительность выполнения.  Все что мы в не запишем будет запланировано и сделано (при успешном ходе проекта). Поэтому важно включить в структуру работ то что нужно (и конечно же не включать то что не нужно) и не пропустить то что ожидается.

Источниками элементов структуры работ будут следующие:

  • Договор – определяет условия договора, структуру проекта – фазы, этапы, ключевые ограничения и даты
  • Требования (SoW) – указывается что ожидается получить в результате проекта, чем должна сопровождаться сдача того или иного элемента работ
  • Маркетинговые документы – конкурентный анализ, маркетинговые требования
  • Коммуникации с клиентом (зафиксированные, желательно) – далеко не все записывается в документах с требованиями и договоре. Сказанное или отправленное по электронной почте может быть не менее важно для успеха проекта. Стоит получить подтверждение по электронной почте и в включать важные элементы в структуру работ.
  • Методика проекта – определяется входами и выходами процессов, принятой в методике структуре работ верхнего уровня
  • Организационные политики и другие методики
  • Наработки с предыдущих проектов – накопленный опыт выполнения проектов
  • Члены команды – их идеи, опыт, обсуждение. Несмотря на то что данный источник один из последних в списке – он обязательно должен быть неоднократно применен как для анализа, проработки, оценки так и для финального утверждения структуры работ.

Применение горизонта планирования в Microsoft Project

0

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

В таком случае мы говорим о Горизонте планирования.

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

При использовании Microsoft Project вы можете несколькими способами определить в плане проекта горизонт планирования:

  • Использовать стандартную колонку (атрибут задачи) Publish (Публиковать)
  • Добавить колонку с указанием входит задача в горизонт планирования или нет

При использовании атрибута Publish (Публиковать) вы получаете возможность определять какие задачи будут опубликованы для исполнителей на проектном сервере а какие нет. Таким образом достигается автоматическое определение какая задача готова для передачи к сведению исполнителям – а какие еще не готовы.

Ниже для примера план проекта в котором несколько задач разработки закрыты для публикации:

Go to Top