Инициация

Хорошее определение заказчика

0

Заказчик это тот кто в ходе приемки скажет “годится, принято” – и его “принято” будет ретранслировано по вертикали и горизонтали. Без его “принято” решение о приемке проекта не будет, его голос является решающим.

via Ivan Selikhovkin

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

 

Устав проекта

0

К вашему вниманию предлагается шаблон документа Устав проекта.

В документ включены следующие разделы

1 Обоснование проекта
1.1 Краткое описание проекта
1.2 Решаемые проблемы/возможность
1.3 Бизнес цели
1.4 Критерии успеха
1.5 Связи и зависимости
2 Определение проекта
2.1 Результаты проекта
2.2 Критерии приемки результатов проекта
2.3 Исключено из проекта
2.4 Время
2.5 Стоимость
2.6 Другие требования
2.7 Допущения и ограничения
3 Организационная структура проекта
3.1 Управляющий комитет проекта
3.2 Руководство проектом
3.3 Команда проекта
3.4 Ключевые лица со стороны заказчика
4 Права и обязанности
4.1 Права и обязанности руководителя проекта
4.2 Права и обязанности управляющего комитета
4.3 Права и обязанности члена команды
5 Порядок управления проектом
5.1 Методика управления проектом
5.2 Политика управления командой проекта
5.3 Политика коммуникаций
5.4 Порядок приемки результатов проекта

 

Скачать шаблон документа Устав проекта в PDF формате

Скачать шаблон документа Устав проекта в Word формате

Стоит ли готовить техническое задание своими силами?

0

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

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

Как вы оцениваете такой ход заказчика как outsource задачи подготовки ТЗ? Какие проблемы вы видите в этом? Какие преимущества?

В шкуре менеджера продукта – готовим бизнес кейс

0

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

Надо понимать что это работа больше предназначена для менеджера продукта (product manager). Но в наших краях (кроме телекомов и ряда банков) это еще редкая профессия. Посему нашему брату, менеджеру проекта, надо осваивать и смежные навыки с менеджером продукта. В частности подготовку бизнес кейса и составление документа маркетинговых требований. Речь, конечно же, не идет о том чтобы менеджер проекта стал оракулом маркетинга – но вот знать что спросить с маркетологов и продавцов надо. Надо знать что мы хотим получить бизнес кейс (business case / MRD – Marketing Requirements Document).

Для кого это документ:

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

Давайте разберемся что должно быть в документе:

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

NASA Guidance for writing Work Statement

0

http://www.hq.nasa.gov/office/procurement/newreq1.htm

DoD Handbook for Preparation of Statement of Work

0

DOD Handbook For Preparations of  SOW.pdf

Документ определения работы

0

В данной статье к вашему вниманию предлагается один из первых документов проекта – Документ определения работы (Statement of Work, SOW). По результатам описания документа будет предложен к обсуждению шаблон данного документа.

Следует отметить что в нашей практике документ с названием Документ определения работы встречается редко. Чаще всего он принимает вид Технического задания или просто договора или приложений к договору. Далее будем придерживаться его классического названия – Документ определения работ (Statement of Work). По тексту будем применять как полное так и сокращенное название документа (SOW)

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

Типы SOW. SOW может составляться на разных этапах проекта. На этапе инициации подачи предложений от поставщиков (Proposal SOW, PSOW) и на этапе подписания договора с конкретным поставщиком (Contract SOW, CSOW).

Состав документа. Давайте рассмотрим более подробно каждую из составляющих документа определения работы ориентируясь на CSOW тип документа:

  • Определение проекта
    • Проблема/Возможность – что является основанием для выполнения проекта (почему).
    • Стратегия решения – какая стратегия решения проблемы реализации возможности (каким образом)
    • Видение решения – краткое описание решения (что).
    • Цель проекта – определение целей проекта со стороны заказчика
    • Границы проекта – что входит и что не входит в проект.
  • Результаты проекта – состав продуктов и услуг которые получит заказчик от исполнителя проекта, ключевые документы и результаты работ проекта. Желательно не перегружать основной документ большим объемом описания бизнес требований к продуктам и услугам – а вынести это в отдельное приложение.
  • Роли и ответственность – указание ролей и ответственность за результаты проекта, процессы или отдельные работы. Перечень конкретных людей с указанием их ролей.
  • Условия - перечень условий и правил выполнения работ. Следует рассмотреть условия выполнения работ с обеих сторон – заказчика и исполнителя.
    • Условия оплаты
    • Условия по объему работ
    • Условия по срокам
    • Условия конфиденциальности
    • Условия по определению прав собственности
    • Условия по квалификации участников проекта
    • Санкции и штрафы
    • Условия по соответствию стандартам и законодательству
    • Форсмажор
  • Подход к выполнению работ – описание ключевых требований к порядку выполнения работ. Если есть задокументированная методика проектного управления – достаточно указать требования по следованию методикой и включить ее как приложение к документу. Следует рассмотреть порядок выполнения работ с обеих сторон – заказчика и исполнителя.
    • Порядок контроля выполнения работ
    • Порядок управления изменениями
    • Порядок приема работ
    • Порядок передачи результатов работ
    • Порядок оплаты работ
    • Подход к решению проблем
    • Порядок коммуникаций
    • Порядок замены состава участников проекта

Рекомендуемые приложения к документу:

  • Ключевые бизнес требования к продуктам и услугам (business requirements)
  • Первичная структура работ (WBS)
  • Соглашение по качеству предоставляемых услуг (QoS)

Опциональные приложения к документу:

  • Методика проектного управления применимая к проекту
  • Шаблоны документов, форм
  • Детальные политики на которые ссылаются из документа
  • Первичная оценка графика работ
  • Перечень ключевых показателей проекта (KPI)

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

0

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

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

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

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

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

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

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

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

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

 

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

0

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

 

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

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

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

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

Производить или закупать? Плюсы и минусы делать самим

0

Когда в компании запускается очередной проект – всегда возникает вопрос со стратегией его выполнения:

  • Делать полностью самим
  • Отдать на outsource (объявить тендер, отдать большую часть работы подрядчику)
  • Промежуточный вариант – около половины  работ выполняется внутри компании (как правило это проектный менеджмент, анализ и тестирование) а остальное – по прямым контрактам с фрилансерами или небольшими компаниями.

У каждого из этих вариантов есть свои плюсы и минусы. В этой статье мы рассмотрим плюсы и минусы варианта делать самим.

Делать самим – плюсы:

  • Полный контроль над ресурсами
  • Низкая стоимость ресурсов (в большинстве случаев это так – если за управление проектом не берется менеджмент с очень высокими зарплатами)
  • Конфиденциальность выше
  • Накопление и сохранение опыта (если нет высокой текучести кадров)

Делать самим – минусы:

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

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

Go to Top