Даже профессиональные проектировщики – системные интеграторы – сталкиваются с трудностями при управлении проектами. Как можно с ними справиться?
Компании, работающие в сфере системной интеграции, часто сталкиваются с одними и теми же проблемами, корни которых лежат в плоскости управления проектами. О типичных ошибках, цена которых исчисляется сотнями тысяч долларов, и о том, как их избежать, рассказывает Анна Старинская, генеральный директор компании «Технологии Управления Спайдер Украина».
Когда инициатива наказуема
Один крупный системный интегратор, получив от заказчика небольшую предоплату (15%), закупил для него дорогостоящее оборудование. Дело было в конце квартала. Принять груз на свой склад и полностью оплатить поставку заказчик должен был в следующем квартале (через три недели), о чем было записано в контракте и что устраивало обе стороны. Но в компании есть правило, которого должен четко придерживаться менеджер проекта: полученное от поставщика оборудование нужно немедленно доставить на склад заказчика. За оперативность менеджера проекта всегда хвалили. И он, как всегда, постарался, можно сказать, совершил невозможное. Договорился с заказчиком, чтобы тот раньше срока расчистил свой склад и привез ему груз досрочно. Облегченно вздохнув, получил накладную и, счастливый, уехал восвояси. По окончании квартала бухгалтерия системного интегратора начала подсчитывать свои налоговые обязательства. И вдруг откуда-то «выплыли» 5 млн. грн. дополнительного налога на прибыль. Причем откуда взялись на бумаге эти несуществующие миллионы, никак не могли понять, пока не подняли первичную документацию и не нашли ту самую накладную…
Безусловно, всю вину можно было бы полностью свалить на сотрудника, чье служебное рвение оказалось излишним и влетело компании в копеечку. Но правильно ли это? Ведь все произошло из-за ограниченности информации у менеджера проекта. Он стремился сделать все по отработанному шаблону, не зная, к каким серьезным последствиям может привести его решение. Но только ли он один виноват? Если бы подобного рода курьез был единичным случаем, можно было бы утвердительно ответить на этот вопрос. Но, к сожалению, подобные проколы и в этой, и в других компаниях, занимающихся системной интеграцией, стали частым явлением. К слову, мы общались с восемью разными компаниями из разных регионов – проблемы у всех аналогичные. Значит, дело не в личности менеджера проекта. Скорее что-то «не то» с системой управления проектами. Эта же мысль посетила генерального директора вышеупомянутой компании, решившего с нашей помощью разобраться в проблеме и устранить ее.
Принц и нищий
Мы стали разбираться, как в данной компании реализуется проект и кто за него отвечает. Оказалось, что все довольно стандартно, практически как у всех крупных системных интеграторов: главная роль в проекте обычно отведена сейлз-менеджеру (менеджеру по продажам), осуществляющему взаимодействие с заказчиками и соответственно привлекающему в компанию деньги. У сейлз-менеджеров самые высокие зарплаты, у них особое, привилегированное, положение: они – высшая каста, белая кость.
После того как контракт с заказчиком заключен, руководство проектом поручается другому человеку – менеджеру проекта. Их зарплата в два раза ниже, чем у сейлов, обязанностей много, а полномочий никаких. Особенностью, свойственной данной сфере деятельности, является и то, что менеджеры проектов не выделены в отдельный пул, а находятся внутри функциональных подразделений.
Практически менеджер проекта – это мальчик на побегушках, который носится между разными отделами и пытается скоординировать их работу над порученным ему проектом. Он никак не может повлиять на исполнителей – таких полномочий у него нет. Его задача – тормошить, просить, взывать к совести тех, кто осуществляет логистику, сборку серверов, принимает технические решения и т. д. Фактически менеджеры проекта – это технический персонал, который занимается планированием, не имея ни достоверных данных о том, как продвигаются работы по проекту, ни рычагов влияния на исполнителей. Выделят ли ему на проект нужных людей, и когда это произойдет, зависит от его личных отношений с руководителями департаментов.
У менеджера проекта есть свой план, но у каждого отдельного подразделения имеется свой. Зачастую они никак не соотносятся между собой. Таким образом, есть разрозненная информация, некое фрагментарное управление проектами, но нет общей системы, которая могла бы связать эти фрагменты между собой.
Итак, вначале за проект отвечает сейл, потом менеджер проекта. Но на этапе завершения и передачи заказчику руководство проектом опять поручается сейлз-менеджеру. В целом за проект перед заказчиком отвечает разве что генеральный директор. А кто ответствен за реализацию проекта перед компанией? Практически никто. Получается разрыв в зоне ответственности: сегодня отвечаю я, завтра – ты, а потом опять я.
Да и цели у обоих менеджеров разные. Задача сейлз-менеджера – заключить контракт, остальное (как будет осуществляться проект, в какие сроки и какими ресурсами) его мало интересует. Условия контракта могут быть совершенно не выгодны для команды реализации проекта. Для сейлз-менеджера важно удовлетворить все «хочу» заказчика, не важно какой ценой. А задача менеджера проекта – сделать вовремя свою работу, не отвлекаясь на разные «пустяки».
Для кого – информация, а для кого – белый шум
Приведу пример такого «пустяка». Одним из этапов некоего проекта по внедрению автоматизированной системы управления была поставка оборудования. По контракту это должно было выглядеть так: заказчик делал предоплату – 15% от стоимости заказа (это стандартная предоплата для такой услуги), после чего системный интегратор начинал работать – закупал оборудование в полном объеме и отправлял его заказчику, который должен был полностью оплатить полученное «железо» только через 15 дней.
Для оплаты оборудования компания-интегратор взяла кредит в банке. Вскоре совершенно случайно выяснилось, что накануне поставки заказчик в разговоре с менеджером проекта обмолвился, что деньги у него есть и для него совершенно не принципиально, оплатить покупку сейчас или ждать положенного по контракту срока. Менеджер проекта пропустил это мимо ушей, ведь денежные вопросы – не его компетенция. Он никому не передал эту информацию не из вредности, а потому что даже не подозревал, насколько она важна для компании. Никто и никогда не обсуждал с ним вопросы оплаты.
Два в одном? Или двое в одной команде?
Казалось бы, что проще – поручить выполнять обе функции одному человеку. Например, чтобы сейлз-менеджер (как человек уважаемый в своей компании и как никто другой знакомый с клиентским запросом) выполнял функцию менеджера проекта. Так, кстати, и происходит в мелких компаниях, где и клиентов немного, и заказы простенькие, а специалистов – считанные единицы. В таких компаниях все сотрудники – технари, четкого распределения ролей нет, все сотрудники взаимозаменяемы. Но в крупной компании такое невозможно, здесь у каждого свои функции, для исполнения которых нужны определенные знания и навыки. Задача сейл-менеджера – продавать, он знает, какие преимущества дает клиенту тот или иной продукт, может красиво вести переговоры, но не вникает в технические тонкости. А менеджер проекта – технарь до мозга костей, он должен понимать, какое «железо» закупать, какое нужно программное обеспечение и т. д. Но главное: если сейл-менеджеру поручить и ведение проекта внутри компании, он просто не сможет заниматься продажами – поток денег в компанию прекратится. Так что принцип «два в одном» для крупных системных интеграторов исключен.
Зачастую у заказчика в ходе реализации проекта вызревают новые пожелания, которые он сообщает сейлз-менеджеру. Не вникая в технические тонкости, тот берет под козырек: «Будет сделано» – и дает новые вводные менеджеру проекта. Последний хватается за голову, так как то, что пообещали заказчику, практически неосуществимо, и пытается на максимально доступном техническом языке объяснить это сейлу. Тот в свою очередь доносит эту информацию до заказчика… На утомительные переговоры и уточнения уходит много времени и сил, зачастую попутно теряется часть необходимой информации.
Как этого избежать? Только одним способом – создав команду управления проектом как внутри компании-подрядчика, так и внутри компании-заказчика. В состав команды заказчика следует включить различных специалистов. Тогда у системного интегратора была бы не одна точка выхода на заказчика, а несколько. И каждый специалист из команды проекта мог бы взаимодействовать с заказчиком на своем уровне – кто-то по финансам, кто-то по техническим вопросам, кто-то по вопросам корпоративной идеологии.
Новая роль
Менеджер проекта должен в иерархии стоять на одной ступени с продавцом.
Однако в любом случае в команде проекта должен быть старший. И эту важную функцию должен выполнять именно менеджер проекта (как это принято в любом другом бизнесе). Но чтобы стать ключевой фигурой в компании, он должен выйти на один ролевой уровень с сейл-менеджером, стать в своей компании VIP-сотрудником. Иначе нельзя требовать от него нужной степени ответственности. Разумеется, и уровень вознаграждения должен быть соответствующим. Так как если уравнять людей в правах формально, не подкрепив это материальными стимулами, менеджер проекта все равно будет восприниматься в компании как технический сотрудник, а не как управленец.
Чтобы изменить существующую в данной отрасли ситуацию, необходимо осознать, что все движения менеджера проекта неминуемо связаны с деньгами, и его просто необходимо посвящать в финансовую сторону проекта, нюансы контракта. У него должны быть другие полномочия, другая ответственность и другие (управленческие!) навыки, которые нужно развивать.
Построение системы
Вместе с заказчиком мы разработали систему управления проектами, позволяющую исправить существующую ситуацию. В первую очередь, как было сказано, необходимо было повысить иерархический уровень менеджера проекта в компании. Что мы и сделали. Далее формализовали и регламентировали взаимодействие подразделений в проекте. И затем (что самое главное!) выделили критические точки проекта – моменты его осуществления, когда неверное действие или промедление способно нанести ущерб компании.
Разумеется, компания и сама могла бы их обнаружить и привести свою деятельность в порядок. Но зачастую это трудно сделать, нужен взгляд со стороны. Необходим некто, кто начнет задавать вопросы, первым из которых будет: «А почему?». Иногда на него совершенно невозможно ответить, никто точно не помнит, когда начали поступать именно так. Мы так делаем, потому, что так «исторически сложилось». А можно ли делать иначе? А более эффективно?
Второй важнейший вопрос, который мы постоянно задавали своему клиенту: «Кто отвечает за результат?». Ведь часто за него никто не отвечает. Особенно это касается точек взаимодействия между разными структурными подразделениями. Внутри каждого отдела, как правило, все четко отлажено, формализовано, но эти процессы не связаны с общими целями проекта, работой других отделов.
По мере описания бизнес-процессов мы задавали эти вопросы и выясняли, что в некоторых точках часто бывают сбои: вот здесь непонятно, кто отвечает за результат, а здесь задание не выполняется вовремя только потому, что никто не заинтересован в его своевременности. В этой точке теряется информация, в той – нужно что-то кому-то передать, а оно не передается, здесь нужно принять решение, а оно не принимается своевременно.
Так стало понятно, где находятся критические точки проекта. Мы двигались по ним и выясняли, действительно ли проблема системная, решали, кто должен отвечать за результат.
Получилось три категории критических точек: результата, принятия решения и взаимодействия. Точка результата – это момент бизнес-процесса, когда должен быть получен какой-то конкретный результат. Например, с такого-то числа в течение трех дней должна произойти поставка. Если информацию о поставке менеджер проекта обязан передать сейл-менеджеру – это точка взаимодействия, если же сейл-менеджер принимает решение, оставлять груз на складе или передавать его заказчику, то это уже точка принятия решений. Любая критическая точка привязана к какому-то ответственному лицу.
Для компании каждая категория критических точек имеет разный вес. Поэтому и степень ответственности за ошибку должна быть разной, соответствующей цене вопроса. Таким образом мы построили систему демотивации, определив величину штрафов, которые могут быть взысканы с виновных лиц. Если человек не совершил вовремя какое-либо важное действие и это стало причиной сбоя работы компании, он должен быть наказан. Самые дорогостоящие ошибки – в точке результата, менее болезненные – в точке принятия решения и самые «дешевые» – в точке взаимодействия (то есть в точке передачи информации). Дискутировали, имеет ли право менеджер проекта принимать управленческие решения самостоятельно, в силу своего нового положения в компании? Было определено, что управленческие решения, цена которых до $100 тыс. включительно, находятся в компетенции менеджеров проекта, при большей сумме – ответственность передается другому лицу.
Тщательно был составлен список точек взаимодействия между подразделениями и перечень рисков, которые могут наступить, если ответственный проморгает свою обязанность.
Каждый риск был не только назван, но и описаны мероприятия по реагированию, определены сроки ликвидации последствий халатности ответственного за взаимодействие сотрудника. Стало также понятно, кто будет работать над «разгребанием» неприятностей и во сколько это обойдется компании.