Гипотетический случай №1.
Есть команда консультантов по какому-то ИТ-решению. Они прекрасно сработались, они досконально знают ИТ-решение, у них есть зрелый метод, по которому они это решение продают и запускают у клиентов. Но трансформация процессов клиента после установки решения происходит только в половине случаев, а иногда клиенты и вовсе разочаровываются в предлагаемом решении и разрывают контракт с консультантами. Рынок жесткий, и репутация на нем значит много.
Есть команда консультантов по какому-то ИТ-решению. Они прекрасно сработались, они досконально знают ИТ-решение, у них есть зрелый метод, по которому они это решение продают и запускают у клиентов. Но трансформация процессов клиента после установки решения происходит только в половине случаев, а иногда клиенты и вовсе разочаровываются в предлагаемом решении и разрывают контракт с консультантами. Рынок жесткий, и репутация на нем значит много.
Гипотетический случай №2.
Руководитель внутреннего проекта развития. Хорошо знает методы проектного управления, владеет основными инструментами (ИСР, календарный сетевой график, реестр рисков, списки задач) и регулярно применяет их на практике. Но ему не удается построить взаимодействие с функциональными подразделениями и командой внутреннего заказчика. На взгляд руководителя проекта они слишком заняты своей функциональной работой, и обещанного выделения на 20% или 40% не происходит. Проект явно срывает сроки, у него есть серьезные проблемы с качеством.
Руководитель внутреннего проекта развития. Хорошо знает методы проектного управления, владеет основными инструментами (ИСР, календарный сетевой график, реестр рисков, списки задач) и регулярно применяет их на практике. Но ему не удается построить взаимодействие с функциональными подразделениями и командой внутреннего заказчика. На взгляд руководителя проекта они слишком заняты своей функциональной работой, и обещанного выделения на 20% или 40% не происходит. Проект явно срывает сроки, у него есть серьезные проблемы с качеством.
Что в этих случаях общего? В своей работе мы постоянно сталкиваемся с необходимостью работать в расширенной команде, когда по отношению к большей части людей у нас нет административных полномочий, или они находятся далеко, или они не воспринимают нашу работу всерьез, или загружены текущими делами и им просто не до нас. Есть много философских и психологических размышлений на эту тему (фреймворки управления изменениями), много инструментов, которые часто неадекватны реальности (поля силы). Но есть и инженерные, повторяемые и воспроизводимые практики построения расширенной команды.
Как инженеры строят что-то? Они определяют функцию, которую должна выполнять система, выявляют оптимальную конструкцию, способную эту функцию выполнить, разрабатывают спецификации и по ним закупают компоненты, а что нельзя закупить, производят сами. Абсолютно тот же подход работает, когда вы делаете команды проекта, предприятия, стартапа. Предприниматели и архитекторы предприятия придумывают стратегию бизнеса и то, как он принципиально устроен, HR набирают максимально подходящих под эти задачи людей, лидеры междисциплинарных команд собирают из этих людей команды, а операционные менеджеры выстраивают процессы. Работа этих людей тесно взаимосвязана, есть множество взаимных влияний и в принятии решений надо учитывать накопленный человечеством опыт и не повторять ошибок.
Как инженеры строят что-то? Они определяют функцию, которую должна выполнять система, выявляют оптимальную конструкцию, способную эту функцию выполнить, разрабатывают спецификации и по ним закупают компоненты, а что нельзя закупить, производят сами. Абсолютно тот же подход работает, когда вы делаете команды проекта, предприятия, стартапа. Предприниматели и архитекторы предприятия придумывают стратегию бизнеса и то, как он принципиально устроен, HR набирают максимально подходящих под эти задачи людей, лидеры междисциплинарных команд собирают из этих людей команды, а операционные менеджеры выстраивают процессы. Работа этих людей тесно взаимосвязана, есть множество взаимных влияний и в принятии решений надо учитывать накопленный человечеством опыт и не повторять ошибок.
Тому, как разрабатывать дизайн-спецификации на команды по стратегии предприятия, тому, как строить команду по этим спецификациям, как управлять конфигурацией команды и как должны взаимодействовать руководители проектов и менеджеры талантов, я обучаю на тренинге по основам системного лидерства.
При этом я использую компактный понятийный аппарат.
Ближайший тренинг см. расписание.
Комментариев нет:
Отправить комментарий