A5 Модель Процесса TenStep

Модель Процесса TenStep содержит ряд ключевых моментов, перечисленных ниже.

"Шаги" не означают последовательный порядок

(A5.P1)

Важно понимать, что десять шагов методологии TenStep вовсе не составляют последовательность. Действительно, Вы должны сперва определить и спланировать проект прежде, чем сможете им управлять. Следовательно, Шаг 1 и Шаг 2 должны быть сделаны прежде остальных. Однако, почти все последующие действия в шагах с Шаг 3 по Шаг 10 выполняются параллельно.

Шаг 3 - ключевой шаг интеграции процессов

(A5.P2)

Во время выполнения проекта все процессы управления объединяются в Шаге 3 - Управляй графиком и бюджетом. Объединение возникает именно здесь благодаря доминирующей философии Процесса TenStep: "Выполняется все, что запланировано". Иными словами, все работы проекта должны быть включены в график. Если какое-либо действие не запланировано и, соответственно, отсутствует в графике, то оно выполняться не должно.

График проекта - точка фокусировки управления всеми запланированными работами, и все процессы управления проектом объединены вокруг его графика. Вы должны предусмотреть в графике действия и необходимое время для коммуникаций, управления объемом, обновления графика, а также все прочие работы по управлению проектом. Объединение возникает, когда процессы управления соприкасаются друг с другом и налагаются на процессы жизненного цикла проекта. Рассмотрим примеры:

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

Чем больше шагов - тем полнее и глубже применяемые процессы управления проектом

(A5.P3)

С каждым последующим шагом Процесса TenStep увеличивается уровень изощренности применяемых практик управления проектом. Как правило, чем больше проект, тем больше шагов требуется для полноценного управления таким проектом. К примеру, малые проекты не обязательно нуждаются в управлении рисками (Шаг 7), поскольку малые проекты обычно не бывают настолько рискованными, чтобы это вызывало какую-то озабоченность. Тем более, они не нуждаются в большом объеме работ по управлению качеством (Шаг 9) и управлению метриками (Шаг 10), что иными словами означает, что данные процессы не являются обязательными для малых и средних проектов.

Процесс TenStep не включает жизненный цикл проекта

(A5.P4)

Данная методология управления проектами является "зонтиком", под которым выполняются все другие работы проекта. Не забывайте, что управление проектом - это процесс, обеспечивающий успешность проекта, но не сам проект и его продукт. Независимо от характера работ по созданию продукта, они следуют жизненному циклу, включающему анализ, проектирование, реализацию, тестирование и внедрение (либо одному из множества других жизненных циклов проекта). Признавая необходимость процессов создания продукта, важность их понимания и правильной организации, процесс TenStep оставляет рассмотрение этих вопросов за своими рамками. Жизненный цикл проекта детально рассматривается в продукте LifecycleStep на сайте www.LifecycleStep.com.

Процесс TenStep не включает определение требований к продукту

(A5.P5)

Некоторые методологии рассматривают работы по анализу требований заказчика как часть процесса управления проектом. Процесс TenStep включает только самый высокоуровневый анализ, необходимый для подготовки документа Устав проекта. Все же работы по детальному (формальному) выявлению и описанию бизнес-требований процесс TenStep относит к содержанию отдельной фазы жизненного цикла проекта и выводит, таким образом, за рамки процесса управления проектом. (См. более подробную информацию о фазе "Анализ" на сайте www.LifecycleStep.com продукта LifecycleStep).

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

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

На первый взгляд, напрашивается вывод, что детальные требования следует собрать прежде, чем будущая трудоемкость проекта будет зафиксирована. Однако, осуществимо ли это? Представим себе типичный проект разработки компьютерного приложения. Проект может длиться 6 месяцев, из которых от 6 до 9 (и более) недель может уйти на составление детальной спецификации требований. Сможем ли мы отложить нашу оценку трудоемкости проекта до завершения работ по сбору требований? Если мы на это пойдем, то проект будет уже на четверть или даже на треть выполнен к тому времени, как мы сможем утвердить его стоимость и сроки. Если вдруг окажется, что его параметры не устраивают одну из сторон, и проект не состоится, то сумма потерянных впустую денег может оказаться неприемлемой. Именно по этой причине большинство методологий управления проектами исключают сбор детальных требований из процессов управления.

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

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

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

Несмотря на важность закупок для некоторых проектов, Процесс TenStep не относит их к управлению проектом

(A5.P6)

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

Процесс финансирования проекта находится за рамками Процесса TenStep

(A5.P7)

Процесс TenStep предполагает, что проект получает необходимое финансирование и комплектование ресурсами. Каждая организация имеет некоторый порядок рассмотрения идей, присвоения им приоритетов и выделения финансирования. Процесс TenStep не включает в себя эту часть работы и не рассматривает ее как часть процесса управления проектом. (Для этой работы TenStep, Inc. разработал методологию PortfolioStep). Процесс TenStep начинается с того момента времени, когда проект формально определен и руководитель проекта назначен. При этом предполагается, что бизнес-обоснование, финансирование и назначение ресурсов уже завершены.

Проект официально начинается с момента назначения его менеджера

(A5.P8)

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

[Пред. страница - Базовые принципы Процесса TenStep]   [След. страница - Сравните Процесс TenStep]

хостинг Rambler's Top100 Рейтинг@Mail.ru Рассылка 'Совет недели менеджеру проекта' Mail.Ru