Портал №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.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.