Добрый день!
Наша Компания задумывается о внедрении методологии планирования календарного плана по методу Критической цепи, основателем которой является Э. Голдратт. Кто-нибудь может поделиться опытом, данный метод действительно дает такие результаты по срокам? С какими проблемами сталкивались при внедрении, какие сложности наиболее часто возникают при использовании метода? Заранее благодарю!
Голдратт, критическая цепь.
Добрый День Лариса ? А какие именно элементы, из написанного Голдраттом, Вы хотели бы внедрить в календарное планирование? Ведь большинство современных инструментов (MS Ptoject, Primavera, Spider ... ит д) рисуют Критический путь без проблем. Сам термин СPM (Critical Path Method) классический, входит в стандарты, детально "разжеван". То есть, в минимальном объеме, критическая цепь Голдратта пристутствует в инструментах по умолчанию. Если Вы искуссно разрабатываете расписания работ, анализируете, какие работы попали в критический путь цепь и сосредотачиваетесь на них при планировании и последующем выполнении, - то Вы уже используете идеи Голдратта.
RE: Голдратт, критическая цепь.
Добрый день! Спасибо за пояснения. Мы планируем внедрить в области планирования проекта три элемента метода "Критической цепи": 1. Оценка длительности задач (50% вероятности наступления в указанную длительность) 2. Устранение конкуренции за ресурсы в плане проекта (все задачи взаимосвязаны по принципу "Финиш-Старт", один ресурс выполняет одновременно одну задачу). 3. Защиту плана буферами в проекте. При этом использовать будем инструмент MS Project с до настройкой. Мое мнение что метод "критической цепи" все -таки отличается от классического метода "Критического путь". Критический путь - фокусируется на выполнении в установленный срок каждой отдельной задачи, а по методу "критической цепи" внимание и усилие Руководителя проекта и ресурсов фокусируется на выполнение в срок всего проекта. В интернете много картинок, которые показывают разницу между "критическим путем" и "критической цепью". В критическом пути, не учитывается конкуренция за ресурсы.
Не всё дело в технике
Добрый день. Как успехи на этом тернистом пути ? :) Чисто алгебраически сумма квадратов меньше квадрата суммы, и график должен быть короче. Однако... ЯТД, что сама по себе техника планирования по ССPM, если ограничиться этими 3 аспектами, вряд ли внедрится гладко. И вот почему : 1. Непросто добиться правды ( пресловутая 50% вероятность) . У ресурсов нет стимулов ужесточать свою жизнь, сдавая подстраховку полностью. Следует продумать систему их стимулирования. Понятно, что она будет категорически противоречить традиционным правилам и привычкам, как ресурсов так и руководства : "проси два - дадут один" vs "дашь два - сделают через три". 2. При длительности назначений с 50%-й вероятностью завершения довольно много задач таки будут просрочены. Для самого проекта в целом это не страшно, т.к. есть проектный буфер. Но даты назначений начнут гулять, что создаёт трудности в управлении ресурсами. Великолепна ситуация 100%-го выделения ресурса на единственный проект. Для некоторых видов ресурсов это возможно. Но некоторые другие ресурсы на практике работают в мультипроектной среде, т.е. в промежутках между назначениями в одном проекте, загружаются задачами по другим ( не путать с многозадачностью). При смещении фактического срока завершения задачи-предшественника ставится под угрозу окно доступности ресурса в связи с назначениями этого ресурса в других проектах. Возникает конфликт не внутри проекта, а на уровне менеджеров проектов. Выходом может являться защита назначений буферами, т.е. запретом на другие назначения некоторое время до и/или после данного назначения. Т.е. ресурс, вроде, и не назначен никуда, а назначить его нельзя. Это вызывает неудовольствие у ресурсного менеджера. Раньше такой конфликт не возникал, т.к. буфер входил во "внутреннюю" подстраховку задачи. Т.е. механизмы решения таких ситуаций должны отрабатываться. 3. Если в компании применяется почасовая ставка, то и ресурс прямо заинтересован в максимально плотной загрузке, без всяких щелей и буферов, а для менеджера проекта любое использование проектного буфера ( т.е. создание незапланированных назначений)будет означать превышение базового бюджета. Что скажет финконтроль ? 4. Если проект очень длинный, возникают трудности с мотивацией ресурсов на конечный результат. А у руководства теряются ориентиры обозримого времени. Здесь возможны решения с применением подходов ССРМ к значимым фазам проекта. Я сейчас как раз все эти вопросы изучаю и обыгрываю. Пока теоретически, хотя и на практике интуитивно некоторые вещи использовал. Мораль одна - начинать надо с головы :) Буду рад, если поделитесь своим опытом.
RE: Не всё дело в технике
Добрый день. Полностью согласна с Вашими размышлениями, что не все так просто как казалось бы после прочтения книги и изучения теории. Не могу пока поделиться практическим опытом как это у нас работает, пока мы только начали отрабатывать на одном пилотном проекте с использованием специального ПО. Вопросов много и задача гораздо шире чем кажется, и действительно начинать надо с "головы". Начали с того, что в рамках стандарта УП мы приняли и договорились с руководством, что для нас в проектах важна, прежде всего, скорость, т.е. срок окончания проекта, но при этом, не забывая про качество и бюджет. По поводу того, что участники проектов не мотивированы на сжатые сроки, это да. Но не надо их просить оценку длительности задачи с 50% вероятностью, пусть это решает сам руководитель проекта и в плане указывает свою оценку по длительности задачи, он же тоже специалист, и есть же Функциональный руководитель, который тоже может выступить экспертом. На рабочей группе, когда обсуждали данный вопрос, специалисты которые участвуют в проектах начали выкрикивать, что мы теперь и в 4 раза будем завышать оценку и т.д. Но это уже показатель компетентности самого специалиста и отношения к своей работе, тут и мотивация никакая не поможет. Очень многое в данном вопросе зависит от Руководителя проекта, он должен эмоционально заряжать участников проекта и показывать своими действиями приверженность к проекту и свой авторитет. Считаю еще, что очень многое также зависти от программного инструмента, без него не обойтись. По поводу мультипроектности, мы для себя приняли что, во-первых, одновременно реализующихся проектов в компании должно быть не более 7; во-вторых, что сотрудник может одновременно участвовать не более чем в трех проектах, и занимать от текущих задач не более чем 30%. И очень важно это отслеживать со стороны Руководства или Проектного офиса. По поводу дат назначения, возможно, соглашусь, но пока не знаю как это на практике. Но суть в том, что не надо привязываться к конкретным срокам, это определенный промежуток времени на задачу, который состоит из дней предупреждения ресурса о начале выполнения задачи и длительности самой задачи. С ресурсам договариваемся заранее, за сколько предупредить и сколько у него времени на выполнение. Лениться не получится, потому что каждый день ресурс будет отчитываться об оставшейся длительности, и в случае проблем Руководитель проекта сможет своевременно отреагировать. По поводу 4 вопроса не совсем поняла. Во-первых, надо избегать затяжных проектов, где то читала, что проект не должен быть дольше 1,5 лет. Мотивировать при этом надо не только на завершение, но и на получение промежуточных результатов. И система мотивации в проекте должна быть не только материальной, но и нематериальной. По данной теме общаюсь с Еленой Федурко, представителем школы Голдратта, посещаю их сайт периодически, планирую в апреле посетить теорию практиков данной теории, которая будет проходить в Москве. Спасибо за Ваш опыт, предлагаю обмениваться им по мере появления новых продвижений в данном вопросе.
RE: RE: Не всё дело в технике
Добрый день, Лариса. Оффтоп : посмотрел ваш профиль и обнаружил, что вы принадлежите к той редкой породе проектных птиц, что и я : выходцы из FMCG :) "Сибирский берег" несколько лет назад звучал на московских тусовках PMI как особенно заметный кейс среди моря строителей, айтишников и аспирантов. Тем лучше, проще будет понять друг друга. По поводу оценки длительности, я своих ПМ натаскивал на способ вытащить из исполнителя оценки по PERT : 1. "за сколько сделаешь?" - "а пёс его знает" - "почему?"- "потому ( перечисляются все риски : будут ли материалы, загрузит начальство и т.п.) 2. "если всё будет плохо ( перечисляются риски), что будешь делать?" - "то-то" - " ну и за сколько сделаешь ?" ( пессимистическая оценка). На повторный неопределённый ответ начинается игра на понижение : "за неделю сделаешь, а за пять дней ?" 3. "если всё будет идеально ( перечисляется отсутствие рисков) за сколько сделаешь ? - (тут обычно идёт легче) - "за день, но это вряд ли" ( оптимистическая оценка) 4. " а если всё, как всегда ?" - "тогда за два дня обычно управляемся"( наиболее вероятная оценка) Так вот, мне представляется, что 50% вероятности - это в данном контексте не наиболее вероятная, а оптимистическая оценка. Т.е. сам бы поднапрягся, да внешние условия не позволяют. И исполнителя следует убедить, что ему будут созданы идеальные условия и никто не будет ругать, если немного опоздает, а уж если досрочно сдаст, то... ( вот тут надо системно подумать - что - и не забывать о качестве). Но это для мэйнстрима, т.е. людей относительно трезвых и самостоятельных, привыкших отвечать за по обязательствам. Но есть ещё, по моим наблюдениям и пара маргинальных групп с общим свойством - не умеют отвечать по обязательствам. Это : а) самоуверенные креативщики ( особенно программисты и амбициозные руководители), искренне переоценивающие свои способности и б) сотрудники, зашуганные до потери чувствительности. Первые занижают оценки из удали, вторые соглашаются со всем, что начальство ни скажет, всё равно - за что нибудь да отлупят завтра, что уж тут сегодня спорить. Вот тут Голдратт не работает, и приходится прибегать к другим способам оценки. Ашманов ( см. "Правила Ашманова") предлагает умножать на три :). От программного инструмента, увы, по моему опыту мало что зависит. Потому как, что бы ни показал инструмент - решения принимают люди. Кстати, о каком специальном ПО вы упоминали ? По поводу длительных проектов : как ни крути, а длинные проекты бывают. В моей крайней фирме один из строительно-технологических проектов начался в конце 2006 года, а планируется к завершению к середине 2012, дай Боже. Сменилось два менеджера и три концепции. Прицепилось ещё 18 подпроектов. Это реальность. Но даже длительность 1,5 года значительно обесценивает "морковку", вывешенную по завершении. А голдраттовская мотивация вся базируется на основных приятностях по завершении проекта. Так что, тут нужен разумный баланс между мотивацией на промежуточный и окончательный результат, но тогда и буфера перед промежуточными значимыми вехами вполне уместны. Пример : запускали модуль ERP-системы, критически важно было совместить ввод в опытную эксплуатацию с началом года. Т.е. дедлайн стоял где-то процентах на 70% общей длительности. Так вот у меня менеджер проекта ( и прочие лидеры проекта тоже ) премиальные получал именно по этой вехе. Остальное докатилось через полгода автоматом. Так вот, если бы вёл план по ССРМ, то проектный буфер поставил бы именно на эту веху, а потом уже в конец. Огромное спасибо за то, что сориентировали по источникам. Правда не совсем понял, какой именно сайт вы имели ввиду ?
RE: RE: RE: Не всё дело в технике
Добрый день! Земля все-таки круглая, "Сибирского берега" больше нет, а о нем еще помнят. Заинтриговали меня по поводу того, что говорили на тусовках PMI про "берег", какую оценку давали проектной деятельности? На самом деле меня эта компания очень многому научила, это моя первая бизнес-школа, и я благодарна всему руководству за тот опыт и возможности, которые они нам всем дали. Что касается оценки длительности по Голдратт... есть работы, которые вообще нельзя сократить в плане, они фиксированы, например, "получение тех экспертизы проектной документации" или другой разрешительной документации в госорганах, там срок фиксирован и повлиять на них мы никак не можем и т.д. Я думаю, что все теории это все-таки теории, важно из этого взять суть и подстраивать под свои потребности. Где нельзя сократить сроки там не сокращать, где по наитию понимаешь, что участник подстраховывается, надо сокращать, и возможно использовать не обязательно цифру 50% . Буфер проекта тоже может рассчитываться по разным методикам, может 50% от крит. цепи, а может и 30%, либо вообще корень квадратный и т.д. Все зависит от того что Вам требуется. Что мне нравится в этой теории, что в принципе, если вот так посмотреть со стороны, ничего же не меняется. С заказчиком Вы согласовываете сроки окончания проекта с учетом буфера проекта, получается, что при классическом пути вы страховку закладываете в каждую задачу, а при МКЦ вы эту страховку из задач убираете и ставите в конец проекта. Ничего по длительности в принципе не меняется. Только вот когда вы страховку убираете в конец проекта, у вас больше шансов закончить проект вовремя, чем при классическом подходе. При классическом подходе страховка разбазаривается впустую и когда она необходима, действительна ее уже нет, и, как правило, проекты задерживаются. А внешние условия в проектах есть всегда и будут, и ничего с этим не поделать. Сразу метод не заработает, необходимо время, необходима статистика по задержкам, необходимо дисциплинированнее исполнителей по срокам, и в конечно счете настанет время, когда исполнители будут давать реальную длительность и ее не надо будет уменьшать. По поводу мотивации по Голдратту ничего не слышала, либо упустила этот момент. У нас в методологии система мотивации включает две составляющие: материальную по вехам и окончанию проекта и нематериальную. Без премирования по вехам не обойтись, особенно в длительных проектах, люди так устроены, что должны чувствовать и промежуточные свои результаты. Длительные проекты надо избегать, пример с проектом, который вы привели, скорее всего, будет расцениваться как неуспешный, и концепцию несколько раз поменяли и руководителей. При планировании таки сроки были обозначены или это связано с изменениями? По - моему мнению, лучше разбивать такие проекты на несколько связанных проектов, тогда и управляемость будет эффективней и оценка результатов. Но не мне судить. По поводу программного продукта не соглашусь. Как вы большие проекты в ручную отслеживаете, необходимо и логику создать и цепь вычислить, а как вы отчёт по буферу формируете, анализ на равномерную загрузку ресурсов делаете??? В плане, в котором 200 строк, скорее всего это сложно. Мы в работе используем надстройку к MS Project "ProChain", рассматривали многие варианты, этот наиболее подходящий оказался.
RE: RE: RE: RE: Не всё дело в технике
Добрый день, Лариса. Земля - круглее некуда, особенно в тесном мире PM. Однако, в середине нулевых, когда я начал приобщаться к бомонду, вокруг меня было очень мало людей из традиционной промышленности, особенно FMCG. На семинары и конференции МО PMI ходили : гуру разного калибра, аспиранты, студенты, айтишники, немного строителей и банкиров, и, естественно, консультанты. Поэтому, каждый человек, обозначивший связь с промышленностью привлекал моё внимание. Улов был невелик : моя компания, "Сибирский берег" да BAT. Про "Сибирский берег" громко хвалился кто-то из консультантов. Уже не помню про что конкретно. Про мотивацию, в явном виде, Голдратт, возможно, и не писал. Но, поскольку вся его идеология построена на холистическом восприятии проекта, то и мотивация команд, в основном, ориентируется на конечный результат. Описанный мной проект вовсе не считался неудачным, просто ожидания инвестора постепенно приходили к вменяемому уровню, сопоставимому с инвестиционными возможностями, что отражалось в пересмотре концепций. Такие "туманные" проекты вовсе не редкость. И в конце, выжившие обычно бывают довольны результатом. За наводку на программный продукт спасибо. Буду знакомиться. Если что, задам вопросы, с вашего позволения. Моя ремарка касалась того, что самый быстрый и красивый автоматизированный отчёт будет бесполезен, если ЛПР не знает, что делать с этой информацией. Т.е. методология первична, автоматизация вторична. :) Со своей стороны, даю ссылки на, в некотором роде, критические материалы, содержащие указания на некоторую неполноту метода ССРМ. Читать надо между строк и в конце :) Может быть, вам пригодится. [] []
RE: RE: RE: RE: RE: Не всё дело в технике
Здравствуйте! Спасибо за ссылки. Я тоже встречала много подобных статей по поводу неполноты метода. Пока тоже не совсем до конца осознала, как это применять у нас в России, с нашей культурой управления среди топ-менеджеров. У нас совершенно другое мышление и подход, редко в российских компаниях встречаются управленцы с системным мышлением, а тут еще и метод "критической цепи"....., отсюда же и отношение исполнителей к оценке длительности... нам еще многому учиться и мышление бы поменять. Я искала российские компании, которые применяют данный метод на практике, нашла даже в городе, но опрос показал, что научились и оценили данный метод, но на практике не применяем, то проектов подходящих нет, либо еще что. Представитель школы Голдратт тоже не смогла мне рассказать про успешный опыт в России, поскольку, с ее слов, данный метод только зарождается у нас. Думаю, что многие ответы на вопросы я смогу получить на конференции практиков ТОС, которая пройдет в Москве в апреле. P.S. По поводу, что методология первична, я не отрицаю, возможно, не правильно выразилась, писав про ПО, предполагала, что оно требуется именно для реализации корпоративной методологии, трудно построить и рассчитать план проекта вручную.
|
Константин Эсвикеев
|
8 августа 2015 г., 13:09 |
Опыт эксплуатации CCPM Prochain
Добрый день! Спасибо за обсуждение метода CCPM. Только стою у истоков проектного менеджмента (1 год опыта) и данный метод кажется очень перспективным. Лариса, очень интересно, смогли ли Вы в полной мере реализовать подход в условиях Российской специфики. С какими трудностями пришлось столкнуться. Помогла ли конференция практиков TOC в Москве и что скажете про ProChain? Спасибо!
|
