Шаг за шагом ШАГ 3: Разработайте план проекта

 

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

 

Шаг 3.1. Проведите мозговой штурм и составьте список задач

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

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

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

 

Ключевые факторы успеха

2

Учитесь видеть проекты целиком

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

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

 

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

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

1. Все ли задачи, нужные для достижения результата, определены? Если нет, добавьте недостающие.

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

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

4. Не возникли ли повторы при формулировке задач? Если какие-то задачи частично совпадают, измените их формулировку, чтобы они отражали разные действия. (Например, задачи «Провести обучение сотрудников службы продаж» и «Провести обучение персонала в лондонском отделении компании» частично совпадают для работников службы продаж из лондонского отделения. Нужно сформулировать эти задачи по-разному — так, чтобы они не зависели друг от друга.)

 

Получив оптимальный список задач, пронумеруйте их (номера пишите в левом верхнем углу каждого листка). Затем пронумеруйте задачи с учетом их иерархии, ставя номера в правом верхнем углу листка, — это так называемые номера дерева работ проекта (WBS, work breakdown structure). Если задачу вы разбили на подзадачи, пронумеруйте их как 1.1, 1.2, 1.3 и т.д. Если те в свою очередь состоят из более мелких задач, поставьте номера 1.1.1, 1.1.2, 1.1.3 и т.д.

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

Вернемся к проекту по обустройству офиса на 100 сотрудников. (Описание этого проекта приведено в предыдущей главе — см. табл. 2.4.) Вы хотите управлять проектом сами, но нуждаетесь в помощи специалиста и потому привлекаете подрядчика. Планируется переоборудовать офис и могут потребоваться новые лампы и розетки. Вы хотите приобрести новую мебель и поставить компьютеры последней модели. Подрядчику вы поручаете переоборудование офиса и меблировку, а компьютеры будут установлены силами ИТ-персонала вашей компании. Заполненные и упорядоченные листки с записями могут выглядеть как на рисунке (см. ниже).

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

 

Шаг 3.2. Превратите список задач в черновой вариант плана

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

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

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

После того как вы структурировали информацию и стал ясен нужный порядок действий, задумайтесь над следующими вопросами:

• Все ли задачи, необходимые для достижения цели, определены (проверьте и проанализируйте описание проекта)?

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

• Позволяет ли формулировка задач правильно понять их?

• Все ли задачи необходимо выполнить для достижения цели или какие-то из них все же лишние?

 

Теперь можно переходить к действиям. Сейчас нужно стремиться к полноте информации. Если вы были внимательны, то заметили, что я добавил к плану проекта еще две задачи — новую задачу 1.3 (Отбор потенциальных подрядчиков) между исходными 1.2 (Составление предложения) и 1.3 (Рассылка предложения потенциальным подрядчикам) и задачу 2.4 (Установка телефонов), присутствовавшую в описании проекта, но забытую при мозговом штурме.

 

Шаг 3.3. Оцените сроки с учетом зависимости задач и задержек[1]

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

Учтите, что, если задача разделена на подзадачи, оценивать следует продолжительность работ по каждой подзадаче, а не по всей задаче в целом. (Продолжительность работ по задаче в целом зависит от продолжительности работ по каждой подзадаче.) Например, задача 1 разбита на подзадачи 1.1–1.6, поэтому нужно оценивать время работы по каждой из подзадач 1.1–1.6, а не срок выполнения задачи 1.

Еще один момент. На практике порой могут возникнуть задержки с выполнением каких-то задач, не зависящие от вас. Возможно, вам удастся как-то использовать это время либо придется приостановить проект. В любом случае возможность задержки нужно включить в план. Например, в план покраски стен следует включить время ожидания: придется подождать, пока высохнет краска, прежде чем наносить следующий слой. Так и в рассматриваемом проекте — в плане необходимо отразить ожидание доставки заказанного оборудования (см. задачи 1.5, 3.3 и 4.4 в табл. 3.4).

Добавив еще два столбца в табл. 3.3, получим таблицу, в которой отражены зависимости задач и возможные задержки (табл. 3.4). Вся новая информация поясняется в примечаниях (которые для плана в общем-то не нужны).

 

Шаг 3.4. Распределите задачи между исполнителями

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

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

Задачи с нулевыми трудозатратами (например, задержки), а также те, которые делятся на подзадачи, не имеют исполнителей (как менеджер проекта, вы будете вести их мониторинг).

Шаг 3.5. Составьте календарный план

Календарный план содержит даты начала и завершения работ по каждой задаче и соответственно даты начала и окончания проекта. Дату начала определяют следующим образом:

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

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

• появляется возможность начать проект (исполнители в рабочее время не заняты чем-то иным, не связанным с проектом).

 

Дату завершения (в общих чертах) определяют путем прибавления трудоемкости проекта к дате его начала.

Я добавил к табл. 3.5 еще два столбца и получил нужный мне календарный план (табл. 3.6). Определяя даты начала и конца работ (исключая при этом выходные и праздничные дни), я пользовался календарем на 2005 г. Для удобства читателя в таблице даны примечания, поясняющие новую информацию (для плана они не нужны).

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

• исключать выходные дни (т.е. 10 рабочих дней равны двум календарным неделям);

• исключать праздничные дни (поэтому в нашем плане исключены 30 мая и 29 августа[2]);

• учитывать отпуска. Скажем, если у Мэри с 15 августа начинается 2-недельный отпуск, то в работах по задаче 4.6 возникнет двухнедельный перерыв, в результате они продлятся до 15 сентября (в нашем плане мы исходили из того, что отпусков у исполнителей в этот период нет);

• что нередко исполнителям приходится параллельно вести другую работу. Довольно часто сотрудники не имеют возможности полностью заниматься лишь одним проектом. Так что если Мэри, например, половину своего рабочего времени должна уделять другому проекту, время, отведенное на те задачи, за которые она отвечает, должно удваиваться. Иными словами, задача, трудоемкость которой равна 2 дням, у исполнителя с 50%-ной занятостью займет 4 рабочих дня;

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

 

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

 

Шаг 3.6. Оцените издержки

Для оценки издержек нужно определить составляющие стоимости, как показано в табл. 3.7. К ним, как уже говорили, относятся:

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

• расходы на приобретение материалов, необходимых для выполнения проекта.

 

Шаг 3.7. Определите контрольные точки и резерв

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

• 7 июля — офис готов к установке мебели;

• 8 августа — установка мебели в офисе завершена;

• 1 сентября — проект завершен, и офис готов к эксплуатации.

 

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

1. Оценка «сверху вниз». Вы просматриваете весь план и предполагаете, какие риски характерны для этого проекта. По сути, менеджер проекта полагается в этом вопросе большей частью на интуицию. Риски того проекта, который я здесь привожу в качестве примера, кажутся мне сравнительно низкими, поэтому я добавляю 10–20%-ный резерв к расходам и затратам времени.

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

 

А теперь проанализируем, что именно в вашем проекте подвержено наибольшему риску. С моей точки зрения, это:

• предположение о том, что подрядчик будет готов приступить к работе на следующий день после заключения договора. Заложите резерв в 10 дней;

• задержки, связанные с ожиданием доставки оборудования. А что, если вы не получите его в срок? Заложите и здесь резерв в 10 дней;

• задачи 26 и 27 предусматривают установку 100 компьютеров. При установке возможны сбои, и потребуется время на их устранение. Добавьте два дня;

• переменные издержки, необходимые для выполнения проекта. Вам известна стоимость компьютеров и программного обеспечения, однако стоимость мебели и электрооборудования вы определили по предварительной оценке, что может быть не совсем точно. Заложите в бюджет 25%-ный резерв на расходы по этим статьям, т.е. 28 тыс. ф. ст. (25% от 111 тыс. ф. ст.);

• расходы на персонал с учетом резерва в 22 дня. Большую часть резерва, если он будет использован, составит ожидание, когда никто не работает, однако время, потраченное менеджером проекта, может увеличиться на 22 дня (6600 ф. ст.), а временные затраты Мэри — на два дня (600 ф. ст.).

 

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

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

• запрашиваете бюджет в размере 380 800 ф. ст., которые я предлагаю округлить до 385 тыс.;

• определяете дату завершения проекта с учетом риска – по вашим расчетам это 29 сентября.

 

Но не слишком ли велик резерв, спросите вы. Дополнительные 22 дня? Представьте, что по завершении проекта вам придется освободить офис и об этом вы уведомляете свой персонал, а также владельца здания, с которым разрываете соглашение об аренде. Тогда, если вы не сможете завершить проект в срок, т.е. 1 сентября, вы рискуете создать себе серьезные проблемы: вашим людям будет негде работать. Резерв позволяет избежать такого риска. Не исключено, что с учетом риска и 22 дней резерва будет недостаточно. На этом этапе проекта уместнее проявлять осторожность, а не оптимизм.

Шаг 3.8. Оценка и корректировка плана — можете ли вы его выполнить, стоит ли его выполнять и нет ли лучшего способа это сделать?

Итак, у вас есть план проекта и нужный вам бюджет. Можно начинать? Подождите, прежде чем приступить к работе, задайте себе следующие вопросы:

1. Можете ли вы выполнить этот проект? По плану проект займет чуть больше трех месяцев (с 31 мая по 1 сентября), обойдется вам в 345 тыс. ф. ст. и потребует привлечения Мэри, Дэйва, Адама и подрядчика. Располагаете ли вы временем и нужными средствами? Готовы ли исполнители работать с вами?

2. Стоит ли вам выполнять проект? Вспомните причину, по которой вы инициируете проект, и продумайте, соответствует ли ей разработанный вами план? Например, если вы устраиваете переезд офиса, чтобы экономить на аренде 500 тыс. ф. ст. в год, то затраты в размере 345 тыс. ф. ст. будут оправданными. Если же, потратив 345 тыс. ф. ст. на проект, вы будете экономить всего 50 тыс. в год, то, вероятно, расходы слишком велики и браться за проект не стоит. Тем не менее планирование не было напрасным, так как доказало нерентабельность проекта.

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

 

В нашем примере основными статьями затрат будут издержки на выполнение проекта, — расходы на закупку мебели и компьютеров. Возможные пути снижения издержек: приобретение более дешевых компьютеров или мебели. Например, 1 тыс. ф. ст. за офисный компьютер — слишком много, особенно если вы покупаете партию в 100 штук. Узнайте, нельзя ли купить компьютеры дешевле. При цене 500 ф. ст. за компьютер вы сэкономите 50 тыс. ф. ст., т.е. примерно 15% бюджета.

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

Если сдвигаются сроки выполнения любой из задач, входящих в критический путь, меняются и сроки выполнения проекта. Так, если задачи 1.1 (Фиксация потребностей) или 1.2 (Написание предложения) завершаются на день позже, срок исполнения проекта «переезжает» с первого сентября на второе. Сравните это с задачей 4.5 (Установка ПО на компьютеры), которую спокойно можно передвинуть на две недели, что никак не влияет на дату завершения проекта.

Чтобы оптимизировать продолжительность проекта, необходимо внимательно рассмотреть следующие вопросы:

• Нельзя ли отказаться от каких-то задач? В нашем примере офис уже оборудован лампами, и, хотя они не идеальны, ими можно пользоваться, т.е. замену ламп можно отложить на будущее. Это позволит ликвидировать задачу 2.2.1 (Установка новых ламп), снизив стоимость проекта на 6 тыс. ф. ст. и уменьшив продолжительность работы подрядчика на 3 дня.

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

• Нельзя ли избавиться от каких-то зависимостей? Например, если бы задача 4.6 (Установка настроенных ПК) не зависела от задачи 3.5 (Установка новой мебели), вы могли бы приступить к ней 21 июля, а не 9 августа. В этом случае вы выигрываете более двух недель и завершаете проект 16 августа, а не 1 сентября. Увы, в данном случае это невозможно, тем не менее проанализируйте все зависимости, поскольку кое-какие из них могут быть лишними.

• Нельзя ли совместить некоторые задачи? Чтобы приступить к задаче 4.6 (Установка ПК), вам, вероятно, сначала нужно выполнить задачу 3.5 (Установка новой мебели), так как ставить компьютеры вы будете на столы. Однако совершенно необязательно ждать полного выполнения этой задачи, ведь для установки первого ПК не нужны все 100 столов. Соответственно, если приступить к задаче 4.6 через два дня после начала установки столов, вы сэкономите 10 дней и сократите продолжительность проекта.

• Нельзя ли использовать какие-то ресурсы более эффективно? Самый лучший способ сделать это — еще раз просмотреть план. Задачи в нем организованы по номерам дерева работ. Измените последовательность задач, упорядочив их по исполнителям, а затем по датам начала задач, как показано в табл. 3.9, и проанализируйте работу каждого члена команды.

Из табл. 3.9 ясно видно, что:

• подрядчик участвует в проекте с 21 июня по 8 августа, но ничем не занят между задачами 2.3 (Укладка ковровых покрытий) и 3.4 (Установка новой мебели). Это означает, что с 8 по 21 июля, т.е. в течение 9 рабочих дней, привлеченный вами подрядчик не загружен работой;

• Дэйв участвует в проекте с 31 мая по 23 июня, но ничем не занят между задачами 1.4 (Рассылка предложения потенциальным подрядчикам) и 1.6 (Оценка заявок). Это значит, что с 2 по 15 июня (10 рабочих дней) Дэйв свободен от работы.

• Мэри участвует в проекте с 31 мая по 1 сентября, но не занята с 7 июня по 4 июля (20 рабочих дней) и с 22 июля по 8 августа (12 рабочих дней).

 

Вы хотели бы, чтобы все члены команды были полностью заняты, пока они участвуют в проекте. Для этого, вероятно, стоит передвинуть некоторые из задач. В работе Дэйва и подрядчика ликвидировать разрывы практически невозможно. Поставьте заранее их в известность об этом; возможно, они сумеют найти на этот период работу, не связанную с вашим проектом (не исключено, что это позволит вам сэкономить на оплате). Есть и другой вариант — увеличить объем работ по проекту и загрузить сотрудников другой работой. Мэри участвует в проекте вплоть до его завершения 1 сентября, так как она устанавливает компьютеры. Поскольку задачи с 4.1 (Подбор новых ПК) по 4.5 (Установка ПО на компьютеры) не входят в критический путь, их можно передвинуть. Исходно вы планировали, что Мэри приступит к задаче 4.1 (Подбор новых ПК) как можно раньше, т.е. 31 мая. На деле она может начать работу на 12 дней позже, что никоим образом не повлияет на сроки выполнения проекта. Если скорректировать таким образом план, Мэри не придется оставаться без дела в период с 22 июля по 8 августа.

• Нельзя ли выделить больше ресурсов? Нельзя ли завершить какие-то задачи быстрее путем привлечения большего количества исполнителей? Не все задачи поддаются дроблению, однако, если поручить задачи 3.5 (Установка новой мебели), 4.5 (Установка ПО на компьютеры) и 4.6 (Установка ПК) двум исполнителям, их можно выполнить в два раза быстрее.

 

Если внести все эти исправления, окончательный план примет вид, показанный в табл. 3.10.

Теперь у вас есть законченный план, вы все продумали и можете приступать к проекту!

 

Шаг 3.9. Согласуйте план с заказчиком

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

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

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

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

• постарайтесь убедить заказчика, что резерв необходим. Это — лучший способ, хотя и не всегда приемлемый. Считайте резерв страховой премией;

• продемонстрируйте заказчику только контрольные точки, а не подробный план. В нашем примере завершение проекта намечено на 13 сентября. Если вы выполните проект к 12 августа и сэкономите ресурсы, заказчик будет очень доволен;

• «спрячьте» резерв путем «раздувания» других задач. Это не лучший способ управления проектом, но нередко приходится поступать именно так.

 

В любом случае не дайте загнать себя в угол — ни в коем случае не отказывайтесь от резервирования!

Ключевые факторы успеха

3

Управляйте ожиданиями

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

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

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

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

Главное, что нужно запомнить

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

• Поймите разницу между трудоемкостью задачи и ее продолжительностью.

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

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

• Подберите надежную команду. Без нее вы не выполните работу, как бы ни был хорош ваш план.

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

ЛИТЕРАТУРА

• Различные варианты плана в форматах MS-Word и MS Excel можно найти на сайте .
• Темы, рассматриваемые в данной главе, являются ключевыми для управления проектами. О них подробно пишут авторы большинства книг, посвященных этому аспекту менеджмента. Я могу рекомендовать вам следующие:

The Definitive Guide to Project Management (Financial Times Prentice Hall) by Sebastian Nokes et al., 2003, Chapter 5.

Practical Project Management: Tips, Tactics and Tools (Wiley) by Harvey A. Levine, 2002, Chapters 2–6.

The Project Workout (Financial Times Prentice Hall) by Robert Buttrick, 2nd edn, 1999, Chapters 6, 7 and 21.

The Project Manager: Mastering the Art of Delivery (Financial Times Prentice Hall) by Richard Newton, 2005, Chapter 5.

 

ЧТО ДЕЛАТЬ СЕЙЧАС

• Начните готовиться к мозговому штурму с составления списка задач:

• Какой проект вы будете вести?
• Когда вы собираетесь начинать его?
• С кем вы планируете работать? Подходят ли они для такой работы? Есть ли у них возможность принять участие в проекте?

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

 

Глава 4 Выполнение проекта

ТЕМА ГЛАВЫ

• Работа менеджера в ходе выполнения проекта.

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

 

ОСНОВНАЯ МЫСЛЬ

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

 

Предварительные замечания

Забудем на время о переезде офиса и воспользуемся другим примером. Это позволит мне ввести вас в новую тему и продемонстрировать разные подходы к проекту.

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

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

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

 

Введение в роль менеджера проекта

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

Теперь нужно выполнить проект с надлежащим качеством, учитывая объем работ, сроки, стоимость и уровни рисков. Для этого надо:

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

• ежедневно проверять, все ли идет по плану;

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

• отслеживать, что может мешать реализации проекта, и вовремя принимать меры.

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

 

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

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

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

• текущий статус;

• проблемы;

• риски;

• изменения.

 

Измерение и отслеживание статуса

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

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

• если Дэвиду поручено приступить к работе 1 сентября, он так и должен сделать, иначе мы отстанем от графика;

• то же самое и с завершением работы — если Дэвид не выполнит ее к 15 сентября, мы тоже отстанем от графика.

 

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

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

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

При этом обязательно сверяйтесь с планом. В первую очередь вам нужно уточнять следующие моменты:

1) соответствие действий утвержденному плану;

2) соблюдение бюджета.

 

Есть два способа контролировать выполнение работ и расход средств:

• по расчетной позиции в плане. Если с решением конкретной задачи вы опаздываете на день, это означает, что как минимум с таким же опозданием завершится и весь проект. Единственный способ избежать этого — наверстать упущенное время. Итак, сверьтесь с календарным планом и ответьте, сделано ли все, что было запланировано. Так же стоит рассматривать и ситуацию с расходами: если вы потратили 200 ф. ст. там, где планировали израсходовать 100 ф. ст., то, каким бы ни был ваш бюджет, вы, вероятно, превысите его минимум на 100 ф. ст., если только не сэкономите эти средства на чем-то другом;

• по текущему тренду. Не менее важен текущий тренд (хотя о нем часто забывают) и его экстраполяция. Если, например, после трех недель работы вы опаздываете на три дня, но задержка возникла при выполнении только одной из задач, это не катастрофа. Однако если каждую неделю вы опаздываете на день, то, скорее всего, план был составлен неверно: сроки занижены на 20%, а это намного хуже. В управлении проектами есть хорошая пословица: «За день нельзя опоздать больше чем на день». Иными словами, нельзя внезапно обнаружить, что вы опаздываете на две недели. Если вы два дня работаете над проектом продолжительностью 100 дней и за это время сделали только то, что планировали сделать за день, то при желании вы, скорее всего, сможете наверстать этот день. Но налицо неприятная тенденция: ваш проект выполняется в два раза медленнее, чем запланировано. Если этот тренд сохранится, дело плохо.

 

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

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

 

Проблемы

Все сложности, возникающие в ходе проекта, называют проблемами. Их устранение — важная часть работы менеджера проекта. С проблемами мы вообще сталкиваемся постоянно. Если по дороге на работу у вас ломается машина, это — проблема. Заболел коллега, с которым вам нужно встретиться и решить некие вопросы? Проблема! Прибор, который вы планировали купить за 1 тыс. ф. ст., стоит 2 тыс. ф. ст. Тоже проблема! Компьютерная программа, которую вы пишите, оказалась сложнее, чем вы предполагали, и на нее уходит не пять, а десять дней? Еще одна проблема. Если подобные проблемы возникают в рамках проекта, обязательно нужно найти способ их решения.

Управление проектами — это структурированный способ достижения цели, и существует процедура решения проблем, повышающая ваши шансы на успех:

1. Удостоверьтесь, что проблема выявлена и характер ее понятен.

2. Найдите адекватные меры решения проблемы.

3. Назначьте ответственного за исполнение.

4. Установите срок, к которому должна быть решена проблема.

 

Риски

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

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

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

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

Существует много способов измерить риск и серьезность последствий. Например, при выполнении проектов, за исключением самых сложных, следует ранжировать риски, используя простую описательную шкалу. И серьезность последствий, и вероятность их наступления можно оценить как высокое, среднее и низкое. Поскольку эта шкала будет использоваться для расчетов, преобразуем ее в балльную, присвоив балл каждому уровню — 1 (низкий), 2 (средний) и 3 (высокий). Приоритетность риска — это произведение серьезности последствий и риска, выраженных в баллах. Максимальное значение присваивается тем рискам, которых следует опасаться сильнее других и по которым обязательно следует предпринять предупредительные меры.

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

1. По плану должны начинаться работы по одной из задач. Эта задача не входит в критический путь, и в общем-то к ней можно не приступать еще три недели. Ответственный исполнитель недавно переболел гриппом, но уже вышел на работу. Похоже, что он не выздоровел полностью и может взять больничный еще на пару дней. Хотя, по вашему мнению, вероятность того, что он вновь заболеет, невысока. К тому же с учетом имеющегося запаса времени это не окажет особого влияния на сроки выполнения проекта. Итак, для этого события: вероятность = 1, серьезность последствий = 1, т.е. приоритетность = 1.

2. Ваш продукт должен быть упакован в коробку. Это необходимое условие его продажи. У вашего основного поставщика упаковки возникли финансовые трудности, и, похоже, его фирму ждет крах. Однако вы сотрудничаете еще с двумя поставщиками, которые могут выполнить заказ. Как видите, вероятность финансовых трудностей у поставщика высока, но последствия — не слишком серьезны. Вероятность = 3, серьезность последствий = 1, приоритетность = 3.

3. Перед началом проекта вы выполнили масштабное исследование рынка, которое свидетельствует, что продукт будет востребован. Поскольку вы тщательно провели исследование, вероятность ошибки низка, но последствия ее очень серьезны. Вероятность = 1, серьезность последствий = 3, приоритетность = 3.

4. Известно, что 60% продаж продуктов такого типа приходятся на предрождественскую неделю. Значит, для успеха проекта его нужно завершить так, чтобы продукт вовремя поступил в продажу. По плану вы должны успеть до Рождества, но план не предусматривает резерва времени, поэтому все задачи нужно выполнить в самые сжатые сроки. Вероятность, что вы не уложитесь в срок, велика, столь же серьезными будут и последствия. Вероятность = 3, серьезность последствий = 3, приоритетность = 9.

 

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

Управление проектом — это структурированный способ достижения цели, соответственно он предусматривает и процедуру управления рисками, повышающую шансы на успех:

• удостоверьтесь, что вы правильно определили риски и поняли их характер;

• сфокусируйтесь на рисках, имеющих наиболее высокую приоритетность;

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

• назначьте ответственного за реализацию этой стратегии;

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

 

Стратегия управления рисками предлагает несколько вариантов действий. Вы можете:

• проигнорировать риск. Если вероятность и влияние риска незначительны, это вполне допустимо;

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

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

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

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

 

Изменения

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

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

• контролировать введение изменений;

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

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

 

Неэффективное управление изменениями часто приводит к провалу проекта.

 

 

Шаг за шагом ШАГ 4: Выполнение проекта

Шаг 4.1. Начинайте проект

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

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

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

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

• подтвердить доступ к необходимым ресурсам и ваше право начать их использование.

 

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

• свою роль в проекте, порученные ему задачи и их последовательность;

• сроки выполнения работ по этим задачам;

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

• порядок информирования менеджера о ходе выполнения работ.

 

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

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

 

Шаг 4.2. Планируйте свой день

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

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

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

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

• какие действия следует предпринять;

• какие вопросы необходимо решить в первую очередь.

 

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

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

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

• шаги 4.3–4.7 позволят вам собрать информацию о проекте и определить, что требует вашего внимания;

• шаги 4.8–4.10 — это те действия, которые вы предпримите, разобравшись в ситуации.

 

Шаг 4.3. Собирайте информацию, составляйте отчеты

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

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

• Что члены команды сделали за истекшую неделю, как идет выполнение плана?

• Что члены команды намерены делать на следующей неделе и насколько это отвечает утвержденному плану?

• Появились ли какие-либо новые проблемы или риски, нужно ли вносить изменения в план?

• Чего добились исполнители, ответственные за решение существующих проблем, снижение рисков или проведение изменений?

 

По итогам совещания обычно составляют отчет для заказчика, в котором должно быть отражено следующее:

• Общий статус проекта — соблюдается ли график работ?

• Если есть какой-то сбой, что вы предпринимаете, чтобы его устранить?

• Ваш текущий прогноз по поводу сроков выполнения проекта.

• Резюме сделанного за истекшую неделю и планы на следующую.

• Решения, которые должен принять заказчик (например, утверждение изменений).

 

Отчет о ходе выполнения работ должен быть простым, объемом не более одного листа формата A4 (образец такого отчета приведен в табл. 4.1).

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

 

Шаг 4.4. Отслеживайте ход работ

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

• Соблюдается ли календарный план? Нет ли каких-либо тенденций, которые могут внушать беспокойство?

• Если есть отставание по срокам, насколько оно серьезно? Входят ли задачи, по которым возникло опоздание, в критический путь или нет?

• Насколько велико отставание? Сколько времени нужно наверстать, чтобы войти в график? Есть ли вероятность превышения резерва?

• Какие есть возможности наверстать упущенное время?

• Какая из этих возможностей оптимальна?

 

Ключевые факторы успеха

4

Постоянно стимулируйте выполнение проекта

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

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

 

Что же можно предпринять, если выявилось отставание от плана? Решение во многом зависит от ситуации, но можно прибегнуть к следующим мерам:

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

• примириться с опозданием и использовать резерв. Это допустимо, но обязательно продумайте, нет ли других способов наверстать упущенное;

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

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

• внести в проект изменение. Иногда, уменьшив объем работ и пожертвовав результатами, можно завершить проект быстрее. Впрочем, не стоит относиться к изменениям легкомысленно и вносить их каждый раз, когда возникает необходимость наверстать упущенное время. Кроме того, все эти изменения требуется согласовывать с заказчиком. Поэтому при реальной угрозе срыва сроков лучше выяснить у заказчика, что для него предпочтительнее — изменение срока сдачи проекта или выполнение проекта в срок, но с иными результатами;

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

 

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

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

 

Ключевые факторы успеха

5

Будьте гибкими и креативными

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

Шаг 4.5. Выявляйте и устраняйте проблемы

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

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

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

• описание проблемы;

• дата выявления;

• влияние на проект;

• исполнитель, ответственный за ее устранение;

• действия по решению проблемы;

• срок, к которому ее необходимо решить;

• дата следующего отчета о ходе решения проблемы;

• является она открытой (О) и по-прежнему тормозит выполнение проекта или закрытой (З), т.е. была решена.

 

Пример реестра проблем для проекта переоборудования офиса приведен в табл. 4.2.

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

Если проблемы остаются нерешенными, а их список только растет, скорее всего, проект выполняется неправильно.

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

 

Шаг 4.6. Выявляйте риски и управляйте ими

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

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

Каждый новый риск следует заносить в реестр, в который должны быть включены следующие сведения:

• описание риска;

• вероятность его наступления;

• серьезность последствий;

• общая приоритетность;

• ответственный за управление риском;

• меры по устранению/снижению риска;

• сроки завершения необходимых операций;

• текущий статус данного риска.

 

Пример реестра рисков приведен в табл. 4.3.

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

Шаг 4.7. Управляйте изменениями

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

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

• описание предлагаемого изменения;

• причину изменения;

• сроки принятия изменения, позволяющие осуществить его;

• влияние на проект — изменится ли продолжительность или стоимость проекта, качество или риск;

• рекомендуемые действия в сложившейся ситуации;

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

• согласие заказчика на внесение изменения.

 

Пример заполненной формы приведен в табл. 4.4.

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

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

Шаг 4.8. Старайтесь обеспечить успех проекту

Итак, вы оценили ход выполнения проекта, разобрались с проблемами, рисками и предлагаемыми изменениями. У вас есть вся информация, которая нужна для управления проектом. Теперь можно переходить к действиям.

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

Ключевые факторы успеха

6

Будьте менеджером проекта!

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

Название «менеджер проектов» говорит само за себя — он не исполнитель проекта, член команды или сторонний консультант. Его роль — управлять проектом, и она очень важна. Когда работу никто не проверяет, не координирует, не направляет и не контролирует, шансы на успех очень низки. Таким образом можно решать лишь самые элементарные задачи.

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

Помните о роли дирижера оркестра. Никто не ждет, что он посреди концерта вдруг сядет за инструмент и начнет играть. Все понимают: его роль — управлять оркестром. Такая же роль и у менеджера проекта — он должен управлять.

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

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

В табл. 4.6 приведены примеры типичных проблем и рассказано о мерах по их устранению.

 

Шаг 4.9. Держите заказчика в курсе проблем

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

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

Ключевые факторы успеха

7

Поддерживайте взаимодействие

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

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

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

 

Шаг 4.10. Обновите план или бюджет проекта

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

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

Изменения следует вносить в следующих случаях:

• если вы нашли лучший способ завершить проект. Такое тоже случается, и этим, естественно, надо воспользоваться;

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

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

 

Когда возникает такая ситуация, перечитайте соответствующие разделы второй главы.

 

Главное, что нужно запомнить

• Помните пословицу «За день нельзя опоздать больше чем на день» и контролируйте выполнение работ. Отставание от плана на две недели не возникает внезапно, это результат опозданий, накопившихся за десять рабочих дней.

• Чтобы оценить, как выполняется проект, определите, насколько далеко вы продвинулись по плану, и проанализируйте тенденцию.

• Расходуйте резерв пропорционально ходу выполнения.

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

• Не допускайте неконтролируемых изменений в проекте.

• Управление проектом построено на преодолении всех обстоятельств, мешающих его выполнению.

• Постоянно информируйте заказчика о ходе работ.

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

ЛИТЕРАТУРА

• Формы отчета, реестры рисков, проблем и изменений в форматах MS-Word и MS Excel доступны на сайте: .
• Рассмотренная тема очень важна для управления проектами и поэтому раскрывается практически во всех работах, хоть и не всегда одинаково хорошо. Отдельным проблемам, скажем управлению рисками, посвящены тома объемом в несколько сот страниц, при желании, конечно, вы с ними можете ознакомиться, хотя эти знания, скорее всего, вам понадобятся лишь в особых случаях. Я рекомендую ознакомиться со следующими материалами:

The Project Workout (Financial Times Prentice Hall) by Robert Buttrick, 2nd edn, 1999, Chapters 21–25.

The Project Manager: Mastering the Art of Delivery (Financial Times Prentice Hall) by Richard Newton, 2005, Charters 5, 7 and 10.

The Definitive Guide to Project Management (Financial Times Prentice Hall) by S. Nokes et al., 2003, Chapters 4–7.

Practical Project Management: Tips, Tactics and Tools (Wiley) by Harvey A. Levine, 2002, Chapters 4–8.

ЧТО ДЕЛАТЬ СЕЙЧАС

• Приготовьтесь начать проект. Готовы ли вы провести стартовую встречу? Ее следует тщательно спланировать. Если вы проведете ее как надо, у вас будет мотивированная и энергичная команда; если провалите — доверие к вам как к менеджеру проекта может быть подорвано.
• Управление проектом должно быть прозрачным. Убедитесь, что у вас есть все необходимые формы и документы, что вы знаете, как их использовать, и понимаете, кто из членов команды имеет право доступа к ним. Определите, будете ли вы рассылать их по электронной почте, выкладывать на сайт или станете использовать варианты, распечатанные на бумаге?
• Спланируйте ваш личный график и то, как вы будете управлять выполнением работ, проблемами, рисками, изменениями и т.д.
• Убедитесь, что члены команды проекта внесли в свой рабочий календарь даты заседаний, на которых должны присутствовать.
• Определите характер взаимодействия с заказчиком для обсуждения проблем и хода выполнения проекта. Договоритесь о еженедельных встречах и отведите на такую встречу минимум час. Даже если пока вы не знаете точно, о чем будете говорить с заказчиком в течение этого часа, вы всегда найдете множество тем для обсуждения.

 

Глава 5 Завершение проекта

ТЕМА ГЛАВЫ

• Как завершить проект, т.е. удостовериться в полноте и правильности полученных результатов.

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

 

ОСНОВНАЯ МЫСЛЬ

• Менеджер должен проконтролировать завершение проекта и подчистить все «хвосты» — только тогда проект можно считать успешным. Для правильного завершения проекта нужно протестировать готовый продукт и убедиться, что заказчик сможет им воспользоваться.

 

Предварительные замечания

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

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

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

Если впредь вы не собираетесь заниматься проектами, здесь можно поставить точку. В ином случае имеет смысл проанализировать проект — что у вас получилось хорошо, а что не очень и что можно было бы сделать иначе? Это поможет вам добиться лучших результатов в последующем.

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

 

Введение в завершение проектов

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

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

1. Протестируйте готовый продукт. Все ли работает? Получили ли вы то, что планировали? Не все продукты надо тестировать, но, если речь идет о компьютерной программе, новой телефонной сети, новом приборе и т.д., тестирование совершенно необходимо.

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

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

 

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

 

 

Шаг за шагом ШАГ 5: Завершение проекта

Шаг 5.1. Протестируйте готовый продукт

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

Хотя характер тестов варьируется, есть ряд общих вопросов, которые обязательно надо решить при тестировании:

• Все ли результаты получены?

• Все ли работает?

• Работает ли готовый продукт так, как надо по плану?

• Соответствует ли качество продукта ожидаемому?

• Оговорил ли заказчик критерии или процесс приемки работ; отвечает ли готовый продукт этим критериям?

 

Если вернуться к нашему примеру с переездом в новый офис, то в этом случае в рамках тестирования вам нужно проверить:

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

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

• соответствует ли гигиеническим нормам освещение рабочих мест и насколько удобен доступ к розеткам;

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

• работают ли телефоны и легко ли соединиться с нужным вам номером.

 

Более подробная информация о тестировании дана в Приложении.

 

Шаг 5.2. Передайте продукт на эксплуатацию

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

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

• Готовы ли заказчики к получению продукта? Например, если вы собираетесь устанавливать новую мебель в офисе, проверьте, подготовлен ли офис, или в нем сейчас работают и мебель ставить некуда.

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

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

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

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

 

Подробнее об этом будет рассказано в Приложении.

 

Шаг 5.3. Обеспечьте клиентскую поддержку

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

• Велика ли вероятность возникновения проблем?

• Как будут решены эти проблемы?

• Как вы узнаете, как долго нужно оказывать поддержку заказчику?

 

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

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

• каждый работник знал, где находится его рабочее место;

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

• все узнали номера своих телефонов, пароли к компьютерам и т.п.;

• каждый знал, как пользоваться новыми компьютерами и телефонными аппаратами.

 

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

 

Шаг 5.4. Высвободите ресурсы

Когда ваши сотрудники выполнят свои задачи в рамках проекта, вы можете «освободить» их. Но не спешите. «Освобождайте» кадры только в том случае, если:

• вы уверены, что они завершили всю работу и выполнили свои задачи. И неважно, закончили ли работу в тот день, что указан в плане, или раньше — главное не дата, а выполнение всего объема работы;

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

 

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

Ключевые факторы успеха

8

Не выключайтесь из работы

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

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

Шаг 5.5. Сделайте выводы

Планируете ли вы в дальнейшем заниматься управлением проектами? Будут ли какие-то другие проекты в вашей компании? Чаще всего люди дают утвердительный ответ на оба вопроса. Если и вы ответите «да», то проанализируйте, как шло выполнение проекта, сразу после его завершения и сделайте выводы. Не откладывайте это на будущее, так как детали быстро забываются.

Постарайтесь найти ответы на следующие вопросы:

• Какую практику следует тиражировать? Что получилось хорошо и что вы повторите в новом проекте?

• От чего вы откажетесь? Что получилось плохо и чего вы не станете делать при выполнении следующего проекта?

• Что обязательно вы введете в новый проект? Чего вы не сделали в этом проекте и что, как теперь понятно, стоило бы сделать?

• Есть ли что-то еще, о чем вы узнали и что стоит запомнить?

 

Привлеките к анализу членов команды, а по возможности и заказчика.

 

Шаг 5.6. Отметьте результаты

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

 

Главное, что нужно запомнить

• Продумайте, нужно ли тестировать и внедрять готовый продукт и как это сделать.

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

• Проконтролируйте, действительно ли все ваши сотрудники, задействованные в проекте, могут быть «освобождены».

• Не забудьте отпраздновать ваш успех.

• Включите задачи, представленные в этой главе, в план и бюджет проекта.

• Если вы не успеваете закончить проект или не укладываетесь в бюджет, не поддавайтесь соблазну не выполнить эти задачи.

ЛИТЕРАТУРА

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

The Definitive Guide to Project Management (Financial Times Prentice Hall) by Sebastian Nokes et al., 2003, Chapters 10–11.

The Project Workout (Financial Times Prentice Hall) by Robert Buttrick, 2nd edn, 1999, Chapters 8–11, 27.

ЧТО ДЕЛАТЬ СЕЙЧАС?

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

 

 

 

Заключение

И вот вы подошли к концу книги. С помощью предложенного в ней алгоритма теперь вы можете управлять проектами. Дополнительную информацию вы найдете в Приложении, а определение понятий — в глоссарии.

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

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

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

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

 

 

Приложение

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

 

Сбор требований

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

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

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

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

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

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

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

 

Пример такого каталога требований приведен в табл. A.1.

 

Привлечение сторонних исполнителей к работе над проектом

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

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

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

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

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

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

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

 

Тестирование, интеграция и внедрение

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

Тестирование — задача сложная. В крупных проектах (например, при разработке сложных компьютерных программ) есть исполнители и даже целые команды, занимающиеся только тестированием. Характер тестирования зависит от вида продукта, полученного в результате выполнения проекта. Обычно проводят следующие тесты:

1. Тестирование на полноту выполнения проекта. Получены ли все ожидаемые результаты?

2. Тестирование функциональности. Насколько функционален готовый продукт?

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

4. Тестирование пригодности к эксплуатации. Может ли заказчик использовать готовый продукт и доволен ли он результатами работы?

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

 

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

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

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

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

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

 

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

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

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

1. Тестирование продукта. Проверка полученных результатов.

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

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

4. Испытание на практике. Интегрированные продукты тестируют в реальных рабочих условиях.

 

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

 

 

Глоссарий

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

Бизнес-анализ

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

Бизнес-кейс/коммерческое предложение

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

Бюджет проекта

Необходимые средства, выделенные на выполнение проекта.

Влияние

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

Внедрение

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

Внешняя зависимость

Связь одной или нескольких задач проекта с задачами, в него не входящими (иными словами, внешними по отношению к нему).

Выполнение

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

Декомпозиция

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

Дерево решений (Work Breakdown Stucture — WBS)

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

Жизненный цикл

Обобщенное, высокоуровневое описание тех этапов, через которые проходит проект.

Зависимость

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

Задача — «черный ящик»

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

Заказчик проекта

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

Изменение

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

Каталог требований/спецификация

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

Контрольная точка

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

Команда проекта

Группа лиц, работающих над проектом под управлением менеджера проекта.

Критический путь

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

Менеджер проекта

Лицо, несущее общую ответственность за выполнение проекта.

Стартовая встреча

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

Номер задачи

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

Объем работ

Формальное описание и определение работ, которые входят в проект — в этой книге также обозначается как «что».

Описание проекта

Документированное описание цели(-ей) и объема работ по проекту.

Ответственный за проблему

Член команды проекта, ответственный за разрешение проблемы.

Параметры проекта

У проекта есть пять параметров: объем работ; качество полученных результатов и выполненных работ; сроки, в которые проект будет завершен; его стоимость и уровень риска. Эти пять параметров представляют собой взаимосвязанные переменные, которые можно осознанно и явно менять относительно друг друга, чтобы приспособить проект под нужды заказчика.

Параметры

См. Параметры проекта.

План проекта

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

Получение выгод

Достижение цели проекта (его «зачем»).

Предшествующая задача/зависимость от предшествующей задачи

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

Проблема/управление проблемами

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

Программа/менеджер программы/управление программой

Программа — крупный или сложный проект, обычно состоящий из ряда взаимозависимых проектов, которые в совокупности направлены на достижение общей цели. Управление программой — «продвинутая» форма управления проектами, осуществляемая менеджерами программ.

Продолжительность

Время от начала до завершения работы над задачей. Сюда входят как время активной работы над задачей (см. Трудоемкость), так и любые задержки или ожидание между началом и завершением работы.

Проект

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

Резерв

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

Результат

Продукт, получаемый по завершении проекта.

Риск/управление риском

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

Системная интеграция

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

Тестирование

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

Техническое задание на тестирование

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

Трудоемкость

Количество времени, которое один исполнитель должен потратить на выполнение задачи.

Управление изменениями

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

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

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

Человеко-час/человеко-день/человеко-неделя/человеко-месяц/человеко-год

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

Экономическая выгода/коммерческая цель

Цель коммерческого проекта («зачем») — обычно используется для обоснования расходов или выделения ресурсов под проект. Определяется как финансовая выгода, которую получит заказчик от инвестиций в проект.

 

 

1 Более наглядно зависимости между задачами показываются в сетевом графике выполнения работ. — Прим. ред.

2 Имеются в виду Spring Bank Holiday и August Bank Holiday, отмечаемые соответственно в мае и августе, — дни, в которые все банки страны отдыхают. — Прим. ред.

 

Отправить