`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Кухар

PM 7-9. Финишируем

+22
голоса

18 декабря состоялось девятое, заключительное занятие Первого открытого сертификационного курса по управлению проектами. Так как я порядком отстал от графика по публикациям о ходе тренинга, то сделаю эту запись сразу о трех последних занятиях. На них поднимались такие темы, как управление рисками (Risk Management), поставками (Procurement Management) и интеграцией проекта (Integration Management), а также профессиональные обязанности руководителя проектов.

Risk Management

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

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

2. Очевидно, что снижение рисков увеличивает стоимость проекта. Стоимость проекта без указания затрат на работу с рисками – лишь декларация о намерениях.

3. Как правило, при планировании деятельности мы чересчур оптимистичны, особенно в отношении рисков. Чем хуже проработка плана по управлению рисками, тем выше риск.

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

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

6. Вероятность успеха проекта всегда больше 0 и меньше 1 (как и провала). Для приоритезации рисков (которая идет после их идентификации) можно не ограничиваться шкалой 0-1, а взять, к примеру, 1-5 или 1-100.

7. Вот как выглядит иерархическая структура рисков:
PM 7-9. Финишируем

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

Procurement Management

0. Управление снабжением связано с процессами покупки и эксплуатации продуктов, услуг и ресурсов, требуемых для реализации проекта у сторонних организаций. Оно предполагает анализ цен поставщиков услуг и/или аппаратного/программного обеспечения; подготовку документов об инициировании предложений (requests for proposals, RFP), выбор поставщиков и субподрядчиков; составление контрактов и переговоры об их условиях; мониторинг выполнения их исполнения и закрытие сделки.

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

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

3. Имеется два главных типа контрактов (не считая простого счета) – с фиксированной ценой (fixed price) и с ценой, определяемой по фактически выполненным работам и затраченным ресурсам (time & material). При первом покупателю проще управлять контрактом, он знает цену вопроса, а продавец сильно мотивирован к выполнению работ, но здесь имеет место большой финансовый риск для продавца, для покупателя же присутствует риск не закончить проект из-за остановки продавцом, кроме того, в данном случае, как правило, стоимость работ переоценена. Второй вариант выгоден продавцу, ему проще управлять изменениями, работы выполняются качественно, однако покупатель не знает стоимость проекта в его начале и велик риск конфликтов при увеличении стоимости.

4. Имеется три типа спецификации на работы: характеристики (performance), функциональность (functional) и дизайн (design). Первая описывает, что конкретный продукт проекта должен из себя представлять. Вторая предполагает отражение конечного результат или цели, а также (возможно) общих характеристик продукта. Третья детально определяет объем работ.

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

6. При ведении переговоров о закупках существуют различные тактики: ограничение времени принятия решения (deadline), сокрытие информации до поры (lying), недостаточность полномочий (limited authority), перекладывание ответственности (missing man), требование справедливости (fair and reasonable), навязывание задержек при рассмотрении вопросов (delay), вбрасывание информации для запутывания оппонента (extreme demands), имитация атаки (attacks) и пр.

Integration Management

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

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

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

3. Планы проектов могут отличаться даже в рамках одной отрасли. Сравните разработку ПО с внедрением ERP-системы. Это две большие разницы.

4. Если план проекта содержит меньше 500 задач на несколько месяцев – это декларация о намерениях.

5. Без информационной системы управления проектами и их портфелями (Project Management Information System или Project and Portfolio Management System) работать проблематично. Бумажная волокита будет отнимать время. Здесь автоматизация необходима, это факт.

6. Ошибки в проектах – это данность, так как здесь слишком много факторов, с которыми нужно иметь дело: культура и структура организации, инфраструктура, администрирование персонала, толерантность к рискам, наличие информационной системы управления проектами, организационные активы и пр. На 100% правильный проект невозможен.

P.S.: Руководитель проектов обязуется выполнять кодекс профессиональной этики и поведения (Code of Ethics and Professional Conduct).

+22
голоса

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT