Для осуществления управления проектом необходимо выбрать соответствующие процессы, входы, инструменты, методы, выходы, а также фазы жизненного цикла. Эту деятельность по выбору принято называть «адаптацией» управления проектом к конкретному проекту. В процессе адаптации руководитель проекта взаимодействует с командой проекта, спонсором, руководством организации или с некоторыми из них в определенном сочетании. В некоторых случаях организация может требовать применения конкретных методологий управления проектом.
Адаптация необходима, поскольку каждый проект является уникальным, и не всякий процесс, инструмент, метод, вход или выход, определенные в Руководстве PMBOK®, требуется при осуществлении конкретного проекта. В ходе адаптации должны решаться вопросы конкурирующих ограничений содержания, расписания, стоимости, ресурсов, качества и риска. Значение каждого ограничения для каждого проекта будет разным, и руководитель проекта адаптирует подход к управлению данными ограничениями с учетом среды проекта, культуры организации, потребностей заинтересованных сторон и других переменных.
В ходе адаптации управления проектом руководитель проекта должен также учитывать различные уровни руководства, которые могут требоваться и в рамках которых проект будет осуществляться, а также культуру организации. Кроме того, на решения по адаптации управления проектом может оказать влияние соображение, является ли заказчик проекта внешним или внутренним по отношению к организации.
В полноценных методологиях управления проектом учитываются уникальный характер проектов и они позволяют руководителю проекта осуществить адаптацию в разумных пределах. Однако адаптация, которая предусмотрена методологией, может потребовать осуществления дополнительной адаптации для данного проекта.
1.2.6. Бизнес-документы управления проектом
Руководителю проекта необходимо сделать так, чтобы подход к управлению проектом учитывал предназначение бизнес-документов. Определение этих документов приводится в таблице 1–5. Эти два документа зависят друг от друга, разрабатываются итеративно и ведутся на всем протяжении жизненного цикла проекта.
Таблица 1–5. Бизнес-документы проекта
За разработку и ведение документа о бизнес-кейсе проекта, как правило, отвечает спонсор проекта. В обязанности руководителя проекта входит выработка рекомендаций и осуществление контроля, чтобы обеспечить согласование бизнес-кейса, плана управления проектом, устава проекта и показателей успеха по плану управления выгодами проекта друг с другом, а также с целями и задачами организации.
В обязанности руководителей проектов входит адаптация указанных документов по управлению проектом для своих проектов. В некоторых организациях ведение бизнес-кейса и плана управления выгодами осуществляется на уровне программы. Руководители проектов должны работать вместе с руководителями соответствующих программ, чтобы обеспечить согласованность документов по управлению проектом с документами программы. На рис. 1–8 показаны взаимосвязи этих важнейших бизнес-документов по управлению проектом с оценкой потребностей. На рис. 1–8 также показана примерная продолжительность жизненного цикла этих различных документов относительно жизненного цикла проекта.
Рис. 1–8. Взаимосвязи оценки потребностей и наиболее важных документов проекта/бизнес-документов
1.2.6.1. Бизнес-кейс проекта
Бизнес-кейс проекта – это документированный анализ экономической целесообразности, используемый для установления обоснованности выгод выбранного компонента, который еще не определен в достаточной степени. Также служит основой для авторизации дальнейших операций управления проектом. Бизнес-кейс содержит перечень целей и причин инициации проекта. Он помогает оценить успешность проекта по его окончании в сравнении с целями проекта. Бизнес-кейс является бизнес-документом проекта, который используется на всем протяжении проекта. Бизнес-кейс может использоваться до инициации проекта и стать основанием принятия решения об инициации или об отказе от проекта.
Оценка потребностей часто предшествует подготовке бизнес-кейса. Оценка потребностей состоит в понимании бизнес-целей и бизнес-задач, проблем и благоприятных возможностей и выработке рекомендаций по их решению и реализации. Обобщение результатов оценки потребностей может быть сделано в документе бизнес-кейса.
Процесс определения бизнес-потребности, анализ ситуации, выработка рекомендаций и определение критериев оценки применимы для любых проектов организации. Бизнес-кейс может включать в себя, среди прочего, документальное оформление следующего:
♦ Бизнес-потребности:
• определение причин необходимости действий;
• ситуационное заключение, определяющее документально бизнес- проблему или благоприятную возможность, которые требуют принятия мер, включая предполагаемую ценность, получаемую организацией;
• идентификация заинтересованных сторон, на которых будет оказано влияние;
• определение содержания.
♦ Анализ ситуации:
• определение стратегий, целей и задач организации;
• определение основных причин проблемы или главных источников благоприятной возможности;
• анализ необходимых для проекта возможностей в сравнении с существующими возможностями организации;
• идентификация известных рисков;
• идентификация критически важных факторов успеха;
• определение критериев принятия решений, по которым можно оценить различные варианты способов действий.
Примерами категорий критериев, используемых для анализа ситуации, являются следующие:
• Требуемые. Это критерии, исполнение которых требуется для решения проблемы или использования благоприятной возможности.
• Желательные. Это критерии, исполнение которых желательно для решения проблемы или использования благоприятной возможности.
• Необязательные. Это критерии, которые не имеют существенного значения. Исполнение данных критериев может стать фактором, определяющим различия между альтернативными способами действий.
• Определение имеющихся вариантов действий, которые необходимо учесть для разрешения бизнес-проблемы или использования благоприятной возможности. Варианты действий – это альтернативные способы действий, которые организация может использовать по своему усмотрению. Варианты действий можно также описать как «бизнес-сценарии». Например, бизнес-кейс может предложить следующие три варианта действий:
• Ничего не делать. Этот вариант действий называют также «бизнес как обычно». Выбор этого варианта действий ведет к отказу в авторизации проекта.
• Выполнять только минимально необходимый объем работ, чтобы решить проблему или использовать благоприятную возможность. Минимальный объем работ можно установить путем определения набора оформленных документально критериев, которые являются ключевыми для решения проблемы или использования благоприятной возможности.
• Выполнять работы в объеме больше минимально необходимого, чтобы решить проблему или использовать благоприятную возможность. Этот вариант действий предусматривает выполнение минимального набора критериев, а также некоторых или всех других оформленных документально критериев. В бизнес-кейсе может быть документировано более одного из указанных вариантов действий.
♦ Выработка рекомендаций:
• заключение о рекомендованном варианте действий, который предлагается выбрать для данного проекта;
• пункты, которые должно содержать заключение, включают в себя, среди прочего:
• результаты анализа возможных вариантов действий;
• ограничения, допущения, риски и зависимости по потенциальным вариантам действий;
• показатели успеха (см. раздел 1.2.6.4);
• подход к реализации, который может включать в себя, среди прочего, следующее:
• контрольные события,
• зависимости,
• роли и сферы ответственности.
♦ Оценка:
• заключение с описанием плана по измерению выгод, которые будут получены от проекта. Сюда относятся все текущие операционные аспекты рекомендованного варианта действий после первоначальной реализации.
Документ бизнес-кейса дает основу для количественной оценки успеха проекта и хода его исполнения в течение всего жизненного цикла проекта путем сравнения результатов с целями и определенными критериями успеха. См. документ «Бизнес-анализ для специалистов-практиков: практическое руководство» (Business Analysis for Practitioners: A Practice Guide) [7].
1.2.6.2. План управления выгодами проекта
План управления выгодами проекта – это документ, описывающий, каким образом и когда будут получены выгоды от реализации проекта, а также механизмы, которые требуется внедрить для измерения этих выгод. Выгода проекта – это конечный результат действий, характеристики поведения, продукты, услуги или результаты, которые приносят ценность организации-спонсору и целевым выгодоприобретателям проекта. Разработка плана управления выгодами начинается на ранних стадиях жизненного цикла проекта с определения целевых выгод, которые должны быть получены. План управления выгодами описывает ключевые составляющие выгод и может включать в себя, среди прочего, следующее:
♦ Целевые выгоды (например, ожидаемые материальные и нематериальные ценности, которые предполагается получить в результате реализации проекта; финансовая ценность выражается в чистой приведенной стоимости).
♦ Приведение в соответствие со стратегией (например, насколько выгоды от проекта согласуются с бизнес-стратегиями организации).
♦ Сроки реализации выгод (например, выгоды по фазам, в долгосрочной и краткосрочной перспективе, текущие выгоды).
♦ Владелец выгод (например, ответственное лицо, которое осуществляет мониторинг, ведет документацию о реализованных выгодах и представляет отчетность о них в предусмотренные планом сроки).
♦ Метрики (например, количественные показатели, которые планируется использовать для демонстрации реализованных выгод, прямые показатели и косвенные показатели).
♦ Допущения (например, факторы, которые, как ожидается, должны быть в наличии или наблюдаться).
♦ Риски (например, риски для реализации выгод).
При разработке плана управления выгодами используются данные и информация, содержащиеся в бизнес-кейсе и оценке потребностей. Например, содержащийся в документах сравнительный анализ затрат и выгод показывает оценку затрат в сравнении с ценностью выгод, получаемых по результатам проекта. План управления выгодами и план управления проектом включают в себя описание того, как бизнес-ценность, полученная по результатам проекта, становится частью текущей операционной деятельности организации, включая подлежащие использованию метрики. Метрики служат средством проверки бизнес-ценности и подтверждения успеха проекта.
Разработка и ведение плана управления выгодами проекта является итеративной деятельностью. Данный документ дополняет бизнес-кейс, устав проекта и план управления проектом. Руководитель проекта ведет работу со спонсором, цель которой заключается в том, чтобы устав проекта, план управления проектом и план управления выгодами оставались согласованными друг с другом на всем протяжении жизненного цикла проекта. См. документы «Бизнес-анализ для специалистов-практиков: практическое руководство» (Business Analysis for Practitioners: A Practice Guide) [7], «Стандарт управления программой» (The Standard for Program Management) [3] и «Стандарт управления портфелем» (The Standard for Portfolio Management) [2].
1.2.6.3. Устав проекта и план управления проектом
Устав проекта – это документ, выпущенный спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта.
План управления проектом – это документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль.
Дополнительную информацию об уставе проекта и плане управления проектом смотрите в разделе 4, посвященном управлению интеграцией проекта.
1.2.6.4. Показатели успеха проекта
Одной из наиболее распространенных задач в управлении проектом является определение того, достиг ли проект успеха.
Традиционно такие метрики управления проектом, как время, стоимость, содержание и качество, являются наиболее важными факторами определения успешности проекта. Позднее специалисты-практики и исследователи пришли к заключению, что успех проекта следует также измерять с точки зрения достижения целей проекта.
Заинтересованные стороны проекта могут по-разному оценивать, как может выглядеть успешное завершение проекта и какие факторы являются наиболее важными. Крайне важно четко определить в документах цели проекта и выбрать цели, которые можно измерить. Есть три вопроса, на которые ключевые заинтересованные стороны и руководитель проекта должны дать ответ:
♦ Как выглядит успех для данного проекта?
♦ Как будет измеряться успех?
♦ Какие факторы могут повлиять на успех?
Ответы на данные вопросы должны быть приведены в документах и согласованы между ключевыми заинтересованными сторонами и руководителем проекта.
Успех проекта может включать в себя дополнительные критерии, увязанные со стратегией организации и с поставкой бизнес-результатов. Эти цели проекта могут включать в себя, среди прочего:
♦ исполнение плана управления выгодами проекта;
♦ достижение согласованных финансовых показателей, предусмотренных в бизнес-кейсе. Эти финансовые меры могут включать в себя, среди прочего:
• чистую приведенную стоимость (net present value, NPV);
• окупаемость инвестиций (return on investment, ROI);
• внутреннюю норму доходности (internal rate of return, IRR);
• период окупаемости инвестиций (payback period, PBP);
• отношение выгод к затратам (beneft-cost ratio, BCR);
♦ достижение нефинансовых целей бизнес-кейса;
♦ совершение перехода организации из исходного состояния к будущему состоянию;
♦ исполнение условий и положений договора;
♦ исполнение стратегий, целей и задач организации;
♦ обеспечение удовлетворенности заинтересованных сторон;
♦ удовлетворительная приемка заказчиком/конечным пользователем;
♦ интеграция поставляемых результатов в операционную среду организации;
♦ обеспечение согласованного качества поставляемого продукта;
♦ исполнение критериев руководства;
♦ достижение других согласованных показателей или критериев успеха (например, производительность процесса).
Команда проекта должна быть способна оценить положение проекта, уравновесить запросы и сохранить проактивные коммуникации с заинтересованными сторонами в целях достижения успеха проекта.
При постоянном приведении в соответствие проекта вероятность его успеха значительно возрастает, так как проект соответствует стратегическому направлению организации.
Проект может быть успешным с точки зрения содержания/расписания/бюджета, но при этом не достичь успеха с точки зрения бизнеса. Это может произойти в случае изменений в бизнес-потребностях или рыночных условиях до завершения проекта.
2. Среда, в которой осуществляется проект
2.1. Общие сведения
Проекты существуют и осуществляются в среде, которая может воздействовать на них. Эти воздействия могут оказывать благоприятное или неблагоприятное влияние на проект. Две главных категории воздействий – это факторы среды предприятия (ФСП) и активы процессов организации (АПО).
Источником ФСП является внешняя по отношению к проекту и часто внешняя по отношению к предприятию среда. ФСП могут оказывать воздействие на уровне организации, портфеля, программы или проекта. Дополнительную информацию по ФСП смотрите в разделе 2.2.
АПО являются внутренними по отношению к организации. Их источником может быть сама организация, портфель, программа, другой проект или их сочетание. На рис. 2–1 показана разбивка влияний проекта на ФСП и АПО. Дополнительную информацию по АПО смотрите в разделе 2.3.
Рис. 2–1. Влияния проекта
Кроме ФСП и АПО в жизненном цикле проекта значительную роль играют организационные системы. Системные факторы, которые воздействуют на властные полномочия, влияние, интересы, компетенции и политические возможности людей действовать в рамках организационной системы, более подробно обсуждаются в разделе, посвященном организационным системам (см. раздел 2.4).
2.2. Факторы среды предприятия
Факторы среды предприятия (ФСП) – это условия, не находящиеся под непосредственным контролем команды проекта, которые влияют на проект, ограничивают или направляют его. Данные условия по отношению к организации могут быть внутренними и/или внешними. ФСП рассматриваются в качестве входов для многих процессов управления проектом, особенно для большинства процессов планирования. Эти факторы могут расширять или ограничивать варианты действий по управлению проектом. Кроме этого, эти факторы могут оказать положительное или отрицательное влияние на конечный результат.
ФСП имеют большие различия в зависимости от типа или характера. Эти факторы необходимо учитывать, чтобы добиться результативности проекта. ФСП включают в себя, среди прочего, факторы, которые описаны в разделах 2.2.1 и 2.2.2.
2.2.1. ФСП, внутренние для организации
Описанные ниже ФСП являются для организации внутренними:
♦ Организационная культура, структура и руководство. Примерами могут служить: видение, миссия, ценности, убеждения, культурные нормы, стиль руководства, иерархия и система взаимосвязей полномочий, организационный стиль, этические нормы и кодекс поведения.
♦ Географическое распределение производственных объектов и ресурсов. Примерами могут служить: местоположение заводов, виртуальные команды, системы общего пользования и облачные компьютерные ресурсы.
♦ Инфраструктура. Примерами могут служить: производственные объекты, оборудование, каналы телекоммуникаций организации, компьютерное аппаратное обеспечение, его доступность и мощности.
♦ Компьютерное программное обеспечение. Примерами могут служить: инструменты составления расписаний, системы управления конфигурацией, веб-интерфейсы к работающим в режиме онлайн автоматизированными системам и системы авторизации работ.
♦ Доступность ресурсов. Примерами могут служить: ограничения на заключение договоров и осуществление закупок, утвержденные поставщики и субподрядчики, а также соглашения о сотрудничестве.
♦ Кадровые возможности. Примерами могут служить: профессиональная квалификация и опыт, навыки, компетенции и специальные знания кадровых ресурсов.
2.2.2. ФСП, внутренние для организации
Описанные ниже ФСП являются для организации внешними:
♦ Ситуация на рынке. Примерами могут служить: конкуренты, доля рынка, узнаваемость бренда и товарные знаки.
♦ Социальные и культурные влияния и проблемы. Примерами могут служить: политический климат, кодексы поведения, этические нормы и представления.
♦ Юридические ограничения. Примерами могут служить: национальные или местные законы и нормативно-правовые акты в области безопасности, защиты данных, делового поведения, трудовых отношений и закупочной деятельности.
♦ Коммерческие базы данных. Примерами могут служить: результаты сравнительного анализа, стандартизированные сметные данные, данные изучения промышленных рисков, базы данных рисков.
♦ Научные исследования. Примерами могут служить: отраслевые исследования, публикации и результаты сравнительного анализа.
♦ Государственные или промышленные стандарты. Примерами могут служить: предписания и стандарты регулирующих органов в отношении продуктов, производства, природопользования, качества и квалификации.
♦ Финансовые соображения. Примерами могут служить: курсы обмена валют, банковские ставки, показатели инфляции, тарифы и географическое положение.
♦ Материальные элементы среды. Примерами могут служить: производственные условия, погодные условия и ограничения.
2.3. Активы процессов организации
Активы процессов организации (АПО) – это планы, процессы, политики, процедуры и базы знаний, специфичные для исполняющей организации и используемые ею. Данные активы оказывают влияние на управление проектом.
АПО включают в себя любые артефакты, практики и знания некоторых или всех исполнительных организаций, участвующих в проекте, которые могут быть использованы для исполнения или руководства проектом. АПО также включают в себя извлеченные уроки по результатам прошлых проектов и историческую информацию организации. АПО могут включать в себя завершенные расписания, данные о рисках и данные об освоенных объемах. АПО служат входами во многие процессы управления проектом. Поскольку АПО являются для организации внутренними, члены команды проекта могут быть в состоянии по мере необходимости вносить обновления и дополнения в активы процессов организации на всем протяжении проекта. Их можно разбить на две категории:
♦ процессы, политики и процедуры,
♦ базы знаний организации.
Обычно обновление активов, относящихся к первой категории, не входит в работы по проекту. Процессы, политики и процедуры обычно устанавливаются офисом управления проектами (ОУП) или другим функциональным подразделением, внешним по отношению к проекту. Они могут обновляться только с соблюдением соответствующих политик организации, связанных с обновлением процессов, политик или процедур. В некоторых организациях команде предлагают адаптировать шаблоны, жизненные циклы и контрольные списки к проекту. В таких случаях команда управления проектом должна адаптировать эти активы с целью удовлетворения потребностей проекта.
Относящиеся ко второй категории активы обновляются на всем протяжении проекта за счет использования информации проекта. Например, на всем протяжении проекта постоянно обновляется информация о финансовых результатах, извлеченных уроках, метриках и проблемах исполнения, а также недостатках.
2.3.1. Процессы, политики и процедуры
Процессы и процедуры организации для проведения работ по проекту включают в себя, среди прочего, следующие:
♦ Инициация и планирование:
• руководящие указания и критерии для адаптации набора стандартных процессов и процедур организации с целью удовлетворения конкретных потребностей проекта;
• специфические стандарты организации, такие как политики (например, политика отбора и найма персонала, политика безопасности и охраны здоровья, политика безопасности и конфиденциальности данных, политика контроля качества, политика осуществления закупок и охраны окружающей среды);
• жизненные циклы продуктов и проектов, а также методы и процедуры (например, методы управления проектом, метрики подсчета, аудиты процессов, целевые области совершенствования, контрольные списки и определения типовых процессов для использования в организации);
• шаблоны (например, планы управления проектом, документы проекта, реестры проектов, формы отчетности, шаблоны договоров, категории рисков, шаблоны заключений о рисках, определения вероятностей и воздействий, матрицы вероятностей и воздействий и шаблоны реестра заинтересованных сторон);
• заранее утвержденные списки поставщиков и различных типов основанных на договоре соглашений (например, договоров с фиксированной ценой, договоров о возмещении затрат и договоров «время и материалы»).
♦ Исполнение, мониторинг и контроль:
• процедуры контроля изменений, включающие в себя действия, согласно которым вносятся изменения в стандарты, политики, планы и процедуры исполняющей организации или в любые документы проекта, а также порядок одобрения и подтверждения любых изменений;
• матрицы отслеживания;
• процедуры финансового контроля (например, отчетность по времени, необходимый анализ расходов и выплат, статьи бухгалтерского учета и стандартные положения договоров);
• процедуры управления проблемами и дефектами (например, определение средств контроля проблем и дефектов, выявление и разрешение проблем и дефектов, а также отслеживание вопросов, требующих решения);
• контроль наличия и управление назначением ресурсов;
• требования организации к коммуникациям (например, имеющаяся конкретная коммуникационная технология, допустимые средства передачи данных, политики хранения документов, порядок проведения видеоконференций, инструменты совместной работы и требования по безопасности);
• процедуры приоритизации, одобрения и авторизации работ;
• шаблоны (например, реестр рисков, журнал проблем и журнал изменений);
• типовые руководящие указания, рабочие инструкции, критерии оценки предложений и критерии измерения исполнения;
• процедуры проверки и подтверждения продукта, услуги или результата.
♦ Закрытие: указания или требования по закрытию проекта (например, заключительные аудиторские проверки проекта, оценки проекта, приемка поставляемых результатов, закрытие договора, перераспределение ресурсов и передача знаний на производство и/или в операционную деятельность).
2.3.2. Репозитории знаний организации
Репозитории знаний организации, предназначенные для хранения и извлечения информации, включают в себя, среди прочего:
♦ репозитории знаний по управлению конфигурацией, содержащие версии программного обеспечения и компоненты аппаратного обеспечения, а также базовые варианты всех стандартов, политик, процедур и любых документов проекта исполняющей организации;
♦ репозитории финансовых данных, содержащие такую информацию, как данные о человеко-часах, понесенных затратах, бюджетах и любых перерасходах средств по проекту;
♦ репозитории исторической информации и знаний об извлеченных уроках (например, записи и документы проекта, вся информация и документация по закрытию проекта, информация о результатах решений по отбору предыдущих проектов наряду с информацией о выполнении предыдущих проектов, а также информация, полученная при управлении рисками);
♦ репозитории данных по управлению проблемами и дефектами, содержащие сведения о статусе проблем и дефектов, информацию о контроле, данные о разрешении проблем и устранении дефектов, а также результаты предпринятых действий;
♦ репозитории данных по метрикам, используемым для сбора и обеспечения доступа к данным измерений по процессам и продуктам;
♦ файлы предыдущих проектов (например, базовые планы по содержанию, базовые планы по стоимости, базовые расписания, базовые планы исполнения, календари проектов, диаграммы сети расписания проектов, реестры рисков, отчеты о рисках и реестры заинтересованных сторон).
2.4. Организационные системы
2.4.1. Общие сведения
Проекты осуществляются в рамках ограничений, установленных организациями через их структуру и модель руководства. Для результативной и эффективной работы руководителю проекта нужно понимать структуру распределения ответственности, подчиненности и полномочий в организации. Это понимание поможет руководителю проекта результативно использовать свои полномочия, влияние, компетентность, лидерство и политические возможности для успешного завершения проекта.
Взаимодействие многочисленных факторов в каждой отдельной организации создает уникальную систему, которая воздействует на проект, осуществляемый в ее рамках. Возникшая в результате организационная система определяет властные полномочия, влияние, интересы, компетентность и политические возможности людей, которые могут действовать в рамках данной системы. Системные факторы включают в себя, среди прочего:
♦ элементы управления,
♦ модель руководства,
♦ типы организационной структуры.
Исчерпывающая информация и разъяснение факторов организационной системы, а также то, как сочетание данных факторов влияет на проект, выходят за рамки настоящего Руководства. Существуют дисциплины с относящейся к ним литературой, методологиями и практиками, которые занимаются изучением этих факторов более глубоко, чем это возможно сделать в настоящем Руководстве. В этом разделе приводится лишь общий обзор указанных факторов и их взаимосвязей.
Обзор начинается с изложения общей информации о системах. Система – это сочетание различных компонентов, способных совместно произвести результат, который не могут дать входящие в нее компоненты по отдельности. Компонент – это распознаваемый элемент в составе проекта или организации, который обеспечивает выполнение определенной функции или группы взаимосвязанных функций. Взаимодействие различных компонентов системы формирует культуру и способности организации. Имеется несколько принципов, относящихся к системам:
♦ системы являются динамическими;
♦ системы можно оптимизировать;
♦ компоненты системы можно оптимизировать;
♦ системы и их компоненты нельзя оптимизировать одновременно;
♦ реакция системы не является прямолинейной (изменение на входе в систему не производит прогнозируемого изменения на выходе из нее).
Внутри системы и на стыке системы с окружающей средой может произойти несколько изменений. Когда такие изменения происходят, в компонентах происходят явления адаптации, которые, в свою очередь, усиливают динамику системы. Динамика системы определяется взаимодействием между компонентами в зависимости от взаимодействий и зависимостей, которые существуют между компонентами.
За системы обычно отвечает руководство организации. Руководство организации изучает оптимизационные компромиссы между компонентами и системой с целью принятия целесообразных мер для достижения наилучших конечных результатов для организации. Результаты такого изучения окажут воздействие на проект, находящийся на рассмотрении. В силу этого важно, чтобы руководитель проекта учитывал данные результаты при принятии решений о путях достижения целей проекта. Кроме этого, руководитель проекта должен также принять в расчет структуру руководства организации.
2.4.2. Модели руководства организации
Недавнее исследование PMI показывает, что понятие «руководство» означает организационное или структурное устройство организации на всех ее уровнях, цель которого определять и влиять на поведение членов организации [9]. Из указанного исследования следует вывод, что концепция руководства является многоплановой и:
♦ включает в себя соображения о людях, функциях, структурах и политиках;
♦ требует обеспечения указаний и надзора на основе данных и обратной связи.
2.4.2.1. Модель руководства
Руководство – это модель, в рамках которой в организации осуществляются властные полномочия. Эта модель включает в себя, среди прочего:
♦ правила,
♦ политики,
♦ процедуры,
♦ нормы,
♦ отношения,
♦ системы,
♦ процессы.
