Портал №1 по управлению цифровыми
и информационными технологиями

Граница между изменением и проектом

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

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

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

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

Давайте посмотрим теперь на процедуры проведения изменений, которыми пользуются с другой стороны стены. Зачем они нужны? Но ведь они нужны ровно за тем же самым. Мы, при проведении изменений в ИТ-инфраструктуре, так управляем риском, используя формализованные процедуры регистрации, авторизации и оценки. 

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

  • Определив границу отвественности проектного офиса и отделив их этим от координаторов изменений мы всего-лишь создаем механизм определения конкретного ответственного лица, не более того. Этим видимое разделение должно ограничиться. Это не разграничение между подходами к выполнению преобразований.
  • При выполнении изменений и проектов мы соблюдаем формальные процедуры процессов управления изменениями и релизами. Эти требования носят общий характер: зарегистрировать, авторизовать, запланировать, выполнить и отчитаться/оценить. Это накладывает определенные корректировки на работу по планированию ряда проектных работ, но в силу прогнозируемости сроков и результата процесса это требование не является большой сложностью. Отказываться от этих требований процесса нельзя, т.к. эти процедуры защищают нашу инфраструктуру и наши услуги от разрушительного воздействия, причем на достаточно низком уровне.
  • Поскольку, в целом, проекты для организации дороже и критичнее чем простые изменения, в силу сложности и масштаба, то требование соблюдения проектных практик проектным офисом - рационально. Это решение позволяет управлять рисками на более высоком уровне, в т.ч. рисками организационного, а не технического характера. Более того, это позволяет сотрудникам, вовлеченным в оба процесса, лучше оценивать любые риски и привносить более мощные проектные приемы и в изменения, когда это становится необходимо.

Таким образом, нам удается и разрушить стену между "Это наш проект и мы будем выполнять его так как считаем правильным!" и "Это наше оборудование, где согласованное RFC?", и обеспечить, то что в ходе изменений любого масштаба услуги остаются под контролем.

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT