Управление запросами на изменение

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

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

Определение источника искажений

Как вы различаете запрос на изменение, берущий начало из необходимости ответить на изменение на рынке, и проблему, для решения которой предназначен проект? Вам нужно выявить это различие перед переходом к следующему этапу в процессе управления изменениями. Запросы на изменение подобны небольшим экономическим моделям и должны содержать такие элементы, которые содержит экономическая модель. Элементы, интересующие нас, - это ожидаемая выгода от изменения. Запрос на изменение, четко описывающий выгоду, которая будет получена от выполнения изменения, такую как , к примеру, упрощение процесса онлайн - покупки, превращение продукта в более привлекательный для целевых потребителей, или изменение функции, направленное на изменение процесса круговорота, - это запрос на изменение, которые могут повысить эффективность (стоимость) проекта. Запрос на изменение этого типа должен перейти на следующий этап в вашем процессе управления изменениями. Изменение может быть выгодно и для самого проекта. Например, изменение, которое может сократить объем работ, необходимый для выработки предоставляемого результата, или изменение, которое позволит группе завершить работу над проектом раньше планируемого срока.

Запросы на изменение могут не включать в себя подробные описания выгод, которые они несут с собой. Эксперт в предметной области, который обнаруживает необходимость соответствовать новым требованиям рынка или обнаруживает возможность сэкономить деньги или время, может не иметь достаточного опыта для формулирования экономического обоснования. Косвенная выгода для организации или проекта может быть скрыта в техническом описании запрошенного изменения. Ваш процесс управления изменениями должен включать в себя предоставление инициатору запроса контактной информации, которую нужно предоставить с запросом на изменение, и для всех инициаторов запроса нужно подготовить ответы на вопросы об их запросах. Посетите, позвоните или напишите по электронной почте инициатору запроса и попросите его более подробно объяснить экономическое обоснование. Задайте ему наводящие вопросы, такие как "Каким новым требованиям рынка должно соответствовать это изменение?", "Как это изменение сэкономит время на выполнение проекта?", или "Сколько денег сэкономит это изменение для проекта?". Избегайте задавать такие вопросы, как "Как это изменение улучшит систему?", или "Как это изменение повысит качество?". Эти вопросы положат начало обсуждению того, почему их решение лучше, чем то, которое было выбрано изначально.

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

Небольшие предупредительные меры...

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

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

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

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

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

Устранение ошибок

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

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

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

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