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

Опасная западня: Работающие менеджеры проекта

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

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

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

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

Вопрос о том, как отбирать управляющих проектами, выходит за пределы этой книги. Но для заинтересованного читателя могу подсказать, что эта тема хорошо раскрыта в книге Роберта Высоцки и Джеймса Льюиса «Менеджеры проектов мирового уровня» (Pobert K. Wysocki and James P. Lewis “The World-Class Project Manager”, Perseus, 2001).

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

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

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

Рис. 1.1. Зависимость между результатом, сроками, стоимостью и содержанием проекта

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

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

Он обязательно воскликнет: «Почему так дорого?» У него в голове была своя цифра, а ваша ее явно превосходит. Он может сказать: «Если это столько стоит, мы не оправдаем свои расходы». Вот именно! Это именно то решение, которое заказчик должен принять. Однако он уверен, что ему удастся склонить руководителя проекта на снижение стоимости. И если вы согласитесь, то только ввяжете и заказчика, и себя в гораздо более серьезные проблемы, которые возникнут позднее.

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

Разумеется, есть и другая возможность. Если визави говорит, что может позволить себе заплатить только такую-то ограниченную сумму за проект, вы можете предложить ограничить его содержание или объем. Если проект годится и с таким объемом, он может быть осуществлен. Иначе разумнее и экономнее вообще забыть о нем и взяться за что-то другое, более прибыльное. Кто-то сказал, что скорее в проекте случайно что-то пойдет не так, чем все пройдет идеально. Что касается стоимости проекта, бюджет наверняка будет превышен. Это просто другой вариант изложения закона Мёрфи: «Если какая-нибудь неприятность может случиться, то она обязательно произойдет».

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

Рис. 1.2. Жизненный цикл проблемного проекта