О том, как меняются подходы и методы управления проектами в нынешних условиях, мы беседуем с Алексеем Малышкиным, начальником отдела контроля проектов ЮникредитБанка.
Intelligent Enterprise: Говорят, что с момента наступления кризиса мы живем в другом мире. В то же время многие считают, что методологии управления проектами настолько хорошо проработаны, что кризисные условия в них прекрасно укладываются и даже сейчас можно успешно управлять проектами, руководствуясь этими трудами…
Алексей Малышкин: Я думаю, что кризис провел разделительную черту между тем, что было, и тем, что стало, в том числе и в области управления проектами. До его наступления на 80% главенствовала методология PMBOK, а всё остальное — это были импровизации, которые позволяли себе менеджеры проектов и программ. Менеджеры опирались на PMBOK, а уже найдя точку опоры, каждый решал сам, в каком направлении двигать Землю дальше. Следование методологии действительно давало возможность легче управлять проектом. И в общем‑то это всех устраивало, несмотря на пугающую статистику провальных и не завершенных в срок проектов.
К сожалению, опора на PMBOK и основанную на нем систему сертификации проектных менеджеров не спасала от провалов. Следование этой методологии отнюдь не гарантировало успешного завершения проекта. В «докризисных» отчетах компаний можно видеть, что значительная часть проектов не завершалась в срок или не укладывалась в бюджет.
Методологию писали компетентные люди, однако это было в условиях другой экономики, когда ограничения были не столь важны. Сейчас обстановка изменилась. В целом ресурсов стало существенно меньше, гораздо сложнее с финансированием проектов. Раньше и сроки не были столь сжаты. Из десяти миллионов инвестиций потерять один тогда было совершенно нормально. Можно было рискнуть. Сейчас же слово «потери» становится просто пугающим. Ресурсы стали намного дороже, возросли риски. Всё это означает, что методика управления проектами должна измениться. На мой взгляд, слепое следование «лучшим практикам» сейчас скорее накладывает больше ограничений, препятствует действительно необходимым мерам.
Расскажите подробнее об этих ограничениях и о тех мерах, которые сегодня следует предпринять, чтобы повысить вероятность успеха проекта.
Первым и наиболее существенным из методологических ограничений стал устав проекта. Фактически этот документ описывает как раз не проект, а именно его ограничения. Можно говорить, что устав — это первое минное поле, на которое ступает проектная команда. Понятно, что короткий документ, принимаемый руководителями компании, отнюдь не полно описывает весь проект. И цель, сформулированная в одном-двух предложениях, не является полным описанием его результата. Опираясь только на эти несколько кратких фраз, невозможно сказать, сколько проект стоит, какие ресурсы для него потребуются и в какой срок он будет выполнен. И, что сейчас самое важное, эти предложения не дают представления о проектных рисках. Однако когда вы начинаете работать в условиях жестких ограничений, то приходится взвешивать каждую строчку устава. И чтобы действительно достичь результата, устав этот нужно преобразовать, сделав его по‑настоящему эффективным инструментом. Устав проекта должен быть не единым документом, лучше, если он будет состоять из нескольких документов-подчастей. Первым из них является устав проекта по целям, он должен давать ясное представление о результатах, которых мы хотим достичь. Возьмем «дачный вопрос»: если мы возделываем свои шесть соток, то планируем, где у нас будет морковка, где петрушка, огурцы и помидоры. Мы вскопаем огород так, чтобы было абсолютно ясно, что здесь место помидорам, а не огурцам. А здесь будет земляника, а не клубника, потому что это две разные ягоды.
Кроме того, мы должны четко описать, что в проекте не будет сделано. Заказчик по умолчанию думает, что будет сделано всё. Но по завершении проекта часто оказывается, что интерпретация размытых формулировок, записанных в уставе, размывает его границы до «сотворения мира заново». К сожалению, обычно ограничения не описываются в форме, которая была бы понятна проектной команде и заказчику. Все больше надеются договориться «на доверии». Но когда принимается результат, все стараются опереться на формальные документы, потому что здесь дело касается ответственности и денег. Соответственно результат достигнутых ранее договоренностей потом нивелируется простым росчерком о неприемке работ. И доказать что‑то, как правило, уже невозможно.
Еще один необходимый документ — устав по изменениям, описывающий, на каких условиях и как мы будем принимать изменения. Кроме того, сейчас необходим устав проекта по рискам. Обычно в уставе проекта риски обозначены довольно обобщенно — например, «в случае чего мы сделаем всё от нас зависящее». И редко когда стоимость этих рисков выделяется из общего бюджета. В результате когда риск увеличивается, мы идем к спонсору и говорим: «Нам нужны дополнительные деньги». Но в сегодняшних условиях спонсор вряд ли одобрит такой запрос. Поэтому риски должны быть описаны отдельным уставом и рассматриваться тоже отдельно.
В сегодняшней ситуации при подготовке проекта возникает необходимость строить документы в том виде, в каком они нужны даже не менеджеру проекта, а спонсору. Он должен четко понимать, что получает и чем рискует. Если раньше после выделения денег ему достаточно было отследить их целевое расходование, то сейчас спонсор хочет видеть, что за эти деньги он получит соответствующий результат.
А дальше? Какие меры можно предпринять на этапе инициации проекта, чтобы облегчить спонсору жизнь, то есть сделать принятие решений менее рискованным?
Чтобы уменьшить риски, есть два стандартных приема, которыми сейчас надо широко пользоваться, — предпроект и пилотный проект. Предпроект — это подготовка проекта (в том числе и пилотного), в ходе которой уточняются его параметры, выявляются риски спонсора и заказчика. Такая подготовка способна дать представление, правильно ли определены риски и ограничения проекта. Пилотный проект — это выпуск опытного образца. В его ходе выполняются все операции по созданию определенного продукта или услуги и получается результат — сам продукт или услуга. Это не теоретические изыскания, а практическая работа. Например, для банка такой работой может быть выпуск опытной партии кредитных карт с целью опробовать их на целевой аудитории и отследить ее реакцию.
Однако использование предпроекта требует пересмотра корпоративных стандартов в области управления проектами, ведь обычно выполняется лишь «пилот». Для заказчиков пилотный проект — это дополнительный риск по срокам, поскольку он связан с дополнительными усилиями, которые нужно уложить в определённые временные рамки. Кроме того, все задачи решаются с учётом стратегических целей, которые ставятся акционерами и должны быть четко выполнены. В результате что такое пилотный проект, акционеры понимают плохо.
Поэтому спонсору нужно в доступном для его понимания виде донести идею предпроекта. Существует простое правило: на предпроект можно потратить не более 20% проектного бюджета. Если идея проекта окажется нежизнеспособной, то мы потеряем лишь эти деньги. Ну а с учётом сегодняшних реалий лучше, чтобы эта сумма составляла 5—10% от общего бюджета проекта. Это не так уж много, если при этом вы смогли доказать спонсору эффективность проекта, существенно понизив его риски. Поэтому я рекомендую в графике сразу заложить дополнительные сроки на предпроект.
Однако если есть серьезные ограничения по срокам проекта, то никто предпроект открывать не будет. Что делать в таком случае? В этом случае его нужно делать в самом проекте. И здесь мы снова сталкиваемся с ограничениями стандартных методологий — в них не описано, как закрыть действующий проект, если по итогам результатов предпроекта возникает такая необходимость. И, само собой, всё это должно быть отражено в уставе — стороны должны четко представлять, на что идут.
Предположим, предпроект проведен и решение о проекте принято, согласованы все документы. Что сегодня выходит на первый план, когда мы говорим об операционном управлении проектом? Что предпринять, чтобы не потерять контроль над проектом в нынешних условиях?
В первую очередь, на мой взгляд, нужны короткие быстрые совещания. Работа проектной команды часто проваливается из‑за несогласованности действий. Если информация передана от одного лица другому, никто не знает, нужна ли она кому‑то еще. К сожалению, в PMBOK нечетко прописаны роли в проектной команде. Матрица ответственности довольно неопределенна, потому что ролей может быть множество, области ответственности часто пересекаются, причём даже передача-прием результата является областью пересечения, которую нужно очень четко отслеживать. Поэтому здесь нужен метод коммуникаций, который эту неопределенность устраняет. И короткие, но частые совещания — например, ежедневно или даже три раза в день по пятнадцать минут — позволят всем участникам команды получать единую актуальную картину ситуации. В итоге каждый гораздо лучше понимает свою ответственность, степень значимости своих действий, чем в ситуации, когда менеджер еженедельно докладывает всем о состоянии проекта. Это совершенно другой подход.
И каждый раз в ходе совещания стоит решать один-два вопроса. Применив правило Парето, можно сказать, что 20% вовремя решенных важных вопросов обеспечат решение 80% оставшихся. Смысл совещаний не только в обмене информацией, но и в фиксации изменений. Незабываемый Штирлиц сказал очень правильную вещь: «Всегда запоминается последняя фраза». Так вот, чем чаще вы будете проводить совещания, тем больше «последних фраз» запомните. После каждой встречи картина будет уточняться, и тогда можно отследить динамику развития ситуации.
В проектах много времени тратится на написание отчетов. Частые совещания заменяют их?
Да, такая деятельность проектной команды позволяет минимизировать и бумажную работу. Зачем множить отчеты, когда картина и так ясна? Теперь вместо стандартных отчетов, которые пишут все, документирование ведет администратор проекта, составляя протокол совещания. Фиксация результатов проекта будет, но потом. Обычно отчет играет две роли: информационный всплеск для обсуждения на совещании и фиксирование истории проекта. При указанном изменении схемы взаимодействий первая составляющая исключается, а вторая остается, в результате мы можем получить стандартную отчетность, описанную в PMBOK. То есть функция документа, который составляет администратор проекта, — не подготовка к совещанию, а описание результата. При этом мой опыт показывает, что благодаря таким более плотным коммуникациям вы экономите около 15% проектного времени.
Хотелось бы уточнить, что администратор проекта — это не просто секретарь, а скорее заместитель, фактически правая рука проектного менеджера. Эффективность последнего при такой поддержке возрастет многократно и позволит в большей степени сосредоточиться на целях проекта, на работе команды и с командой.
Вы говорили о том, что описание рисков нужно фиксировать в уставе проекта. А как управлять ими в ходе работ?
Безусловно, риски должны пересматриваться на каждом этапе проекта. Фактически на каждом этапе должен быть составлен параллельный план на случай возникновения основных рисков. Но это можно сделать только для тех рисков, которые выявлены. А кроме них, как известно, в ходе проекта могут возникнуть и не выявленные риски, потому что всё предусмотреть невозможно. Возникает задача этот риск обойти либо нейтрализовать. Уничтожить риск практически невозможно, на это нужно затратить слишком много усилий и времени. Поэтому нужно выработать правильную методологию поведения — как реагировать на появление риска.
Худший вариант — знать о риске, но ничего не предпринимать. Я называю его «камикадзе». Можно попытаться обойти риск, однако это тоже не всегда срабатывает — до какого‑то момента это возможно, но в итоге все равно проявится. Наиболее правильным подходом мне представляется попытка превращения риска из минуса в плюс. Знаете, есть такое восточное высказывание: «Если ты своего врага превратишь в друга, то у тебя будет в два раза больше друзей». Нужно выработать восприятие риска не как опасности, а как некоего обстоятельства. Если мы воспринимаем обстоятельства как опасность — они и будут опасностью. Если как проблему, значит, это будет проблема. Но если мы воспримем их как задачу, то это будет задача.
Скажем, заказчик хочет внести в проект изменения, которые не были обозначены в уставе, но объективно их нужно сделать. Мы принимаем эти изменения, но оговариваем, что внесём их после завершения основного проекта. При этом первое: мы показываем позитив и не отходим от устава. Второе: мы показываем, что мы это сделаем, но позже, потому что изначально этого не было, и мы правы. Если требования настойчивые, то от них тоже не стоит отказываться, а надо пересмотреть список работ. Можно создать второй план проекта, и пусть заказчик решает, соглашаться ли на него. К уставу необходимо создать дополнение, что на практике обычно пропускается. Ведь изменений бывает довольно много, нужно писать большой объем документов, а потом их еще и утверждать.
В любом случае мы показываем готовность к конструктивным действиям, а не пытаемся бороться, защищать бывший список работ — заказчик все равно не даст ничего сделать. Сейчас, в кризисное время, многие проекты пересматриваются. Однако в стандартной методологии описания действий на такой случай нет. Здесь скорее нужны знания из области психологии. Вообще психологические знания очень важны для руководства проекта.
Сейчас, когда многие компании сокращают штат сотрудников, проектные ресурсы обычно тоже сильно урезаются. В результате даже для тех ролей, которые в методологии управления проектами считались стандартными, не всегда удается выделить человека — приходится одному «сидеть на двух стульях». Что делать руководителю проекта в такой ситуации?
Если бы я попал в такое положение, то, во‑первых, заручился бы поддержкой спонсора, потому что без финансовой помощи здесь не обойтись — нужна какая‑то компенсация недостающих ресурсов. Треугольник ресурсы — сроки — деньги все‑таки нужно сбалансировать: если недостаточно ресурсов, то надо компенсировать их деньгами и сроками. Ведь в середине этого треугольника находится качество.
Затем можно попытаться восполнить команду. Я бы ни в коем случае не рекомендовал набирать людей «с улицы», даже если это готовые коллективы. Если брать работника «с улицы», то, по моему опыту, раньше чем через два месяца вы команду не наберете. Когда я пытался это сделать, мне удавалось принять лишь одного человека из семидесяти. И это при том, что они уже прошли фильтр кадровой службы. Ведь претенденты хватаются за что угодно и стараются «продать» себя любыми способами — лишь бы взяли. Если претендент хороший психолог, вы можете и не разглядеть, что он действительно собой представляет, — сделал он двадцать раз успешно то, что нужно вам, или не делал ни разу. В итоге ваша ошибка потом может вылиться в необходимость самому выполнять его работу.
Поэтому нужно ориентироваться на компании, которые уже доказали свою эффективность, то есть привлекать внешних подрядчиков. Их преимущество в том, что они быстро вникают в проблемную область. Для проверки им можно дать небольшую работу, посмотреть, как они её выполнят.
При работе с аутсорсинговыми компаниями одна из решаемых задач — замена/подстраховка наших ресурсов на период проекта или на долгосрочной основе, если говорить о нескольких проектах. Такие команды более гибко формируются на профессиональной основе и хорошо сбалансированы. Если нам не подходит кто‑то из сотрудников какой‑то команды из какой‑то компании, мы всегда можем попросить заменить его. Замена произойдет быстрее, чем поиск по рынку. Преимущество аутсорсинга именно в мобильности ресурсов, предоставляемых аутсорсинговой компанией. Если компания ориентируется во многих областях и способна легко перестроить свои ресурсы, то ее преимущество однозначно.
Но здесь нужно отметить один важный нюанс. Весь проект я на аутсорсинг отдавать не стал бы — только его фрагмент. Иначе риски могут появиться там, где о них и не думали. Во-первых, команда должна иметь опыт подобных проектов, и именно такой проект целиком вряд ли кто‑то делал, а это условие довольно жесткое. Во-вторых, любой проект соотносится со стратегическими целями компании. Одно дело, когда вы привлекаете исполнителей на какой‑то участок работ, не раскрывая конечного результата. Но если внешний человек управляет достижением — возникает риск, связанный с конкурентной средой.
В целом опыт управления проектами надо адаптировать к текущей ситуации. И смело отступать от стандартных методологий, если это кажется оправданным. Во многих случаях они могут быть ненужным ограничением. Сейчас сложилась уникальная ситуация, когда выиграть могут те, кто правильно построит проектную деятельность на развитие. Ведь развитие не останавливается — оно просто приобретает другие формы.
Проектный подход в аутсорсинге
Сергей Зайцев
Директор Управления развития Stack GroupОбсуждая тему управления проектами, стоит поговорить об ИТ-аутсорсинге, который еще до наступления кризиса стал набирать популярность и в России. Выстраивание взаимодействия между клиентом и аутсорсером — организационный процесс, требующий проектного подхода к управлению. Утверждаю это исходя из опыта Stack Group, активно развивающей практику работы с разными категориями потребителей услуг сети датацентров Stack Data Network (SDN).
Мы рассматриваем проработку и запуск услуги для каждого клиента SDN как отдельный проект, сочетающий в себе ряд отработанных бизнес-процедур и комплекс мер по учёту специфики бизнеса клиента (как правило, такая задача возникает при работе с крупными компаниями, предъявляющими повышенные требования к качеству ИТ‑сервисов). Благодаря такому подходу мы смогли быстро перейти от этапа «штучных» работ к «конвейерной» модели проектирования, сохранив при этом способность обеспечить наивысший уровень качества — с момента постановки задачи до постпроектного сопровождения.
