Завершающие

Сделать сделали, а передать то – забыли!

0

Среди ошибок проектных менеджеров при разработке новых ИТ сервисов встречается ошибка отсутствия блока необходимых работ по передаче сервиса в промышленную эксплуатацию.

Эта ошибка коренится в том что проектный менеджер забывает включить в перечень ключевых заинтересованных лиц ИТ менеджеров по операциям:

  • менеджеров сервиса
  • менеджеров по обслуживанию пользователей,
  • техническая поддержка – контакт центр поддержки ИТ

Какие могут возникнуть риски? Масса!

Риск проблем с технической поддержкой. Уже во второй половине проекта часто начинается доносится тревожный звоночек – некоторые пользователи, которые участвуют в ознакомлении с первыми релизами продукта, вместо обговоренного контакта с менеджером проекта начинают по привычке звонить в техническую поддержку. Техническая поддержка может по разным причинам сделать следующее:

  • Отказать пользователю в обслуживании – что создаст негативное впечатление о проекте
  • Дать неверный совет по использованию ПО – что может привести к негативному впечатлению о продукте
  • Дать обещание ответить пользователю и не выполнить обещание в срок – пока поддержка начнет искать кто реально может обслужить данный вопрос. Хуже всего если в технической поддержке просто забросят вопрос.

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

Что необходимо сделать менеджеру проекта:

  • Обязательно включить в перечень заинтересованных лиц менеджеров по ИТ операциям. Найти всех кто отвечает за работу с пользователями, техническую поддержку. Включить в перечень ключевых лиц в работу над архитектурой, развертыванием и тестированием. Обязательно в этап передачи в эксплуатацию и go live.
  • Определить порядок приема в эксплуатацию. Какие внутренние стандарты приняты в компании по передачи ИТ сервисов в эксплуатацию?
  • Вовлечь в работу и информировать. Делать рассылки о всех операциях в рамках проекта которые касаются конечных пользователей. Установить процедуру согласования подобных операций.
  • Включить в план проекта работы по обучению технической поддержки и менеджеров по ИТ операциям на всех стадиях проекта – от ознакомительной на ранней стадии, совместной работы над архитектурой, планами по развертыванию и тестированию до конечного обучения.

 

Критичность закрытия фаз/итераций. Пример из практики

0

Очень важно в крупных корпоративных проектах закрывать фазы (этапа, итерации) согласованием пакета закрывающих документов.

 

Сам факт закрытия фазы позволяет:

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

Из практики отечественных проектов встречались ситуации когда в проекте на этапе зависли на согласовании несколько аналитических документов. Казалось бы согласованным в документах было около 80%. Команда проекта решила что необходимо двигаться к разработке и по ходе решить оставшиеся 20% требований. Однако в течении нескольких последующих месяцев это привело к тому что

  • аналитический документ и зменился более чем на половину
  • объем работ вырос в полтора раза
  • было потеряно около трети времени на разработку в следствии кардинального изменения
  • существенно изменились сроки проекта
  • поставщик понес убытки на потерянном объеме работ
  • клиент был недоволен что “его по-прежнему не пониманию и делают всякую ерунду”
  • клиент наблюдая податливость в протягивании согласования аналитического документа позволял себе “пропихивать” новые изменения и расширять рамки проекта

У каждого свое понимание конца

0

Можно смело утверждать что у клиента и у подрядчика есть свое понимание конца проекта. И именно это является одной из причин затягивания сдачи проекта.

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

По ходу проекта надо управлять изменениями и при необходимости обновлять не только структуру работ, сроки и стоимость – но и условия приема проекта.

E-mail – наша рисковая зона комфорта

0

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

Что проще написать письмо? Это не подбирать на лету слова, не тратить время на сборы и т.п. Потом всегда можно сказать – я-вам-выслал-письмо-по-этому-поводу-сейчас-вам-скажу-дату-и-время …

А всегда ли это помогает нам добиваться результата, всегда ли e-mail является самым лучшим инструментом коммуникаций?

Мы забываем о том что сегодня люди завалены почтой и делами, делами и почтой. Что может произойти с электронным сообщением:

  • Он будет 150 непрочитанным сегодня письмом где-то посередине этого списка
  • Его прочтут по диагонали, сделают неправильные выводы и возможно сделают (или не сделают) то что вы хотите
  • Даже если вам ответят – могут сослаться на то что вас не так поняли и когда отвечали то имели не это в виду
  • Вы не знаете с каким эмоциональным состоянием, настроением, мотивацией отвечали вам. С другой стороны также теряют массу невербальных коммуникаций
  • Ваша шутка в письме может прийтись к прочтению в очень неудачное время. В личной беседе вы можете лучше оценить обстановку и собеседника. А в оффлайне?
  • Некоторые вообще мало читают электронную почту. Есть руководители у которых компьютер – атрибутика стола. Электронную почту принимает офис менеджер.

(more…)

Процессы по PMBoK

0

Группа процессов инициации

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

В группу процессов инициации входят следующие процессы:

  • Разработка Устава проекта
  • Разработка предварительного описания содержания проект

Группа процессов планирования

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

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

Группа процессов мониторинга и управления

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

  • Мониторинг и управление работами проекта
  • Общее управление изменениями
  • Подтверждение содержания
  • Управление содержанием
  • Управление расписанием
  • Управление стоимостью
  • Процесс контроля качества
  • Управление командой проекта
  • Отчетность по исполнению
  • Управление участниками проекта
  • Управление рисками
  • Администрирование контрактов

Группа завершающих процессов

Формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению. Группа завершающих процессов содержит следующие процессы:

  • Закрытие проекта
  • Закрытие контрактов
Go to Top