Выпуск №16. Оценка длительности задач

Подкаст Разговоры о проектном бизнесе. Выпуск 16.

Содержание выпуска:

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

#подкаст

На днях на тренинге был вопрос о стыковке подходов с обычным управлением проектами. И на недавней конференции Форум по управлению проектами с коллегами обсуждали механики контроля проектов. В частности "Метод освоенного объема".

Метод освоенного объема даёт в целом хороший механизм получения индикаторов. НО! Есть несколько меленьких "но":

1. Индикаторы метода освоенного объема не имеют встроенных механизмов "что такое хорошо" и "что такое плохо". С этим каждый борется по своему задавая уровни отклонений.


2. Индексы отклонения по срокам хороши, но... получается если мы контролируем "допустимый уровень отклонений" , то значит у нас ЕСТЬ БУФЕР, но в расписании мы его не закладываем.

Как же так? Получается, как детской песенке песенке "Ж.па есть а слова нет". Резерв закладываем, но никому его не показываем, но что-то вычисляем.

#ccpm

В это воскресенье записали уже 20й выпуск подкаста про управление проектами методом Пульса.

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

Сегодня сделали отдельный канал с записями подкастов, чтобы удобно слушать прямо из Телеграмма:
https://t.me/bipulse_podcast

Применение Управления проектами критической цепи (Метод Критической Цепи, МКЦ) в строительных проектах.

В проектах капитального строительства часто каждый сокращенный день строительства это прибыль/экономия в миллионах рублей/долларов. Метод Управления проектами критической цепи позволяет сокращать сроки, строительства но за это есть расплата.

При применении МКЦ мы строим "сжатый" или "оптимистичный" график работ, и поэтому жесткого срока выхода подрядчика на объект нет. У этих сроков всегда есть "дрейф" вправо.

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

И такая ситуация - основное препятствие применения МКЦ в капитальном строительстве.

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

И если этап завершится сильно раньше целевого срока , то у вас останется два варианта действий:
1. Найти убедительный довод для подрядчика, чтобы он начал работы на своём этапе раньше оговоренных сроков.
2. Смотреть как несколько миллионов денег (рублей/долларов) убытков или недозаработанных испаряются каждый день.

Какой вариант вы выберете?

#ccpm

Паспорт проекта или Соглашение о Целях.

Пересматривая материалы по "классическому управлению проектами", и также вспоминая, что было на недавнем Форуме по управлению проектами и вопросам наших Клиентов, нашел, что все думают что "Паспорт проекта" это самый важный документ.

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

По всей видимости, по аналогии с Мыслительными процессами Теории ограничений (Thinking processes), в следующих редакциях Метода я буду говорить про:
- Мыслительный процесс "Соглашение о целях проекта"
- Мыслительный процесс "Планирование проекта"
- Мыслительный процесс "Оценка длительности задач"
- Мыслительный процесс "Анализ угроз проекта"

То есть, это не просто "Мероприятие" и "Совещание" или "Алгоритм". Это именно "Мыслительный процесс" выработки решений. И относиться к нему нужно как к Мыслительному процессу, привлекая к выработке решений всех кто владеет ситуацией и понимает что-то в обсуждаемом вопросе.

Следствие из этого: ведущий мероприятия "Мыслительный процесс Соглашение о целях проекта" становится Исследователем, задавая неудобные вопросы: доведение до абсурда, "блондинка", "диверсионный анализ" и другие.

#метод #метод_пульса

Выпуск №17. Алгоритм оценки длительности задач

Подкаст Разговоры о проектном бизнесе. Выпуск 17.

#подкаст

Выпуск №17. Алгоритм оценки длительности задач

Подкаст Разговоры о проектном бизнесе. Выпуск 17.

Содержание выпуска:

- Алгоритм оценки длительности задач.
- Кто должен давать оценку длительности задачи.
- Насколько точной должна быть оценка.
- Что такое "Коэффициент точности планирования".

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

Автор и ведущий Иван Абашкин https://t.me/ivan_abashkin
Отвечает на вопросы автор Метода - Алексей Васильев.

Слушать в Дзене
Слушать в Rutube
Слушать в VK
Слушать в YouTube
Слушать в Яндексе
Слушать в Podster.fm

Прочитать подробней про Метод управления проектным бизнесом https://pulsemanagement.org/
Задать вопрос в нашу радиопередачу: https://t.me/proprocess_ru

#подкаст

Выпуск №17. Алгоритм оценки длительности задач

Подкаст Разговоры о проектном бизнесе. Выпуск 17.

Содержание выпуска:

- Алгоритм оценки длительности задач.
- Кто должен давать оценку длительности задачи.
- Насколько точной должна быть оценка.
- Что такое "Коэффициент точности планирования".

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

#подкаст

"Управление проектами Методом критической цепи" или "Управление проектами критической цепи" ?

С точки зрения канонического перевода термина "critical chain project management" в книгах "Критическая Цепь" и "вовремя и в рамках бюджета" можно говорить "Методом..." , но с моей точки зрения это совершенно не фокусирует нас на объекте управления. А именно "Проекты критической цепи".

Есть простое "Управление проектом" (см, Свод знаний по управлению проектОМ), есть "управление программой проектов" (это отдельный свод знаний). А в Теории Ограничений есть "Критическая цепь" и "Проекты критической цепи".

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

Есть всего один приоритет: Все обещанное содержание должно быть выполнено в срок или раньше. Даже если будет превышение бюджета. Потому, что основе предложение ценности при внедрении "Управления проектами критической цепи" это - Мы НАДЕЖНЫЙ поставщик и ВСЕГДА выполняем все взятые на себя обязательства вовремя и в полном объёме.
Кроме этого, превышение сроков это ВСЕГДА увеличение стоимости. А каждая просрочка проекта это значит мы не запустили ТАКОЙ ЖЕ проект вовремя и Клиент ушел в другому поставщику.

Поэтому лучше говорить и думать про "Управление проектами критической цепи" и никак иначе. Так вы задаёте фокус внимания всего персонала на достижении основной цели бизнеса.

Ссылка на термин в словаре:
https://bipulse.ru/app/dictionary/docs/управление%20проектами%20критической%20цепи

TOCICO анонсировал:

Exciting Announcement: The Online TOC Thinking Processes Fundamentals Certification Exam is Now Available!

$99
https://www.tocico.org/page/ThinkingProcessesFundamentalsExam
#tocico

Подкаст 18. Пульс спринта.

https://t.me/bipulse_podcast/60

#подкаст

Как запустить ИТ-бизнес быстро и без лишних действий

Метод управления проектным бизнесом даёт возможность очень БЫСТРО достигать целей. Но у него встроенных механизмов поиска цели.

В Теории ограничений есть алгоритмы для непрерывного совершенствования. Даже алгоритм "Стоя на плечах гигантов" это тоже совершенствование. И "Шесть вопросов к новой технологии" это просто проверка решения на прочность при внедрении когда вы уже ЗНАЕТЕ кому продаете.

Но нет алгоритма ПОИСКА цели.

Поэтому если у вас есть идея о стартапе то задайтесь о нескольких вопросах:

1. Идея о продукте - это запрос существующего Клиента или это ваша идея?

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

Если это ваша ИДЕЯ, то первое, про что нужно подумать: А не ГАЛЛЮЦИНАЦИЯ ли это?

2. Есть ли у меня существующая аудитория, которой я могу это продать?

Если у вас уже есть аудитория которой вы можете предложить новый продукт/услугу, это отлично! Значит получить предоплату и доработать предложение решив проблему Клиента. Ничто так не укрепляет веру, как предоплата (с).
Подтверждение спроса в этом случае 1-2 месяца.

Если у вас нет готовой аудитории (контакты) которой вы можете продать ваше новое изделие/продукт, то придется эту аудиторию искать, а значит предложение ценности для придуманной аудитории является ГИПОТЕЗОЙ. Подтверждение спроса может занять 3-6 месяцев, это значит что вам нужно финансовое плечо на это время. Потому что денег в это время не предвидится, а будут расходы на рекламу и оплату труда.

3. Сколько времени займет поиск аудитории и уточнение предложения ценности?

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


4. Как я могу сократить время поиска аудитории и уточнение предложения ценности?

Это самый важный вопрос! При ответе на него записывайте даже самые немыслимые варианты, среди них может попасться настоящая жемчужина. А главное что это и есть те самые Цели для которых можно строить планы достижения в формате проектов.

И в подкрепление этого алгоритма пару историй:

История первая. Парсер (мониторинг) цен от Максима Кульгина (xmldatafeed.com и компания Нотиссимус)

(источник: видео Максима Кульгина на youtube)

У компании Нотисимус, как разработчика мобильных приложений для розничных компаний накопилась хорошее портфолио в этом сегменте как специалистов "ИТ для розницы". А если это это так, то существующие клиенты начали спрашивать "Я вот как бы нам цены конкурентов получить для сравнения?"

То есть есть, был прямой запрос Клиента и при анонсе подтянулась и другая аудитория которая профильная для компании. Бизнес стал расти.

История 2. Анализ цен поставщиков компьютерного оборудования.

(В этой истории автор заметки принимал участие)

Была идея: Нам для участия в тендерах и предложения цены нужно просматривать много экселек для подбора подходящего оборудования. НАВЕРНОЕ это нужно кому-то еще, таким же как мы? (как price.ru только по ценам дистрибьютеров, а не розничным)

Тут предложение ценности было ГИПОТЕЗОЙ. Ниша мелких интеграторов непонятная "такой же как мы" - это как? В процессе пути выяснилось, что формат экселек у всех разный, ТТХ у оборудования по разному записывается, а нужно как-то сравнивать , даже формат у каждого поставщика иногда меняется. В результате, чтобы держать базу в актуальном состоянии и продавать к ней доступ нужен был человек на полную ставку. И это при том что снаружи еще никто не купил. Это не стало бизнесом и система почила в бозе.

#ответы_на_вопросы

Луренс Лич о Методе освоенного объема.

8.3.4. ПРОБЛЕМА
В методе освоенного объема применяется «индекс выполнения стоимости» (Cost-Performance Index, CPI). Он показывает, какова финансовая ситуация в проекте. Если индекс больше единицы, дела идут хорошо (по сравнению с оценочными показателями, тратится меньше, делается больше). Если индекс меньше единицы, значит, все хуже, чем планировалось (на определенный объем работ израсходовано больше, чем ожидалось).

Индекс выполнения стоимости = Плановая стоимость выполненных работ / Фактическая стоимость выполненных работ

Чтобы спрогнозировать, сколько денег будет потрачено к концу проекта, можно использовать первоначальную оценку бюджета на конец проекта (бюджет по завершении) и индекс выполнения стоимости:

Прогноз по завершении = Бюджет по завершении / Индекс выполнения стоимости


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

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

Проблема в том, что метод освоенного объема не учитывает явления вариабельности и возможности использования буферов.

На рис. 8.9 показано использование бюджета проекта во времени с расчетом проектно-
го буфера и буфера на затраты. Можно не волноваться за проект, пока он не выходит за рамки этих буферов.

#ccpm

рисунок 8.9

#ccpm

Дмитрий Егоров и "Жизнеспособная система управления" выпустили увлекательную историю о внедрении решения управления запасами на основе решений Теории Ограничений в ХимТраст.

Я не смог оторваться пока не досмотрел до конца. Рекомендую!

https://vk.com/wall-191082764_254

Подскаст 19. Искусство приоритизации.

https://t.me/bipulse_podcast/62

#подкаст

Есть ли у Стратегия мистер Фикс?

Заметка о стратегии развития бизнеса и ИТ-Продуктов

В Теории Ограничений, а точнее в мыслительном процессе Дерево Стратегии и Тактики (ДСТ), Стратегия - это ответ на вопрос "ЧТО я хочу получить", а тактика - это "КАК этого достигнуть".

Однако, по отношению к ИТ-компаниям или реальному бизнесу обсуждая возможности стратегической сессии, термин Стратегия часто определяется, как ответ на вопрос "ЧТО я хочу получить через 5 лет" (или 10-15 и тд).

А если мы забрасываем якорь ("Что я хочу получить" ) на 5-10 лет, то получается что СПОСОБ ("как" ) мы туда придём - это серия Проектов.

Проект - это способ упаковки Целей по направлениям с понятными эффектами и результатами.
Проекты развития задают точки опоры "это готово, то готово" и определяют периоды пересмотра Целей.

Можно отрицать Проекты, как бывает иногда в ИТ-продуктах, но тогда
- Куда вы хотите прийти?
- А за счет чего?
- А почему вы решили, что вы туда придёте?
- Уже задумались?

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

С другой стороны, если вы НЕ ЗНАЕТЕ КАК достигнуть цели (как например "хочу много денег"), то тут на сцену выходят бесконечные эксперименты и метания из стороны в сторону (с применением Sсrum и Kanban). Но тогда я спрошу:
- А сколько стоит один эксперимент?
- А можно ли провести эксперимент не проводя эксперимент?
- Если вы тратите время и ресурсы на эксперименты, то на что другое важное вы не тратите?

И если при ответе на эти вопросы вы ужаснулись, то может остановиться и подумать? А точнее провести мыслительные эксперименты с применением мыслительных процессов ТОС.

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

Ссылки по теме и ключи для дальнейшего поиска:
* Дерево стратегии и тактики. (Словарь TOCIO)
* Алгоритм Стоя На плечах гигантов (Standing on the Giant shoulders)
* Мыслительные процессы ТОС (Словарь TOCIO)
* Постановка целей и планирование проектов. (Метод управления проектным бизнесом).
* Дао предприятия (Метод управления проектным бизнесом).

Выпуск подкаста про цели: https://t.me/bipulse_podcast/32

Подскаст 20. Управление загрузкой ресурсов

https://t.me/bipulse_podcast/64

#подкаст

Я наверное нашел базовые посылки на которых работает Метод!

Метод базируется на базовых посылках (кроме тех что в Книге):
1. Мы не знаем детально всего, но знаем хоть что-то для принятия решений.
2. Мы можем что-то требовать если сотрудник самостоятельно ВЗЯЛ ответственность, а не подтвердил её вручение.

#метод #метод_пульса

В апреле я публиковал Дерево Стратегии и Тактики (ДСТ) внедрения Метода.
тут: https://t.me/bipulse/300

Приведённое ДСТ было адаптировано для внедрения BIPULSE, и вошло в расширенное руководство пользователя.

И сейчас могу поделиться результатами его применения!

Выводы:

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

2. Внедрять нужно постепенно разворачивая ритмы, начала операционный - фиксируем все цели и задачи что ДЕЛАЕМ сейчас, а уже потом строим на этом фундаменте остальные.
2.1 Нельзя пытаться заглядывать на километр в будущее, если стоишь по пояс в болоте. (кто не верит, рекомендую Болото Неодолимое в Ленинградской области)
2.2 Другими словами сначала внедряем Agile-подходы, которые отвечают именно за операционный уровень управления, а поверх них уже проекты и планирование.

3. Следующий шаг нужно делать только ПОСЛЕ того, как выявились проблемы на текущем шаге. А не потому, что "левая нога зачесалась".
3.1 Если говорить в терминах Теории Систем, то каждый следующий "горизонт планирования" - это "надсистема" по отношению к текущей системе. Проблемы системы решаются её надсистемой.
3.2 Если проблемы не случились, никому ваши новые изменения не нужны. Это значит на текущем уровне развития компании имеющегося инструментария ДОСТАТОЧНО.

4. Если у вас есть сотрудники у которых НЕТ проблем, и поэтому они не хотят меняться. То... всегда можно СОЗДАТЬ им проблемы.
4.1 Любой собственник или управленец +1 уровня может создать проблемы своим подчиненным просто поменяв механизмы премирования.
4.2 Всегда нужно учитывать последствия такого шага.

#метод #метод_пульса

Тут исследование говорит, что только 17% проектов завершаются в срок.

https://t.me/isopmru/543

Самое время подумать, как их делать вовремя с ИСУП BIPULSE! ;)