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

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

Путаница в терминах

Предположим, кто-то говорит вам, что он нашел работу в другом городе и собирается туда переехать. Этот человек сразу понимает, что нужно найти жилье. И он говорит:

– У меня проблема. Я должен найти жилье.

Вы спрашиваете, какова его миссия.

– Найти жилье, – отвечает он.

– А как насчет видения?

– Иметь жилье, – отвечает он, слегка сконфуженный.

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

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

– В своем жилье в новом городе, – ответил бы он.

– А что сейчас? – спросите вы.

– Сейчас у меня жилья нет, – скажет он.

Таким образом, разрыв состоит в наличии или отсутствии жилья. Это можно сформулировать очень просто: «У меня нет жилья». Это и есть та проблема, которую человек пытается решить.

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

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

Рис. 5.1. Шеврон, показывающий миссию, видение и проблему

Реальный мир

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

А вот главный «политический» казус, с которым вы можете столкнуться: спонсор проекта вооружил вас миссией (общей задачей), основанной на его собственном определении проблемы, которая должна быть решена. А это определение может быть неправильным, и вам придется противостоять ему. Иначе вы потратите много денег организации только для того, чтобы понять, что вы разработали правильное решение для неправильно сформулированной проблемы.

Реальная миссия для любого проекта

Итак, миссия нужна, чтобы достичь видения. Добавлю, что то видение, которого вы только пытаетесь достичь, уже есть у вашего клиента и вы должны удовлетворить его потребности. Это главная задача. Вы можете руководствоваться мотивом извлечения прибыли, но ваша миссия всегда в том, чтобы соответствовать запросам клиента. Естественно, вы должны знать эти запросы. Иногда это нелегко, потому что потребители сами не всегда ясно представляют, чего хотят; поэтому вы должны стараться правильно интерпретировать суть их потребностей. Лучшей вашей гарантией при этом будет вовлечение заинтересованных сторон в проект от этапа выработки его концепции до этапа закрытия. Это позволит контролировать, все ли действия по проекту дают желаемый результат.

Миссию проекта можно записать, дав ответ на два вопроса:

1. Что мы собираемся делать?

2. Для кого мы собираемся это делать?

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

Определение целей проекта

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

Постановка целей традиционно базировалась на прошлых результатах. Эта практика способствовала закреплению в настоящем грехов прошлого.

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

Цель обозначает желаемый результат. Задача обозначает действие, совершаемое для достижения этого результата. Цель обычно выражается существительным, тогда как задача – глаголом.

Одна аббревиатура поможет вам запомнить основные характеристики документа, который можно назвать постановкой целей. Мы говорим, что цель должна быть SMART: конкретной, измеримой, достижимой, реальной и определенной по времени (сокращение от соответствующих английских слов: specific, measurable, attainable, realistic, time limited).

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

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

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

Все мы знаем, что одни люди способны на большее, чем другие. Поэтому сделать какую-то цель или группу целей измеримыми и достижимыми очень трудно. Я расскажу об этом подробнее в главе 6, когда буду говорить об оценке срока проекта.

Для определения целей и задач проекта и мониторинга прогресса в их достижении полезно поставить два вопроса.

1. Каков желаемый результат? Это система координат по результату. Она помогает сосредоточиться на том результате, который вы хотите достичь, а не на усилиях, которые для этого затрачиваете.

2. Как мы узнаем, что достигли желаемого результата? Я называю этот вопрос «доказательным». Он помогает установить критерии выхода в тех случаях, когда результат не может быть измерен количественно.

Приведу два примера целей.

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

• Наша цель состоит в том, чтобы собрать в фонд пожертвований от местных телезрителей $600 000 к 18 сентября 2016 года.

Характер цели

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

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

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

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

Целесообразно оценивать возможность возникновения в проектах рисков по следующим параметрам:

В расписании проекта

В его бюджете

В качестве проекта

В удовлетворенности заказчика

Таблица 5.1. Пример анализа рисков по проекту

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

Я уже отмечал, но не могу не повторить: старайтесь идентифицировать не каждый возможный риск, а только наиболее вероятные. Это следует отдельно разъяснить тем членам команды, которые имеют особую склонность к анализу или часто занимают позицию отрицания. Анализ рисков несет в себе позитивный заряд – вы как бы спрашиваете: «Если произойдет то-то и то-то, что мы будем с этим делать?» Вы же не провоцируете людей кричать: «Это будет ужас!»

В главе 6 я приведу подробные данные об инструментах и методиках управления рисками в проектах.

Резюме

• Как вы сформулируете проблему, так и будете ее решать.

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

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

• Миссия состоит в том, чтобы достичь видения. Она отвечает на два вопроса: «Что мы собираемся делать?» и «Для кого мы собираемся это делать?»

• Цели должны быть SMART: конкретными, измеримыми, достижимыми, реальными и определенными по времени (сокращение от соответствующих английских слов: specific, measurable, attainable, realistic, time limited).

Упражнение

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

1. Чего вы хотите достичь этим проектом? Какую потребность вашего заказчика или клиента он удовлетворяет? Кто конкретно реально воспользуется конечным результатом(-ами) проекта? (То есть кто является вашим настоящим заказчиком или клиентом?)

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

3. Сформулируйте и запишите миссию проекта, ответив на два основных вопроса: «Что мы собираемся делать?» и «Для кого мы собираемся это делать?».

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

Ответы на вопросы

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

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

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

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

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

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

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

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

Шаг 1. составьте список рисков

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

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

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

Шаги 2 и 3. определите вероятность материализации риска и его возможное негативное воздействие на проект

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

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

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

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

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

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

Шаг 4. предотвращайте риски или минимизируйте их последствия

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

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

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

Шаг 5. заранее разрабатывайте меры на случай чрезвычайных ситуаций

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

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

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

Шаг 6. определите «точку пуска» для включения чрезвычайного плана

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

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