Управление проектами
Проект Антона Витязя
Управление содержанием проекта
Хорошо управляемый объем работ
02 years
by Антон Витязь
in Планирование, Управление содержанием проекта, Управление сроками проекта
До какого уровня структуры работ мы должны опускаться для организации ежедневного контроля. Проблема в балансе между микроменеджментом и объемом работ который слишком большой и тем самым размытый для контроля.
Если мы определим в структуре работ много элементов с объемом в 4-6 часов которые будут включать по несколько задач на час-два – мы упремся в микроменеджмент. И он похоронит руководителя проекта и проект вместе с ним.
С другой стороны – если мы нарежем нижний уровень структуры работ блоками по 200 и более часов и всего пару задач по 50 часов то мы потеряемся в том что происходит и слишком поздно узнаем о срыве сроков на несколько дней а то и на неделю.
Оптимальным являются элементы работ которые содержат около 5 задач (плюс-минус 1-2), в среднем по 6-12 часов каждая. То есть задачи на выполнение которых надо 1-2 дня. Т.е. от 30 до 100 часов.
Обязательства, задачи и факт
02 years
by Антон Витязь
in Управление интеграцией проекта, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта, Управление коммуникациями проекта
Если мы рассмотрим коммерческие проект – в нем обязательно найдется место следующим вещам - соглашением о том что-то будет сделано (решено, доставлено, проверено) и будут достигнуты определенные результаты. В самом начале проекта это все находится в договоре и приложением с оценками плана работ. В ходе проекта появляются вопросы, проблемы, изменения.
Все это важные составляющие менеджмента проекта и их следует учитывать – можете помнить, можете копаться в десятке различных документов и почте. А я предпочитаю фиксировать это в списке. Это список обязательств. Природа их может быть разная – часть типов обязательств мы упомянули выше. Общее – срок, стоимость, приоритет, статус и прогресс. Наличие прозрачного и понятного списка обязательств с историей их возникновения и необходимым уровнем деталей по их выполнению – не только инструмент управленческого учета и управления ресурсами но и инструмент коммуникаций с заказчиком.
С обязательствами может быть связан перечень задач. Часть это перечня задач может быть видна заказчику, часть – нет. По задачам мы собираем факт затрат – времени сотрудников, компонент, закупок и т.п. Часть затрат получают оценку (по установленным в контракте часовым ставкам, по прайсу), могут быть предоставлены скидки.
Стоит ли готовить техническое задание своими силами?
02 years
by Антон Витязь
in Анализ, Инициация, Менеджмент, Управление содержанием проекта
Мне уже не раз встречались проекты по подготовке технического задания – это отдельный этап перед большим тендером на внедрение IT систем (ориентировочный бюджет более миллиона долларов).
Руководством предприятий было определено что доверять написание ТЗ одному из потенциальных участников тендера – это перекос. Самим делать подготовку качественного ТЗ было также принято неэффективно – низкие компетенции в анализе требований, высокая загрузка по текущим операционным задачам и внутренним проектам. Выбор пал на консалтинговую компанию.
Как вы оцениваете такой ход заказчика как outsource задачи подготовки ТЗ? Какие проблемы вы видите в этом? Какие преимущества?
В шкуре менеджера продукта – готовим бизнес кейс
02 years
by Антон Витязь
in Инициация, Управление содержанием проекта, Управление продуктом
Речь пойдет о самых первых шагах проекта по созданию рыночного продукта – его инициации. В большинстве проектов менеджеру дают требования и говорят – на те требования и иди делай. Но иногда менеджера проекта могут привлекать на этапе инициации проекта и просят организовать работы по составлению обоснования проекта.
Надо понимать что это работа больше предназначена для менеджера продукта (product manager). Но в наших краях (кроме телекомов и ряда банков) это еще редкая профессия. Посему нашему брату, менеджеру проекта, надо осваивать и смежные навыки с менеджером продукта. В частности подготовку бизнес кейса и составление документа маркетинговых требований. Речь, конечно же, не идет о том чтобы менеджер проекта стал оракулом маркетинга – но вот знать что спросить с маркетологов и продавцов надо. Надо знать что мы хотим получить бизнес кейс (business case / MRD – Marketing Requirements Document).
Для кого это документ:
- Для спонсора проекта – одного из директоров принимающих решение о запуске проекта по разработке нового продукта или услуги
- Для функциональных директоров которые будут участвовать в согласовании документа – это маркетинг, продажи, финансы.
- Его собственником должен быть менеджер продукта – кто то из маркетологов, менеджеров по развитию бизнеса или руководства. Данный документ не должен находиться в собственности менеджера проекта – если конечно речь не идет о трансформации позиции с менеджера проекта в менеджера продукта.
Давайте разберемся что должно быть в документе:
- Резюме для руководства – менее чем на страницу вывод из всего документа – предлагающего один или несколько вариантов решения, ключевые цифры и основания. Несколько вариантов решения полезно тогда когда руководство любит сделать свой вклад в решение – даже если правильный вариант очевиден.
- Кто клиент продукта. Возможно будет несколько обособленных сегментов клиентов которые будут пользоваться вашим продуктом (услугой). Определить клиента не указав потребности – это значит говорить без каких либо оснований. Какие цели у клиентов? Какие проблемы они испытывали при использовании продуктов-заменителей или продуктов конкурентов? Где они в реальной жизни и когда нуждаются в продукте? Где они его приобретают?
- Описание продукта – описание посредством пользовательских характеристик верхнего уровня.
- Отличие продукта от конкурентов. В чем он уникален, кто ближайший конкурент, кто заменитель, в чем разница (конкурентное преимущество). Очень желательно проверить себя на то что мы не создаем еще один похожий на 100 уже существующих продуктов да еще не с самым лучшим соотношением цена-качество.
- Риски, связанные с разработкой, производством и продажей продукта. Очень хорошо трезво взглянуть на рынок, оценить вероятность возможностей, ответные действия конкурентов и т.п.
- Жизненный цикл продукта – когда выпускаем продукт, какие масштабы производства в какое время запланировано, в каких регионах. Сюда также полезно включить развитие характеристик продукта – создание новых версий и редакций продукта.
- Анализ затрат и доходов
- Соответствие стратегии, миссии и видения развития компании. Анализ соответствия по отдельным стратегиям – финансовой (можем ли мы обеспечить денежный поток необходимый для реализации проекта, достаточно ли у нас финансового запаса прочности), технологический (есть ли у нас необходимые инструменты и технологии, достаточно ли у нас опытных людей)
Откуда берется работа?
02 years
by Антон Витязь
in Планирование, Управление содержанием проекта
Давайте рассмотрим вопрос – откуда берется структура работ? О важности структуры работ много написано и сказано. На ее основе определяется объем работ и далее стоимость и длительность выполнения. Все что мы в не запишем будет запланировано и сделано (при успешном ходе проекта). Поэтому важно включить в структуру работ то что нужно (и конечно же не включать то что не нужно) и не пропустить то что ожидается.
Источниками элементов структуры работ будут следующие:
- Договор – определяет условия договора, структуру проекта – фазы, этапы, ключевые ограничения и даты
- Требования (SoW) – указывается что ожидается получить в результате проекта, чем должна сопровождаться сдача того или иного элемента работ
- Маркетинговые документы – конкурентный анализ, маркетинговые требования
- Коммуникации с клиентом (зафиксированные, желательно) – далеко не все записывается в документах с требованиями и договоре. Сказанное или отправленное по электронной почте может быть не менее важно для успеха проекта. Стоит получить подтверждение по электронной почте и в включать важные элементы в структуру работ.
- Методика проекта – определяется входами и выходами процессов, принятой в методике структуре работ верхнего уровня
- Организационные политики и другие методики
- Наработки с предыдущих проектов – накопленный опыт выполнения проектов
- Члены команды – их идеи, опыт, обсуждение. Несмотря на то что данный источник один из последних в списке – он обязательно должен быть неоднократно применен как для анализа, проработки, оценки так и для финального утверждения структуры работ.
6 углов проектного менеджера – уже не так железно
02 years
by Антон Витязь
in Методика, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта, Управление качеством проекта, Управление рисками проекта
Развитие концепции железного треугольника управления проектами- стоимость, время и содержание проекта – шестиугольник проектного управления.
В состав шестиугольника входят следующие дополнительные компоненты:
- Удовлетворенность клиента (Customer Satisfaction)
- Риск (Risk)
- Качество (Quality)
С моей точки зрения железный треугольник был действительно железным – меняя одну из составляющих мы неизбежно оказывали влияние на одну из двух других или обе. В случае с шестиугольником это уже не очевидно.
Удовлетворенность клиента – безусловно одна из важнейших составляющих проектного управления. Но в ней есть немало эмоционального контекста – и далеко не всегда она имеет прямые (железные) связи с изменением других компонент.
Аналогично риск. Сама природа риска такова что мы скорее не может полностью покрыть перечень рисков которым подвержен проект. В свою очередь точность измерения рисков также условна. Таким образом трудно утверждать насколько реально повлияло изменение одной из компонент на риск.
Применение горизонта планирования в Microsoft Project
03 years
by Антон Витязь
in MS Project, Мониторинг и управление, Планирование, Управление содержанием проекта, Управление сроками проекта
Во многих проектах есть свой предел в плане до которого мы можем четко расписать задачи. После этого предела у нас еще нет возможности детализировать структуру работ, дать правильные оценки. Возможно даже не ясно по какому сценарию далее пойдет проект – могут быть готовые несколько сценариев но не один мы не можем пока считать утвержденным.
В таком случае мы говорим о Горизонте планирования.
Горизонт планирования – временные рамки от начала проекта или текущего момента до определенного момента будущего когда возможна оценки длительности задач, четко ясен вариант выполнения проекта и по большинству задача возможно назначение реальных исполнителей.
При использовании Microsoft Project вы можете несколькими способами определить в плане проекта горизонт планирования:
- Использовать стандартную колонку (атрибут задачи) Publish (Публиковать)
- Добавить колонку с указанием входит задача в горизонт планирования или нет
При использовании атрибута Publish (Публиковать) вы получаете возможность определять какие задачи будут опубликованы для исполнителей на проектном сервере а какие нет. Таким образом достигается автоматическое определение какая задача готова для передачи к сведению исполнителям – а какие еще не готовы.
Ниже для примера план проекта в котором несколько задач разработки закрыты для публикации:
Сделать сделали, а передать то – забыли!
03 years
by Антон Витязь
in Внедрение, Завершающие, Инициация, Исполнение, Планирование, Управление интеграцией проекта, Управление содержанием проекта, Управление качеством проекта, Управление коммуникациями проекта, Управление рисками проекта
Среди ошибок проектных менеджеров при разработке новых ИТ сервисов встречается ошибка отсутствия блока необходимых работ по передаче сервиса в промышленную эксплуатацию.
Эта ошибка коренится в том что проектный менеджер забывает включить в перечень ключевых заинтересованных лиц ИТ менеджеров по операциям:
- менеджеров сервиса
- менеджеров по обслуживанию пользователей,
- техническая поддержка – контакт центр поддержки ИТ
Какие могут возникнуть риски? Масса!
Риск проблем с технической поддержкой. Уже во второй половине проекта часто начинается доносится тревожный звоночек – некоторые пользователи, которые участвуют в ознакомлении с первыми релизами продукта, вместо обговоренного контакта с менеджером проекта начинают по привычке звонить в техническую поддержку. Техническая поддержка может по разным причинам сделать следующее:
- Отказать пользователю в обслуживании – что создаст негативное впечатление о проекте
- Дать неверный совет по использованию ПО – что может привести к негативному впечатлению о продукте
- Дать обещание ответить пользователю и не выполнить обещание в срок – пока поддержка начнет искать кто реально может обслужить данный вопрос. Хуже всего если в технической поддержке просто забросят вопрос.
Конфликт с другим сервисом находящимся в промышленной эксплуатации. Хуже всего если это важный операционный сервис критичный для работы бизнеса. Данный конфликт может создать проблемы для текущих операций пользователей. Кроме всего прочего это может косвенно указать на архитектурные ошибки или ошибки в планировании развертывания – связанные с тем что не были учтены все сервисы работающие у конечных пользователей продукта.
Что необходимо сделать менеджеру проекта:
- Обязательно включить в перечень заинтересованных лиц менеджеров по ИТ операциям. Найти всех кто отвечает за работу с пользователями, техническую поддержку. Включить в перечень ключевых лиц в работу над архитектурой, развертыванием и тестированием. Обязательно в этап передачи в эксплуатацию и go live.
- Определить порядок приема в эксплуатацию. Какие внутренние стандарты приняты в компании по передачи ИТ сервисов в эксплуатацию?
- Вовлечь в работу и информировать. Делать рассылки о всех операциях в рамках проекта которые касаются конечных пользователей. Установить процедуру согласования подобных операций.
- Включить в план проекта работы по обучению технической поддержки и менеджеров по ИТ операциям на всех стадиях проекта – от ознакомительной на ранней стадии, совместной работы над архитектурой, планами по развертыванию и тестированию до конечного обучения.
Критичность закрытия фаз/итераций. Пример из практики
03 years
by Антон Витязь
in Анализ, Завершающие, Инициация, Исполнение, Мониторинг и управление, Планирование, Процессы, Управление интеграцией проекта, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта, Управление качеством проекта, Управление человеческими ресурсами проекта, Управление коммуникациями проекта, Управление рисками проекта, Управление поставками проекта
Очень важно в крупных корпоративных проектах закрывать фазы (этапа, итерации) согласованием пакета закрывающих документов.
Сам факт закрытия фазы позволяет:
- показать промежуточный результат в проекте
- согласовать с заказчиком понимание где сейчас находится проект
- отметить срез ключевых показателей проекта – по срокам, стоимости и объему работ
- определить легитимную основу для дальнейших действий
- снизить риски разногласий, проблем в понимании достигнутых договоренностей и результатов
- приучить заказчика к умению закрывать проект – приучать к этому нужно с ранних этапов, делать это системно по четко определенной процедуре
- выстраивать логическую связь от достигнутых результатов к запланированном на следующем этапе
Из практики отечественных проектов встречались ситуации когда в проекте на этапе зависли на согласовании несколько аналитических документов. Казалось бы согласованным в документах было около 80%. Команда проекта решила что необходимо двигаться к разработке и по ходе решить оставшиеся 20% требований. Однако в течении нескольких последующих месяцев это привело к тому что
- аналитический документ и зменился более чем на половину
- объем работ вырос в полтора раза
- было потеряно около трети времени на разработку в следствии кардинального изменения
- существенно изменились сроки проекта
- поставщик понес убытки на потерянном объеме работ
- клиент был недоволен что “его по-прежнему не пониманию и делают всякую ерунду”
- клиент наблюдая податливость в протягивании согласования аналитического документа позволял себе “пропихивать” новые изменения и расширять рамки проекта
У каждого свое понимание конца
03 years
by Антон Витязь
in Завершающие, Мониторинг и управление, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта
Можно смело утверждать что у клиента и у подрядчика есть свое понимание конца проекта. И именно это является одной из причин затягивания сдачи проекта.
Чтобы избежать этого – надо в самом начале проекта зафиксировать как можно четче что является результатом проекта, как и кто определяет на основании чего качество результатов (продуктов) проекта.
По ходу проекта надо управлять изменениями и при необходимости обновлять не только структуру работ, сроки и стоимость – но и условия приема проекта.
Next »