Registered Education Provider

ГлавнаяНовостиНовости

Вопросы и Ответы Доктора Гарольда Керснера: Как изменения в проектном управлении поддерживают Agile и Scrum

25.04.2018


В ноябре прошлого года Доктор Гарольд Керснер принял участие в он-лайн Конференции Международного Дня Управления Проектами Международного Института Обучения (IIL’s IPM Day online conference) и сделал сообщение на тему «Как изменения в проектном управлении поддерживают Agile и Scrum».

В ходе дискуссии обсуждалось, как в течение многих лет управление проектами постоянно совершенствовалось усилиями по использованию лучших практик других управленческих подходов, таких как Six Sigma. Сегодня происходит обратное движение: другие управленческие дисциплины используют лучшие практики проектного управления для своего постоянного развития и совершенствования.

Это становится реальным для постоянного совершенствования в процессах Agile и Scrum. Проектное управление постоянно совершенствуется и улучшается!

В ходе сообщения Доктора Гарольда Керснера в он-лайн Конференции мы получили сотни вопросов участников, ответы на которые мы хотим сообщить Вам в следующих разделах:

  • Agile and Scrum
  • Руководители Проектов Будущего
  • Отчётность и метрики
  • Управление Портфелями
  • Государственный Сектор
  • Вызовы
  • Культурные различия
  • Провалы и успехи проектов
  • Достижение выгод
  • Разное

AGILE AND SCRUM

Какова роль Руководителя Проекта в среде Agile Scrum когда в ней действует Scrum Master?

Я представляю роль Руководителя проекта как ассистента по вопросам традиционного (классического) управления проектами

Может ли роль традиционного Руководителя Проекта ещё существовать в мире Agile ?

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

Как мы должны осуществлять планирование в гибких средах Agile и Scrum по сравнению с традиционным планированием?

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

Как могут методы Scrum или Kanban (Agile методологии в целом) соответствовать методологии PMI (т.е. Стандарту PMBOK)?

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

Примечание редактора: Возможно д-р Гарольд Керснер достаточно поверхностно знаком с Руководством PMBOK, т.к.
1) Начиная с первой главы через весь PMBOK красной нитью протянута идея необходимости отбора процессов, подходящих под ваш конкретный проект и адаптации их под вашу ситуацию;
2) Последнее издание Руководства PMBOK вышло с дополнением «Agile: практическое руководство» разработанном при плотном взаимодействии с Agile Alliance.

Существует ли путь перехода от водопадной модели к Agile? Должны ли мы переходить к Agile и забыть о всех методах управления проектами по водопадной модели?

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

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

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

Каков лучший подход для управления проектами регистрации доменов в интернет? Лучше следовать водопадной модели в традиционном проектном управлении или использовать Agile/Scrum метод?

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

Подход Agile & Scrum сокращает или исключает использование традиционного управления проектами в IT индустрии?

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

Благодарю Вас за объяснение отличий между выгодами и ценностями. Это то, что ожидают высшие руководители Компаний. Каковы Ваши рекомендации по профессиональной сертификации в Agile и Scrum и добавляет ли она ценность для руководителей проектов и их руководителей? Если да, что Вы порекомендуете? Спасибо.

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


Руководители Проектов Будущего

Следует ли Компании иметь методологию проектного управления или позволить Руководителям Проектов управлять проектами как им захочется?

Великолепный вопрос! Я уверен, что в будущем методологии будут исключены и заменены инструментами - такими как формы, темплейты и чек-листы. У меня есть клиент располагающий 50++ инструментами. В начале проекта Руководитель Проекта и некоторые члены команды отбирают необходимые инструменты и создают кастомизированную методологию, или гибкую методологию или фреймворк, который наилучшим образом соответствует потребностям клиента.

Я только что получил сертификат PMP. На основе Вашего представления о Руководителе Проектов будущего, с чего Вы порекомендуете мне начать?

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

Что Вы порекомендуете опытному Руководителю проекта для развития его карьеры? Есть ли другие направления (например, обучение) для развития?

Если Вы настроены по-своему и не хотите перемещаться из зоны своего комфорта, у Вас проблема. Если Вы настроены на изменение – обучение является стартом.

Какие 3 главных компетенции определяют Руководителя Проекта будущего? Как профессионалам овладеть этими компетенциям?

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

Как Искусственный Интеллект и машинное обучение влияют на роль Руководителя Проекта и необходимые компетенции?

В прошлом году я написал в блоге об Искусственном интеллекте и машинном обучении.

Как Вы видите будущую совместную работу Проектного Управления и Управления Организационными Изменениями для достижения выгод и ценности в проектах?

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

Отчётность и Метрики

Такие инструменты, как Метод Освоенного Объёма обеспечивают метрики для расписания и бюджета проекта. Какие типы метрик Вы рассматриваете как проверенные практикой для измерения выгод и ценности?

Не существует единственной метрики для измерения выгод и ценности. Ценность метрик достигается из атрибутов или компонент. Например, я наблюдал в одной IT Компании использование метрики ценности, включающей 5 компонент: время, стоимость, функциональность, надёжность протоколов, качество дизайна продукта. Каждая компонента имела определённый вес, и общая расчётная величина метрики по всем компонентам докладывалась в единой метрики дашборда.

Топ менеджеры заинтересованы в исполнении KPI, которые могут быть определены. Что Вы посоветуете для связи дашбордов, метрик и KPI?

Я согласен, что связи необходимы. Однако, я также уверен, что Вы должны представлять топ менеджерам дашборды, которые обеспечивают их той информацией, которая им необходима, а не той информацией, которую они хотят видеть. Если Ваша библиотека метрик включает 50 метрик, я бы не создавал дашборд для представления всех 50 метрик. Вместо этого я бы спросил Топ Менеджеров – «Какие решения Вы ожидаете принять, и какие метрики требуются Вам для принятия таких решений?». Обеспечивая топ менеджеров избыточной информацией Вы приглашаете их в микроменеджмент.

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

Стандарты должны быть для каждого инструмента. Стандарты для дашбордов используют пространство, цвета, представления, эстетику и т.д., но не специально для информации, а специально для метрик. Это должно быть кастомизировано для каждого клиента.

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

Вы правы. Именно так я преподаю эту тему.

Управление портфелем

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

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

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

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

Государственный Сектор

Я работаю в Государственном Секторе в Кейп Верд, в маленькой стране на западном побережье Африки. Принимая во внимание сложность проектов Государственного Сектора, вовлечённость большого числа стейкхолдеров, изменения содержания и сжатые сроки, что Вы посоветуете по наилучшему использованию методологий проектного управления и как могут помочь практики Agile? Благодарю Вас, Доктор Керснер.

Методологии не обязательно могут быть решением Ваших проблем. В традиционном управлении проектами, к сожалению, мы стараемся держаться подальше от стейкхолдеров и клиентов в ходе выполнения проекта из-за наших опасений получения от них запросов на изменение содержания и их вмешательства в проект. В Agile проектах мы приветствуем вовлечение стейкхолдеров и клиентов в проект и ожидаем от них хотя бы поверхностного понимания проектного управления и практик Agile. Другими словами, оказывается, что в Agile и Scrum клиенты и стейкхолдеры имеют гораздо лучшее понимание их ролей и ответственности в проекте. Это должно улучшить жизнь для Руководителей Проектов.

Расскажите о Вашем опыте и лучшей практике в управлении проектами Государственного Сектора по управлению выгодами и ценностями?

Проекты Государственного Сектора не содержат мотиваторов по прибыли и это немного меняет картину. Но в таких проектах есть другие воздействия на выгоды и ценности. Я рекомендую Вам почитать книгу Дэвида Вирика «Управление Проектами Государственного Сектора». Это хорошая книга, опубликованная Издательским Домом Джона Вилли.

Как обеспечить бенчмаркинг бизнеса в условиях монополии Государства?

Дэвид Вирик написал книгу «Управление Проектами Государственного Сектора». Книга опубликована Издательским Домом Джона Вилли. В книге представлен сравнительный анализ проектов государственного и частного сектора и различные подходы бенчмаркинга.

Вызовы

Что делать, если мы начинаем проект в Компании, которая не знает основ проектного управления?

Это приглашение к катастрофе. Моя рекомендация провести обучение, включая обучение топ менеджеров.

Как «продать» вышестоящему руководству необходимость обучения топ менеджеров проектному управлению?

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

Что делать, когда топ менеджеры не хотят посещать курсы по стратегии Компании?

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

Что делать, если Директор Проектного Офиса отклоняет просьбу адаптировать методологию проектного управления для нужд бизнеса и настаивает на своей. Как Руководителю Проекта добиться такого изменения?

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

Каков главный вызов для управления проектами?

Главный вызов - преодолеть уверенность, что Компании имеют универсальное решение по управлению проектами. В будущем, методологии должны быть кастомизированными под нужды каждого клиента. Управление проектами требует гибкости.

У Вас есть рекомендации по управлению и мотивации IT специалистов (технологов и программистов) которые сопротивляются изменениям, требующим для цифровой трансформации?

Архитекторы корпоративной культуры находятся на «верхнем этаже корпоративного здания». Если сотрудники не хотят покидать зону своего комфорта, тогда наступает момент для высшего руководства Компании принудить их к изменениям.

Если Спонсор отказывается участвовать в делах проекта, следует ли Руководителю Проекта предложить остановить проект вместо того, чтобы принимать решения за Спонсора не будучи авторизованным для принятия таких решений?

Я наблюдал подобные ситуации в нескольких Компаниях. Что я рекомендую делать Руководителям Проектов – принимать решения самим и направлять Спонсору записку по электронной почте с вопросом – согласен ли он с моим решением или нет? Это заставляет Спонсора действовать, потому что Ваша просьба и принятое Вами решение задокументировано в переписке по электронной почте.

Культурные различия

Доктор Керснер – благодарю Вас за презентацию. Когда Вы говорите о политических/религиозных/культурных различиях – как Ваша дочь сближала различные культуры? Каковы Ваши рекомендации по быстрому преодолению таких различий в глобальной программе?

Моя дочь обучалась этому у коллег в глобальных командах. Они передали ей некоторые приёмы. Она не смущалась спрашивать у них советы и рекомендации.

Я работал в мульти-культурных командах и разрешал культурные противоречия принятием определённых решений. Как Вы посоветуете добиваться консенсуса в таких командах?

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

Как определить, что Руководитель проекта смог использовать верные политические, религиозные и культурные знания?

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

Как приоритезировать метрики в случае конфликта метрик по выгодам бизнеса с политическими и культурными метриками?

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

Провалы и успехи проектов

Вы упоминали, что необходимо иметь критерии провала проекта… что делать, если провал проекта не допустим?

Если провал не допустим, Вы должны внимательно изучить возможные компромиссы и альтернативы. Это общая практика соблюдения правил для проектов таких организаций, как Управление безопасности труда и защиты здоровья работников, Агентство по охране окружающей среды США, Агентство безопасности и гигиены труда и др.

Относительно проверки здоровья проектов – что может быть примером определения критерия провала в сравнении с критерием успеха проекта?

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

Мы часто устанавливаем критерии успешности для завершённого проекта. В Agile было бы очень важно декомпозировать критерии успешности на мелкие составляющие для поэтапного подхода в разработке продукта. Как мне убедить в этом стейкхолдеров?

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

Достижение выгод

В чём заключается выгода в достижении выгод? В чём здесь ценность для Компании?

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

Доктор Керснер, можете ли Вы порекомендовать источники (авторов, журналы, и т.п.) для обучения Руководителей Проектов достижению выгод?

Есть несколько книг по управлению изменениями, в которых описано достижение выгод. Я написал статью для Международного Института Обучения по реализации выгод и управлению ценностью.

Если достижение выгод является частью проектного управления, не считаете ли Вы что это также существенная часть управления программами?

Да, это существенная часть управления проектами, но многие люди ещё не осознали это.

Кто конкретно достигает выгоды из проекта в бизнес среде? Если успешный результат проекта передаётся в операционную деятельность, видимо руководители операционных подразделений должны извлекать выгоды из результатов успешных проектов?

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

Приветствую, Гарольд – блестящее выступление! В организациях, требующих вовлечения проектных команд в достижение выгод и ценностей, общее число проектов должно быть сокращено? Если так, ценность оставшихся проектов должна превышать выгоды от всех проектов организации, включая сокращённые?

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

Доктор Керснер, должны ли быть сделаны оценки достижения выгод даже перед началом проекта, для определения тех выгод и ценности которые обеспечит проект? Или оценка достижения выгод отличается от процессов анализа затрат и выгод, возврата инвестиций и т.п. Спасибо!

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

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

Очень хороший вопрос. Я считаю зависимость линейной. На самом деле, она не линейная, если мы работаем над проектами в которых мы измеряем непрерывно выгоды и ценности в ходе выполнения проекта. К сожалению, большинство Компаний не обладают такой степенью зрелости и оценивают выгоды и ценности после завершения проекта и получения его результата. Исключением являются Agile и Scrum проекты.

Великолепная презентация, спасибо. Какие различия Вы видите между управлением изменениями и достижением выгод?

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

Разное

Прекрасная информация. Мне только не совсем ясно влияние слияний и поглощений на управление проектами. Можете ли Вы кратко пояснить это?

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

Если на реализацию выгод уйдут многие годы, как топ менеджмент может решить, являются ли применимыми критерии выхода из проекта?

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

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

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


Гарольд Керснер (M.S., Ph.D., Engineering, and M.B.A) является Высшим Исполнительным Директором по управлению проектами Международного Института Обучения. Он всемирно признанный эксперт в области проектного управления и стратегического планирования, автор многочисленных книг бест – селлеров, включая книгу Управление Проектами: Систематический подход к планированию, разработке расписания и контролю в управлении проектами 2.0. Доктор Керснер прежде преподавал управление проектами в Университете Болдвин-Вэленс, инжиниринг в Университете Штата Иллинойс и деловое администрирование в Государственном Университете Штата Юта. Он получил огромный практический опыт в корпорации Thiokol , где руководил департаментами управления программами и проектами для таких заказчиков, как NASA, Военно-Воздушные силы, Армия, Военно-Морские силы, внутренние программы НИР и ОКР.

Первоисточник: https://iil-email.com/43Z9-3HI-F41FQN94A/cr.aspx


Все

Версия для печати