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

Вопрос из зала: разница между изменением и проектом

Опубликовано 20 мая 2012
Рубрики: Вопрос из зала, Управление изменениями
Комментарии

Постоянный участник дискуссий на нашем портале Александр Пешков спрашивает:

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

Если первое, все понятно — можно установить пороги и разделять.

Если второе — тогда проектами становятся только те разработки, которые изменяют пользовательские функции или параметры качества. Здесь нюансы — какие именно параметры и функции? Можно ли считать пользовательскими функции консоли администратора приложения, к примеру?

Какая у вас практика, и какие есть плюсы/минусы у этих подходов?

Каков процент проектов в общем объеме изменений, в первом и втором случаях?

Также по теме:

«VAP: Управление изменениями и конфигурациями в ИТ»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 25

  • Дмитрий Исайченко

    «F vj»

    Рука дрогнула...

    А наш вебинар «Управление изменениями и релизами: один или два процесса?» не даёт ответ на этот вопрос? Или этот ответ неубедителен?

  • Victoria Golubeva

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

  • Andrey Kapustin

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

    Те изменения, которые выбиваются размерами из общего потока, оформляются под названием «фаза проекта» и может выпоняться по сути как отдельный проект с выделенным руководителем/ответственным. При этом критериями выделение доработки в отдельную фазу:

    — существенное кол-во ресурсов на реализацию

    — внешние изменения для пользователя НЕ определяют организации фазы, т. к. к примеру рефакторинг/редезайн

  • Andrey Kapustin

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

    Те изменения, которые выбиваются размерами из общего потока, оформляются под названием «фаза проекта» и может выпоняться по сути как отдельный проект с выделенным руководителем/ответственным. При этом критериями выделение доработки в отдельную фазу:

    — существенное кол-во ресурсов на реализацию

    — видение Заказчика данного изменения как существенного/крупного: например кардинально меняется бизнес-процесс

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

    «Какая у вас практика, и какие есть плюсы/минусы у этих подходов?»

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

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

    «Каков процент проектов в общем объеме изменений, в первом и втором случаях?»

    90% по первой схеме, 10% нет.

    В 10% входят крупные изменения, на которые пока не удалось выбить денег, но по которым ведется работа с Заказчиком: что без этого будет плохо.

  • Вадим

    еще один критерий — необходимость привлечения внешних (по отношению к внутреннему ИТ) ресурсов

  • Станислав Уштей

    Могу предложить взглянуть на проблему с другой стороны:

    Это два разных процесса. Смотрим ITIL для процесса управления Изменениями и смотрим PMBOK для процесса управления проектом.

    Могу заверить, что при детальном рассмотрении получатся разные производимые продукты/сервисы, в также: цели, решаемые задачи, исполняющие роли, исполняемые документ и прочие артефакты.

    Другой вопрос – распределение ответственностей между разными командами, ролевыми группами или оргподразделениями (по другому «раздел поляны»)

    Пример: Мы можем создать институт менеджеров изменений, при этом поручить им :

    1. Общение с бизнесом в рамках решения вопросов, связанных с изменением информационного решения (ИР) – роль «менеджер изменений»;

    2. Владение ИР и обеспечение их целостности при изменениях – роль «бизнес-архитектор»;

    3. Организацию сопровождения при приеме ИР в промышленную эксплуатацию;

    4. Управление уровнем сервисов в рамках поддержки и сопровождения ИР (как бы считая ИР -сервисом) – роль «менеджер сервиса»

    5. Контроль и управление проектом при реализации изменений ИР – роль «руководитель проекта».

    Видно, что этому коллективу отданы: и процесс управления изменениями, и процесс управление уровнем сервиса, и процесс управления проектами.

    Понятно, что это пример и разделить можно и по другому.

    При этом вопросы о масштабах изменения или стоимости проектов тоже будут решены, но уже как производные от процессов и ответственностей конкретной команды.

    • Vladimir Lyaleko

      У меня вот при детальном изучении проектной методологи RRINCE2 сложилось прямо противоположное представление. Изменение по сути частный случай проекта. Это отчасти подтверждает раздел 1.3 книги Service Strategy где описывается BPM Guidens.

      • Станислав Уштей

        На него можно смотреть как на частный случай при функциональном подходе, когда люди что-то делают. Нельзя возразить против того, что для проведения любого изменения нужен проект — «мини», с трудоемкостью 1 ч/д или «макси», с трудоемкостью 10000 ч/д

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

        С моей точки зрения — очень важно различать деятельность организационно-штатного подразделения (см. пример) и ролевое исполнение процессов. Во втором случае получается более глубокое понимание деятельности сотрудников компании

        • Vladimir Lyaleko

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

          Если посмотреть 7 процессов PRINCE2, то они фактически представляют собой расширенный жизненный цикл изменения. Мапинг сделать очень просто. Более того, в методологии отдельным разделом написано про адаптацию, мол управление проектами может быть адаптированно для изменений любой сложности! Принципы управления похожи, цели ещё более похожи! Компетенции зависят от задачи...

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

          Про организационную деятельность и ролевое исполнение процессов полностью согласен.

          • Станислав Уштей

            Очень правильно сказано – абсолютно с Вами согласен.

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

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

            Мне идеи BPM симпатичны тем, что они позволяют использовать для построения EA или отдельных систем управления компании различные методологии и их framework-и, а самое главное избегать зависимости от них и их создателей. Обсуждаемый вопрос великолепный тому пример: как только мы встали на что-то жестко-ограниченное: PRINCE2 или на ASAP/RUNSAP — сразу начинается «путанится», с которой и связан обсуждаемый вопрос.

            При этом , я на пример, с удовольствием использую ASAP/RUNSAP, чтобы выстроить операционные процессы управления жизненным циклом Информационного решения, а вы вот PRINCE2 наверное

    • Alexander Peshkov

      Меня не покидает мысль о том, что мы все говорим о том, что халва — сладкая. Действительно, есть цель — проведение изменения существующей услуги, либо ввод/вывод услуги. Есть инструменты — управление изменениями, или проектная методика. Насколько я себе слабо представляю PMBoK — все об одном и том же, на выходе проекта будет тоже самое, что и на выходе изменения — некие функции. Вариант назначения в проектный блок по признаку стоимости имеется, и его можно применять, но как я вижу, второй вариант пока что не применяется (это относение к проекту изменений, результатом которых будет являться изменение внешней спецификации услуги). Кстати, такой вариант, с моей точки зрения, сильно обрадовал бы проектный офис, так как при большое количество изменений выдавалось бы именно туда, так как практически любое изменение отражается на внешней спецификации (ну, а иначе, для чего его делать). Возможно даже, что способ разделения проектов и изменений через их стоимость является наиболее простым в использовании...

  • Pavel Solopov

    А может быть Изменение это цель, а Проект способ достижения цели?

    • Станислав Уштей

      Тут можно запутаться, так как цель изменить Информационное решение (ИР) конечно общая и для проводимого проекта, и для проводимого изменения.

      Если мы работаем в процессном поле то можно увидеть разницу:

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

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

      P.S. Коллеги, я понимаю, что специализированные методологии управления проектами замахиваются именно на знание того, что именно они создают. Я в своих рассуждениях опираюсь на практики BPM и ITSM

      • Pavel Solopov

        менеджер проекта может вообще не знать, что он создает

        Что-то у меня большие сомнения в результатах от такого проекта.

        Это похоже на наши госпроекты. Где главное не дорога, а количество уложенного асфальта.

        • Станислав Уштей

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

    • Олег Скрынник

      Ну, началось...

      Предлагаю заканчивать прелюдию и переходить к главному вопросу — а что такое «проект»?

      Это ведь тоже основополагающее понятие, как и «сервис». Без определения термина дальше никак 🙂

      • Роман Журавлёв

        Управление проектами — это сложный дорогой способ управлять изменениями. Проект(ы) — это изменение (-ния), проводимое (-мые) с применением указанного способа.

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

        Отношение границ ИТ-проектов и ИТ-изменений действительно блестяще описано в вебинаре ДИ, слайды 8-10, лучше не скажешь.

        • Олег Скрынник

          Предлагаю тему считать закрытой.

          (наконец-то пришёл лесник, который всех разогнал 🙂 )

          Я полностью согласен с изложенной точкой зрения.

  • Данил Матесов

    Выдержка из учебных материалов Школы Бизнеса Открытого Университета

    ----------------------------------

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

    Ограниченные Неограниченные

    Временной масштаб Ограниченный Большой или неопределенный

    Приоритеты Ясные Спорные

    Степень понимания Высокая Низкая

    Решение Сходство с известными решениями Неопределенность характера решений

    Количество заинтересованных сторон Малое Большое

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

    Последствия Ограниченные Неясные или опасные

    Ограниченные проблемы скорее всего будут поддаваться рациональному, линейному и упорядоченному подходу, характерному для управления проектами. В случае ограниченной проблемы можно сказать: «Мы находимся в пункте А и должны попасть в пункт Б». Неограниченные проблемы в силу присущего им вовлечения множества интересов, большей неопределенности и сложности обычно не поддаются решению методами управления проектами. Столкнувшись с неограниченной проблемой, Вы можете сказать: «Мы должны попасть из пункта А в пункт Б», но затем пункт Б может быстро превратиться в пункт В или Г, а закончиться все может тем, что Вы начнете сомневаться в том, действительно ли вы находитесь в пункте А! К неограниченным проблемам требуется итерационный подход.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.