Управление содержанием проекта: что мы делаем?

Настройте себя на успех проекта, четко определив цели - объем - в начале.

Изображение David Mark с сайта Pixabay

Предотвратить катастрофу проекта

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

Управление масштабами имеет решающее значение для успеха проекта

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

Предотвратить смещение прицела

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

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

По данным Project Management Institute, 64% всех проектов не соответствуют первоначальному графику и бюджету. И самая большая причина этих сбоев - плохое определение области видимости, или, если мы правильно определили область действия в начале, сползание области.

Хорошая новость заключается в том, что если мы четко определим область видимости и будем управлять ее сползанием, мы на пути к успеху!

Я обучил более 4000 менеджеров проектов и руководил десятками проектов. Позвольте мне показать вам, как определить объем и управлять сползанием объема, прежде чем ваш проект будет перегружен!

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

stevendepolo Стивен Деполо (CC BY) через Flickr

Когда следующий вторник?

Каждый раз, когда я читаю класс по определению объема и ясности коммуникации, я прошу поднять руки по этому вопросу. Скажем, я преподаю в четверг. Я прошу: «Поднимите руку, если вы думаете, что следующий вторник наступит через 5 дней». Около половины присутствующих поднимают руки. Затем я прошу: «Поднимите руку, если вы думаете, что следующий вторник наступит через 12 дней». Другая половина присутствующих поднимает руки.

Это показывает, что простой английский - не точный язык. Для некоторых «следующий вторник» наступит через пять дней. Для других «следующий вторник» следует после «этого вторника», так что до него двенадцать дней.

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

Согласование объема вашего проекта

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

• выражение корпоративного имиджа, по мнению высшего руководства
• источник юридической ответственности, по мнению корпоративного юриста
• инструмент для получения новых доходов, по мнению отдела маркетинга
• еще одна статья затрат на поддержание в соответствии с финансами
• возможность решить некоторые проблемы с наймом и получить хороших перспективных сотрудников в соответствии с человеческими ресурсами
• техническое обслуживание, по словам ИТ-отдела
• проект, который нужно завершить, по мнению команды веб-разработчиков

Главное здесь в том, что все правы. Успешное управление объемом требует уметь понимать точку зрения каждого, видеть, что им нужно и что они могут предложить, и объединить все это в один план и одно определение.

Попадание на ту же страницу

Каждый, кого затрагивает проект, имеет свою точку зрения, а также свой язык. Как «корпоративный имидж» руководства трансформируется в «эффективную целевую страницу» маркетинга и сообщения ИТ-отдела «404 Page Not Found»? Архитектура - это способность видеть одну вещь в нескольких представлениях, с разных точек зрения и на нескольких языках. Как руководители проектов, мы также должны быть архитекторами, способными увидеть проект со всех сторон и решить все проблемы.

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

Согласование объема

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

Уточняющие предположения

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

Этапы управления объемом

Институт управления проектами определяет четыре процесса, которые составляют управление содержанием:

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

PMI предлагает причудливое имя для создания сначала определения области высокого уровня, а затем подробного WBS. Они называют это прогрессивной проработкой.

Вопросы, определяющие остальную часть проекта

Четкое определение содержания необходимо для планирования и определения всех других аспектов проекта. Правильное определение каждой из восьми других областей управления проектом зависит от твердого, четкого определения объема. Если вы не совсем уверены в девяти областях управления проектами, вы можете прочитать «Девять областей управления проектами и почему они имеют значение».

Включения и исключения

Отличный инструмент для определения объема и предотвращения смещения объема - это включение как определения того, что мы делаем, то есть списка включений, так и списка того, что люди просили о том, чего мы не делаем, то есть список из исключений. Для этого есть две причины.

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

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

Затем, когда сайт тестируется, приходит менеджер и говорит: «Но я не смог прочитать сайт на креольском языке. Что случилось?» Мы извлекаем описание объема и показываем ему, что креольский язык пока исключен.

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

Создание иерархической структуры работ (WBS)

Структурирование декомпозиции работ начинается, когда все заинтересованные стороны одобряют описание объема работ. Это процесс создания очень тщательного, подробного, иерархического списка всех компонентов проекта.

Например, предположим, что мы строим самолет. Наше первоначальное описание выглядит так:

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

Каждый из этих основных компонентов становится заголовком для списка более мелких компонентов. В состав крыла входят:

• крыло
• топливные баки
• топливопроводы
• закрылки

В конечном итоге это детализировано до полного списка частей. Для коммерческого самолета это может быть более 1 миллиона деталей!

Создание остальной части плана проекта

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

Например, WBS - это список того, что мы делаем. Исходя из этого, мы спрашиваем, как мы будем делать каждый компонент. Это создает список действий, который является ключевым компонентом оценки времени. Кроме того, когда мы знаем, что делаем, мы можем спросить: «Что может пойти не так?» и это отправная точка для планирования рисков. И спрашивая "что делает его хорошим?" это начало качественного планирования.

Управление масштабом проекта

После утверждения WBS мы завершаем остальную часть плана проекта. После утверждения всего плана мы приступаем к работе. Теперь наша задача - завершить проект. Или, с точки зрения управления проектом, мы собираемся выполнить указанный объем с приемлемым качеством в срок и в рамках бюджета, что бы ни случилось.

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

Анализ освоенной стоимости

Анализ освоенного объема (EVA) начинается с отслеживания объема, времени и затрат. Проще говоря: что мы завершили, сколько времени это заняло и сколько денег мы потратили? Получив эти цифры, мы решаем их с помощью некоторых уравнений. Уравнения пропорциональны: они спрашивают, какой объем мы выполнили относительно потраченного времени и денег. Эти результаты отвечают на вопрос: если мы продолжим работать с такой скоростью, закончим ли мы раньше, чем у нас закончатся время и деньги? Если так, то все хорошо. Если нет, то мы должны выяснить, почему мы работаем медленно или тратим слишком много денег, и решить эту проблему.

Управление ползучестью

Анализ освоенного объема измеряет прогресс в достижении нашей поставленной цели в указанном объеме. Но что, если заказчик получает отличную идею и хочет, чтобы она была добавлена ​​в проект? Что делать, если инженер думает о лучшей функции, и он хочет, чтобы он добавил? Что, если какой-нибудь топ-менеджер уволится, его заменит новый начальник, а он захочет чего-то совершенно другого?

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

Короче говоря, не позволяйте никому перемещать стойки ворот. Если кто-то хочет изменить объем, мы рассчитываем стоимость изменения проекта и дополнительное время, которое на это потребуется. Затем мы ведем переговоры: мы предпочитаем не вносить изменений, но мы внесем изменения в объем, если проект получит продление крайнего срока и дополнительные средства, чтобы мы могли предоставить новый , увеличенный объем, который больше, чем было указано, и поэтому больше, чем было заложено в бюджет или график.

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

Управление всеми девятью областями

Есть еще одна вещь, которую мы можем сделать, чтобы обеспечить результаты проекта и доставить удовольствие заказчику. Обратите внимание на то, что я сказал выше, добиваться результатов «с приемлемым качеством… что бы ни случилось». Это указывает на тот факт, что мы должны управлять не только объемом, временем и стоимостью. Очень важно управлять всеми девятью областями управления проектом на протяжении всего проекта, от начала до конца. Управление качеством проекта обеспечивает приемлемые или отличные результаты. Управление рисками проекта гарантирует успех, что бы ни случилось. Чтобы узнать о всех девяти областях и почему они важны, прочтите «Девять областей управления проектами и почему они имеют значение».

Выполнение того, что вы обещали

Если мы продолжим работу над проектом по созданию продукта, услуги или результата, которые мы определили в описании объема работ, то однажды - надеюсь, за день до того, как закончатся деньги и время, - мы будем готовы выполнить поставку.

Или мы думаем, что готовы доставить. Но действительно ли мы уверены? А что думает заказчик. Давайте посмотрим на шаги, которые мы выполняем, чтобы убедиться, что мы доставляем клиенту то, что нужно, и добиваемся успеха.

Верификация и валидация

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

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

• Если мы доставляем что-то крупное, сложное или что-то, что должно отвечать строгим требованиям, мы, вероятно, захотим организовать валидацию задолго до даты доставки. Это дает команде проекта время скорректировать или исправить все, что не соответствует требованиям клиентов.
• Если возникает спор о том, дает ли наш проект результаты, на которые подписался заказчик, они могут запросить независимую проверку и подтверждение (IV&V), когда внешний подрядчик приходит, чтобы определить расхождения между тем, что мы доставляем, и тем, что заказчик. хочет и рекомендует решения.

Доставка

Однако, как правило, IV&V не требуется. Мы предоставляем результаты проекта, которые могут включать установку, настройку и обучение, в зависимости от того, были ли они включены в описание содержания проекта. Заказчик, так сказать, пинает шины и либо доволен, либо просит несколько небольших изменений, которые мы вносим. И вот проект готов - почти.

Клиентское удовольствие

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

Что останавливает ваши проекты?