<<
>>

Управление проектами перемен и перемены в управлении проектами

Планируя проект, мы часто сомневаемся в его завершении вовремя по независящим от нас причинам. Однако проект можно запланировать так, чтобы не только успеть в срок, но и обогнать себя В статьях, опубликованных в предыдущих номерах &.СТРАТЕГИ1/1, вы могли познакомиться с теорией ограничений систем, ее основными понятиями, логикой, принципами внедрения и методом прео доления сопротивления переменам.
В данной статье я предлагаю рассмотреть новый, основанный на ТОС, си стемный подход к управлению проектами Приступая к выполнению проекта, мы берем на себя три вида связанных между собой обязательств: содержание (объем, выгода, спецификация), бюджет (ресурсы), время (срок исполнения, длительность). В этой связи можно вы делить типичные проблемы, с которыми приходится стал киваться при управлении проектами: • не выдерживаются изначально установленные сроки, • по ходу исполнения вносится слишком много изме нений; • отсутствуют/опаздывают необходимые ресурсы; • идет постоянная борьба за то, какой проект более приоритетен; • превышается бюджет; . многие работы приходится выполнять повторно. Традиционный метод управления проектом выглядит так: проект разбивается на отдельные этапы/задания, для каждого из которых устанавливается определенный срок и/или длительность. Участники проекта должны обеспе чить, чтобы каждое отдельное задание было закончено вовремя, и таким образом своевременно завершить про ект. Однако каждый знает, что существует закон Мерфи. Поэтому, давая оценку того, сколько времени может уйти на выполнение своего задания, каждый из участников проекта стремится максимально подстраховать себя. Ду маю, вы согласитесь с тем, что данный подход напомина ет локальный оптимум: каждый сражается за срок выпол нения своего задания и верит, что этим поможет всему Хейти Пакк проекту. А если проект опаздывает или превышает бюджет Указанные проблемы неизбежно ведут к тому, что изна чальные обязательства оказываются в конфликте между собой. Если мы хотим выполнить одно обязательство, другие два оказываются под угрозой. Так, стремясь вы полнить обязательства по срокам, мы часто вынуждены превышать бюджет за счет привлечения дополнительных ресурсов или «пожертвовать» частью изначального содержания проекта. Всем известно, что проекты внедря ются в условиях высокого уровня неопределенности и подвержены воздействию закона Мерфи который гласит: «Если неприятность может случиться, то она обязательно случается». Каким образом составляющая закона Мерфи проникает в проекты? За счет того, как мы исходя из общепринятой практики распределяем ресурсы между проектами, подстраховываем себя от риска и планируем задания. (как это слишком часто бывает), все считают, что это про изошло из-за того, что им не позволили заложить в свою оценку достаточной подстраховки от воздействия закона Мерфи. Другими словами, изначальные планы были не реалистичны. Поскольку в действительности традицион ный метод борьбы с составляющей закона Мерфи не оправдывается, нам необходимо найти такой способ управления проектами, который защитит нас от неопреде ленности и воздействия закона Мерфи. Иначе все так и будут продолжать жаловаться на нереалистичность изна чальных планов. В этой статье я докажу, что мощностей и подстраховки, заложенных в планы проектов, достаточно для того, чтобы выполнить все три изначальных обяза тельства по проекту (срок, бюджет, содержание).
Я пока жу, что эти мощности и подстраховка просто выбрасыва ются на ветер из-за традиционного метода, требующего устанавливать сроки окончания каждого отдельного зада ния вместо того чтобы защитить от неопределенности весь проект. Природа проекта: успеем, не успеем... Начнем с очень странного вопроса: сколько будет 10 плюс 10? Ответ 20 верен только в том случае, если мы складываем окончательные цифры. Но в проектах мы ни когда не имеем дело с окончательными цифрами. Это не просто 10 плюс 10, а 10+ плюс 10±. В проектах нам точно не известно, что и как будет происходить, поэтому мы го ворим о приблизительных предварительных оценках. Итак, при управлении проектами ответ на вопрос «Сколь ко будет 10 плюс 10?» будет 20±, другими словами, точ ного ответа никто не даст. Поскольку речь идет не о конеч ных цифрах, мы должны помнить, что существует процент неопределенности. Рассмотрим пример. Допустим, один проект состоит из пяти последовательных заданий. Существует 50%-я веро ятность того, что на выполнение каждого задания уйдет 10 или меньше дней, и 50%-я вероятность колебания в пре делах ±2 дня (т. е. имеет место средняя неопределенность выполнения задания 20%). Сколько времени уйдет на проект? Правильный ответ: «В зависимости от того, что случится в процессе выполнения проекта». Иначе говоря, точный ответ дать не может никто. Давайте смоделируем выполнение этого проекта в компьютерной программе, сделаем 1000 прогонов и посмотрим на статистику. Как мы и ожидали, в результате моделирования длительность выполнения всего проекта получается 50± дней. Рассмо трим кратко один важный момент, к которому мы вернем ся позже. Для отдельного задания средняя неопределен ность составляет ±20% (10 ± 2 дня). Если проект состоит из 5 заданий, то средняя неопределенность составит ±10% (50 ± 5 дней). Для каждого отдельного задания не предсказуемость выше, чем для цепи заданий в целом. Вероятность выполнения всего проекта в срок должна быть выше вероятности выполнения в срок отдельного за дания. Почему же тогда опаздывают целые проекты? По чему получается так, что, чем длиннее цепь заданий в проекте, тем больше проект опаздывает? Нельзя забывать, что статистические колебания в про цессе реализации проекта — только часть картины. Зача стую в проектах мы встречаем множество точек интегра ции, в которых должны сойтись несколько заданий для то го, чтобы можно было начать следующий этап. Рассмо трим пример. В рамках одного проекта у нас есть шесть заданий (А, В, С, D, Е, Y). При этом к выполнению шесто го задания У можно приступить только после того, как бу дут завершены первые пять. Допустим, что задания А, В, С и D будут выполнены раньше, чем запланировано, а зада ние Е опоздает на 20 дней. Когда можно начать это шестое задание Y? Только по завершении самого «медленного» задания Е. Таким образом, получается, что, несмотря на то, что мы сэкономили время на выполнении первых че тырех заданий, вся эта экономия теряется из-за опозда ния задания Е. Существует еще один аспект, усложняющий реализацию проектов. Он состоит в том, что у нас есть ресурсы, назна ченные для выполнения нескольких заданий. В этом случае для того, чтобы такой ресурс мог приступить к выполнению следующего задания, необходимо дождаться: 1) чтобы он закончил задание, над которым работает в данный момент, и освободился для следующего задания; 2) чтобы это зада ние было закончено предыдущим ресурсом и передано ему. Поскольку существует подобная зависимость, возникает ве роятность того, что это следующее задание не будет начато и соответственно закончено в срок. Зная это, участники проекта закладывают достаточно высокий уровень подстра ховки при оценке времени, необходимого им дпя выполне ния заданий. Как правило, в учебниках по статистике можно найти график вероятности в виде симметричной кривой по фор ме колокола. Однако в действительности, когда речь идет о вероятности временных затрат на выполнение отдельного задания, кривая будет выглядеть, как на рисунке 1. Это кривая смещенного распределения вероятности. Почему график распределения вероятности временных затрат не симметричен? Представьте себе ситуацию: кто-то говорит вам, что хочет встретиться с вами на 5 минут. Но вы зна ете, что вероятность того, что встреча продлится пять ми нут, очень мала. Есть какая-то вероятность того, что она может занять меньше 5 минут, но, скорее всего, она затя нется на 15 минут. И вы не удивитесь, если проблема, ко торую человек хочет с вами обсудить, настолько важна, что встреча не завершится и через 45 минут, хотя вероятность того, что встреча, которая планировалась на 5 минут, зай мет 45 минут, невелика. Поскольку вероятность того, что встреча продлится дольше 5 минут, значительно больше вероятности того, что она продлится меньше 5 минут (и не может быть вероятности того, что встреча продлится ми нус 30 минут), кривая не будет симметричной. Одна ветвь будет всегда длиннее другой (рис. 1). Так как в проектах существует зависимость от многих факторов: интеграции, непредвиденных обстоятельств, наличия или отсутствия ресурсов, смещенного распреде ления вероятности и т. д., участники проекта закладывают в каждое свое задание достаточно временной подстрахов ки. Исполнитель задания знает: согласившись на опреде ленные временные рамки, он дает обещание, выполнение или невыполнение которого скажется на его репутации. Вряд ли в организациях найдутся такие «камикадзе», ко торые, давая оценку по срокам, исходят, к примеру, из 50%-й вероятности выполнения своего задания. При пла нировании срока выполнения свого задания люди учиты вают, что что-то может случиться в цепи предшествующих заданий, что-то может случиться во время выполнения ими задания, и поэтому подстраховывают себя как можно большим запасом времени Кроме того, руководитель всего проекта, делая оценку длительности проекта, закла дывает свой запас времени, поскольку ему известно обо всех зависимостях и о факторе смещенного распределе ния вероятности. Руководители проектов знают: несмотря на уже заложенную подстраховку, что-то все равно может пойти вразрез с планом. Кроме того, они хорошо осведо млены, что если заказчику (руководителю, начальнику) время исполнения проекта покажется затянутым, он по требует сократить сроки. Поэтому, когда их просят оце нить срок выпопнения проекта, они, пытаясь защитить се бя и свою репутацию, дают безопасную оценку. Возникает немало конфликтов, когда руководители дол жны установить срок выполнения проекта/задания и не могут это сделать, поскольку не уверены, вложатся ли они в указанные сроки. Как ведут себя люди, участвующие в проекте? Их задача — делать свою работу хорошо, быть хорошими специалистами. С одной стороны, для того что бы быть хорошими специалистами, они должны делать то, что хорошо для фирмы. А для того чтобы делать то, что хорошо для фирмы, они должны установить максимально короткий срок выполнения задания, поскольку для всей фирмы лучше, чтобы срок выполнения проекта был мень ше. Но с другой стороны, для того чтобы сделать работу как следует, они должны обезопасить себя от неприятных последствий и дать безопасную для себя временную оцен ку, иначе говоря, минимум в два раза длиннее 50%-й ве роятности того, что они выполнят задание в срок. И посту пают они так из самых лучших побуждений, желая быть надежными сотрудниками. Конфликт налицо. Рассмотрим конфликт управляющего проектом, кото рый хочет делать то, что хорошо для фирмы. Для того что бы делать то, что хорошо для фирмы, ему надо завершить весь проект как можно быстрее. А чтобы завершить весь проект быстрее, он должен планировать с минимальной подстраховкой по времени. Вместе с тем, чтобы делать то, что хорошо для фирмы, он должен обеспечить своевре менное выполнение проекта — ведь, если проект опозда ет, обвинять будут именного его. Значит, он должен себя подстраховать. Еще один конфликт связан с поведением тех, кто уча ствует в реализации проекта. Предположим, что сотруд ник, выполняющий задание, хочет делать свою работу хо рошо. Для этого ему необходимо делать то, что хорошо для фирмы, и избегать неприятных последствий для се бя — передать работу следующему ресурсу как можно бы стрее. Поскольку реальная длительность выполнения за дачи неизвестна, этому специалисту может повезти и он выполнит свое задание не за 10 дней, как обещал, а за 5. В этом случае он оказывается перед дилеммой: передать задание дальше, показав, что он заложил слишком большую подстраховку, или подержать его у себя, чтобы доработать. Это широко распространенная дилемма. Рас смотрим ее на примере денег. Представьте себе прави тельственный департамент, у которого есть бюджет на определенную программу. 15 ноября выясняется, что осталась не потраченной сумма в 2 миллиона гривен. Что предпримет в этом случае департамент? Вернет деньги в бюджет? Никогда! Если это сделать, на следующий год заявка на бюджет этого департамента будет урезана. Чтобы избежать подоб ного, департамент находит способ по- Работа всегда тратить эти деньги, к примеру, на об- займет все то учение, время, которое на нее Итак, что делать, если задание бы- отводится ло закончено раньше установленного срока? Придерживать его или переда вать? Это заставляет вспомнить об одном очень интересном феномене — законе Паркин- сона, который гласит: работа всегда займет все то время, которое на нее отводится. Если мне дали две недели, тогда я буду выполнять задание две недели. А если мне дали четы ре недели, то я буду делать эту работу четыре недели. Край не редко я получаю какую-то выгоду для себя, если сделаю задание быстрее. Это типично для человеческой натуры. По чему я утверждаю, что закон Паркинсона действует в про ектной среде? Потому что при 50%-й вероятности того, что мы выполним задание в срок, и при том, что, защищая себя, мы на самом деле даем оценку, в два раза превышающую эти 50%, в большинстве случаев мы должны были бы вы полнять задание досрочно, но этого не происходит. Есть еще ряд вещей, вытекающих из закона Паркин сона. Возьмем так называемое правило трехминутного яйца, суть которого состоит в следующем: если на ра боту отводится определенное время, то считается, что эта работа не может быть готова раньше. Другими сло вами, если я передам работу следующему ресурсу ра ньше, он может вернуть ее мне, поскольку в его пони мании досрочно выполненное задание не могло быть сделано должным образом! К тому же по его графику у него еще не подошло время работать с этим задани ем. Следовательно, из-за нашего подхода к управлению проектами мы не используем весь тот выигрыш по вре мени, который был заработан. У нас теряются четкие критерии того, что такое выполненное задание. Мы не осознаем, как повлияет на весь проект тот факт, что мы потратим на выполнение своего задания на несколько дней больше. Традиционный подход к упра влению проектами заставляет людей мыслить ло кально. Они заинтересованы только в том, чтобы сде лать свою работу хорошо и передать ее. В большинстве случаев людей оценивают по тому, насколько они удач но выполнили свое задание: обещали за две недели — выполнили за две — хорошо. Вся защита, подстрахов ка будет разбазарена или просто спрятана. Существует еще один фактор, определяющий человеческое поведение в проектах, — студенческий синдром. Суть этого явления такова: когда студенту через неделю предстоит сдача экзамена, он говорит: «У меня слишком мало времени, я не успею подготовиться. Дайте мне еще неделю». Преподаватель переносит экзамен еще на неделю, но в конечном итоге сту дент готовится к экзамену только в последнюю ночь. Другими словами, если мы даже получим больше времени, чем требу ется для выполнения задания, мы все равно не начнем зани маться им немедленно. Мы же знаем, что заложили в оценку срока достаточно солидную подстраховку: на самом деле мы планируем время с запасом, в 2-3 раза превышающим вре мя, необходимое для выполнения задания при 50-60% веро ятности выполнения в срок. И все равно это время пропадает из-за локального подхода к управлению проектами Все намного сложнее, чем кажется. Жонглируя проектами Совокупности действия факторов зависимости ресур сов, накопления отрицательных колебаний и смещенного распределения вероятности, закона Мерфи и особенно сти поведения людей, выражающейся в стремлении под страховать себя в виде законов Паркинсона, трехминутно го яйца и студенческого синдрома, достаточно, чтобы выбить из колеи любой отдельный проект. Можно пред ставить себе размах ущерба, наносимого проектам, вне дряемым в условиях мультипроектной среды, в которой одни и те же ресурсы задействованы в нескольких проек тах. Речь идет о матричных организациях, где есть руково дители проектов, отвечающие за проекты, и управляющие ресурсами, отвечающие за ресурсы. Они отвечают за отделы, из которых берутся ресурсы для того, чтобы вы полнить проекты. Поскольку ресурсы, работающие в про-ектах, напрямую не подчиняются руководителю проекта, он вынужден для получения ресурсов, необходимых для его проекта, конкурировать с руководителями других про ектов, которым необходимы те же ресурсы. Дилемма, которая стоит перед высшим руководством компании: начинать новые проекты или не начинать? По чему руководители хотят вводить новые проекты в си стему? Потому что они должны реагировать на те воз можности, которые открываются для них на рынке, и чем быстрее, тем лучше. А почему руководители не хотят на чинать новые проекты? Потому что прежде необходимо выполнить те проекты, обязательства по которым были приняты ранее. Чем больше проектов находится в системе одновременно, тем большая опасность того, что ресурсы будут вынуждены перепрыгивать от одного проекта к дру гому и возникнет конфликт приоритетов. Что мы имеем в виду, говоря о перепрыгивании от зада ния к заданию, и каков ущерб, наносимый этим исполне нию проекта в срок и в рамках бюджета? Рассмотрим при мер. У вас ведутся 3 проекта: проект А, который требует работы на две недели плюс-минус, проект В — тоже две недели плюс-минус и проект С — также две недели плюс- минус. Если вы можете их сделать один за другим, то про ект А закончится после двух недель, В — после четырех, С — после шести недель. Что же происходит в реальности, когда мы хотим быть «справедливыми» в управлении про ектами? Мы перебрасываем людей из одного проекта в другой Вам не даюг паботать над проектом А две недели. Ч^рез несколько дней после того, как вы начинаете проект А, появляется что- то более важное в проекте В и вас пере брасывают на проект В, потом — на проект С. Необходимо четкое понимание того, что время, которое мы вкладыва ем в проекты, и время, за которое мы их завершаем, — не одно и то же время. Поскольку ресурсы, начав проект А, вынуждены его оставить на какое-то время из-за срочных заданий в проектах В и С и продолжают перепрыгивать от проекта к проекту, то, несмотря на то, что реальное время работы по проекту А — 2 недели, проект А будет закончен не за это время, а значительно позже, так как ресурсы од новременно заняты в нескольких проектах. Теперь вы по нимаете, почему вся подстраховка пропадает и почему проекты опаздывают, независимо от того, какую бы под- сфаховку мы в них не закладывали. Стараясь начать выполнение задания как можно рань ше, мы этим на самом деле вынуждаем ресурсы перепры гивать от задания к заданию, в результате чего нарушают ся все наши временные оценки по срокам и мы видим, что правила сложения в оценке длительности проекта не ра-ботают, что заставляет нас добавить еще больше подстра ховки к нашей оценке по срокам. Вот тут мы попадаем в замкнутый круг. Добавив больше подстраховки, получаем больше времени, а это в свою очередь влияет на наше поведение, провоцируя студенческий синдром (мы откла дываем выполнение задания) и активизируя закон Пар- кинсона (используем все время, которое нам дано). Как результат — наша подстраховка разбазаривается, и мы опять сказываемся в той же ситуации — не выполняем сроки. Это заставляет нас заложить еще больше подстра ховки в оценки по срокам. Мы начинаем терято прио ритеты и полную картину. Все становится срочным, все на чинает казаться важным. Все это приводит к тому, что мы перепрыгиваем от задания к заданию, так как все кричат, что их задание нужно было сделать еще вчера. 1/1 посколь ку мы видим, что все равно опять не успеваем, в следую щий раз подстраховываемся еще больше и так далее Как вырваться из этого замкнутого круга? Первый шаг решения — понять то, что нам необходимо сократить вре мя, которое уходит на завершение задания/проекта. Для того чтобы закончить работу раньше, вы должны начать позже. I Нужно не толкать новые проекты в систему, а придер жать их и работать только над каким-то конкретным их ко личеством. Мы должны установить приоритеты относи тельно очередности выполнения проектов и правильно — ступенчато — расположить проекты по времени. Какая модель даст правильное расположение проектов по вре мени? Если мы зададим этот вопрос, становится ясно, ку да нужно смотреть, чтобы найти механизм синхронизации проекта. Какой ресурс более всего загружен, из-за чего чаще всего опаздывают проекты? Этот ресурс — ограни чение нашей системы. Мы должны сделать эшелонирова ние проектов по времени исходя из загруженности этого ресурса. Если мы ведем параллельно много проектов, то находим на графике задания того ресурса, который загру жен больше всего, убираем остальные задания и видим нечто похожее на развалы (рис. 3). Что мы обычно дела ем, если у нас появляются такие развалы? Их надо просто выровнять и начать строить заново. Мы определили, что красный ресурс на нашем графи ке — самый загруженный. Поскольку он используется па раллельно во многих заданиях, нам необходимо выров нять нагрузку самого загруженного ресурса и переплани ровать задания проекта так, чтобы устранить конфликт ресурса — чтобы устранить ситуацию, когда несколько заданий для этого ресурса планируются на один тот же отрезок времени. Для этого мы «выравниваем развалы» и после этого просто сдвигаем все проекты в соответствии с графиком работы самого загруженного ресурса. Этот ре-сурс делает работу последовательно по заданиям 1, 2, 3, 4. I/I только закончив четвертое задание, он переходит к следующему проекту (к заданию номер 5). Такой принцип работы означает, что все последующие проекты как целое сдвигаются по времени, и остальные ресурсы подчиняют ся ритму работы самого загруженного ресурса. Поэтому такой критический ресурс мы называем «барабаном», за дающим ритм работы для остальных ресурсов, которые в результате такого подчинения тоже перестают постоянно прыгать от задания к задания. Какой ресурс будет «бара баном» и то, каким будет список проектов, — решает высшее руководство. Может оказаться, что следующий проект должен ждать какое-то время, пока этот ресурс не освободится, но нам надо объяснить руководителю проек та, что это необходимо. Ступенчатое расположение проек тов можно сравнить с узкой дверью, через которую бы стро проходит большое количество людей, встав в очередь друг за другом. Если же толпа людей начинает ломиться в узкую дверь, у всех уйдет значительно больше времени на то, чтобы через нее пройти, не говоря уже о травмах и возможных жертвах (рис. 3). Когда мы добились, чтобы проекты меньше мешали друг другу, можно продолжав искать возможности улуч шения. Как я показал ранее, причиной опоздания проек тов и превышения бюджета является локальный подход, стремящийся обеспечить «защиту» каждого отдельного задания. Я хочу продемонстрировать вам другой подход к планированию проекта, который фокусируется не на до стижении локальных результатов, а на успешном выпол нении проекта как целого. Поставить буфер на защиту проекта Если мы согласны с тем, что проект — не просто сумма индивидуальных заданий, а единое целое, т. е. система, то будет естественным ожидать, что проект, как и любая си стема, имеет свое ограничение, диктующее конечные ре зультаты. Следовательно, нам надо управлять проектом как системой: найти ограничение, найти способ, как его лучше использовать, подчинить все остальное этому реше нию и т. д., другими словами, в управлении проектами мы должны использовать пять направляющих шагов ТОС (см. статьи Хейти Пакка «Внимание! Ограничение!», и «Укро щение сопротивления»). Как сделать первый шаг — найти ограничение системы? Система, которую мы хотим сейчас улучшить, — это управление проектом как целым. Давайте посмотрим на очень простой проект, который состоит из нескольких заданий (рис. 4), и определим критический путь, т. е самый длинный путь зависимых заданий. Такой путь по времени будет составлять 10 + 10 = 20+ 16 = 36 + 20 = 56. Это так называемый критический путь, диктующий время исполнения проекта. Это и есть ограничение. Второй шаг: максимально использовать ограничение. Нам следует избежать потери дней и недель на этом са мом длинном пути. Мы знаем: чтобы защитить весь про ект, необходимо защитить критический путь, потому что весь проект зависит от того, как мы оперируем на этом пути. Для того чтобы защитить не каждый отдельный шаг, а весь путь, нам надо использовать ту индивидуальную защиту, которая заложена в каждом отдельном шаге, «вы тащив» ее оттуда и поставив в конец всего пути. За счет чего мы можем это сделать? За счет того, что, как мы убе дились выше, в каждом задании заложена временная под страховка, как минимум, в два раза превышающая необхо димую для обеспечения 50%-й вероятности выполнения данного задания в срок. Это время, которое закладывает ся в каждое отдельное задание, мы можем разбить напо ловину. Мы знаем, что не всегда сможем завершить дан ное задание в установленный короткий срок, но мы также знаем, что у нас есть 50% вероятности того, что мы смо жем успеть в этот срок. Это и позволяет нам «вытянуть» время подстраховки из каждого отдельного задания и за-ложить его в буфер для всего проекта (рис. 5). Теперь каждый участник проекта знает: для его задания отведено меньше времени, но в конце проекта есть «огнетушитель» — защитный буфер. Мы работаем без каких-либо проме жуточных сроков сдачи заданий. Инструкция самая про-стая: выполняйте задание так быстро, как можете. Допу стим, на выполнение задания мы запланировали 10 дней и знаем, что существует высокая вероятность того, что по требуется больше, чем 10 дней. Но это не страшно: у нас есть защитное время в конце проекта. С другой стороны, если удается выполнить задание быстрее, чем за 10 дней, проект без промедлений переходит на следующий этап. Никаких искусственных замедлений или искусственных промежуточных сроков сдачи задания. Перед всеми стоит единственный срок — срок сдачи проекта. Передача зада ний в проекте идет по принципу эстафеты. Каждый участ ник эстафеты получает палочку и старается бежать как можно быстрее ради победы всей команды. Соответствен но и мотивация должна быть выстроена на вознагражде нии командного результата, а не локального. Давайте теперь воспользуемся законом статистиче ских колебаний. Если не происходит искажений во вре мени выполнения отдельных заданий, то степень нео пределенность для всего проекта будет меньше, чем степень неопределенности для каждой отдельной зада чи, потому что статистические отклонения усредняются. Это означает, что для защиты всего проекта нам не нуж но все время подстраховки, которое мы забрали из от дельных заданий. Буфер можно сократить наполовину. Таким образом, он будет составлять 1/3 от всего проек та. Другими словами, если у нас 9-месячный проект, то время буфера составит 3 месяца, а график исполне ния — 6 месяцев. И мы должны работать так, как если бы у нас было только 6 месяцев. Это совершенно иной стиль работы. Время подстраховки теперь сконцентри ровано там, где оно необходимо, — в конце всего про екта. Так буфер превратился в инструмент управления проектом: его можно использовать в качестве измери-теля, показателя и инструмента для планирования. Теперь поговорим о рисках. Что может случиться, если произойдет конфликт ресурсов? На графике (рис. 6) у нас имеются ресурсы А, В, С, D, Е. По этому графику возника ет конфликт в работе ресурса С, так как ресурс назначен на выполнение двух разных работ в одно и то же время. При такой ситуации необходимо скорректировать опреде ление самой длинной цепи в проекте, которая является не только самой длинной цепью логически зависимых друг от друга заданий, но и принимает во внимание зависи мость ресурсов. Если мы видим, что один ресурс должен параллельно выполнять два задания, то сдвигаем крити ческий путь и формируем критическую цепь — самую длинную цепь взаимозависимых заданий. Критическая цепь отличается от критического пути тем, что учитывает зависимость ресурсов. Таким образом, прежде чем мы назовем окончательную дату сдачи проекта нам надо учесть возможность возникновение консрлиш ресурсов. В противном случае мы не сможем выполнить обещание, данное клиенту. Увеличение длительности критической це пи означает, что буфер всего проекта в данной ситуации тоже должен быть длиннее. Нельзя забывать, что ресурс критической цепи полу чает задания из других, так называемых питающих, пу тей. Что случится, если опоздает питающий путь? Это за ставит критический ресурс ждать и задержит продвиже ние заданий в критической цепи. Рассматривая эту воз можность, мы понимаем, что нам необходим буфер, ко торый подстраховал бы критическую цепь в точке при мыкания питающего пути. Это означает, что сотрудник, выполняющий задание на питающем пути, должен на чать свою работу немножко раньше, поскольку мы не хотим, чтобы критический ресурс ждал свою работу. По чему нам следует создать этот буфер? К примеру, мы должны заплатить за какое-то оборудование или подож-дать что-то, на что у нас может уйти на несколько дней больше, чем было запланировано. Пусть лучше задерж ка произойдет на питающем пути, но к моменту, когда задание должно перейти на критическую цепь, оно дол жно быть завершено предыдущим ресурсом. Рассмотрим следующий шаг, который сделает проект еще более защищенным. Иногда мы не имеем всех необходимых ресурсов или же они не готовы к использо ванию, либо мы вынуждены начать работу над каким-то срочным проектом-сюрпризом. Почему бы не сообщить людям заранее о том, что они должны подготовиться к выполнению задания из критической цепи? В начале про екта, когда до выполнения конкретного задания должно пройти несколько месяцев, мы не можем назвать точную дату начала работы над этим заданием. Однако, скажем, за 10 дней до того, как будет необходимо приступать к ра боте, мы предупредим об этом сотрудника, проинформи руем, что существует высокая вероятность прихода крити ческой цепи в его отдел в ближайшем будущем. Таким об разом, мы вводим так называемые ресурсные буферы, которые на самом деле являются информационными. Предупреждая сотрудников, мы защищаем себя от воздей ствия одного из законов Мерфи: ситуации, когда ресурсов нет именно тогда, когда они нужны. Итак, у нас есть три типа буферов: защитный буфер всего проекта в конце самой длинной (критической) цепи; питающий буфер в конце каждого питающего пути крити ческой цепи; ресурсный буфер — время, за которое мы предупреждаем ресурс о том, что ему будет дано задание для немедленного выполнения. В результате мы получили систему измерения, позво ляющую нам сравнить реальное состояние проекта с за планированным. Каким образом это скажется на реализа ции проектов, планируемых таким образом? Исполнение проекта перестает напоминать импровизацию, потому что теперь мы имеем надежную систему информации — бу феры, которые мы ввели в план. Мы смотрим, что проис ходит в буферах, сколько буфера уже было выбрано, сколько осталось, и в соответствии с этим принимаем ре шение. Каким образом измерить, насколько мы успешны на пути реализации проекта? Самая важная вещь, требую щая нашего внимания, — критическая цепь. Нам необхо димо знать, сколько процентов критической цепи уже за вершено. Если вы посмотрите на проекты, то увидите, что большинство заданий находятся не на критической цепи, а на параллельных линиях, из-за чего можно легко поте рять правильный фокус. Теперь же, когда мы знаем, что критическая цепь — это то, что важно для всего проекта, мы понимаем, что на самом деле важно то, какую часть критической цепи мы закончили, и совершенно не имеет значения, закончено 20% или 90% других заданий. Если мы продвинулись по критической цепи только на 50%, не имеет значения то, что по остальным некритическим за даниям пройдено 90%. В действительности проект завер шен только на 50%. Если вы используете подход критиче ской цепи, то четко видно, на каком этапе находи.ся проект. Если сделана половина критической цепи и использовано 80% буфера, значит, существует высокий риск опоздания. Если выбрано 50% буфера — работа идет по плану. А если, сделав половину критической цепи, мы выбрали лишь 20% буфера, это значит, что идем с опережением плана. Возможно, в следующий раз мы смо-жем планировать более жестко и установить более корот кий срок. Как измерить буфер? Так же, как измеряется уровень воды в резервуаре. Если на выполнение задания ушло на 3 дня меньше, чем было запланировано, это зна чит, что мы увеличили буфер на 3 дня. Если выполнение задания опаздывает на 3 дня — буфер уменьшится на 3 дня. Буфер динамичен. Нам все время видно, сколько бу фера осталось. Не менее важно регулярно получать информацию о том, над каким заданием ведется работа и сколько еще времени, по мнению исполняющего, потребуется для его завершения. Руководитель проекта должен постоянно спрашивать исполняющего задание: «Как вы думаете, сколько у вас уйдет времени, чтобы закончить задание?». Да, мы знаем, что эта оценка может не соответствовать действительности, однако данная информация — своего рода показатель того, как идет реализация проекта. Пред положим, на выполнение одного задания было потрачено на 5 дней больше, чем планировалось. Это означает, что мы выбрали из буфера 5 дней. Вероятно, мы сможем далее компенсировать эти дни, а может быть, и нет. Допу стим, мы уже работаем 3 дня над заданием, на выполне ние которого запланировано 15 дней. На третий день узнаем у исполняющего это задание, что по его оценке ему потребуется еще 15 дней, чтобы завершить и передать его следующему ресурсу. Что это означает? Что мы уже потенциально потеряли 3 дня из буфера, поскольку со гласно нашему плану он должен был сказать: «12 дней». Если, отвечая на этот же вопрос, на следующий день спе циалист отвечает что ему требуется 14 дней на заверше ние задания, мы понимаем, что состояние буфера не из менилась. Если же он назовет 15 или 17 дней, мы прогно зируем, что из буфера будет выбрано еще больше време ни. Каждый день мы смотрим на динамику буфера и ви дим, что происходит с нашим проектом. Преимущество такой системы в следующем: если задание действительно серьезно бьет по нашему буферу, мы можем предпринять какие-то срочные действия, чтобы исправить положение По сути дела, воздействие закона Мерфи пробивает дыры в наших резервуарах (буферах) и таким образом наносит ущерб нашей защите. В чем состоит задача руководителя проекта? Он должен найти способ компенсировать то, что «забрал» Мерфи. Давайте посмотрим на рисунок 7 и сравним два про екта, один из которых управляется традиционным спо собом, а другой — по системному подходу теории ограничений Каким из этих проектов вы хотели бы управлять?
<< | >>
Источник: Коллектив авторов. Менеджмент. Стратегии с которыми побеждают. 2006

Еще по теме Управление проектами перемен и перемены в управлении проектами:

  1. 27 УПРАВЛЕНИЕ ПРОЕКТОМ
  2. Организация управления проектом
  3. 23.1. Управление при помощи проектов
  4. Управление проектами
  5. Содержание процессов управления проектом
  6. 23.3. Методы управления проектами
  7. 2.3.3. Информационные системы управления проектами
  8. ГЛАВА 4. УПРАВЛЕНИЕ ИННОВАЦИОННЫМИ ПРОЕКТАМИ
  9. Современные подходы к управлению проектом
  10. Организационные формы управления проектами
  11. Предоставление отчётов команде по управлению проектом
  12. 23.4. Организационные структуры управления проектом
  13. 3.5.Цели и задачи управления инвестиционными проектами