Замечание

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

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

Определение и реализация определенного уровня и качества и сорта продукции входят в обязанности руководителя и команды проекта. Определение требуемого уровня качества существенно облегчается при наличии у проекта конкретного заказчика и контракта с ним.

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

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

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

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

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

Организационное планирование

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

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

- заказчик; - снабженец;

- руководитель проекта; - бригадиры;

- прораб; - отдельные рабочие.

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

Для распределения ответственности между участниками проекта обычно используют так называемую матрицу распределения ответственности. Вид такой матрицы применительно к рассматриваемому проекту-примеру может

соответствовать содержанию табл. 3.5.

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

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

Таблица 3.5. Матрица распределения ответственности проекта-примера

Основные функции управления	Проектные роли
Заказчик	Руководитель проекта	Прораб	Снабженец	Бригадиры	Отдельные рабочие
Финансирование проекта	О	У
Планирование работ		О	У
Материальное обеспечение работ по плану				О
Организационная подготовка работ		У	О
Организация работ			О		У
Выполнение работ по плану		О	У
Контроль выполнения плана проекта		О	У
Контроль качества			О		У
Сдача-приемка работ	У		О		У	У

Планирование коммуникаций

Планирование взаимодействия тесно связано с планированием организации и включает определение потребностей участников проекта в информации.

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

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

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

При разработке плана коммуникаций часто используют так называемую матрицу отчетности. Разрабатывают такую матрицу обычно на основе матрицы распределения ответственности и стандартных отчетов. Для рассматриваемого проекта-примера такая матрица может иметь вид, показанный в табл. 3.6. В этой матрице использованы в основном стандартные отчеты Project, а также форма сводки о выполнении работ, необходимая для поддержки предлагаемой системы отчетности (она выделена в табл. 3.6 звездочкой). Работа с матрицей отчетности также требует использования легенды. В табл. 3.1 например, "Е"означает разовый отчет, символ "Н" - еженедельный, а "Д" ежедневный. Применительно к ежедневным отчетам о выполнении работ "ДО" означает ответственность за сбор и обобщение ежедневных данных, а "ДП" - ежедневное получение данных.

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

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

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

Таблица 3.6. Пример матрицы отчетности для проекта-примера

Основные функции управления	Проектные роли
Заказчик	Руководитель проекта	Прораб	Снабженец	Бригадиры
Сводка по проекту	Е	Н
Критические задачи		Н
Отчеты о затратах		Н
Задачи, запланированные на неделю		Н	Н
Завершенные задачи		Н
Выполняющиеся задачи			Д
Использование задач			Д
Использование ресурсов			Д
Дела по исполнителям и времени				Д	Д
Сводка о выполненных работах		ДП	ДО	Д	Д

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

Планирование рисков

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

Планирование рисков строится по следующей схеме:

- идентификация рисков;

- оценка рисков;

- разработка мер реагирования на те риски, которые этого требуют.

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

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

Ожидаемое денежное выражение обычно вычисляют по формуле

ОДВ=ДВ*р,

где:

-ОДВ - ожидаемое денежное выражение;

- ДВ - оценка риска в денежном выражении;

- р - вероятность события риска.

Размерность ОДВ всегда совпадает с размерностью величины ДВ и может иметь размерность стоимости или времени.

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

Для оценки разброса затрат проекта используется предположение о том, что статистические показатели затрат подчиняются закону бета-распределения. При этом оценка затрат каждой задачи / определяется тремя показателями:

- минимально возможной (оптимистической) оценкой а _i;

- средней (ожидаемой) b _i,

- максимально возможной (пессимистической) с _i.

Гипотеза о том, что показатели затрат подчиняются закону бета-распределения, позволяет для каждой i-и задачи вычислить:

- математическое ожидание затрат z _i/ по формуле ;

- дисперсию затрат d _i по формуле .

Зная эти показатели для каждой задачи проекта, математическое ожидание затрат проекта Z, дисперсию затрат проекта D и среднеквадратичное отклонение затрат проекта можно вычислить следующим образом:

/

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

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

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

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

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

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

Планирование контрактов

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

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

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

При планировании контрактов обычно рассматривают следующие вопросы.

- Приобретать ли продукты и услуги?

- Как это сделать?

- Что именно приобрести?

- Сколько приобрести?

- Когда приобрести?

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

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

Планирование и управление изменениями

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

Методически процедуры управления изменениями должны включать следующие аспекты:

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

- выявление происшедших изменений и их документирование;

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

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

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

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

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

Контрольные вопросы.

1. Что означает инициация проекта?

2. В чем заключается предварительное планирование проекта?

3. Как осуществляется создание нового файла проекта?

4. Как происходит формирование ресурсного обеспечения и объема трудозатрат?

5. Как осуществляется формирование взаимосвязи задач графика реализации проекта?

6. В чем заключается разработка предварительного описания проекта?

7. Укажите алгоритмы оценки стоимости проекта с применением Project/

8. В чем заключается работа с бюджетом проекта?

9. Как создаются и форматируются отчеты средствами Project?

10.Перечислите алгоритмы форматирования листов распечатки.

11.Как осуществляется печать данных в виде, определяемых экранными формами?

12.Как осуществляются алгоритмы стандартных отчетов?

13.Как происходит формирование базового плана проекта?

14.В чем заключается определение критериев успеха проекта?

15.Назовите и охарактеризуйте вспомогательные процессы планирования проекта на стадии предварительного планирования.