Основы проектного менеджмента. Классическое руководство Хигни Джозеф

В главе 1 отмечалось, что управление рисками – это процесс систематической идентификации, анализа и реагирования на риски, связанные с проектом. Ключевым словом здесь является систематический, поскольку многие руководители проектов пытаются работать с рисками без соблюдения соответствующих норм и формальностей, не уделяя планированию этой работы достаточно внимания, а то и вовсе игнорируя его. Это верный способ призвать на свою голову неудачу, если не катастрофу. Нормальный комплексный план по рискам проекта позволяет руководителю занимать активную позицию, если что-то пойдет не так. Без этого плана ему придется реагировать на те или иные сбои в проекте по ходу дела, а это самый дорогой из возможных сценариев. Системность придает работе порядок и эффективность. В конце главы 5 уже были сжато изложены важнейшие пункты работы по противодействию рискам проекта. Здесь эта тема раскрыта более подробно.

Определение управления рисками проекта

Управление рисками проекта начинается на самом раннем этапе его жизненного цикла. Должно быть выработано ясное понимание возможных рисков. Источники рисков практически бесчисленны, что только подчеркивает необходимость хорошо продуманного и детального плана работы с ними. Типичные примеры – уход из команды ключевого участника, погодные катаклизмы, сбои в работе техники и плохое обеспечение ресурсами.

Многие руководители проектов затягивают с оценкой рисков и откладывают разработку плана их управления, полагая, что многих деталей проекта они еще не знают и в нем много неизвестных факторов. Это известная западня, которой следует остерегаться. Еще на фазе инициации жизненного цикла проекта необходимо осуществить общую первичную оценку рисков. Руководитель проекта и члены команды должны со стратегической точки зрения ответить на вопрос «Что может пойти не так?» и заложить основу детального плана соответствующих действий. Без такого основания проекты часто подвергаются негативному воздействию рисков, которые неожиданно становятся реальностью, хотя их можно было предотвратить или вообще устранить, имея планы на случай непредвиденных ситуаций. Такой подход характеризуется как реактивно-пассивный, то есть лишь реагирующий на возникший раздражитель, тогда как успешный руководитель проекта должен занимать проактивную, наступательно-опережающую позицию. Иногда в ходе проекта возникают и потенциальные возможности – «позитивные риски», которые руководитель проекта должен использовать для достижения целей проекта.

В Руководстве к Своду знаний по управлению проектами (PMBOK® Guide) управление рисками проекта определяется в качестве одной из областей знаний. PMBOK описывает управление рисками проекта как «процессы, связанные с планированием управления рисками, идентификацией, анализом, планированием реагирования, а также с мониторингом и контролем рисков в проекте» (PMBOK, 555). Таким образом, эти процессы нужно понимать как строящиеся по заданным правилам и контролируемые мероприятия, не допускающие вариаций или допускающие их в минимальной степени. Применительно к процессам проекта вариации обычно равнозначны неэффективности. Важно управлять рисками правильно, хотя с учетом реальностей и переменных в типичной среде проекта какая-то степень гибкости, конечно, возможна. По мере накопления опыта в управлении рисками у вас начнет развиваться интуитивное ощущение возможных пределов этой гибкости в зависимости от типа, продолжительности, объема, глубины и широты проекта.

Шесть шагов процесса планирования управления рисками проекта

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

Мозговой штурм. Составление списка потенциальных рисков проекта не должно носить характер аналитической разработки; нужен настоящий мозговой штурм, когда подхватываются на лету все идеи. Шаги 2 и 3 позволяют подробно рассмотреть их. В идентификацию потенциальных угроз и того, что может пойти не так, важно вовлечь всю команду. Некоторые руководители проектов пытаются проделать эту работу самостоятельно, чтобы дать членам коллектива возможность выполнить другие задачи. Это близорукий и вредный подход. Начальный шаг должен осуществляться в атмосфере тесного сотрудничества и включать в себя всех членов команды, являющихся специалистами в своих сферах и отвечающих за свои части проекта. Максимально задействуйте интеллектуальный капитал всей команды. Если за пределами такого мозгового штурма окажется хотя бы один член коллектива, весьма вероятно, что часть рисков останется неидентифицированной и успех проекта будет под угрозой. Помните, что нужно вовлекать всех: специалисты по закупкам (снабженцы) не помогут определить возможные проблемы разработки программного обеспечения, а программисты – проблемы с закупками.

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

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

Я объединяю шаги 2 и 3, поскольку они оба связаны с классификацией рисков по приоритетности. Они помогают расставить риски в порядке очередности и определить, сколько времени, усилий, человеческих ресурсов и денег следует направить на предотвращение каждой из идентифицированных угроз или на смягчение ее негативных последствий. Это также следует осуществлять с полным участием членов команды и привлеченных экспертов по предметной области (Subject Matter Experts, SME).

Насколько вероятно, что каждый из идентифицированных рисков станет реальностью? Этот вопрос надо и задавать, и отвечать на него. Часто достаточно использовать шкалу вероятности «Высокая – Средняя – Низкая» и применить соответствующий показатель к выявленному риску. Если вероятность риска высока, его помечают литерой «В»; если вероятность средняя, он получает обозначение «С»; если же низкая – «Н». Эти показатели не должны присваиваться рискам произвольно. Необходимо энергичное сотрудничество всей команды и активная аналитическая и исследовательская работа руководителя проекта для их правильного определения.

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

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

Тем, кто предпочитает количественные оценки, можно предложить простую таблицу. Реальность риска и его негативный эффект оценивайте в цифровых показателях. Шкалу вероятности можно установить в пределах от 1 до 10. При этом 1 будет означать самую малую вероятность, а 10 – самую высокую. Негативное воздействие можно оценить по той же шкале или прямым ущербом для бюджета проекта.

В соответствии с данными таблицы главное внимание команды должно быть направлено на проект В из-за высокой стоимости риска по нему: $28 000. По тому же принципу можно определить негативный эффект для графика или распределения ресурсов.

Одни риски удается предотвратить, последствия других можно только минимизировать. Например, землетрясения или уход в отставку важного заинтересованного лица предупредить нельзя. Но некоторые риски могут и должны быть предотвращены с помощью шага 4. Если вы идентифицировали риск и имеете возможность не допустить его, делайте это. Активность и наступательность – лучшие союзники руководителя проекта. Ликвидируйте риск до того, как он получит возможность роста и развития. Тогда вам не придется иметь с ним дела в дальнейшем.

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

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

Превентивные меры – это действия, которые предпринимаются до того, как риски становятся реальностью. Меры на случай непредвиденных ситуаций – действия, производимые при материализации рисков. Разрабатывая эти меры, вы отвечаете на вопрос «Что делать, если риски станут реальностью?».

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

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

Точка пуска нередко является важнейшим элементом плана рисков проекта. Между этой точкой и «запуском» чрезвычайных мер существует прямая связь. Как отражено в самом названии этой точки, она определяет некую границу, за которой риск становится достаточно реальным для того, чтобы руководитель проекта задействовал чрезвычайные меры. Это трудное решение должно обеспечить эффективность заранее продуманных чрезвычайных мер, если они будут осуществлены в оптимальное время. Активируйте «точку пуска» слишком рано – и вы, скорее всего, потратите время, усилия и средства впустую. Определите эту точку слишком поздно – и риск может материализоваться в худшем своем проявлении. При этом план на случай чрезвычайной ситуации уже не сработает. Однако вернемся к нашему примеру.

Если у надежного поставщика возникли проблемы с персоналом и он вынужден был остановить производство из-за забастовки, то, скорее всего, у вас на такой случай предусмотрены альтернативные поставщики Б и В. У каждого имеются на складе нужные вам устройства, и каждый поставил условие, что ему необходимо две недели для поставки. Если устройства нужны к 15 февраля, «точка пуска» даст вам эти две недели плюс-минус несколько дней. Значит, оптимальной «точкой пуска» будет 31 января. Если меры на непредвиденный случай приходятся на особо сложный период исполнения проекта, необходимо предусмотреть возможность прибавить еще несколько дней.

«Точка пуска» должна быть либо определенной точкой, либо согласованным отрезком времени. Большинство руководителей проектов рассматривают «точки пуска» как самый деликатный момент в планировании управления рисками проекта. Однако они стоят затрачиваемых усилий. Как консультант я часто сталкиваюсь с хорошо продуманными планами управления рисками, которые проваливаются из-за несвоевременного применения чрезвычайных мер или отсутствия таковых. «Точка пуска» включения чрезвычайных мер должна стать для руководителей проектов важным элементом, который улучшает эффективность управления рисками в целом.

Создание резервов

Самый полный план управления рисками проекта окажется ничтожным, если в нужный момент у вас не найдется времени или средств, чтобы принять необходимые меры. Создание резервов позволит вам использовать полный потенциал вашего плана. Самые хорошо составленные планы часто оказываются недейственными, если в них не предусмотрено достаточно времени и средств для исполнения. Таким образом, любой руководитель проекта должен предусмотреть резервы для чрезвычайных ситуаций и управленческие резервы.

Резервы для чрезвычайных ситуаций – это запас времени и средств, позволяющий реагировать на риски, которые идентифицированы и приняты. Эти резервы создаются для того, чтобы покрывать известные риски. Между резервами для чрезвычайных ситуаций и «процессом в шесть шагов» (или другим подобным подходом) существует прямая связь. Когда процесс из шести шагов завершен, руководитель должен оценить резервы, необходимые для покрытия идентифицированных и признанных рисков.

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

Управленческие резервы создаются для покрытия неизвестных рисков по проекту. Иногда вы действительно не знаете того, чего не знаете. Например, если ваш текущий проект включает в себя большие объемы научно-исследовательских и опытно-конструкторских разработок (НИОКР), а анализ исполнения подобных предыдущих проектов показывает среднее превышение сметы по ним на 10 %, то эти 10 % не могут быть отнесены ни к какому рисковому событию. Однако такая информация диктует необходимость увеличить общий бюджет проекта на 10 % в качестве управленческого резерва.

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

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

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

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

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

Что касается программы проектов, в ней взаимоотношения между проектами определены более точно. Например, в программу легкой атлетики входит эстафета, в которой четыре бегуна должны передать друг другу эстафетную палочку. Самая быстрая команда выигрывает не всегда, потому что в передаче эстафетной палочки бывают ошибки и ее могут даже уронить. Многие проекты в программах имеют отношения типа «предшественник – последователь» (один проект должен быть завершен до того, как начинается новый). Для того чтобы обеспечить плавный переход от одного проекта к другому, необходимо уделять всемерное внимание процессу «передачи эстафетной палочки». План управления мультипроектными рисками как раз концентрируется на таких событиях.

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

Действенным инструментом управления рисками является стандартная матрица рисков (рис. 6.1). Она поможет расположить проекты в квадратах в соответствии с вероятностью наступления рисков и их негативным воздействием.

Рис. 6.1. Матрица рисков

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

Эффективным инструментом управления рисками проектов является также реестр рисков (табл. 6.1).

Таблица 6.1. Реестр рисков

Источник: семинар Американской ассоциации менеджмента «Повышение навыков управления проектами: основа успеха».

Реестр рисков, последний компонент в инструментарии управления рисками проекта, – живой, динамичный механизм, который поможет отслеживать статус рисков, пока ваш проект развивается в своем жизненном цикле. Реестр рисков также позволяет определять ответственных за проведение акций, совершаемых в непредвиденных и чрезвычайных ситуациях, результаты этих акций, а также активные и латентные риски.

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

План управления коммуникациями проекта

Проводя семинары по проектному менеджменту, я прошу слушателей идентифицировать трудности, с которыми они могут столкнуться при управлении проектами.

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

Начнем с электронной почты. Да, мы до сих пор проводим совещания, звоним заинтересованным сторонам проекта по телефону или лично встречаемся с членами своей команды. Однако сегодня в коммуникациях проектов доминирует электронная почта. Большинство из нас смирилось с этим. Электронная почта прочно вошла в нашу жизнь, позволяя моментально связываться с адресатом на другом конце планеты или в другом конце зала совещаний. Она дает возможность выстраивать наши ответы по их приоритетности, а в случае необходимости – создавать и бумажную «нить» общения. Все это хорошо, но по своему опыту я заметил, что мы еще не полностью освоили все возможности этой технологии и не научились максимально использовать ее потенциал.

Разве вам не приходилось получать электронные сообщения на пяти машинописных страницах с бесчисленными параграфами? Некоторые сообщения напоминают новеллы, посвященные любимым. И наоборот, некоторые имейлы из трех слов оставляют адресата в недоумении по поводу того, что же хотел сказать отправитель. Такую манеру использования электронной почты я называю «коммуникациями Дикого Запада». В ней не существует никаких правил, законов или норм. Электронные коммуникации по проекту зависят от вкусов и привычек отправителей и получателей. Это оставляет впечатление «свободного полета мысли» и никоим образом не сочетается со средой проекта, в котором есть строгие ограничения по содержанию, расписанию и расходам.

Создайте отдельный порядок электронной переписки и следите за тем, кто и с кем поддерживает связь по проекту. Уточняйте, какие электронные сообщения должны поступить конкретной заинтересованной стороне проекта. Разработайте рекомендации сотрудникам по тому, кого ставить в копию сообщений. Разве не приходилось вам вернуться из отпуска и обнаружить в своей электронной почте 500 копий писем, большинство которых не имело отношения ни к вам, ни к вашему проекту? Просматривать их не просто утомительно – они отнимают много времени. Соберите команду и с ее участием создайте порядок электронной переписки по проекту. Этим вы реально повысите эффективность коммуникаций проекта и встретите понимание со стороны членов коллектива.

Несколько рекомендаций руководителям проектов и членам команды по использованию электронной переписки по проекту.

• Посылайте электронные сообщения только тем, кому они необходимы.

• Внимательно перечитайте имейл перед отправкой, используйте режим проверки правописания.

• Используйте раздел «Тема сообщения».

• Создайте в команде правила использования электронной почты и придерживайтесь их.

• Если вы рассердились… подождите немного, прежде чем отправлять сообщение.

• Не пишите романов, будьте кратки.

• Соблюдая краткость, старайтесь включать в сообщение всю необходимую информацию.

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

• Если информация носит деликатный или закрытый характер, встречайтесь со своими корреспондентами лично.

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

Вот некоторые вопросы по плану управления коммуникациями проекта.

• Что является предметом коммуникаций по проекту?

• Когда эти коммуникации должны осуществляться (в конце года, в другое время)?

• Как будут осуществляться коммуникации (по электронной почте, путем направления бумажных документов с оригиналами подписей, на совещаниях)?

• Как часто должны осуществляться коммуникации?

• Кто отвечает за коммуникации (и обеспечивает их осуществление)?

• Кто является адресатом коммуникаций?

Дав ответы на эти вопросы, вы сможете составить план управления коммуникациями проекта (табл. 6.2).

Таблица 6.2. План управления коммуникациями проекта

Некоторые хорошие руководители проектов, с которыми я встречался и работу которых наблюдал, – умные, работоспособные, отлично разбирающиеся в современных компьютерных технологиях – не всегда добиваются успеха, потому что неправильно подходят к разработке и исполнению плана управления коммуникациями проекта. Они его просто не составляют. А вы обязательно разработайте такой план!

Резюме

• Управление рисками проекта должно начинаться на старте и продолжаться на протяжении всего жизненного цикла. Ключ к успеху в том, чтобы начинать эту работу как можно раньше и заложить для нее прочную основу; подходить к этим вопросам проактивно; правильно управлять рисками в рамках процесса и проявлять гибкость.

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

• Создание резервов на случай чрезвычайных ситуаций и управленческих резервов позволяет максимально использовать потенциал вашего плана по управлению рисками.

• Стандартная матрица рисков – полезный инструмент при управлении большим количеством рисков в проекте.

• Реестр рисков может стать эффективным инструментом классификации угроз проекту и выделения главных из них.

• Создайте порядок использования электронной почты в проекте; привлеките к этому членов вашей команды для достижения единого понимания.

• Разработайте собственный план управления коммуникациями проекта. Этот процесс так же важен, как и все другие процессы управления проектами.

Упражнение

Выберите один из своих текущих или прошлых проектов и попрактикуйтесь на нем в «шестишаговом процессе». Составьте список потенциальных рисков, выделите главные, пользуясь показателями «В – С – Н» или просто цифровой шкалой. Выберите три любых риска и разработайте для них:

• превентивные меры;

• чрезвычайные меры;

• «точки пуска».

Достаточно двух-трех таких точек для каждого риска.

В предыдущей главе говорилось, что план должен отвечать на вопросы «Что необходимо сделать?», «Сколько это займет времени?» и «Сколько это будет стоить?». Планирование составляющей плана под названием «Что?» очень важно, потому что проекты часто терпят неудачу, поскольку о значительной части работы просто забывают. Когда задачи проекта определены, необходимо сформулировать требования к его срокам и ресурсам. Этот процесс называется оценкой.

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

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

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

Простой пример

Приведем простой пример: уборка комнаты (рис. 7.1). Скорее всего, она начнется со сбора разбросанной одежды, игрушек и других вещей. Я могу почистить ковер пылесосом. Могу помыть окна и протереть стены, потом протереть мебель от пыли. Все эти действия явятся субзадачами по отношению к задаче уборки комнаты.

Рис. 7.1. Схема ИСР по уборке комнаты

Для того чтобы пропылесосить комнату, нужно достать пылесос из кладовки, присоединить шланг, вставить штепсель в розетку, перемещать пылесос по комнате, выбросить пыль из мешка, а потом убрать пылесос обратно в кладовку. Это еще более мелкие задачи по отношению к субзадаче «пропылесосить». На рисунке 7.1 показано, как это может быть отображено в формате ИСР.

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

Типичная ИСР имеет от трех до шести уровней (рис. 7.2). Конечно, бывают проекты и с большим количеством уровней иерархичности работ. Обычно пределом считается 20 уровней. Но это относится только к очень крупным проектам. Обратите внимание, что уровень 1 называется программным. Разница между программой и проектом только в одном уровне.

Рис. 7.2. Уровни иерархической структуры проекта

Примером программы является создание самолета; ИСР для нее показана на рис. 7.3. Обратите внимание, что конструирование и строительство двигателя, крыльев и авионики представляют собой отдельные проекты. Задача руководителя программы – правильная интеграция отдельных проектов. Двигатель крепится к крылу, так что в ИСР по двигателю будет обозначен такой элемент, как «Разработка на крыле системы крепежа двигателя», а в ИСР по крылу – «Разработка на двигателе системы крепежа к крылу». Если эти элементы работ не будут правильно скоординированы, то крепежи двигателя не подойдут к крепежам крыла. Такая работа по координации называется системной интеграцией.

Рис. 7.3. Компоненты ИСР

Рекомендации по разработке ИСР

Один очень важный вопрос при разработке ИСР заключается в следующем: «До какой степени можно «измельчать» работы»? Общий принцип состоит в том, чтобы разбивать (декомпозировать) работы по проекту до такой степени, до какой можете определить их срок и стоимость с желаемой точностью; или до такой степени, когда работа станет занимать минимальный отрезок времени, с которым вы планируете составлять ее расписание. Если это расписание до ближайшего дня, разбейте работу на такие порции, в которых выполнение очередных задач занимает примерно день; если до ближайшего часа, то продолжительность выполнения задачи должна составлять около часа.

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

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

Существует по крайней мере одно программное обеспечение, которое называется «Эксперт по суперпроектам» (SuperProject Expert™), которое сразу компонует и распечатывает ИСР после того, как заложены данные о расписании проекта. Это неплохая программа, тем более что она сразу «выдает» привлекательную картинку ИСР. Однако, прежде чем ее запускать, нужно составить хотя бы приблизительный рисунок ИСР, потому что до тех пор, пока каждый член команды не согласится, что идентифицированы все задачи, любое расписание будет обманчивым. Нет уверенности в том, что главный путь исполнения проекта, намеченный на основании частичного расписания, совпадет с тем, который определен на основе полной гармонограммы проекта.

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

ИСР не должна быть симметричной, то есть все ее направления не обязательно должны быть разбиты, например, до шестого уровня. Поскольку правилом является декомпозиция работ до того уровня, на котором вы добиваетесь желаемой точности оценки сроков и стоимости, одно направление ИСР может иметь шесть уровней, а другое, например, три.

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

Важной функцией ИСР является распределение ответственности за решение тех или иных задач. Каждая намеченная к выполнению задача должна быть поручена конкретному исполнителю, который несет ответственность за ее решение. Форма распределения ответственности показана в табл. 7.1.

Таблица 7.1. Схема распределения задач

Оценка сроков, стоимости и ресурсов проекта

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

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

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

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

Такова общая идея. Однако по закону Паркинсона («работа занимает все отведенное на нее время») выполнение задачи может занять больше отведенного времени, но почти никогда – меньше. Одна из причин – если остается время, люди стремятся улучшить сделанное. Другая причина – работники опасаются, что, если они будут сдавать работу раньше срока, им установят более жесткие временные нормативы или увеличат нормативы производительности.

Это очень важный момент: если людей наказывать за то, что они работают лучше, чем установлено нормативом, они перестанут это делать. Следует также принимать во внимание вариабельность результатов труда. Если один и тот же человек сортирует карты снова и снова, результаты у него будут различаться. Иногда ему потребуется две минуты, иногда – четыре. В среднем это три минуты, но можно ожидать, что в половине случаев результат составит три минуты и менее, а в половине – три минуты и более. Очень редко он будет равняться точно трем минутам.

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

То же самое относится и ко всем задачам по проектам. Время их выполнения различается вследствие действия сил и обстоятельств, неподконтрольных индивидууму. Карты в колоде перемешаны каждый раз по-новому. Внимание работника может отвлекать громкий посторонний шум. Работник может уронить карту во время сортировки. Может устать. И так далее.

Можно ли избавиться от вариабельности? Никогда.

Можно ли снизить ее роль? Да, через постоянную практику, путем внесения изменений в процесс работы и т. д. Однако важно подчеркнуть, что определенные колебания в результатах труда людей будут всегда. Мы должны понимать и принимать это.

Вот история Кэрен. Однажды руководитель остановился около ее рабочего стола примерно в час дня. «Нужно сделать для меня оценку проекта, – сказал он Кэрен. – Я обещал шефу представить ее к четырем часам. Сделаешь?»

Кэрен кивнула и несмело улыбнулась шефу. «Мне нужна только приблизительная оценка», – сказал он и выплыл из комнаты.

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

Прошло два месяца. И вдруг разорвалась бомба. На пороге ее комнаты появился улыбающийся руководитель. «Помнишь ту оценку, которую ты готовила для меня по проекту XYZ?»

Кэрен напряглась, припоминая. Руководитель не уходил, и она наконец вспомнила то задание. На стол Кэрен легла толстая пачка документации. «Вот теперь твоя работа», – сказал он и уплыл в руководящие сферы.

Просматривая документы, Кэрен чувствовала все большую озабоченность. Между их содержанием и тем, о чем говорил руководитель, предлагая оценить проект, была огромная разница. «Ничего, наверняка он знает об этом», – поспешила успокоить себя Кэрен.

В конечном счете она составила новую оценку стоимости проекта, основываясь на переданных боссом документах. Она оказалась почти на 50 % выше, чем первоначальная. Она еще раз проверила все цифры, убедилась, что ее расчеты правильны, и пошла к руководителю.

Едва взглянув на цифры, он буквально взорвался. «Ты что со мной делаешь?! Я уже сказал шефу, что мы сделаем все за ту цену. Я не могу теперь заявить, что проект стоит настолько дороже. Он убьет меня!»

«Но ведь вы тогда говорили, что нужна только приблизительная цифра, – защищалась Кэрен. – А вот что дали мне теперь. Это и рядом не лежит с тем объемом, который вы называли раньше. Это намного больше».

«Ничего не могу поделать, – уперся руководитель. – Я уже ознакомил его с теми цифрами. Тебе придется найти способ уложиться в них».

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

Нетрудно предположить окончание этой истории. Стоимость работ в итоге оказалась даже больше той, которую Кэрен подсчитала во второй раз. Были громы, молнии и стенания, но в конечном счете Кэрен осталась на своем рабочем месте. Правда, руководство послало ее на курсы по проектному менеджменту, надеясь, что она научится составлять более правильные оценки.

Американская ассоциация менеджмента популяризирует несколько методов, которые могут помочь руководителям проектов готовить правильные и хорошо обоснованные оценки предстоящих работ.

Опора на предыдущий опыт

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

Уровень детализации оценок

Устанавливайте адекватный уровень детализации своих оценок. Если вы в фазе инициации проекта, то достаточно наметить крупные компоненты оценок. Если вы уже составили иерархическую структуру работ и находитесь на продвинутой стадии планирования проекта, следует разбить его на более мелкие компоненты. Чем меньше единица или пакет работ, тем более точной будет ваша оценка.

Персональная ответственность за подготовку оценок

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

В таблице 7.2 показано, что стандартная 40-часовая рабочая неделя должна учитывать неизбежные потери в проекте (15 %), переделки/исправления (10 %) и дополнительные затраты труда. Как показывают цифры, оценочные затраты труда составляют 56 часов, а не 40, оценочная потребность в рабочих днях составляет семь, а не пять дней.

Таблица 7.2. Производительность труда работника

Менеджеры проектов должны работать в реальном мире. Мы выполняем работу в трех координатах: содержание, время и стоимость (см. рис. 11.1). Следовательно, при составлении оценок по проектам нужно учитывать реальную производительность труда.

Баланс между сроками, стоимостью и ресурсами проекта

Работая над созданием среды проекта, не забывайте о динамике человеческой природы. Помните, что члены вашей команды не роботы.

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

Рис. 7.4. Взаимозависимость между сроками, стоимостью и ресурсами проекта

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

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

Первая оценка оптимистичная, или оценка, основанная на наилучшем сценарии. Вторая – пессимистичная, или оценка, основанная на наихудшем сценарии. И третья оценка – наиболее вероятная.

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

где О – оптимистичная оценка, НВ – наиболее вероятная оценка, П – пессимистичная оценка.

Один из вариантов оценок по трем точкам – техника оценки и анализа проектов (Program Evaluation and Review Technique, PERT). Она была разработана в 1957 году для проекта по конструированию ракет Polaris для подводных лодок специальной командой, в которую входили представители Департамента исследований военно-промышленных корпораций Booz Allen Hamilton, департамента ракетостроения Lockheed и отделения оценки программ ВМФ США.

Многие проекты являются предприятиями по решению уникальных задач, которые до них не решались. Соответственно, нет никаких предшествующих или архивных данных. Программа PERT оказалась очень эффективной в оценке такого рода проектной среды. Она особенно хорошо работает там, где присутствует высокий уровень неопределенности и очень высоки пессимистичные оценки. PERT позволяет управляющему проектом использовать специальный индекс по отношению к оценке наибольшей вероятности в том случае, если она базируется на опыте и всестороннем анализе фактической ситуации. Различие между ней и средним стандартом методики трех точек заключается в том, что в программе PERT эта оценка содержит фактор утяжеления, так что она становится утяжеленным средним стандартом. Вы прибавляете вес наиболее вероятной оценке потому, что, основываясь на опыте и реальности, считаете, что таким будет наиболее вероятный результат. Оценка наибольшей вероятности умножается на фактор 4 (4НВ). Таким образом, наиболее вероятная оценка учитывается четыре раза, а оптимистическая и пессимистическая – всего по разу. Всего получается знаменатель из шести единиц. Поэтому, вычисляя оценку наибольшей вероятности по методике PERT, вы делите сумму на шесть.

где О – оптимистичная оценка, НВ = оценка наибольшей вероятности, П = пессимистичная оценка.