Комментарии 4
Статья дельная, многие пункты проходил на личном опыте. Материал подан хорошо структурированным. Было бы интересно увидеть кейсы в более бытовом описании на пальцах. Как с каждой проблемой разбирались по факту
Думаю, пришло время вспомнить о СИСТЕМНОМ(!!!) Управлении рисками проекта: идентификация, качественный анализ (определение потенциальных источников и последствий рисков), количественный анализ рисков (расчет вероятности наступления риска), оценка рисков (потенциальный ущерб в деньгах с учетом вероятности и приоритещация), а также заранее разработанные САРА-plans для критических рисков.
Тогда не будет "кризиса" в понимании автора
У меня есть заметки по проекту 2016-2017 годов, где я переработал своё понимание кризисных проектов (этот проект тоже был кризисный, меня заводили на 3-й годовой этап программы проектов). И, соответственно, думаю, что к выходным я напишу отдельную статью про управление проектом в режиме высокой неопределенности через риски и dynamic OODA loop. Отмечу, что идентификация, качественный анализ, количественные оценки - это всё в пользу бедных, если это делается только (!) в родительской организации проекта. Ведь у заказчиков есть свое понимание подхода к рискам (в СБРФ одно, в Schneider Electric второе, в ФОИВ третье - из моего опыта), в следствие чего естественно даже плотная работа с рисками натыкается на невозможность использовать именно инструментарий - обычное разделение рисков уже не работает :) Так же отмечу, risk management - это целая область, которая к счастью в IT-project management играет настолько глобальную роль, что imho, в любом комплексном и сложном IT-проекте роль risk manager должна быть выделенной. F.e. технический долг должен управляться через риски etc. Также отмечу, что до недавнего времени я занимался именно проектным управлением, а не программным и/или портфельным. И занимался плотно. А правильное управление рисками в проекте должно быть органично встроено в портфельное управление. Тогда возможны не только отказ от риска или его снижение, но и даже передача риска от одного высокотехнологичного проекта в другой внутри портфеля.
Да, Валерий, разбудили Вы во мне автора :)
Кризисное управление проектами после killpoint (авторский пример из опыта)