Руководство проектом со стороны заказчика

Содержание:

1.       Работа руководителя проекта от заказчика. Кто он вообще такой (образование, характер, компетенции)

2.       Компетенция руководителя проектов со стороны Заказчика и что нужно подтянуть

3.       Зачем для управления проектами руководитель со стороны Заказчика, и что, если его нет?

1.      Работа руководителя проекта от заказчика. Кто он вообще такой (образование, характер, компетенции)

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

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

2.      Компетенция руководителя проектов со стороны Заказчика и что нужно подтянуть

a)      Коммуникатор между командой проекта и пользователями системы.

Руководитель реализации проектов должен быть коммуникабельным. Важно, чтобы сотрудники компании относились к нему с должным уважением, а руководство Компании донесло до сотрудников, что РП на данном проекте представляет интересы Руководства компании.

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

b)      Контролер сроков по проектным задачам.

Как и у РП от Исполнителя, у РП от Заказчика должен всегда находиться под рукой план проекта. Для ведения плана проекта очень желательно понимать основы управления проектами. Для этого нужно ознакомиться с азами управления проектами, например, посетив курсы Project Management Institute, или изучив практики управления проектами. В настоящее время огромное количество информации (в том числе обучающих лекций) находится в свободном доступе. Руководству компании стоит позаботиться о выделении средств и времени на подготовку специалиста. В среднем на приобретение теоретических знаний понадобится около 20 часов – по два часа в день, в течение двух недель.

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

c)      Приёмщик результатов проектных задач.

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

Все результаты по проекту так или иначе проходят утверждение у РП со стороны Заказчика. В функции руководителя проектов входит решение конфликтов при приемке результатов проектных задач пользователями системы.   

3.      Зачем для управления проектами руководитель со стороны Заказчика, и что, если его нет?

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

А что ожидать от проекта, если такого специалиста не будет. Первое – РП со стороны Исполнителя постоянно будет обращаться непосредственно к Руководству компании по самым тривиальным вопросам. А таких вопросов будет много: от предоставления контактов сотрудников до решения конфликтных ситуаций. Также никто не застрахован от недобросовестного Исполнителя, который не достигнет целей проекта в итоге.

Наличие должности руководитель проекта со стороны Заказчика существенно снижает риски провала проекта. Руководство компании более уверено в результатах проекта. По ходу проекта часто появляются смежные бизнес-процессы подлежащие автоматизации, в задачи руководителя проектов входит оценка необходимости такой автоматизации. Часто РП выявляют скрытые проблемы как в бизнес-процессах, так и у сотрудников компании.

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

Не стоит экономить на повышении компетенций руководителя проектов. По окончании проекта такой сотрудник станет основным носителем знаний по внедрённой системе и её популяризатором.

Специалист компании «Кодерлайн»

Евгений Еленко

• 

  Подгорный Денис
  Специалист проектного отдела

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

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

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

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

РП со стороны заказчика должен участвовать на всех этапах проекта. На его плечи ложатся 4 ключевые обязанности:

1. Мониторинг хода исполнения работ проекта, прогнозирование отклонений и принятие своевременных мер по их устранению.
2. Координация коммуникации между всеми участниками проекта и заинтересованными сторонами.
3. Обеспечение согласования проектных документов.
4. Управление ожиданиями ключевых пользователей.

Любой проект внедрения 1С на предприятии состоит из нескольких этапов, и на каждом из этих этапов у руководителя проекта со стороны заказчика имеются свои важные задачи. Рассмотрим их.

Этап отбора подрядчика

Оптимально, если РП со стороны заказчика изначально проводит отбор потенциальных подрядчиков для исполнения проекта. На этапе подбора РП оценивает всех кандидатов и определяет, насколько их подход к работе и методы реализации совпадают с мнением заказчика.

Цель отбора – найти подрядчика, который четко понимает, что нужно заказчику, в какие сроки и в каком объеме, а также обладает всеми необходимыми ресурсами для исполнения заказа в соответствии с планом.

Этап обследования

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

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

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

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

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

Этап моделирования

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

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

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

Этап реализации

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

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

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

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

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

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

Ну и, естественно, РП от заказчика должен быть человеком, который глубоко погружен в проект. Он должен «гореть» им, внимательно изучать документацию и к финалу проекта знать систему ничуть не хуже подрядчика. Важное значение имеет личная заинтересованность РП в успешном завершении проекта и запуске системы 1С, чтобы все бизнес-задачи были решены, а инвестиции (часто весьма солидные) – оправданы.

____________________________________

Автор статьи: Денис Подгорный – специалист проектного отдела.
Дата публикации статьи 01.06.2023.

Подпишитесь на нашу рассылку
и получите еще больше статей от экспертов по 1С!

Хочу сказать про такую важную позицию в любом проекте, как руководитель проекта (PM — по ненашенски project manager) со стороны заказчика. По  опыту (не скажу что он очень обширен, но кое-что бывало в моей профессиональной жизни), бывают такие вот проблемы и проблемки:

1. Если он слишком слабый…

Бывает, что человек, поставленный РМ-ом от заказчика слишком слаб и не имеет рычагов для воздействия на
других сотрудников предприятия. Это грозит существенным растягиванием проекта, с некоторой вероятностью может сделать проект невозможным. И уж точно будет куча проблем связанных с коммуникацией — получением информации от пользователей, утверждением подготовленных техзаданий, приемкой работ. Не говоря уж про волнующий момент старта новой системы.

2. Если он слишком сильный…

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

3. РМ, нанятый со стороны, под проект Я встречался и с таким подходом. Когда в компании-заказчике понимали, что людей, которые могли бы заниматься проектом с достаточным погружением нет, и нанимали внешнего специалиста, которому ставилась конкретная задача — вести проект и внедрить систему. Мотивация самая простая: оклад + бонус. Оклад на время контракта (планируемый срок проекта + 20% времени), бонус в размере чуть ли не половины оклада за весь этот срок. Бонус — только в случае, если проект будет запущен. По большому счету, вариант отличный. Для большой компании хороший ход. Один минус — руководитель проекта человек чужой, он с одной стороны не в курсе многих особенностей работы компании, и не может ответить на вопросы сам. С другой стороны — у него нет авторитета, наработанного уважения в организации, поэтому ему очень сложно влиять на сотрудников компании, требовать с них выполнения сроков и так далее.

4. Если он слишком высоко

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

С одной стороны, здорово конечно — возможности влияния, все рычаги воздействия на коллектив, всё в наших руках. Какие минусы? Ну, во первых — многие участники испытывают робость, общаясь «с сами». Пусть даже «сам» дал свой личный номер сотового, и уверил что можно звонить ему в любое время дня и ночи, и все равно — и все равно, все себя чувствуют слегка некомфортно. Ну еще бы — грузить своими рабочими момента солидного дядечку, лет за 50, владельца большой компании, занятого и делового. А рабочих моментов, текучки, гораздо больше, чем по настоящему стратегических вещей, требующих вмешательства птицы такого высокого полета.

И второй момент — он, конечно, очень занят. У него куча дел, встречи и переговоры, решение вопросов развития бизнеса. И у него часто нет времени погрузиться в дела проекта, даже при большом желании. Ну нету и все тут!

Важное! Есть малые проблемы — будут и большие. Одним из самых сложных этапов в проекте является внедрение — это кульминация всего, что было сделано. В этот момент происходит столкновение двух реальностей — системы, которую сделал исполнитель, и ожиданий от системы, которые есть в голове у заказчика. В этот момент очень много требуется от людей, влияние человеческого фактора огромно. Сотрудникам предприятия надо переучиваться, осваивать что-то новое (а этого ведь никто не любит). На этом этапе им будет сложнее всего, и если на ранних этапах проекта (обследование, интервью, подготовка задания на разработку), были проблемы — на этом этапе проблемы будут с вероятностью 100%, все что раньше происходило, усилится.

Если подвести итог, главные требования к PM (сугубо мое личное мнение):

Он должен быть!

Ага, именно так ) Без него проект будет идти абы как, и исполнитель не может взять на себя его функции. Так же как не может руководить сотрудниками заказчика в стиле «ну ты им скажи, чтобы они все делали». На каком основании — ведь исполнитель, не начальник в чужом доме (у клиента), исполнитель будет командовать и распоряжаться?

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

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

.

• Главная
•  > 
• Продукты и услуги
•  > 
• Комплексное внедрение системы
•  > 
• Методика внедрения

Организационные задачи Заказчика на проекте

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

• Владелец проекта. Утверждает требования к системе, принимает решения о финансировании работ и о приемке работ.
• Руководитель проекта. Осуществляет организационные мероприятия со стороны Заказчика и обеспечивает необходимые взаимодействия на проекте. Должен обладать необходимыми полномочиями для организации работ сотрудников предприятия. Загрузка 3 ч в день.
• Менеджер проекта. Выполняет операционный контроль выполнения задач проекта и обеспечивает документооборот. Загрузка 3 ч в день.
• Рабочая группа проекта (РГ), состоит из ключевых руководителей подразделений, входящих в рамки проекта. Загрузка 1-2 часа в день. Функции группы:
• Выработка требований к системе.
• Предоставление материалов для работ Исполнителю.
• Оценка методических решений, анализ и согласование проектной документации.
• Заключение о результатах работ.
• Оперативная группа ИТ-специалистов (ОГС). Загрузка – полная, 8 часов день. Функция группы
• Организация работы пользователей, контроль за выполнением регламентов и рабочих инструкций.
• Методическая помощь пользователям и эскалация вопросов на уровень Исполнителя при необходимости (обратная связь).
• Контроль правильности эксплуатации базы данных и программных средств, администрирование системы, корректировка прав доступа.
• Ключевые пользователи. Из всех пользователей по каждой подсистеме, отделу выделяются пользователи, наиболее ответственные и способные к обучению. В дальнейшем эти пользователи с одной стороны участвуют в выработке требований к системе, и являются центрами компетенции по системе в своем отделе.

Выделение человеческих ресурсов предприятия – рабочего времени персонала на проект, и мотивация персонала – важнейшая задача Заказчика.

Практический опыт показывает, что  внедрение автоматизированной ERP-системы – это на 80% проект организационных изменений на предприятии, и только на 20% – проект установки, доработки и настройки программ!

Распределение трудоемкости проектных работ (в абсолютном выражении) на стадиях:

• Функциональное моделирование: Исполнитель 50%, Заказчик 50% (выработка требований, анализ и согласование результатов).
• Функциональные требования на доработки: Исполнитель 70%, Заказчик 30% (выработка требований, анализ и согласование результатов).
• Реализация: Исполнитель 90%, Заказчик 10% (участие в испытаниях, анализ результатов испытаний).
• Ввод в действие (пусконаладка): Исполнитель 30%, Заказчик 70% (ввод и выверка исходных данных).
• Опытная эксплуатация: Исполнитель 20%, Заказчик 80% (работа пользователей в системе).

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