Posts tagged риск

Спрашивайте про отсутствие

0

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

Неизвестное отсутствие ключевых участников проекта как со стороны заказчика так и внутри команды проекта – это риск существенного сдвига сроков. И этот риск один из наиболее часто срабатывающих практически в любой период. Летом отпуска – более прогнозируемое. Зима – люди могут заболеть в любой момент, наибольший риск – эпидемии.

Отсутствие может быть самое разное. Для каждого из типов отсутствия стоит предпринимать разные действия:

  • Отпуск - получайте данные у HR но обязательно сверяйте с сотрудником и его руководителем. Часто встречается ситуация когда отпуск в кадрый подает за год, а потом планы на отпуск меняются.
  • Командировка - уточняйте как у сотрудника так и у его руководителя
  • Обучение - уточняйте как у сотрудника, у его руководителя и у HR. Есть такие виды информации которые могут знать только HR (их планы по обучению сотрудников), только сотрудник (его личные планы по обучению), руководитель (договаривается об обучении сотрудников с тренером)
  • Личные события (свадьба, лечение, небольшие отсутствия, посидеть с ребенком) – у сотрудника.
  • Болезнь - уточните как человек часто болеет. Есть такие люди которые болеют пару дней в году, а есть такие – которые 3-4 раза по неделе за зиму. Уточните есть ли дети и как часто они болеют

 

Список вопросов по проблеме

0

Когда перед нами проблема нам стоит себе задать ряд вопросов:

Первый взгляд на проблему

  • Эта проблема имеет отношение к проекту?
  • Как влияет проблема на проект – как это влияет на стоимость, качество, график проекта?
  • Как это влияет на еще не реализовавшиеся риски проекта?
  • Стоит ли нам вообще как-то реагировать на проблему?
  • Кого мы должны оповестить о возникновении проблемы?

Вопросы по решению проблем

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

Вопросы по анализу проблем

  • В чем причина возникновения проблемы?
  • Какой это был риск? Повторится ли он еще раз?
  • Как мы можем быстро ликвидировать проблему?
  • Как мы можем ликвидировать источник проблемы?
  • Какие меры нам надо предпринять чтобы минимизировать влияние проблемы?

Меряем проблему

  • Как это влияет на удовлетворенность клиента?
  • Сколько нам стоит проблема?
  • Кто оплатит расхода ны проблему, ее устранение и предотвращение? Один за все части или можем как то перераспределить затраты?
  • Какой приоритет у этой проблемы по отношению к другим проблемам и задачам проекта?

Закрываем проблему

  • Как мы определим что проблема решена?
  • Кто должен принять решение о закрытии проблемы?
  • Кого мы должны оповестить о решении проблемы?

Данная статья взята из материалов книги Наша книга по управлению проектами

Философия проблем

0
  1. Проблемы будут. Мы управляем рисками и готовим запас на непредвиденные проблемы. Плохо когда мы наступаем на проблему дважды и когда все наши проблемы – непредвиденная случайность или происки злых духов (судьбы, конкурентов, гавнюков с соседнего отдела). Чем мы тогда управляем?
  2. Проблемы – это сработавщие риски. Наша работа управлять рисками, не допускать их реализации или минимизровать их влияние в случае реализации. Делайте выводы из анализа проблем и в следующем проекте работайте над риском проблемы а не опять над проблемой. Не наступайте на грабли дважды.
  3. Мы говорим о проблемах сразу же. Все члены команды должны знать это и делать это. Если вы будете наказаывать гонца за то что он нам рассказал о том, что вражеское войско перешло границу – то вы узнаете об этом от вражеского войска под вашим домом.
  4. Мы обсуждаем проблемы без личностых выпадов и переводов стрелок. Мы решаем проблему а не людей. Нам необходимо решить проблему и принять меры по пресечению ее появления в будущем. Самое важное для команды которая работает длительный срок – капитализация знаний.
  5. Проблемы часто касаются именно руководителя проекта – в первую очередь это вопрос к качеству управления рисками, к качеству работы с командой и других процессов. Поэтому при анализе человеческого фактора – ставьте себя первым в список на разбор полета. Если причина проблемы это член команды и это не исправимо – это вопрос дипломатичного решения без театральных публичных действий. Хорошо подумайте о мотивации человека, о том дали ли ему реашть задачу адекватную его компетенциям, о его загрузке и приоритетах. Вычеркните неконтролируемые обстоятельства. Семь раз подумайте – а потом только принимайте решения бьющее по человеку.
  6. Если мы не решаем проблему – мы часть проблемы.
  7. Если мы скрываем проблему – мы проблема.
  8. Проблема часто не решается одним человеком и даже командой. Вполне нормально если мы обращаемся к менеджеру проекта. Также нормально если менеджер проекта эскалирует проблему на более высокий уровень.
  9. Менеджер проект постоянно эскалирующий проблемы вызывает вопросы в своей компетентности.
  10. Менеджер проекта который постоянно пытается решить проблемы вне его компетенции вызывает вопросы в своей компетентности.

Данная статья взята из материалов книги Наша книга по управлению проектами

6 углов проектного менеджера – уже не так железно

0

Развитие концепции железного треугольника управления проектами- стоимость, время и содержание проекта – шестиугольник проектного управления.

В состав шестиугольника входят следующие дополнительные компоненты:

  • Удовлетворенность клиента (Customer Satisfaction)
  • Риск (Risk)
  • Качество (Quality)

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

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

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

Go to Top