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

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

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

Это может привести к тому, что мы начнём формировать очень простые одностраничные отчеты, которые заинтересованные стороны действительно прочитают и поймут, в gротивоположность длинным. Это означает внимание к цели.

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

Гибкость продукта варьируется между проектами. В некоторых проектах по развитию ИТ продукт является полностью гибким, и его окончательная форма зависит от обратной связи, которая будет генерироваться по инкрементам продукта в ходе проекта, что требует применения адаптивного (гибкого) подхода. На практике это комбинация уровней портфеля, программы и проекта и требует максимального внимания к конечной цели. Рекомендуется задокументировать цель и сделать ее доступной; это одна из целей «видения продукта», которое используется в некоторых проектах Scrum. Внимание к бизнес ценности в Agile проектах — это их способ обеспечить соответствие цели.

В других типах проектов, где продукт является относительно фиксированным и существуют другие механизмы, гарантирующие, что конечный продукт будет удовлетворять цели, члены проектной команды могут перенести большую часть своего внимания с цели на продукт (следовательно, принцип «сосредоточить внимание на продуктах» (PRINCE2^®)), но все же требуется по крайней мере минимальное внимание цели, чтобы гарантировать, что-то, что строится, будет соответствовать цели, что можно сделать путем сравнения прогнозируемых выгод с ожидаемыми (принцип «постоянная оценка целесообразности» и тема «экономическое обоснование» в PRINCE2^®).

Когда проект запускается для внешнего клиента, у клиента будет своя цель проекта, а у вас своя. Чтобы преуспеть, вам нужно понимать обе.

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

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

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

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

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

Лучший способ определить уровень детализации — это иметь цель для каждого элемента в плане. Например, если вы рассматриваете возможность добавления ресурсов в план, у вас должна быть для этого цель: как вы собираетесь его использовать? Как это поможет проекту? Сколько усилий это займет? и стоит ли это того?

Иногда нужно решить, хотите ли вы иметь определенный элемент в своих планах, а иногда — то, как вы хотите спланировать или подготовить что-то. Будь то экономическое обоснование, устав проекта или отчет: вы все равно должны спросить себя, почему вы готовите этот документ и как он может помочь проекту.

Поиск «шаблона» — это противоположность тому, чтобы делать что-то на основе цели.

Подготовка документов, таких как бизнес-кейс и устав проекта, обычно является скучной, бесплодной, бюрократической необходимостью, в то время как все эти документы имеют обоснование и применимы к большинству проектов. Если вы попытаетесь найти «шаблон» и заполнить его, работа будет просто сделана впустую; тогда как вы можете вместо этого проверить реальное назначение этих документов, посмотреть, могут ли они помочь в вашем проекте и каким образом они могут помочь, а затем подготовить документ так, как вам нравится, просто для достижения этих целей: это будет правильный документ.

Пока вы думаете о том, как подготовить документы для достижения их целей, вы можете забыть рассмотреть все варианты. Чтобы избежать этого, вы можете проверить, что предлагают PRINCE2^®, PMBOK^® Guide, P3. express и DSDM^®, а затем оценить эти рекомендации в контексте ваших целей.

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

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

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

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

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

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

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

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