Почему заказчик должен платить за управление проектом

Хочу поделиться своим личным опытом. Я, как и многие выступавшие, выросла из программистов. Занималась 1С с 2005 года: изначально я была программистом 1С, затем перешла в консультанты и потом – в руководителя проектов.

С ужасом вспоминаю свой первый проект: перечитав кучу документации, я поняла, что большая часть – теория, которая не имеет отношения к моей жизни. Что делать – непонятно, что от меня ждет заказчик – непонятно. Спустя 15-16 лет я пришла к определенным выводам и выработала модель понимания того, что именно заказчик ждет от вас, как от руководителя проекта, и за что он готов платить. А он готов платить, потому что от проекта зависит очень многое.

Зачем нужно управление проектом

Заказчик – это не абстрактная фигура. Это группа людей, которым поручено внедрить 1С.

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

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

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

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

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

Информировать о ваших действиях на проекте

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

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

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

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

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

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

Например, мне рассказывают, что заказчик странный: с ним договаривались, что он даст складовые остатки, а он их к оговоренному сроку не дал. Начинаешь выяснять, как именно договаривались. «Мы в функциональной модели, в первом документе проектного обследования прописали требования к объекту, что они к декабрю проведут инвентаризацию, получат остатки и мы стартанем с 1 числа».

Спрашиваешь: «Ты ему напоминал? Ты эту задачу ставил в пул задач?». Это длительная задача, важная, ее за день не сделать – на это может уйти две-три недели, потому что склады и цеха бывают разные. Человек эту функциональную модель читал, подписывал в июле или в августе. С тех пор прошло несколько месяцев – понятно, что про эту задачу он забыл.

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

Если это просто где-то в бумажке написано, вашей вины в просрочке формально нет, человек же подписал. Но с точки зрения управления проектом вы сдвинулись на неопределенный период, когда заказчик посчитает склады. У вас повисла проектная команда, которой нужно что-то делать. Заказчик не может платить команде за то, что они месяц «курят бамбук». При этом на месяц скидывать их в другой проект тоже не вариант: время входа в проект достаточно длительное. То есть, формально вы не виноваты в простое, но с точки зрения проекта – это конкретный “фейл”.

В 80% случаев провал проекта – вина руководителя проекта. Она может быть неформальная – “на бумажках” вы все сделали, но вы не напомнили заказчику, вы его не дернули, вы его не проконтролировали.

В качестве примера приведу задачу по нормализации номенклатуры. Наименований условно 15-20 тысяч: понятно, что люди эту номенклатуру не нормализуют за день. Выделяйте на эту задачу полгода и каждую неделю контролируйте, сколько номенклатур нормализовано. Докладывайте об этом на совещаниях ключевому человеку со стороны заказчика. «По плану нужно нормализовать 25 тыс. наименований, сегодня нормализовано из них 100 штук. По прогнозам, мы сдвигаемся, потому что вы ничего не успеете». Когда человек со стороны заказчика это понимает, он может воспользоваться ресурсами и рычагами, чтобы повлиять на ситуацию.

Прогнозировать проблемы

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

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

В качестве примера: с 1 июля у меня произошел запуск в Калининграде. Я курировала этот проект, но не была там руководителем. У нас там работают два руководителя проекта по разным подсистемам. Запуск прошел с 1 июля, где-то с 15 июня должно было начаться обучение.

За день до начала обучения – 14 июня – мне звонит «плохой» руководитель проекта и говорит: «А ты в курсе, что все прилетающие должны проходить двухнедельную обсервацию?» Это значит, что я не могу прислать туда консультантов. То есть, я-то их пришлю, но они две недели будут там сидеть, никакого обучения в очном формате не будет.

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

Казалось бы, мелочь, но заказчику-то обещали с 15 июня начать обучение. Реально ничего могло и не начаться, потому что вмешались обстоятельства, которые руководитель проекта мог бы предусмотреть.

Основная работа руководителя проекта – общение. То есть он должен каждую неделю, перед каждой фазой проекта брать свою проектную команду и спрашивать: «Ты на этой неделе что делаешь, что тебе нужно, чтобы работать, что может помешать?»

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

С точки зрения проектной команды роль РП – обслуживающая. У нас есть люди, которые кодируют, пишут документацию, обучают, запускают, отвечают на вопросы. А руководитель проекта должен сделать все, чтобы команда могла спокойно работать. Чтобы у них было все необходимое для работы, чтобы они вовремя приехали, отсидели в обсервации, вышли без штрафов (15 тысяч за каждый выход) и так далее.

Защита проекта

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

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

Бумажки нужны не только нам. Когда я составляю функциональную модель (делаю описание бизнес-процессов), я, как РП с большим опытом, понимаю, что достоверность этой информации – 70%. Есть 30% операций, которые мы не поняли либо вообще не учли, потому что нам забыли об этом сказать: это человеческий фактор. То есть на 30% возникнет отклонений.

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

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

Для этого есть несколько вариантов:

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

• Если бумажки нет, РП скажет вам: это важный человек в организации – меняйте, как хотите.

Вывод: бумажки нужны, и нужны обеим сторонам.

На что уходит бюджет управления проектом (УП)

В каждый проект мы включаем бюджет управления проектами. Я примерно сделала раскидку в процентном соотношении: что и на что уходит.

Примерно 40% бюджета уходит на совещания со всеми: проблемы, информирование клиента о том, в какой стадии находится проект – этот вид работ занимает основное время при руководстве проектом.

Около 10% бюджета уходит на составление документации. Документация может быть разной. Я из PMBoK использую только план и реестр рисков.

План по людям я использую в Project и только для своих целей. В Project есть такое понятие, как пул ресурсов по нескольким проектам. Он позволяет получить картинку: кто и насколько в месяцах занят на проекте. На основании этой картинки руководитель проектного офиса сможет понять, какой сотрудник загружен, а какой – нет.

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

Для заполнения планируемых трудозатрат я использую метод освоенного объема, который мне хорошо помогает. Если в Project я ставлю процент выполнения, он считает мне примерно фактические трудозатраты при 100% выполнения, и я могу соотнести их с тем, что есть в базе учета рабочего времени. Сравнив два эти числа, я могу прикинуть, есть у меня ресурс на что-то или нет. Может, у меня есть часов 200, которые я могу на что-то потратить, или у меня глубокий перерасход, и я забиваю на все «бантики» и иду по документации.

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

Обновление релизов, ошибки 1С – на это уходит 30% бюджета. Риск здесь не в том, будут в новых релизах ошибки или нет, а в том, повалят они вам систему или вы сможете с ними как-то жить. Я понимаю, что формально ошибка 1С появилась не по вине РП, и вы не обязаны с ней разбираться. Но раз ошибка возникла, чего вы ждете? Что бухгалтер будет вручную сдавать баланс? Этого не произойдет, он вернется на старую систему и будет ждать, пока в новой системе эту ошибку исправят. Поэтому я закладываю время на исправление ошибок, но там, где возможно. Потому что есть такие ошибки, которые наши программисты не смогут исправить, как бы ни старались.

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

Сколько времени уходит на управление проектом

Теперь в часах. Я проанализировала три проекта – два небольших и один средний.

Если взять долю часов на управление проектом в целом из базы учета рабочего времени: от 10 до 17% уходит на управление проектом – именно на те задачи, которые были перечислены на предыдущем слайде, включая исправление ошибок 1С.

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

Да, много, но зато все три проекта – это проекты с отзывами, референсами и людьми, которые довольны тем, как прошло внедрение. Они готовы рассказывать о проекте.

Надо ли показывать часы на управление проектом заказчику? Сейчас я не показываю.

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

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

Должен ли руководитель проекта сам лезть в этот проект

У меня это работает плохо: хорошо идут проекты, в которые я не лезу.

Что значит «лезу»? Это значит, что я беру какой-то кусок, его автоматизирую и заодно управляю проектом. У меня так не работает, я не могу абстрагироваться.

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

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

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

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

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

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Инструментарий руководителя проекта".