пятница, 28 октября 2016 г.

Снится ли Microsoft Project критические цепи?

"Жора, побывавший там под самый Новый год, возразил, что никакой машины там не было, а были там какие-то серые шкафы, тунеядец был не в черном халате, а в белом, и пахло там печеной картошкой. В общем, мура, обман трудящихся. Если хотите знать мое мнение, сказал Жора Наумов, он же Гирш Наумови...ч, то все очень просто: какой-то еврей из Академии наук охмурил нашего Теодор Михеича и гонит себе сейчас докторскую из нашего трудового пота."

Кейс - небольшой проект по запуску нового сервиса, 10 месяцев, менее 1 млн. Евро бюджета, около 100 человек в проекте, несколько подразделений российского филиала, несколько подрядчиков, географическая распределенность. Уровень зрелости ПУ - между 2-с и 3-м, для отрасли высокий, РП выделенный, специалист в предметной области, без серьезных знаний ПУ, планирование и контроль хода реализации осуществлялся при поддержке офиса управления проектами. Команда планирования имела аналогичный опыт, задачи типовые, на многие задачи были доступны исторические данные. Инструментом составления расписания по МКЦ был MSP2010 со специализированным шаблоном. В компании очень высокий уровень личной ответственности, обязательности и ориентированности на общий результат, низкий уровень бюрократии. Размер плана - порядка 1,000 задач.

Проблемы на инициации проекта
Расписание контрольных точек (КТ) - пришлось в устав писать дедлайны КТ, а не их плановые даты, в результате полученное на этапе планирования агрессивное расписание КТ не совпало с датами из устава, пришлось объяснять спонсору и владельцам ресурсов причину расхождения. Сразу возник вопрос - какие КТ ставить в календари Outlook участникам проекта - из устава или из сжатого расписания? Постоянный перенос дат КТ по мере расходования буфера проекта крайне расхолаживающе действует на исполнителей, а сделать мотивацию по достижению агрессивных сроков не всегда осмысленно, т.к. даты открытия сервиса по точкам привязаны к промо-периодам и раннее завершение проекта бизнес-кейса не улучшит.
Проблемы при планировании проекта
Длительности работ ставились исполнителям директивно командой планирования и РП. Несмотря на наличие исторических данных определение 50% длительности и 95% длительности все равно напоминало гадание на кофейной гуще, т.к. статистически значимых массивов для определения нормативов не было. Какая ситуация сложилась бы на сколько-нибудь уникальном проекте, догадаться несложно, т.к. в таких проектах типична ситуация "два оценщика, четыре мнения". Аналогично, даже если проект типовой, но технология позволяет реализовать решение ста тысячами разных способов, как это часто случается в ИТ проектах, исторические данные теряют свою ценность по сравнению с оценками исполнителей/планировщиков.
"Узкие места" были заранее известны, их было три, планирование только подтвердило предположения.
Итоговый план исполнителями был воспринят как малореалистичный, мотивация участников и так была близка к сдельной работе и замотивирована на завершение проекта к заданной дате (нет сервиса к промо-периоду и высокому сезоны - продажи меньше плана).
Плановая стоимость проекта - один большой вопрос. Должен ли буфер содержать стоимости или это пустая задача? Если пустая задача, то надо пересчитывать нормативы стоимости ресурсов, т.е., вести два справочника, если буфер содержит стоимости, то как все это учитывать? Забегая вперед - а как считать освоенный объем, по физобъему, т.к. по длительностям, при искаженных стоимостях ресурсов, будет полная ерунда?
Метод освоенного объема (EVM) - вообще один большой вопрос. Бюджетная кривая, изначально рассчитанная на то, что проект будет от нее отклоняться, вопрос, насколько - это не та идея, которую вы сможете продать топ-менеджменту и финансам? Внятных ответов в Сети по тому, как обойти этот вопрос, я не нашел, есть только статьи типа такой 'Theory of Constraints Project Management in Aircraft Assembly David K. Christ The Boeing Company September 10, 2001'. Т.е., при переходе на МКЦ выбор стоит еще в отказе от EVM?
Со стороны программного и портфельного менеджмента тоже совсем все не ясно. Вот есть программа из трех проектов - маркетинговое изучение нового сервиса (продукта), разработка и производство сервиса (продукта), модернизация системы отчетности для контроля и управления этим новым сервисом (продуктом). Я могу на одном слайде показать три колбаски с КТ, на котором объяснить, что происходит - вот тут готовы результаты исследований, вот тут мы по этим результатам дорабатываем новую версию сервиса, вот тут должна появиться новая отчетность. Руководство запоминает эти даты, а далее в проекте все эти КТ запланированы на первую половину отведенной длительности проекта, и когда спонсор смотрит в план управления проекта, он вспоминает, что в презентации дорожной карты даты КТ были другие. Ну что, удачи офису управления проектами и РП объяснять причины расхождений, до тех пор, пока все руководство не поймет простой истины - КТ больше верить нельзя, в этом методе есть только одна дата, которая "гарантируется" - дата завершения проекта или фазы. А в промежутке спонсор увидит "агрессивную дату", которая никогда не будет выполнена, и "здоровье буфера". Такой подход не способствует повышению уверенности спонсора и требует более длительных собраний, больше бюрократии, отчетности и т.п. Как это все должно работать на уровне портфельного менеджмента, мне сейчас тоже не ясно, т.к. вместе с расписанием КТ уходит и инструмент дорожной карты портфеля и EVM.
Итог - менять надо гораздо больше, чем говорят в красивых презах, и менять не только в методологии и программном обеспечении, но и в головах исполнителей, функциональных руководителей, менеджеров проектов и руководства предприятия.
Контроль - как и куда списываться? Если агрессивная плановая длительность задачи завершилась, списываться ресурсы должны в буфер или на эту задачу? Сколько еще ресурсов можно списать в задачу после завершения ее плановой длительности? Или списываться ресурсы могут только в пакет работ или даже в контрольный счет и до тех пор, пока он не закрыт? Это, на мой взгляд, единственный способ объединить МКЦ и EVM хоть в каком-то виде, но применимо ли это в проектах менее 1 млн.? На мой взгляд, нет.
Вообще, есть множество очень практических вопросов, которые давно надежно решены в классических методологиях, но ответы на которые доступные ресурсы по МКЦ не дают, везде ответ по типу "платите 1,500 фунтов, и мы расскажем". И что-то у меня сомнения, что расскажут, из моего опыта общения на форумах, посвященных МКЦ.
Итого, потенциальные выгоды (уменьшить использование техник padding) не больше, чем при обычном и отработанном management by exceptions, а проблем на порядок больше. Причем, наличие буфера на мой взгляд, отвращает исполнителей и планироващиков от техники padding, чем наличие контролируемого спонсором бизнес-кейса и management by exceptions на всех уровнях. Пока чистый проигрыш PRINCE2.
Еще одна дилемма - показывать исполнителям буфер или нет? Ответов нет, и за и против список длинный.
Закрытие. Самые главные вопросы - кого вознаграждать и за что; как обновлять историческую информацию по исполнению и планам; какие lessons learned?
Заключение. Использование МКЦ для непроизводственных проектов, где расписание не упирается в статистически управляемые производственные процессы, вызывает серьезные вопросы в целесообразности использования, которые возникают на всех этапах проекта. В дополнение к возникающим проблемам, внедрение МКЦ требует устранения некоторых очень важных и распространенных инструментов планирования и контроля, используемых в т.ч. и для портфельного управления. Другими словами, пока это выглядит как http://www.youtube.com/watch?v=2rfc0o1k_HM

Update. Сейчас понятно, что EVM прекрасно стыкуется с МКЦ.

Комментариев нет:

Отправить комментарий