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