IT Project Management: Реестр заинтересованных лиц, Реестр и балансировка требований

Важно понимать, что Клиент никогда не сделает за Вас эту работу.

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

Реестр формируется из покупателей и пользователей продукта, а также из ваших сотрудников, которые в какой-то момент могут оказать влияние на проект.

В процессе сбора требований, разделяйте требования и ожидания. Ожидания, это некая абстракция, Ваша задача сделать ее конкретикой, превратить в требование.

Требования необходимо получить от заинтересованных лиц, это достаточно трудоемкий, но необходимый процесс.

Как бы соблазнительно ни казалось использовать опросники в электронном виде, наилучший результат будет от личных встреч (возможно групповых), а еще лучше если на этом этапе вы уже сможете показать демо своего продукта и перевести разговор в конструктивное русло.

Очень хорошо, если к сбору требований вы можете привлечь бизнес аналитиков.

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

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

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

Особенностью этих реестров является тот факт, что мы не анализируем, и тем более не отвергаем требования, а просто их собираем и фиксируем.

После того, как требования зафиксированы, переходим к анализу и так называемой балансировке.

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

К балансировке требований мы будем возвращаться на всем этапе планирования с целью корректировки относительно новых обстоятельств.

Что стоит четко усвоить, так это то, что фиксируем не только то, что будем делать, но и то что не будем делать. Например, при внедрении CRM с-мы мы не будем помогать Клиенту с VPN, как бы сильно не просил. Открыть коммерческий проект — да, возможно порекомендуем сначала выполнить его, а потом основной. Если ситуация такова, что нужно несколько проектов — объедением в портфель.

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

Оглавление цикла статей об управлении проектами

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.