Всех с Днем знаний!

Андрей Малахов выпустил статью о том, как собрать свой гибридный подход к управлению проектами

Статья очень интересная, я для себя много извлек.

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

Главный конкурент - метод "абы как и так сойдет" 😒

На фестивале "ПиР.Практики Развития" выступаю на свою любимую тему "Национальные особенности управления". Интересно будет посмотреть что на эту тему скажет HR сообщество. Если кто-то будет - присоединяйтесь!

https://vk.com/festpir_official?w=wall-214282173_810

https://www.facebook.com/developmentpractices/posts/pfbid0EAp1g9p39ndPjLyLPimbK3vKeQtabhCXPP9zqQD86LHWmbjwjeNwdeiXSuLZPPeol

https://www.instagram.com/p/Cwt5b6zPelL/

Выступления и подготовка книги дают мало времени для канала. Постараюсь исправиться.

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

Ну и в качестве попытки зайти на эту тему с другой стороны #ПроектныйЮмор


— Доктор, вот у меня почему то раны вокруг рта…
— М м, кажется, Вы едите с ножа, не пользуетесь вилкой и ложкой.
— Да? Да, это так. Но ложкой мне неудобно.
— Тогда вот Вам йод.

— Доктор, а почему я суп так медленно ем? И мне очень неудобно.
— Потому что Вы едите его ножом. Ешьте ложкой.
— И это все, что человек с медицинским образованием может мне сказать?
— Да. То есть нет. Можете отхлебывать из тарелки через край.
— Доктор, Вы вообще в своем уме?

— Доктор, доктор! Мне так больно, у меня кровь течет! За что мне это?
— А чем Вы ели?
— Ножом, конечно.
— А ложку не пробовали взять?
— Почему Вы так безжалостны ко мне, а еще врач?! Это невыносимо!
— Вы ложку взять не пробовали?
— Нет!
— А что Вам помешало?
— Я не хочу об этом говорить. Просто зашивайте.

— Знали бы Вы, доктор, как я хочу пасты!
— Могу себе представить, но у каждого своя судьба.
— Как Вы считаете, когда-нибудь у меня получится поесть макарон? Я ведь не хочу ничего особенного.
— А Вы просто сварите макарон, возьмите вилку и ешьте.
— Да? Хорошо, я подумаю.

— Доктор, и как люди манную кашу едят и не режутся?
— Ложкой!!
— Вот и Вам со мной стало скучно. Раньше Вы не кричали.

— Алло, позовите доктора, пожалуйста.
— Извините, доктор обедает

Продолжая писать книгу дошел до темы стандартов управления проектами. Стандартов, как известно в мире десятки, в России - полтора десятка. Коллеги из Центра оценки и развития проектного управления (ЦОРПУ) ведут и постоянно обновляют список.

Мне интересно отразить в книге две вещи:
1. Зачем стандарты нужны
2. Почему по ним не получается жить

Первая вещь тезисно на картинке. Вторая сводится к теме национальных особенностей.

А вот любопытно почему по корпоративным стандартам часто не получается жить? Они вроде собирают и то что есть в российских/международных стандартах и то что есть в особенностях конкретной компании...

Формат книги не предполагает углубления в эту тему, а вот здесь в канале интересно порассуждать на эту тему. См.следующий пост

#Мысли

Итак #Мысли почему не работают корпоративные методологии:

▪️ Высокая инертность. Большие усилия на разработку. Долго разрабатываются. Долго согласовываются. Потом очень сложно поменять. Во многих компаниях слово "Agile" в стандартах появилось через несколько лет после того, как по нему начали пробовать жить. А у некоторых и до сих пор не появилось 🙃

▪️Не практичные. Слишком техничные и на птичьем языке. Часто настолько сложные, что понятны только разработчикам. Пользователям не понятно почему именно так. Откуда те или иные требования

▪️Фрагментарные. Сложно сочетаются с другими ключевыми процессами компании (HR, закупки, финансы)

▪️Слишком узкие. Не учитывают нюансы разных проектов "One size fits all". Недавно Андрей Малахов публиковал статью о сборке своего подхода, там частично эта тема тоже затрагивалась.

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

В продвинутых организациях частично удается с ними справиться на основе упрощения стандартов (моя версия стандарта на основе РИМ-III меньше 10 страниц), перекладывания требований в ИТ системы и аккуратного структурирования информации в базах знаний.

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

Завершая день стандартов.

Есть совершенно феерический в своей простоте и наглядности швейцарский гибридный стандарт по управлению ИТ проектами Hermes.

Является обязательным для ИТ проектов Правительства Швейцарии. Как у них принято в честь этого изложен на четырех языках.

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

Попал под лошадь на обложку журнала IT-Manager

Моя статья Agile, Scrum и «византийская система управления». Разбор полетов в мире ИТ-проектов

#Статьи #Похвастаться

Сейчас идет очередной поток моего курса по классическому проектному управлению. На очередном вебинаре задали хорошие вопросы про одно и тоже:

А) Может ли у проекта быть два заказчика? В моем случае, цель\ - создание оборудования (опытного образца, это результат проекта) и документации для серийного производства. есть внешний заказчик, который формулирует технические требования к результату и сроки. Он же будет владеть физически тем опытным образцом который будет создан в рамках проекта. Однако интеллектуальная собственность,\документация остаются внутри РГ, у моей организации и второй, третий, дестяый образец будет создаваться именно нами. Кто заказчик?

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

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

Итак. Давайте сначала посмотрим кто такой Заказчик

Заказчик - Физическое или юридическое лицо, которое является владельцем результата проекта и, соответственно, формулирует требования к нему [ГОСТ 54869]

Соответственно для вопроса
А) ответ - в проекте два Заказчика.
Б) ответ - в проекте несколько Заказчиков. Будут и Функциональные Заказчики и Заказчик платформы. Что делать см.следующий пост

Итак помочь ответить на вопрос может база Российской модели управленческой сложности (МУС). Вот все-таки когда-нибудь найдутся ресурсы и я таки ее выложу.

Для ситуации, когда есть большое количество сторон, определяющих требования рекомендуются следующие активности:
▪️применение методов системной инженерии;
▪️создание общих органов для всех участников постановки требований и приемки продукта – Управляющего Совета для топ-менеджмента, Оперативного Совета для среднего уровня руководства;
▪️обеспечение ведения реестра (базы данных) требований и отслеживания всех озвученных требований до конкретных функций создаваемого продукта, которые можно продемонстрировать заказчикам;
▪️привлечение профессиональных бизнес-аналитиков для работы с требованиями и выстраивания соответствующего процесса.
проведение приоритизации требований. Рекомендуется для использования модель Moscow (КВЖД) и дополнительно модель Кано ;
▪️выделение своего набора параметров продукта для каждой стороны, определяющей требования, для минимизации взаимного влияния требований. Рекомендуется использовать инструмент Структурная матрица зависимостей(DSM);
▪️разнесение требований в отдельные документы: основной документ с описанием общих требований (Техническое задание, ТЗ) и отдельные связанные документы (Частное Техническое задание, ЧТЗ), описывающие детальные требования вовлеченных сторон
фиксация распределения ответственности по приемке в Матрице распределения ответственности;
▪️как можно более раннее определение состава приемочной комиссии(й);
▪️фиксация и последующий контроль всех достигнутых договорённостей по требованиям и приемке в обязывающих документах (протоколах, соглашениях, меморандумах и т.д.);
▪️организация приемки результатов по частям, с привлечением на каждое мероприятие приемки только необходимых участников;
▪️проведение промежуточного тестирования и контроля получаемых частей продукта.

Шесть основных видов ИТ инструментов управления проектами

1️⃣ Стандартное офисное ПО. До сих пор не смотря на все эти цифровизации и искусственные интеллекты Word, Excel, PowerPoint их аналоги от Google / Yandex остаются основными рабочими инструментами Лидера проекта.
2️⃣ Инструменты MindMapping. Очень хороши для структурирования мыслей и создания простых личных моделей. Лучший безусловно MindManager, хотя за последние годы остальные к нему хорошо подтянулись. Вот здесь обзор 2023 года.
3️⃣ Бесконечные доски. Системы, самыми известными из которых являются Miro и Mural, позволяют команде очень удобно совместно работать с большими объемами информации. Так как эти системы ушли из России появились наши аналоги. Здесь есть обзор
4️⃣ Софт для создания создания сложных моделей. Позволяет создавать сложные планы по разным аспектам (сроки, затраты, ресурсы, ...). Раньше лидерами здесь были MS Project и Primavera. После их ухода остались open source решения. Вот здесь обзор 8 сервисов с открытым кодом для управления проектами. Ну и есть российские проприетарные системы - Спайдер Проджект, BiPulse, Plan-R.
5️⃣ Таск-менеджеры "на стероидах". Системы, которые зарождались как таск-менеджеры для команд сейчас превратились в многофункциональных монстров. Такие универсальные "швейцарские ножи". Раньше самыми используемыми у нас были Jira и Trello (хотя есть и очень удачный Wrike, и Smartsheet и еще миллион решений). Сейчас много появилось - от Яги Ростелекома (да именно так и называется :) до широко известного Битрикс 24. Вот хороший свежий обзор
6️⃣Информационные системы управления проектами (ИСУП). Комплексные системы для автоматизации крупной организации. Здесь можно почитать что они включают. Много чего включают. Раньше тут царствовали MS Project Server и Oracle Primavera для стройки. Сейчас тут лидеры Адванта, ПМ Форсайт и модули 1С.

Безусловно это мой субъективный взгляд на предмет 🦉
Всех несогласных прошу в комментарии 🙃

#Инструменты

Вместе с командой СКОЛКОВО решили разобрать больную для всех тему.

Стейкхолдеры: как распознать их и как выстроить с ними работу.

5 октября в 11:00 буду ждать вас с кружкой кофе (или чая) на регулярном бизнес-завтраке.

Что расскажу и покажу:
— 10 вопросов для выявления заинтересованных сторон проекта.
— 4 шага работы со стейкхолдерами
— Карта воздействия для перевода интересов в контрольные точки
— Инструменты работы со стейкхолдерами

Когда: 5 октября, четверг, 11:00 (мск)
Формат: онлайн
Регистрация

Коллеги из сообщества практиков проектного управления проводят активность под названием «ветер перемен»

Они каждый квартал проводят экспресс-опрос по 7-ми вопросам - изучают развитие проектного управления в нашей стране. Полученные данные из опроса они переводят в индексы и сравнивают с предыдущими результатами. И эксперты дают свои комментарии 😁

В этот раз по моей просьбе они добавили к 7-ми традиционным вопросам ещё один. Про соотношение классических и Agile подходов в организации.

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

https://yangx.top/CommunityProject/1386

https://yangx.top/CommunityProject/1387

https://yangx.top/CommunityProject/1388

https://yangx.top/CommunityProject/138

https://yangx.top/CommunityProject/1390

https://yangx.top/CommunityProject/1391

https://yangx.top/CommunityProject/1392

https://yangx.top/CommunityProject/1393

#Исследования

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

А к Вам, мои уважаемые подписчики, есть ряд вопросов...

Итак спасибо всем, кто проголосовал.
Любопытно сравнить с прошлым опросом (апрель 2022):
Слова, которые ассоциируются с каналом примерно совпали, что приятно 🙃

А вот запросы несколько поменялись - ощутимо больше стал запрос на базовые инструменты (46% против 36% полтора года назад) и сложные инструменты (54% против 46%). Ну и провалы стали чуть менее интересны (было 57%, стало 46% - видимо достаточно много разобрал 😊).

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

Чтож, запросы понятны - будем работать!

Для начала пост с обзором тех инструментов, что уже были в канале..

Итак я уже разбирал базовые инструменты
▪️Механизм (процедура) запуска проекта. Цель - Официально запустить проект в организации
▪️Механизм фиксации требований к результатам – совокупность шагов по фиксации того, что должно быть на выходе проекта
▪️Матрица RACI / РОСИ. Инструмент распределения ответственности в команде
▪️Методика установка целей по принципу ВОДКИ. Больше смешно, чем полезно, но все-таки пусть здесь будет 🙃
▪️Шесть основных видов ИТ инструментов управления проектами. Краткое описание
▪️Фактография по ситуации. Нужен, чтобы холодно и беспристрастно зафиксировать факты связанные с проблемной ситуацией на проекте. Позволяет перевести эмоциональное (обычно) обсуждение проблемы в русло фактов и логики развития ситуации

Более сложные инструменты
▪️Гейтовый подход. Нужен, чтобы зафиксировать точки принятия решений (ТПР, гейты, анг.gate – ворота.). Дает возможность регулярно пересматривать актуальность проекта в свете новой информации. Если не актуален - закрывать
▪️Инструменты и подходы продуктового мышления - большая подборка
▪️Инструменты LeanСамарAgile - неформальное представление команды, заряд жизненной энергии, доска рефлексии
▪️Центр оперативного реагирования и прогнозирования (ЦОРП). Разработан командой Александра Кутузова для реализации сложных строительных проектов
▪️Инструменты для управления проектами изменений. Голосование с конференции Газпромнефти какие инструменты для управления проектами изменений обязательные, а какие не очень
▪️Визуализация методов принятия решений в командах. Мой перевод картинок Юргена Аппело.
▪️unFixed. Очень интересная модель от Юргена Аппело. Меня все не покидает смутное ощущение громадных ее возможностей, но все не представляется случай попробоовать где-то применить
▪️Фокусы внимания для Штабного режима работы. Я продолжаю над ними работать. Уже есть новая версия, но тут пусть пока старая повисит
▪️Инструменты интеграции проектов. Что можно использовать из программной рамки, если программу над проектами по каким-то причинам надстраивать не хочется
▪️Модифицированная Карта Влияния (Impact map). Продолжаю с ней экспериментировать - кто готов попробовать - поделитесь результатами.


Эти и другие инструменты уже перенесены в базу BrizPM. Дальше буду давать инструменты уже со ссылкой туда

И продолжая тему инструментов

Благодаря волонтерам - обновление базы по инструментам работает!

Спасибо Юрию Киму и ЦОРПУ в базе BrizPM появилось обновление описания одного из базовых инструментов - Реестра рисков и Механизма (процедуры) управления рисками.

Цель управления рисками проекта — снижение вероятности и воздействия на цели проекта неблагоприятных событий и повышение вероятности и воздействия на цели проекта благоприятных событий.

Риск проекта – это неопределенное событие или условие, которое в случае реализации, будет иметь отрицательное или положительное влияние на цели проекта (содержание, сроки, стоимость, качество). PMBoK, PMI

Риск – это вероятностное событие. Это то, что может случиться, а может и не случиться. Риски с потенциально отрицательными последствиями для проекта называются «угрозы», а с потенциально положительными — «возможности»)

Реестр рисков (risk register): Список выявленных рисков, содержащий, в том числе, результаты анализа и планируемые меры по реагированию на риски. (ГОСТ Р ИСО 21500 — 2014)


Эти описания явно можно дополнять и расширять - желающие велкам в личку

#Инструменты

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

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

Кто хотел инструментов?
Берите Пентабазис - не промахнетесь!

#Инструменты Пентабазис. 5+1 базовых вопросов проекта