Я некоторое время работал над темой управления рисками в разработке программного обеспечения. Согласно другой литературе, могут быть известные известные (типичные риски), известные неизвестные (риски, связанные с продуктом) и неизвестные неизвестные (черные лебеди).
известные известные
У вас есть некоторая отраслевая статистика, и вы можете использовать некоторые модели (например, РИСКОЛОГИЯ), чтобы добавить, скажем, 20% к объему и графику.
известные неизвестные
Здесь вы можете провести мозговой штурм с командой и составить список рисков, связанных с проектом, а также придумать превентивные действия и оценить их, чтобы их можно было включить в объем. Но как быть с остальными известными неизвестными? Стоит ли планировать непредвиденные обстоятельства? Сколько? 10%?
черные лебеди
Просто план на случай непредвиденных обстоятельств? Сколько? 20-30%?
Как вы планируете эти риски на этапе инициации или планирования проекта, особенно когда заказчик запрашивает оценку? Как вы обычно представляете заказчику все эти различные виды рисков, особенно если риски удваивают смету бюджета или графика?
Риски обычно подразделяются на две категории: известные неизвестные и неизвестные неизвестные. Вы можете разбить последнее на Неизвестные Известные Неизвестные и Неизвестные Неизвестные Неизвестные. Известное известное не является риском, поскольку оно подразумевает определенность.
У вас есть два типа водителей, когда речь идет о вашем бюджете и рисках графика. Первый драйвер носит случайный характер или случайные переменные, которые будут определять ваши результаты. Лучший визуальный ряд — установить оценку по трем пунктам, например, в лучшем случае — 1000 долларов; скорее всего 1500 долларов; в худшем случае — 2800 долларов — и нарисуйте треугольное распределение, соединяющее эти три значения. Для простоты предположим, что вы устанавливаете свой бюджет в размере 1600 долларов США, что на 100 долларов США больше, чем наиболее вероятно в вашей оценке. Таким образом, диапазон от 1601 до 2800 долларов считается неблагоприятным, а все, что ниже 1600 долларов, — благоприятным.
Ваш второй драйвер — это риски более осторожного типа или эпистемические риски. Это конкретные угрозы, которые вы можете идентифицировать и рассчитать вероятность и влияние. Из-за специфики угрозы вы можете рассчитать затраты на смягчение, а также то, какую стоимость вы хотите предложить на случай непредвиденных обстоятельств, возможно, на основе ожидаемой денежной стоимости.
На ваш последний вопрос нелегко ответить. Это зависит от того, как вы заключаете контракт с вашим клиентом. Если вы заключаете сделку с риском, т. е. заключаете контракт с фиксированной ценой, вашему клиенту не нужно знать, что вы предусмотрели в своем предложении относительно риска. Не его/ее дело. Если T&M или стоимость плюс, то это становится совместным обсуждением ваших оценок угроз, подсчитанных вами затрат и совместного решения о том, что положить в резервы. Ваши целевые значения — это то, что вы устанавливаете по контракту. Резервы не предусмотрены контрактом, но хранятся у клиента на случай, если что-то случится.
В любом случае, презентация вашего предложения непростая. Клиенты хотят услышать гарантированный успех практически при нулевых затратах. Это ваша задача как продавца услуг.
Риски можно принимать, контролировать или передавать. Ваш план проекта, безусловно, должен включать анализ рисков и рекомендуемые средства контроля, но риски должны принадлежать заинтересованным сторонам проекта. Как руководитель проекта вы должны сосредоточиться на документировании рисков и обеспечении разумного контроля проекта для тех рисков, которые не принимаются или не передаются.
У каждого проекта есть цель. В большинстве случаев цели управления проектами нереалистичны. Например, проект, который оценивается с использованием наилучшего планирования и без задержек в процессе, к сожалению, является обычным явлением и будет представлять ваш наилучший сценарий для рассматриваемого проекта.
С другой стороны, оценка измеряет то, что, по вашему мнению, вы знаете, а затем учитывает ваш конус неопределенности и другие данные анализа рисков, чтобы получить более реалистичную оценку. Чем больше вы знаете о проблемной области и чем больше вы знаете о рисках, с которыми вы можете столкнуться, тем точнее будут ваши оценки.
Как правило, вам может быть полезно предлагать свои оценки в виде диапазона, а не набора фиксированных чисел. Размер диапазона по своей сути предполагает неопределенность, и в этом суть: вы делаете обоснованное предположение, основанное на наборе предположений.
Альтернативный метод заключается в применении к вашим оценкам «фактора выдумки». Это может быть основано на исторических показателях (например, ваши проекты обычно получают +/- 20% от реалистичной оценки) или на допустимости риска (например, ваш проект может допустить отставание от графика <= 10%).
Я большой сторонник прозрачности в планировании, поэтому, если вы пойдете по этому пути, я обязательно признаю, что эта цифра является выдумкой, а не результатом количественного анализа. В Scrum я обычно применяю фактор обмана 0,6 для новых команд и 0,8 для уже существующих команд, но ваш пробег может определенно отличаться.
Риск никогда не равен нулю, и оценки не являются гарантией. В общем, я обнаружил, что лучший способ справиться с этой реальностью — просто задокументировать их как часть предположений вашего проекта.
Например, документация вашего проекта может включать формальный или неформальный анализ рисков, а также целевой график или набор оценок. Задокументировав предположения, лежащие в основе плана вашего проекта, вы улучшите коммуникацию и в то же время предусмотрите непредвиденные обстоятельства.
Рассмотрим воображаемый проект, в котором вы предполагаете:
Если какое-либо из этих предположений окажется ложным в какой-то момент проекта, заинтересованные стороны могут провести повторную оценку. Организация может решить предпринять любое количество действий, если проект выходит за рамки допусков, включая изменение плана или отмену проекта.
Если вы продаете услуги с фиксированной ценой, вам также необходимо учитывать этот риск в своих оценках. Иногда ваша организация выходит вперед, а иногда нет. Если ваша организация не может мириться с таким риском, не заключайте контракты с фиксированной ценой.
Помните, что ваша роль как менеджера проекта заключается, прежде всего, в применении разумных средств контроля над проектом и регулярном информировании заинтересованных сторон о статусе проекта. С политической точки зрения руководителей проектов могут обвинить в том, что проект соскользнет с рельсов, но старайтесь помнить, что ваша роль заключается в отслеживании проекта и применении средств управления проектом . На самом деле вы не можете гарантировать конечный результат, и вам не следует пытаться.
Если вы хотите продать клиентам кота в мешке, переключитесь на отдел продаж. В противном случае используйте свое положение для информирования заинтересованных сторон о масштабах и предположениях, содержащихся в плане вашего проекта, и будьте готовы объяснить, как вы пришли к плановым цифрам, которые должны быть утверждены руководством и клиентами для продвижения проекта вперед.
Руслан
Дэвид Эспина