17 авг 2022

Что внедрять в первую очередь — методологию или информационную систему управления проектами?

Для кого:
  • Руководители проектного офиса
  • Куратор проектной деятельности
Знания и навыки:
  • Построение проектного офиса
  • Управление проектами
  • Управление изменениями
  • Управление ресурсами
  • Управление ИТ-проектами
  • Настройка инструментов управления
Время на чтение:
  • 7 минут

Проектная методология — целостный набор правил, логика взаимодействия участников проектов для различных объектов управления (проект, программа и т. д.), роли и распределение ответственности между ними и многое другое.

Информационная система управления проектами (ИСУП) — информационная система, которая позволяет автоматизировать процессы проектного управления (например, подготовить управленческую отчетность по проектам).

PMLogix

Есть три стратегии внедрения:

  • сначала ИСУП,
  • сначала методология,
  • параллельное внедрение.


Рассмотрим отдельно каждую из стратегий, оценим их преимущества и недостатки.

 

Стратегия 1. Сначала ИСУП

ИСУП — более понятный предмет для внедрения. Ни у кого не возникает вопросов, что такое информационная система. ИСУП — что-то условно материальное. Мало кто спорит с ее нужностью, чего не скажешь о процедурах, регламентах, правилах, которые являются основными продуктами разработки и внедрения методологии. Поэтому очевидные плюсы ИСУП — простота и наглядность результата (например, управленческий отчет можно увидеть в системе).

 

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

 

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

 

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

 

В чем недостатки такой стратегии?

 

1. Когда мы занимаемся автоматизацией, мы осознанно запрашиваем ресурсы под конфигурацию и последующую доработку программного обеспечения подрядчиками. Чаще всего ресурсов на оптимизацию процессов, на их доработку и корректировку попросту нет, как и на процедурную и содержательную расчистку текущей организации проектной работы. В таком случае мы можем начать «автоматизировать бардак» — использовать некачественную/неактуальную информацию, кривые и неэффективные процессы. Мы перенесем «бардак» из офлайна в онлайн, при этом не добившись нужного эффекта и дискредитировав саму идею автоматизации вместе с проектным управлением.

 

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

 

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

 

3. Очень часто мы внедряем ИСУП как IT-проект, то есть привлекаем подрядчика, который только настраивает программу, обучает сотрудников использованию системы и устраняет баги. В его полномочия не входят вопросы приживаемости (проведение ретроспективы, сбор обратной связи и т. д.). Эта часть остается на стороне исполнителя, который часто либо не понимает важности этого аспекта, либо не обладает нужной экспертизой, либо не располагает необходимым бюджетом.

 

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

 

Вообще внедрение любой системы должно включать в себя стадию обеспечения приживаемости (т.е. перехода к реальному использованию системы), потому что ее отсутствие создает практически стопроцентную вероятность последующей неэффективности системы и её краха.

 

4. Методологические решения мы вынуждены принимать по ходу дела. И в связи с этим возникает много вопросов, например: что включает в себя объектная модель? что для вас значит программа и чем она отличается от проекта? что в себя включает жизненный цикл? Если проект направлен только на разработку и внедрение ИСУП, от него и не ожидается разработки методологии, на это не выделяется бюджет, в команде внедрения нет экспертов-методологов. Поэтому такие вопросы если и разрешаются, то практически «на коленке».

 

5. Также немалые риски связаны с прохождением внутренней системы контролей — на соответствие ИТ-архитектуре, требованиям по информационной безопасности, требованиям закупок и т. д. Эти корпоративные реалии, к сожалению, не позволяют сделать что-то работающее “quick&dirty” (быстро создать черновой работающий вариант) и принести пользу с помощью рабочего инструмента в короткий срок.

 

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

 

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

 

Стратегия 2. Сначала методология


Во-первых, разработка методологии означает то, что часть решений, принципиально важных для автоматизации, уже принята и формально закреплена: есть четкое понимание, что такое объектная модель, какие есть процессы, какие есть KPI для отчетности и т. д. Всё это — основа для составления реестра требований к системе, которые к тому же гораздо легче приоритизировать.

 

Главным результатом станет использование более четких критериев выбора информационной системы и, соответственно, его ускорение. А это подразумевает сокращение рамок проекта и его удешевление.

 

Кроме того, если есть методология, мы опираемся на согласованные внутренние распорядительные документы. Ответственность четко распределена среди участников проектной деятельности и потому она намного сильнее ощущается, чем если бы просто была закреплена в приказах, инструкциях или протоколах используемых при запуске ИСУП.

 

В чем недостатки такой стратегии?

 

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

 

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

 

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

 

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

 

Стратегия 3. Параллельное внедрение


Самый оптимальный вариант, однако тоже со своими недостатками, — это параллельное внедрение. Этот вариант медленнее, чем первый, однако заметно более эффективный.

 

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

 

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

 

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

 

В чем недостатки такой стратегии?

 

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

 

2. Методологические решения будут более медленными и тяжелыми в согласовании, чем IT-решения. Это приведет к тому, что, когда решения уже будут согласованы, придется переделывать IT-систему (поскольку, скорее всего, для ее первичной разработки мы будем основываться на временных решениях).

 

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

 

В заключение отмечу, что при выборе того или иного подхода необходимо учитывать ситуативные обстоятельства внедрения ИСУП.

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

 

Единственное, не стоит вести разработку IT-решения и методологии абсолютно параллельно, но независимо друг от друга (такое нередко встречается). Мудрой стратегией будет вести проект по двум направлениям, но с лагом во времени, чтобы сначала снять проблематику, согласовать цели, определить методологические решения, а далее уже заниматься IT-частью.

 

Если вы понимаете, что нет явного запроса на организационные изменения(решение принимается на уровне проектного офиса, а не выше), стоит начинать с ИСУП и дополнять ее точечными методологическими решениями.

 

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

Еще больше актуальной информации про полезные методы и инструменты проектного менеджмента, внедрения организационных изменений и ИТ-решений ищите в нашем Телеграм-канале: Уж&Ёж. Управление проектами. PMLogix

Авторы статьи:
Андрей Малахов
Прокомментировать статью
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Смотрите также:
13 Мая 2024
Что такое уровни управления
Уровни управления в организации — это ступени иерархической структуры, которая обеспечивает порядок, а также распределение ответственности и полномочий между сотрудниками. Во главе структуры стоит тот, кто управляет компанией: генеральный или исполнительный директор, которому подчиняются управленцы нижестоящего уровня. Менеджеры, стоящие “под” главой предприятия, контролируют следующий, также нижестоящий, уровень руководителей.
26 Апр 2024
Что такое проектный треугольник и зачем он нужен проджекту
Что из себя представляет проектный треугольник и как его применяют в  управлении проектами? Как использование этого инструмента позволяет объяснить заказчику, что качественный продукт, сделанный в короткие сроки, стоить дешево не может?  В чем отличия треугольника при использовании в гибких методологиях от применения в классическом подходе Waterfall?
16 Апр 2024
Что такое декомпозиция и чем она отличается от других видов планирования
Декомпозиция – это метод разделения большой цели, продукта, задачи, работы или процесса на маленькие части, этапы, подзадачи. Часто декомпозицию применяют для составления плана работ и контроля реализации большого сложного проекта. Как её применять, читайте в этой статье.
Подписаться на рассылку
Высылаем анонсы статей и полезные материалы
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

Комментарий успешно отправлен

Произошла ошибка при отправке. Попробуйте еще раз

Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена