Управление ИТ-проектом

       

Дело 3. Управлять изменениями


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

Изменения призваны обеспечить проекту «самонаведение» на цель (внося корректировки в «траекторию» – в состав работ). Но в чрезмерном количестве они приводят к обратному эффекту – исчерпав ресурсы проект вовсе «не долетает» до цели.

Посему, очень важно организовать работу с изменениями по определенным правилам. Один из возможных подходов: использование матрицы требований в качестве основы (подробное описание в главе VI). Члены команды дополняют матрицу новыми позициями в течение проекта, а руководитель проекта производит периодическую ревизию списка. Рано или поздно, каждое требование должно быть отклонено или включено в состав работ по проекту. Возможный алгоритм принятия такого решения приведен ниже.

  1. оценить соответствует ли требование целям проекта (базовым положениям устава и/или концепции проекта). Если выявлено несоответствие – требование отклоняется.
  2. оценить предполагаемое влияние работ по реализации требования на проект (если проект останется в треугольнике – то следующий шаг 4, если нет – то 3).
  3. определить, возможно ли «уложить» реализацию требования в треугольник, и что для этого потребуется (нужно ли сжатие расписания или быстрый проход, сильно ли возрастут риски и т.п.).
  4. обсудить результаты с командой, при необходимости – со спонсором и принять совместное решение о включении / отклонении требования
  5. оповестить заказчика, пользователей и прочих заинтересованных лиц о принятом решении (положительном или отрицательном).

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

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



Содержание раздела