Да все уже 100 раз про управление проектами написали

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

Типовые сложности

Сначала о главном и самом интересном – о проблемах с точки зрения подрядчика-исполнителя проекта автоматизации. Все методологии должны помогать избавиться от проблем еще до момента, как они — сложности — возникнут. Но в жизни так не бывает.



Вот типовые сложности, с которыми мы чаще всего сталкиваемся на проектах:

1. Рассинхронизация действий в комплексных проектах с участием нескольких подрядчиков.
   Проект стартовал, бюджеты утверждены, но по какой-то причине один из исполнителей вылетает с проекта или отстает по срокам. Всем остальным приходится в этот момент перераспределять ресурсы, больше вкладывать усилий в проект. Хорошо, если заказчик еще не выплатил полную сумму подрядчику, который выбыл из проекта, не завершив свою задачу, и в бюджете проекта есть средства для компенсации оставшимся подрядчикам дополнительных усилий.
   
   У нас были ситуации, когда приходилось очень сильно менять структуру управления проектом, переходить от водопада к гибридной методологии, буквально дарить дополнительные лицензии и интегрировать не запланированные заранее модули платформы Forward, чтобы закрыть дыры в функционале из-за отставания кого-то из смежных подрядчиков и сдать проект в опытную эксплуатацию в срок.
2. Неправильный выбор CRM-системы для телекома.
   Часто заказчик выбирает CRM по косвенным признакам, посмотрев презентации, оценив красоту интерфейсной части и отчетов. Но упускает при этом, какие типовые процессы есть в выбранной CRM, насколько она соответствует специфике телекоммуникационной отрасли.
   
   Например, при продаже необходимо проверять техническую возможность подключения по выбранному адресу, понимать, есть ли свободные порты, какая есть нагрузка на сегмент сети в целом. А выбранная CRM даже не знает о существовании такого процесса. Когда выясняется, сколько будет стоить доработать CRM под бизнес-процессы телекома, встает вопрос: «А не проще/дешевле внедрить сразу готовую и специализированную для телекома систему управления взаимоотношениями с клиентами?».
3. «Бесплатные» open-source решения.
   
   Если айтишники заказчика берутся за внедрение какой-то части IT-ландшафта, которая задействована в комплексной автоматизации, то может возникнуть проблема понимания объемов трудозатрат и бюджетов. Айтишник говорит менеджеру: “возьмем open-source, он бесплатный”, — подразумевая, что не надо платить за лицензии вендору. Менеджер слышит что-то типа «быстренько поставим вот эту штуку и она сразу заработает, да еще и платить никому не надо!»
   
   Возникает разрыв. Менеджер считает, что со стороны его айти-службы задача, почитай, выполнена. А фактически может требоваться интеграция open-source с другими информационными системами, большая настройка и изменение бизнес-процессов у заказчика. В итоге проект затормаживается, и мы оказываемся в ситуации из 1 пункта этого списка.
4. Ожидания по срокам.
   Раньше выбор информационных систем для биллинга осуществлялся IT-службой предприятия. Сейчас все чаще выбор производят подразделения, отвечающие за продажи и маркетинг. Отсутствие технического бэкграунда, распространение облачных сервисов и рост общей информатизации жизни создает иллюзию простоты. Никто не задумывается, что для текущей комфортной работы в бесплатном для обычных пользователей Gmail были затрачены ресурсы огромной организации в течение многих лет.
   
   Поэтому мы постоянно слышим, что ожидания по срокам внедрения биллинга 3-4 месяца. Редко какой заказчик оценивает объем работ в полгода или год.

Если бы я составлял ТОП подсистем, с которыми возникают разные проблемы при комплексных проектах, то это были бы:

• CRM,
• Service Desk,
• Техучет/инвентори.

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

Когда водопад обращается вспять

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

Начинаются проблемы

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

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

И сталкиваемся с жестокой реальностью в виде несоответствия ранее предоставленной документации с реальной ситуацией на местах в городах присутствия провайдера. Получаем сработавшие риски:

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

Перезапуск

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

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

Следование классической методологии не помогло выявить недостатки постановки ТЗ, и потребовалась полная переработка всех договоренностей с клиентом и переписывание всей проектной документации.

Пофлексили на корню

Обратился к нам клиент, желающий запустить своего виртуального оператора. Мы просчитали проект запуска MVNO разной степени самостоятельности от MNO. Клиент рассматривал проект, как диверсификацию бизнеса и не обладал достаточным опытом в телекоме. Бюджетирование проекта планировалось выполнять на основе высвобождающихся средств от основного бизнеса. При этом собственник желал работать исключительно по Agile, считая эту методологию максимально прогрессивной и подходящей для запуска нового бизнеса.

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

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

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

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

Выход из проекта, таким образом, тоже результат, хоть и не положительный.

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

Agile c ограничениями по срокам, бюджету и функциональности – WTF?!

Да, есть и такое. Заказчик может хотеть работать по Agile, но при этом зафиксировать жестко сроки, бюджет и функционал. У нас же это вызывает диссонанс.

Для нас работа по чистому Agile с клиентом подразумевает, что мы предоставляем команду, а заказчик берет на себя существенную долю трудозатрат по управлению проектом. Мы отвечаем за исполнение спринтов и операционное управление задачами. За общий результат проекта фактически отвечает руководитель проекта со стороны заказчика. Наш опыт говорит, что на получение приемлемого результата/MVP, проверки гипотез по какой-то функциональной области будущей информационной системы требуется 3-4 спринта. Это достаточно большой временной промежуток и трудозатраты. А помните, мы ранее говорили, что ожидаемый срок автоматизации сейчас 3-4 месяца? Нет, мы в общем не против, мы умеем работать с таким сроком, но не без помощи команды клиента.

У заказчика, который воспринимает Agile, как прогрессивную методологию, потому что она на слуху, другое понимание. Он хочет, чтобы мы назвали конкретные сроки, конкретный бюджет, чтобы мы управляли всем SCOPE проекта, но при этом чтобы это все происходило «по эджайлу».

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

Гибрид спасает?

Ситуация схожа с предыдущим кейсом – собственник желает запустить Full MVNO в дополнение к основному виду бизнеса. У клиента есть жесткие сроки, и проект запуска MVNO завязан на нескольких смежных проектах внутренней автоматизации.

Заказчик ставит существенные ограничения по бюджету, срокам реализации проекта и требует интеграцию систем Forward с внутренними информационными системами использующими СУБД Oracle. В дополнение к этому, т.к. запускается Full MVNO, требуется закупка, установка и конфигурация телекоммуникационного оборудования. Работа предстоит в связке с IT-командой заказчика и несколькими командами других подрядчиков.

Проект запускается, очень большая нагрузка на нашу команду. Приходится работать с переработками, очень плотно общаться с коллегами. Состав задач в спринтах меняется очень динамично, заказчик вовлечен в проект и флексит не меньше задач, чем добавляет.

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

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

Какие проекты мы не берем в работу?

Низкая проектная грамотность

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

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

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

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

Неадекватные требования

На этапе предпроекта и составления ТЗ можно понять, насколько адекватны требования за заявленный бюджет. Неадекватное отношение к срокам, деньгам – это важный звоночек и управленческие риски, которые потом перетекут в проектные риски, потому что ожидания заказчика не будут оправданы. Качественно завершить такой проект очень тяжело.

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

Еще один пример: запускается MVNO, требования к функциональности информационной системы исчисляются несколькими тысячами пунктов. Эти требования скомпилированы на основании опыта операторов по всему миру и плохо соотносятся с условиями ведения бизнеса данного оператора. Дополнительно собственники подразумевают, что запуск MVNO – это некий стартап, в который вкладывать большой объем средств не планируется. Наш опыт говорит, что нормальным в этой ситуации был бы список из 100+ требований. Чтобы просто разобрать эти тысячи требований и дать по каждому ответ с указанием на документацию по платформе Forward – это трудозатраты, которые не окупятся, судя по увиденному нами отношению заказчика к бюджетированию проекта.

Низкая квалификация технических специалистов заказчика

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

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

В следующей статье – о рисках

Большие корпоративные проекты – это всегда финансовые и репутационные риски. Так что мы выпустим вторую часть статьи и расскажем в ней о рисках с точки зрения компании-подрядчика по автоматизации.

А пока приглашаем вас в комментариях поделиться вашим опытом о сложностях и проблемах на проектах!