что такое инициация проекта
Инициация проекта. В чем суть нового проекта? Часть 3
Целью инициации проекта является получение обязательства начать проект. Вы хотите, чтобы клиент или спонсор могли принять обоснованное решение о переходе на этап планирования.
Как правило, первым шагом в инициации проекта является назначение менеджера проекта. В некоторых случаях руководитель проекта может быть назначен в проект после его утверждения.
Во время инициации проекта вы определяете проблему, которую должен решить проект, и собираете всю сопутствующую информацию. Как только у вас есть первоначальное определение проекта, пришло время подготовить устав проекта, документ, который формально описывает проект и излагает полномочия менеджера проекта.
В этой главе мы рассмотрим ключевые элементы определения проекта и что входит в устав проекта на стадии его инициации.
Кто такие заинтересованные стороны проекта
Термин «заинтересованная сторона» означает конкретного человека или группу людей, которые заинтересованы в результатах проекта. Это может быть клиент, отделы, влияющие на проект, и даже люди, которые работают над задачами проекта.
Для руководителя проекта необходимо знать важность, влияние и заинтересованность заинтересованных сторон в проекте. Вам также необходимо знать их ожидания и вклад в проект. Таким образом, вы, как руководитель проекта, можете сосредоточиться на построении отношений с заинтересованными сторонами, которые оказывают наибольшее влияние на успех проекта.
Давайте рассмотрим основные виды заинтересованных сторон:
Иногда бывает сложно определить, кто является заинтересованными сторонами для вашего проекта, а также оценить, какие из них наиболее важны, и как эффективно с ними работать. Вот где пригодится документ анализа заинтересованных сторон или реестр заинтересованных сторон.
Цели, Требования и Интересы
ERP: инициация проекта. Альтернативный взгляд со стороны клиента
UPD: меня обвинили в плагиате, поэтому я вынуждена изменить название статьи. В самой статье изменений не произошло.
Дисклеймер: пост не претендует на объективность. Исключительно субъективное мнение на основании не слишком большого опыта внедрения ERP на стороне клиента. В статье описаны некоторые действия, которые желательно сделать до заключения контракта на внедрение ERP-системы.
Что такое «консалтинг»?
Предлагаю для начала определиться с терминологией.
Мне кажется при внедрении ERP представители бизнеса несколько по-иному понимают понятие «услуги консалтинга», чем представители компании-исполнителя. Давайте попробуем внести ясность. Определение из Википедии:
«Консалтинг (консультирование) — деятельность по консультированию руководителей, управленцев по широкому кругу вопросов в сфере финансовой, коммерческой, юридической, технологической, технической, экспертной деятельности. Цель консалтинга — помочь системе управления (менеджменту) в достижении заявленных целей.»
Так вот, цель проекта – внедрение ERP-системы. Именно это прописывается в договоре с исполнителем. В рамках проекта внедрения консультанты НЕ будут выполнять аудит и реинжиниринг бизнес-процессов как таковых.
В рамках проекта внедрения ERP консультанты выполняют анализ существующих процессов и пожеланий пользователей для их корректного отражения в новой системе, не более того. Операции, выполнение которых планируется вне системы, вообще выпадают из зоны их внимания.
Как правило, всесторонний аудит процессов с целью достижения определенных бизнес-показателей (например, сокращение товарных остатков, сокращение времени поставки клиенту) выполняют консалтинговые компании другого профиля по отдельному договору и за отдельные деньги.
Действительно, при внедрении ERP происходит «оптимизация…, повышение…, минимизация…» бизнес-показателей, но это происходит только, если выполняется хотя бы один из пунктов ниже:
Что нужно сделать ДО заключения договора с консалтинговой компанией
Нужно простыми словами пояснить и бизнесу, и компании-исполнителю зачем необходима ERP–система. Ведь что-то же сподвигло рассматривать вопрос о ее внедрении? Что именно? Зачем? Необходимо сформулировать эту мысль и изложить на бумаге.
На предприятии все должны понимать для чего внедряется новая система, какие улучшения она должна принести на предприятие, насколько сильно изменения коснутся конкретных подразделений бизнеса.
В этом случае бизнес будет понимать ради чего вся эта свистопляска с дополнительной нагрузкой в виде общения с консультантами, изучения толстых документов с непонятной терминологией, необходимости изучения нового софта и т.д. Особенно это актуально для подразделений, в чьей работе не предвидится каких-либо кардинальных изменений и для них смена самописки на промышленную систему выглядит как мена шила на мыло. На одних только вопросах и стенаниях консультантам типа «А зачем вы внедряете нам свою систему?», «А нас всех уволят после внедрения вашей системы?», «У нас все хорошо работает, не надо нам ни чего внедрять!» и т.д. можно сэкономить значительное количество дорогого консультантского времени.
Изначально сформулированная цель будет полезна и исполнителю. Это поможет консультантам понять вектор, в направлении которого заказчик желает развиваться, применять «правильные» критерии при выборе конкретного варианта решения задач из нескольких возможных, упростит налаживание продуктивных контактов с пользователями.
Поэтому перечень требований к функциональности системы:
Альтернатива референсу — демонстрация каких-либо важных процессов в уже настроенной системе. У компании-интегратора могут быть свои учебные и/или тестовые базы, на которых они могут продемонстрировать какие-либо типовые процессы.
Даже если будут показаны / продемонстрированы процессы, совершенно не пригодный для использования на проекте, но при этом у заказчика появятся более конкретные вопросы относительно реализации, и он получит исчерпывающие ответы на эти вопросы – это не будет бесполезной тратой времени.
Инициация проекта
Инициация проекта – это стадия проекта, на которой выполняется определенный набор работ для его успешного запуска. В частности, происходит четкое определение целей и задач проекта, назначение руководителя проекта, разработка устава, идентификация участников и заинтересованных лиц.
Очень, очень часто этот этап жизненного цикла проекта начинающему руководителю проекта кажется неважным и ненужным. Действительно, о чем тут думать, начальство сказало делать – значит, надо делать. Скорее бежать планировать, например, а то и сразу выполнять. И это одна из самых больших ошибок, какую только можно сделать.
Что именно происходит на этапе инициации проекта в конкретной компании, чаще всего зависит от самой компании. Где-то решение о том, что “проекту быть” уже принято, и нужно только подготовить устав, а где-то именно на этом этапе происходит оценка целесообразности проекта и принимается решение после подготовки устава. Но в любом случае, это та контрольная точка, после которой будет понятно, делаем мы проект или нет, и которая позволяет формально этот проект начать.
Если обобщить, то инициация проекта – это момент, когда еще можно остановиться и подумать, а делать ли проект вообще? Когда еще не затрачены деньги, время и усилия. Когда вашей репутации хорошего руководителя проектов еще не нанесен урон, который потом будет сложно исправить. После того, как устав подписан, а руководитель проекта назначен, что-то решать уже поздно.
Что бы не входило в инициацию проекта в вашей компании, на этом этапе необходимо четко сформулировать и описать основную информацию о проекте, сделать обоснование его целесообразности, описать конечный продукт и результаты проекта. То есть формализовать всю информацию, которая позволит понять, а нужно ли его вообще делать, этот проект. Важно понимать, что причин инициации проекта может быть всего три: сокращение расходов, увеличение прибыли, снижение рисков.
Также стадия инициации проекта – это возможность сделать так, чтобы основные заинтересованные лица понимали, о чем этот проект вообще и какую роль они в нем будут выполнять, не обольщались тем, что вы все сделаете идеально и придете с готовым результатом, и осознали, что чуда не будет, и им тоже придется в этом участвовать.
Вся перечисленная информация кратко фиксируется в уставе проекта, который обычно содержит не более двух-трех страниц. Как написать хороший устав проекта. Устав является первым документом, официально «запускающим» проект, а также определяющим руководителя проекта.
Так же советую даже в наш век высоких технологий, когда распечатанные документы уже не так популярны и намного проще согласовывать устав проекта через электронную почту, все же хранить у себя распечатанный и подписанный устав. Так надежнее, ну и важность любой бумажки при подписании автоматически повышается в разы.
Как расценивается инициация проекта с позиции менеджера проекта? С точки зрения профессиональной этики именно на этапе инициации он должен честно ответить себе на вопрос, можно ли этот проект сделать в рамках имеющих ограничений по времени, деньгам, ресурсам и проч.? Если уже сейчас понятно, что нельзя, самое время поднять руку и с цифрами в руках объяснить, почему нельзя. Помните, подписывая устав, вы берете на себя профессиональную ответственность за выполнение того, что в нем указано в рамках тех ограничений, которые там указаны, и с этого момент неуспех проекта – это ваш личный неуспех.
Крайне желательно именно здесь, на берегу, договориться о том, что от вас ждут, как от руководителя проекта, какие полномочия у вас будут, и как будут измеряться результаты. Это не всегда можно внести в устав, но нужно хотя проговорить этот вопрос со спонсором, чтобы не осталось недопонимания.
Пример инициации проекта из реальной жизни
Итак, я живу в квартире уже 15 лет, краска на потолке облупилась, батареи старые и вообще мне некомфортно. И я думаю, что неплохо бы затеять проект “Ремонт в квартире”. Как это будет происходить?
После того, как я все это придумала-посчитала-прикинула, я все это аккуратно записываю в один документ, проверяю на адекват и решаю, готова я за это взяться и беру ли на себя ответственность сделать все в срок и в бюджет, учитывая все существующие факторы. Если да, то подписываю бумажку, даю ее же на подпись мужу и родителям, и вуаля – проект начат!
Вот как-то так. Помните, что пропуск стадии инициации и начало работ без формальных полномочий и подписанного устава – ошибка, которая в 99% случаев приведет к перерасходу денег, трате времени и не улучшить вашу карму, как руководителя проекта.
Опыт постановки проектного управления
Опыт постановки проектного управления
Руководитель проектного офиса в ЗАО «АЭМ-Технологии». Работала в различных компаниях Санкт-Петербурга и Москвы, в том числе OpenWay, PricewaterhouseCoopers, Orange Business Services (France Telecom), НИПК «Электрон». Выполняла различные проекты, в том числе по внедрению информационных систем, разработке стратегий, организационным изменениям, реинжинирингу бизнес-процессов, разработке методологии и внедрению проектного управления в производственных компаниях.
В общем случае, проект постановки проектного управления можно разбить на пять этапов (рис. 1.):
Ниже мы обсудим их последовательно.
Рис. 1. Этапы проекта по постановке проектного управления.
Этап 1. Зарождение идеи: зачем нам проектное управление?
Для ясности дальнейшего текста введем два определения:
Внедренец — тот, кто должен поставить проектное управление (независимо от того, сотрудник ли это самой компании или внешний консультант).
Инициатор — топ-менеджер или владелец компании, которая хочет поставить это самое проектное управление.
Когда компания (точнее, кто-то из руководителей или владельцев) решает поставить проектное управление, за этим решением может стоять целое множество разных предпосылок. Соответственно, цели могут отличаться весьма значимым образом, при том что название будет одно: постановка проектного управления.
На мой взгляд, не бывает хороших и плохих целей при постановке инструментов управления, равно как и хороших или плохих условий и ограничений. Важно, чтобы картины мира участников не расходились между собой, а также с ожиданиями и возможностями самих участников. Разумеется, цели должны быть измеримыми и критерии их достижения должны быть понятны всем сторонам еще на начальном этапе.
Таким образом, на первом этапе, еще до старта проекта, внедренцу (как из самой компании, так и внешнему) необходимо ответить на вопрос: как руководители компании пришли к решению использовать проектное управление? Причем осознать ответ на этот вопрос важно не только для внедренца, но и для самого инициатора, поскольку нередко он не понимает, что же послужило реальным стимулом для такого намерения. Это только в красивых книгах по менеджменту все решения, принимаемые руководителями компании, обоснованны и разумны. Ответы на этот вопрос могут быть самыми неожиданными. Ниже в шутливой манере приведены самые частые предпосылки к постановке проектного управления.
Нередко мы имеем дело с действием одновременно нескольких предпосылок. Причем я ни разу не видела случая, когда и аудиторы посоветовали, и руководитель компании осознал необходимость постановки проектного управления, и на самом деле надо. Чаще всего встречается сочетание из двух факторов:
Короткое резюме этапа 1: По сути, в результате этого этапа стороны должны познакомиться друг с другом, присмотреться и сделать первичное исследование сложившейся ситуации и идеи использования проектного управления. А также понять, зрелое это решение (и насколько обдуманное) или эмоциональное и стоит ли вообще дальше идти в этом направлении.
Этап 2. Обсуждение идеи: что же конкретно мы хотим получить?
Понять предпосылки и исходные мотивы руководства компании недостаточно для запуска проекта. Дальше встает вопрос о конкретных целях внедрения проектного управления. Что хотим получить в результате постановки проектного управления? Как узнаем, что мы получили именно это? И чего нельзя допустить ни в коем случае?
И тут начинается сложно формализуемый очень интересный процесс. Для внедренца главная задача на этом этапе – не просто зафиксировать декларируемые задачи, но, что гораздо важнее, понять истинные цели постановки проектного управления, определить зазор между ними, оценить их выполнимость в условиях заданных ограничений.
На этом этапе важно «разговорить» инициатора внедрения, а последнему важно как можно более честно рассказать о том, что на самом деле ему нужно и что именно он ждет от проекта. По сути эта точка – первая встреча взаимных ожиданий и готовности. И первая точка возможных взаимных нестыковок.
Даже если у инициатора есть противоречия в его собственном представлении о желаемом (что случается весьма часто), нужно терпеливо выкладывать «кусочки мозаики» на стол и собирать всю картинку целиком. Справиться с известными противоречиями гораздо легче, чем с неизвестными. Не буду описывать случай, когда инициатор намеренно искажает информацию – в такой ситуации у проекта нет шансов. Думаю, нет смысла останавливаться на том, что вышеперечисленная информация (включая цели, ожидания и опасения) должна быть собрана со всех ключевых руководителей и центров влияния.
После того как цели и ожидания озвучены, задача обеих сторон – оценить готовность себя и второй стороны к реальным действиям. Здесь мне приходилось сталкиваться с заверениями:
«Мы действительно готовы к внедрению. Мы будем твердо настаивать на обязательности исполнения проектов по методологии для всех подразделений. Поддержка, полномочия – всё дадим».
На практике после первых шагов внедрения это часто выливалось в:
«Саботируют, не ведут проекты по утвержденной методологии? Нехорошо, ну поговори сама с ними еще раз».
Для успеха проекта жизненно необходимо понять реальную, а не декларируемую готовность и заинтересованность каждой из сторон. Понятно, что это непросто и инструментов для этого практически нет. Но тупиковых и не решаемых задач весьма немного. Вопрос, как правило, в цене решения. Причем для каждой из сторон.
В большинстве проектных методологий этапы 1 и 2 объединены в один – инициация проекта. Однако, на мой взгляд, этап 1 (знакомство и первичное исследование сложившейся ситуации и идеи использования проектного управления) необходимо выделять отдельно. По результатам этих этапов часто происходит формальное открытие проекта.
Короткое резюме этапа 2: В результате этого этапа стороны должны увидеть цели друг друга (причем как что нужно получить, так и чего никак нельзя не допустить), ожидания и возможности друг друга. И принять осознанное решение о том, нужны ли сторонам корректировки позиций или же пора в бой. В конце этого этапа часто очень не хватает возможности как-то явно убедиться, что все действительно одинаково друг друга поняли, видят общие цели и смогут вместе выполнить задачу. Распространенные инструменты, такие как устав проекта, соглашение о проекте или даже отчет об экспресс-обследовании организации, эту проблему не решают, а иногда и серьезно затуманивают реальное положение вещей.
Оценка реальной готовности компании к проектному управлению
На мой взгляд, одним из факторов успеха проекта постановки проектного управления будет проведение адекватной оценки уровня зрелости компании (хотя бы экспресс-оценки). Это обследование может быть проведено либо на этапе 2 (обсуждение идеи), что позволит лучше понять ситуацию as is и сформулировать адекватные цели проекта, либо на этапе 3 (детализация задачи). После этого необходимо сопоставить поставленные задачи с окном возможностей компании, а также ближайшими планами развития вовлеченных в проект ключевых отделов и сотрудников. Ибо, к сожалению, очень часто компании ставят себе правильные цели исключительно в расчете «на вырост» или ждут динамику развития проектного управления, характерную для совсем другой отрасли. Нередко компании хотят то, к чему сами будут готовы (дозреют) лет через пять – такое тоже бывает. И ведь желание правильное, цель верная, только в текущих условиях проектное управление «не заработает».
Процедуры инициации проекта
Развитие управленческой культуры, к сожалению, не всегда идет поступательно равномерно. Например, к тому, что процессам планирования проекта нужно уделять внимание на протяжении практически всей его продолжительности, многие руководители уже привыкли. Но вот инициация проекта далеко не в каждом случае воспринимается как нечто значимое. Тем не менее, практика показывает, что усилия и время, потраченные на процедуры инициации, способны значительно повлиять на качество и результативность работы над проектной задачей.
Что является основанием для начала проекта?
По существу, инициатором проекта может выступить любой сотрудник компании, если он в этом усматривает необходимость и понимает, что в штатном операционном режиме эту задачу не решить, и она требует объединения усилий целой группы участников. Однако для одной категории работников инициация является обязанностью, а для других групп она всего лишь похвальная активность. Если встать на позицию финансового управления и системы бюджетирования, то, как правило, именно руководители центров финансовой ответственности и обязаны в основной своей массе выступать инициаторами. Назовем основные причины рассмотрения идей и их проработки на предмет запуска в проектную реализацию.
В глобальном смысле все проектные решения связаны с проблемами управления. И при рассмотрении стратегического контекста проблематизации решение уникальных задач носит характер либо реализации возникающих возможностей, либо исключения затруднений (проблем) более низкого уровня. Напомню, что под проблемой в управленческом смысле мы понимаем неопределенность или противоречие в процессе познания явления деятельности. Их устранение невозможно с позиции действующей концепции управления для принятия решения.
В этом суть и базис стратегического планирования – выстроить такую последовательность уникальных задач (проектов), реализация которых выведет компанию на устойчиво новое состояние и концепции управления и уровня развития бизнеса. Процесс инициации с идейного замысла может начинаться в регламентной процедуре подготовки к сессии стратегического планирования или же тактического бюджетного процесса, а может возникнуть спонтанно, ситуационно. Последнее крайне нежелательно, но с этим поделать ничего нельзя, таковы наши современные реалии, мир порой меняется гораздо быстрее любых планов.
Цели и задачи проектной инициации
Проектная инициация – это не один процесс, а целая их группа согласно стандарту PMI. Они формируют начальную группу мероприятий для обеспечения состоятельности самой проектной идеи и запуска ее проектной реализации. При этом уже на данной фазе выявляются и даже устраняются многочисленные риски, отработать которые на стадии инициации гораздо выгоднее, чем после старта проекта. Инициация метафорична фразе из поговорки «Семь раз отмерь!», поскольку планирование и исполнение, начавшись практически одновременно, после приказа о начале проекта становятся значительно более затратными.
Среди задач-результатов процессов инициации выделяются следующие.
Планирование проекта следует сразу за его инициацией, но между процессами планирования и процедурами инициации имеется обратная связь, возникающая, например, по итогам получения закупочной документации. Ниже представлена часть процессной модели PMBOK, на которой мы и наблюдаем прямые и обратные связи между процессами.
Выбор проектных инициатив
Предположим идеальный вариант развития событий, при котором практически все инициативы выдвинуты к ежегодному мероприятию, посвященному стратегическому планированию. То есть в штатном режиме все инициативы обработаны проектным комитетом. Заслушаны предварительные презентации, по наиболее значимым мероприятиям уровня направлений деятельности и выше разработаны бизнес-планы. По существу, разработка ТЭО, бизнес-планов, иных предварительных расчетов является подготовкой к серьезной групповой работе над проблемами управления и развития компании.
Начинается сессия стратегического планирования или иное мероприятие подобного типа, на котором отрабатываются существенные затруднения для движения компании вперед по канве видения и миссии. Выявленные проблемы предваряют планирование, дерево проблем порождает построение дерева целей. Как раз в это время процесс подходит к весьма важному моменту: к рейтингу проблем и целей подводится пул проектных инициатив, которые начинают состыковываться между собой как некие «пазлы». Ведь еще в момент рождения идей они уже в большей своей части соответствовали присутствующей симптоматике и, возможно, еще не выявленным, а только ощущаемым проблемам.
Когда синхронизация проблем, целей и инициатив произведена, команда управленцев переходит к формированию рейтинга инициатив на основе трех параметров: проблемности, важности и достижимости результата. Под проблемностью мы понимаем уровень проблем, которым соответствует предлагаемое проектное решение. Оно оценивается в ходе коллективной работы присвоением инициативе балльной оценки от 0 до 10. Чем выше оценка, тем выше проблемность инициативы.
Процесс присвоения рейтинга инициативам продолжается по критерию важности. Важность может складываться от нескольких параметров, в зависимости от предпочтений управленческой команды. Один из вариантов разграничения критерия важности предусматривает оценку актуальности инициативы, ее эффективность и объем целевой группы. Далеко не каждая инициатива, хоть и проблемная, требует реализации немедленно. Часто оценка эффективности инвестиций имеет значительно большее значение, и этого нельзя не учитывать. Тут как раз бизнес-планирование, которое выполнено предварительно, ТЭО и расчеты дают хорошее основание для принятия оценочного решения.
Что мы понимаем под объемом целевой группы? Состав и значимость заинтересованных в проекте сторон также очень важен и требует хотя бы субъективной экспертной оценки. Это могут быть непосредственно участники проекта: заказчик, инвестор, куратор, PM и т.д. К целевой группе относятся также и пользователи проектных результатов, заинтересованные в его успехе косвенно: кредитные учреждения, бюджет, клиенты, поставщики и т.п.
Далее вы можете посмотреть на пример таблицы расчета рейтинговой оценки инициатив. Веса в таблице расставлены так, как сочла группа руководителей одной из производственных компаний в ходе мозгового штурма. Это не является каким-то эталоном, но для сравнения предложенные соотношения можно взять.
Наконец, третьим большим критерием оценки выступает достижимость или реализуемость инициативы. Она тоже делится на параметры:
В настоящей статье мы осуществили обзор основных процедур инициации проекта. Нами определены основные цели и задачи этой работы, акцентировано внимание на инструментальной процедуре формирования рейтинга инициатив для отбора их в портфель проектов. По своему опыту я знаю, что генеральному директору, кураторам и РМ часто не хватает такой увязки проблем, стратегических целей и проектных инициатив в единый контекст решений, чтобы возникли правильные ориентиры развития. А в динамике реальных событий расставленные таким образом приоритеты небесполезны.