Констатация содержания задачи

Каждую задачу лучше всего определить с помош;ью краткого описания поддежа-ш;их выполнению работ (констатации содержания задачи), которое должно включать след}юш;ие пункты:

• краткое описание работ, подлежаш;их выполнению;

• входные данные (входы), которые необходимо получить от других задач;

• ссылку на применимые спецификации, условия контракта или иные документы;

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

Типы задач и работ

Можно выделить различные виды задач, каждый из которых требует особого подхода к составлению календарного плана и бюджета:

• задачи по проектированию и разработке;

• задачи по производству;

• задачи по строительству или установке (вводу продукта в эксплуатацию);

• задачи по снабжению проекта (поставки или субподряды);

• задачи управления.

В рамках этих категорий существуют три основных типа задач:

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

• задачи без оговоренного срока исполнения или описания объема работ - операции, которые нельзя напрямуЮ связать с определяемым конечным продуктом или результатом, - управляются и контролируются установленным для этой цели бюджетом, который распределен по фазам жизненного цикла проекта. Пример: работа по управлению проектом, включающая зарплату и транспортные расходы менеджера проекта и персонала поддержки, когда эти траты относятся непосредственно на проект;

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

Схемы нумерации для ИСП

Схемы нумерации, используемые в структуре проекта, должны быть тщательно разработаны, чтобы обеспечить на каждом уровне возможность суммирования данных по календарным планам, стоимости, ресурсам и технической информации, начиная с уровня задачи или пакета работ и через промежуточные уровни восходя до уровня проекта. Многие организации расширяют схему нумерации до м)льтипроектного и корпоративного уровней, чтобы обеспечить такое суммирование в масштабе всей организации; особенно это актуально для информации о ресурсах. Схема нумерации структуры проекта должна иметь свою, отличную от других схем систему обозначений и не объединяться непосредственно, например, с системой нумерации счетов бухгалтерского учета. Номера, используемые ИСП, должны быть совместимы с программным обеспечением информационной системы управления проектами в том, что касается разрядности и процедур суммирования. Типичная система нумерации ИСП приведена на рис. 10.2.

Программное обеспечение для поддержки ИСП

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

10.9 МАТРИЦА ЗАДАЧ И ОТВЕТСТВЕННОСТИ

Матрица задач/ответетвенности- это инструмент планирования, который предназначен для установления связи работы, определенной в структуре проекта, с организационными единицами, субподрядчиками и отдельными сотрудниками. Таким образом, с одной стороны, существует иерархическая структура организации (ИСО), а с другой - работа, выполняемая в соответствии с иерархической структурой проекта (ИСП); цель матрицы ответственности - объединение этих структур. Так как иерархическая структура проекта никогда не будет точно

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

На рис. 10.5 приведен пример данного инструмента. Разработка матрицы покажет, хорошо ли составлена структура проекта, достаточно ли она детализирована, не избыточна ли детализация. Также планировщику предоставляется возможность удостовериться, что каждому исполнителю назначена как минимум одна операция в сетевом графике PERT/CPM/PDM.

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

Матрица задач/ответственности часто называется линейной схемой ответственности, ЛСО (Linear Responsibility Scheme, LRC). Великолепное рассмотрение использования этого важного инструмента в управлении проектами можно найти в книге Клеланда (Cleland) и Кинга (King) [17, pp. 374-393].

10.10 ИДЕНТИФИКАЦИЯ СВЯЗУЮЩИХ

И КЛЮЧЕВЫХ СОБЫТИЙ (КОНТРОЛЬНЫХ ТОЧЕК)

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

Основное определение события

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

Члены команды проекта

Условные обозначения:

Р - осуществляет работу;

К - необходимо проконсультироваться;

У - должен утвердить;

И - необходимо известить;

О - объединяющая ответственность;

Ф - изготовляется на фабрике.

Рисунок 10.5. Пример матрицы задач/ответственности

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

С одним событием могут быть ассоциированы следующие даты:

• плановая дата - время наступления события, согласованное и принятое на данный момент;

• прогнозируемая (ранняя, или предсказанная) дата - предполагаемое на данный момент время наступления события при условии, что имеющийся план выполняется без отклонений или изменений;

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

• целевая дата - желательное время наступления события;

• дата выполнения обязательств - дата, к которой событие должно наступить согласно обязательствам перед заказчиком или руководством организации;

• фактическая дата - время фактического наступления события.

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

Контрольный список для определения интерфейсных и контрольных событий

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

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

Таблица 10.3. Контрольный список для идентификации интерфейсных и контрольных событий

1. Объекты или субъекты, участвующие в интерфейсных и контрольных событиях и идентифицируемые однозначно

Общие Проекты, системы, подсистемы, элементы проекта,

требования, фонды

Документы Контракты, субподряды, спецификации, чертежи, бюджеты,

расписания, графики, отчеты, наряды на работы, процедуры, ведомости материалов, перечни деталей, инструкции

Оборудование Модели, испытательные стенды, компоненты, материалы,

(аппаратные запасные части, агрегаты, сборки, модули, поставляемые

средства) элементы аппаратных средств, промежуточные элементы

аппаратных средств, аппаратные блоки, запасные части

Программное Потоковые диаграммы последовательности процессов,

обеспечение списки кодов, блок-схемы, пакеты программ, распечатки,

(операционное) магнитные ленты, исходные коды, объектные коды,

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

Услуги Обучение, техническая поддержка - оперативная,

управленческая или административная

Средства Здания и сооружения, испытательное оборудование и машины,

производства инструменты и инструментальное обеспечение, операционное

или производственное оборудование и машины

2. Операции, выполняемые над объектами или субъектами

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

3. Указатель событий

Страдательное причастие, имеющее общий корень с каким-либо существительным

из раздела 2 и связанное с одним или несколькими объектами/субъектами из раздела 1.

Пример: "Разрешено использование фондов по контракту XY".

"Аппаратный блок 2 получен на рабочей площадке". "Завершено тестирование пакета программ № 3". "Здание построено и готово к использованию".