Контроль масштаба проекта

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

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

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

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

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

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

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

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

Перечень работ (SOW) обычно будет сопровождать RFP или RFQ, когда разработчик выполняет работу для клиента. SOW обычно бывает намного более точным и подробным в описании работы, которую нужно выполнить, но не всегда. Убедитесь, что SOW, на основании которого вы работаете, является подробным и содержит описание функций и артефактов управления проектом, за которые вы будете отвечать. Обязанности, встречи, отчеты и коммуникации, не указанные в SOW, должны быть рассмотрены при помощи запросов на изменения. Запросы на изменения, сильно изменяющие масштаб проекта, не должны быть проблемой. Если они становятся проблемой, то это будет проблемой заказчика, при условии, что у вас есть хорошо подготовленный SOW.

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

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