Управление проектом

Управление проектом — это процесс контроля работы команды для достижения всех целей проекта в рамках заданных ограничений. ^{[ 1 ]} Эта информация обычно описывается в проектной документации , созданной в начале процесса разработки. Основными ограничениями являются объем , время и бюджет . ^{[ 2 ]} Второстепенная задача состоит в том, чтобы необходимых ресурсов оптимизировать распределение и применить их для достижения заранее определенных целей.

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

Проект — это временное и уникальное мероприятие , предназначенное для производства продукта, услуги или результата с определенным началом и концом (обычно ограниченное по времени и часто ограниченное финансированием или персоналом), предпринятое для достижения уникальных целей и задач, как правило, для достижения полезные изменения или добавленная стоимость. ^{[ 3 ]}^{[ 4 ]} Временный характер проектов контрастирует с обычным бизнесом (или операциями) , ^{[ 5 ]} которые представляют собой повторяющуюся, постоянную или полупостоянную функциональную деятельность по производству продуктов или услуг. На практике управление такими различными производственными подходами требует развития определенных технических навыков и стратегий управления. ^{[ 6 ]}

История

До 1900 года проектами гражданского строительства обычно руководили творческие архитекторы, инженеры и мастера-строители , например, Витрувий (первый век до н.э.), Кристофер Рен (1632–1723), Томас Телфорд (1757–1834) и Исамбард Кингдом Брюнель. (1806–1859). ^{[ 7 ]} В 1950-х годах организации начали более систематически применять инструменты и методы управления проектами к сложным инженерным проектам. ^{[ 8 ]}

Как дисциплина управление проектами развилось из нескольких областей применения, включая гражданское строительство, проектирование и тяжелую оборонную деятельность. ^{[ 9 ]} Двумя родоначальниками управления проектами являются Генри Гант , которого называют отцом методов планирования и контроля. ^{[ 10 ]} который известен тем, что использовал диаграмму Ганта в качестве инструмента управления проектами (альтернативный вариант «Гармонограммы», впервые предложенный Каролем Адамецки ); ^{[ 11 ]} и Анри Файолю за создание пяти функций управления, которые составляют основу совокупности знаний, связанных с управлением проектами и программами. ^{[ 12 ]} И Гантт, и Файоль изучали Фредерика Уинслоу Тейлора теории научного менеджмента . Его работа является предшественником современных инструментов управления проектами, включая структуру декомпозиции работ (WBS) и распределение ресурсов .

1950-е годы ознаменовали начало современной эры управления проектами, когда основные инженерные области объединились в одно целое. Управление проектами стало признано отдельной дисциплиной, вытекающей из дисциплины управления инженерной моделью. ^{[ 13 ]} В Соединенных Штатах до 1950-х годов управление проектами осуществлялось на разовой основе, в основном с использованием диаграмм Ганта и неформальных методов и инструментов. В то время планирования проектов были разработаны две математические модели . Метод критического пути (CPM) был разработан совместным предприятием DuPont Corporation и Remington Rand Corporation для управления проектами по техническому обслуживанию предприятий. Методика оценки и анализа программ (PERT) была разработана Управлением специальных проектов ВМС США совместно с корпорациями Lockheed и Booz Allen Hamilton в рамках программы создания ракетных подводных лодок Polaris . ^{[ 14 ]}

PERT и CPM очень похожи по своему подходу, но все же имеют некоторые различия. CPM используется для проектов, предполагающих детерминированное время активности; время выполнения каждого действия известно. PERT, с другой стороны, учитывает стохастическое время активности; время, в которое будет выполняться каждое действие, не определено или варьируется. Из-за этого основного различия CPM и PERT используются в разных контекстах. Эти математические методы быстро распространились на многие частные предприятия.

В то же время, по мере разработки моделей планирования проектов, технологии оценки развивались стоимости проектов, управления затратами и инженерной экономики, благодаря новаторским работам Ханса Ланга и других. В 1956 году Американская ассоциация инженеров-сметчиков (ныне AACE International ; Ассоциация по развитию сметной инженерии ) была сформирована первыми практиками управления проектами и связанными с ними специальностями планирования и составления графиков , оценки затрат и контроля над проектами. AACE продолжила свою новаторскую работу и в 2006 году выпустила первый интегрированный процесс управления портфелем, программами и проектами ( управления общими затратами структура ).

В 1969 году Институт управления проектами (PMI). в США был основан ^{[ 15 ]} PMI публикует оригинальную версию «Руководства по своду знаний по управлению проектами» (PMBOK Guide) в 1996 году под руководством Уильяма Дункана в качестве основного автора, в котором описываются практики управления проектами, которые являются общими для «большинства проектов, большую часть времени». ^{[ 16 ]}

Типы управления проектами

Методы управления проектами могут быть применены к любому проекту. Он часто адаптируется к конкретному типу проекта в зависимости от его размера, характера, отрасли или сектора. Например, строительная отрасль, которая занимается строительством таких объектов, как здания, дороги и мосты, разработала свою собственную специализированную форму управления проектами, которую она называет управлением строительными проектами , и в которой менеджеры проектов могут пройти обучение и получить сертификацию. ^{[ 17 ]} Индустрия информационных технологий также развилась и разработала свою собственную форму управления проектами, которая называется управлением ИТ-проектами и специализируется на предоставлении технических активов и услуг, которые необходимы для прохождения различных этапов жизненного цикла, таких как планирование, проектирование, разработка. , тестирование и развертывание. Управление биотехнологическими проектами фокусируется на тонкостях биотехнологических исследований и разработок. ^{[ 18 ]} Управление проектами локализации включает применение многих стандартных методов управления проектами к переводческим работам, хотя многие считают этот тип управления совершенно другой дисциплиной. Например, менеджеры проектов играют ключевую роль в улучшении перевода, даже если они не говорят на языке перевода, поскольку они хорошо знают цели исследования, чтобы принимать обоснованные решения. ^{[ 19 ]} Аналогичным образом, управление научными исследованиями также может применять подход управления проектами. ^{[ 20 ]} Существует государственное управление проектами, которое охватывает все общественные работы, проводимые правительством, которые могут выполняться государственными учреждениями или передаваться по контракту подрядчикам. Другая классификация управления проектами основана на жестком (физическом) или мягком (нефизическом) типе.

Общим для всех типов управления проектами является то, что они фокусируются на трех важных целях: время, качество и стоимость. Успешные проекты завершаются в срок, в рамках бюджета и в соответствии с ранее согласованными стандартами качества, т.е. с соблюдением «железного треугольника» или «тройного ограничения», чтобы проекты можно было считать успешными или неудачными. ^{[ 21 ]}

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

Подходы к управлению проектами

Исследование 2017 года показало, что успех любого проекта зависит от того, насколько хорошо четыре ключевых аспекта согласованы с контекстной динамикой, влияющей на проект. Их называют четырьмя П : ^{[ 22 ]}

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

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

Независимо от используемой методологии , необходимо тщательно рассмотреть общие цели проекта, сроки и стоимость, а также роли и обязанности всех участников и заинтересованных сторон . ^{[ 23 ]}

Управление реализацией преимуществ

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

Кроме того, методы BRM направлены на обеспечение стратегического соответствия между результатами проекта и бизнес-стратегиями. Эффективность этих практик подтверждается недавними исследованиями, доказывающими, что практики BRM влияют на успех проектов со стратегической точки зрения в разных странах и отраслях. Эти более широкие последствия называются стратегическим воздействием. ^{[ 24 ]}

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

Метод критического пути

Метод критического пути (CPM) — это алгоритм определения графика работ по проекту. Это традиционный процесс, используемый для планирования проектов на основе прогнозов. Метод CPM оценивает последовательность действий, требуемые трудозатраты, взаимозависимости и результирующее время ожидания для каждой последовательности строк, чтобы определить необходимую продолжительность проекта. Таким образом, по определению, критический путь — это путь задач на сетевой диаграмме, для которого нет дополнительного времени (или очень мало дополнительного времени)». ^{[ 25 ]}

Управление проектами критической цепочки

Управление проектами критической цепочки (CCPM) представляет собой применение теории ограничений (TOC) к планированию и управлению проектами и предназначено для борьбы с неопределенностями, присущими управлению проектами, принимая во внимание ограниченную доступность ресурсов (физических, человеческих навыков). , а также возможности управления и поддержки), необходимые для реализации проектов.

Цель — увеличить поток проектов в организации ( пропускную способность ). Применяя первые три из пяти фокусирующих шагов ТОС, определяются системные ограничения для всех проектов, а также ресурсы. Чтобы воспользоваться этим ограничением, задачам критической цепочки присваивается приоритет над всеми остальными действиями.

Управление прибавочной стоимостью

Управление прибавочной стоимостью (EVM) расширяет управление проектами методами улучшения мониторинга проекта. ^{[ 26 ]} Он иллюстрирует ход проекта к завершению с точки зрения объема работ и стоимости (стоимости). Заработанное расписание является расширением теории и практики EVM.

Итеративное и инкрементное управление проектами

В критических исследованиях управления проектами было отмечено, что поэтапные подходы не очень подходят для крупномасштабных проектов, в которых участвуют несколько компаний. ^{[ 27 ]} с неопределенными, неоднозначными или быстро меняющимися требованиями, ^{[ 28 ]} или те, у кого высокая степень риска, зависимости и быстро меняющихся технологий. Частично это объясняется конусом неопределенности , поскольку планирование на начальном этапе проекта страдает от высокой степени неопределенности. Это становится особенно актуальным, поскольку разработка программного обеспечения часто представляет собой реализацию нового или инновационного продукта.

Эти сложности лучше решать с помощью более исследовательского или итеративного и поэтапного подхода. ^{[ 29 ]} Развилось несколько моделей итеративного и поэтапного управления проектами, включая гибкое управление проектами , метод разработки динамических систем , экстремальное управление проектами и Innovation Engineering®. ^{[ 30 ]}

Бережливое управление проектами

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

Жизненный цикл проекта

Жизненный цикл проекта состоит из пяти этапов; известные как группы процессов. Каждая группа процессов представляет собой серию взаимосвязанных процессов, позволяющих управлять работой посредством ряда отдельных шагов, которые необходимо выполнить. Этот тип проектного подхода часто называют «традиционным». ^{[ 31 ]} или « водопад ». ^{[ 32 ]} Пять групп процессов:

Инициирование
Планирование
Выполнение
Мониторинг и контроль
Закрытие

Некоторые отрасли могут использовать варианты этих этапов проекта и переименовывать их, чтобы они лучше подходили организации. Например, при работе над физическим проектированием и строительством проекты обычно проходят такие этапы, как предварительное планирование, концептуальное проектирование, эскизное проектирование, разработка проекта, строительные чертежи (или контрактная документация) и управление строительством.

Хотя поэтапный подход хорошо работает для небольших, четко определенных проектов, он часто приводит к проблемам или неудачам в более крупных проектах или проектах, которые являются более сложными или имеют больше неясностей, проблем и рисков. ^{[ 33 ]} - см. пародию на «шесть этапов большого проекта».

Процессно-ориентированное управление

Внедрение управления на основе процессов было обусловлено использованием моделей зрелости, таких как OPM3 и CMMI (интеграция модели зрелости возможностей; см. Изображение:Capability Maturity Model.jpg).

Управление производством проектов

Управление производством проектов — это применение управления операциями для реализации капитальных проектов. Структура управления производством проекта основана на проекте как взгляде на производственную систему, в которой проект преобразует входные данные (сырье, информация, рабочая сила, оборудование и оборудование) в выходные данные (товары и услуги). ^{[ 34 ]}

Планирование на основе продукта

Планирование на основе продукта — это структурированный подход к управлению проектом, основанный на определении всех продуктов ( результатов проекта ), которые способствуют достижению целей проекта. Таким образом, он определяет успешный проект как ориентированный на результат, а не на деятельность или задачу. ^{[ 35 ]} Наиболее распространенной реализацией этого подхода является PRINCE2 . ^{[ 36 ]}

Группы процессов

Традиционно (в зависимости от того, какая методология управления проектами используется) управление проектами включает в себя ряд элементов: четыре-пять групп процессов управления проектами и систему контроля. Независимо от используемой методологии или терминологии, будут использоваться одни и те же основные процессы управления проектами или этапы разработки. Основные группы процессов обычно включают в себя: ^{[ 38 ]}

Инициация
Планирование
Производство или исполнение
Мониторинг и контроль
Закрытие

В проектах со значительным исследовательским элементом (например, исследования и разработки ) эти этапы могут быть дополнены точками принятия решений (решения «годить/не годиться»), на которых обсуждается и принимается решение о продолжении проекта. Примером может служить модель фазового затвора .

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

Инициирование

Инициирующие процессы определяют характер и масштаб проекта. ^{[ 39 ]} Если этот этап не будет выполнен должным образом, маловероятно, что проект сможет удовлетворить потребности бизнеса. Ключевыми элементами управления проектом, необходимыми здесь, являются понимание бизнес-среды и обеспечение того, чтобы все необходимые элементы управления были включены в проект. О любых недостатках следует сообщать и давать рекомендации по их устранению.

Начальный этап должен включать план, охватывающий следующие области. Эти области могут быть отражены в серии документов, называемых «Документы инициации проекта». Документы инициирования проекта — это серия плановых документов, используемых для создания заказа на протяжении всего проекта. К ним, как правило, относятся:

проектное предложение (идея проекта, общая цель, продолжительность)
объем проекта (направление и трек проекта)
Иерархическая структура продукта (PBS) (иерархия результатов/результатов и их компонентов)
структура декомпозиции работ (WBS) (иерархия предстоящих работ, вплоть до ежедневных задач)
Матрица распределения ответственности (RACI — Ответственный, Подотчетный, Консультируемый, Информированный) (роли и обязанности соответствуют результатам/результатам)
ориентировочный график проекта (этапы, важные даты, сроки)
анализ потребностей и требований бизнеса в сравнении с измеримыми целями
обзор текущей деятельности
финансовый анализ затрат и выгод, включая бюджет
анализ заинтересованных сторон , включая пользователей и вспомогательный персонал проекта
устав проекта , включая затраты, задачи, результаты и графики
SWOT-анализ : сильные и слабые стороны, возможности и угрозы для бизнеса.

Планирование

После этапа инициации проект планируется на соответствующем уровне детализации (см. пример блок-схемы ). ^{[ 37 ]} Основная цель — адекватно спланировать время, затраты и ресурсы, чтобы оценить необходимую работу и эффективно управлять рисками во время реализации проекта. Как и в случае с группой процессов инициации, неспособность адекватного планирования значительно снижает шансы проекта на успешное достижение своих целей.

Планирование проекта обычно состоит из ^{[ 40 ]}

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

Также обычно желательны дополнительные процессы, такие как планирование коммуникаций и управление объемом, определение ролей и обязанностей, определение того, что закупить для проекта, а также проведение стартового совещания.

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

Выполнение

При выполнении мы должны знать, какие запланированные сроки необходимо выполнить . Фаза исполнения/реализации гарантирует, что результаты плана управления проектом выполняются соответствующим образом. Этот этап включает в себя правильное распределение, координацию и управление человеческими ресурсами и любыми другими ресурсами, такими как материалы и бюджеты. Результатом этого этапа являются результаты проекта.

Проектная документация

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

Мониторинг и контроль

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

Мониторинг и контроль включают в себя: ^{[ 41 ]}

Измерение текущей деятельности по проекту («где мы находимся»);
Мониторинг переменных проекта (затраты, усилия, объем и т. д.) в сравнении с планом управления проектом и базовыми показателями эффективности проекта ( где мы должны быть );
Определение корректирующих действий для надлежащего устранения проблем и рисков ( Как мы можем снова встать на правильный путь );
Влияние на факторы, которые могут обойти интегрированный контроль изменений, чтобы внедрялись только утвержденные изменения.

Два основных механизма поддерживают мониторинг и контроль в проектах. С одной стороны, контракты предлагают набор правил и стимулов, часто подкрепляемых потенциальными штрафами и санкциями. ^{[ 42 ]} С другой стороны, ученые в области бизнеса и менеджмента обратили внимание на роль интеграторов (также называемых проектными баронами) в достижении целей проекта. ^{[ 43 ]}^{[ 44 ]} В свою очередь, недавние исследования в области управления проектами поставили под сомнение тип взаимодействия между контрактами и интеграторами. Некоторые утверждают, что эти два механизма мониторинга заменяют собой ^{[ 45 ]} поскольку один тип организации уменьшит преимущества использования другого.

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

Сопровождение проекта — это непрерывный процесс, который включает в себя: ^{[ 38 ]}

Постоянная поддержка конечных пользователей
Исправление ошибок
Обновления продукта с течением времени

На этом этапе аудиторы должны обратить внимание на то, насколько эффективно и быстро решаются проблемы пользователей.

В ходе любого строительного проекта объем работ может меняться. Изменения — это нормальная и ожидаемая часть строительного процесса. Изменения могут быть результатом необходимых модификаций проекта, различных условий на объекте, наличия материалов, изменений, запрошенных подрядчиком, расчета стоимости и воздействия третьих сторон, и это лишь некоторые из них. Помимо выполнения изменений на местах, изменения обычно необходимо документировать, чтобы показать, что на самом деле было создано. Это называется управлением изменениями. Следовательно, владелец обычно требует окончательной записи, чтобы показать все изменения или, более конкретно, любые изменения, которые изменяют материальные части готовой работы. Запись делается в контрактной документации – обычно, но не обязательно, в проектных чертежах. Конечным продуктом этих усилий является то, что в отрасли называют исполнительными чертежами или, проще говоря, «как построено». Требование их предоставления является нормой в строительных контрактах. Управление строительной документацией — это очень важная задача, выполняемая с помощью онлайн- или настольного программного обеспечения или поддерживаемая с помощью физической документации. Растущая законность ведения правильной документации в строительной отрасли привела к увеличению потребности в системах управления документами.

Когда в проект вносятся изменения, жизнеспособность проекта приходится переоценивать. Важно не упускать из виду первоначальные цели и задачи проектов. Когда изменения накапливаются, прогнозируемый результат может не оправдать первоначально предложенные инвестиции в проект. Успешное управление проектом определяет эти компоненты, а также отслеживает и контролирует прогресс, чтобы оставаться в рамках сроков и бюджета, уже намеченных в начале проекта. Были предложены точные методы определения наиболее информативных точек мониторинга на протяжении жизненного цикла проекта относительно его хода и ожидаемой продолжительности. ^{[ 46 ]}

Закрытие

Закрытие включает в себя формальное принятие проекта и его завершение. Административная деятельность включает архивирование файлов и документирование извлеченных уроков.

Этот этап состоит из: ^{[ 38 ]}

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

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

Управление проектами и системы управления проектами

Контроль проекта (также известный как стоимостное проектирование ) должна быть установлена как независимая функция в управлении проектами. Он реализует функции проверки и контроля во время обработки проекта для усиления определенных показателей производительности и формальных целей. ^{[ 47 ]} Задачами проектного контроля также являются:

создание инфраструктуры для подачи нужной информации и ее обновления
создание способа информирования о различиях в параметрах проекта
разработка информационной технологии проекта на основе интранета или определение системы ключевых показателей эффективности (KPI) проекта
анализ расхождений и генерация предложений по потенциальному регулированию проекта ^{[ 48 ]}
установление методов создания соответствующей структуры проекта, организации рабочего процесса проекта, контроля и управления проектом.
создание прозрачности параметров проекта ^{[ 49 ]}

Выполнение и реализация этих задач могут быть достигнуты путем применения конкретных методов и инструментов проектного контроля. Могут применяться следующие методы управления проектом:

инвестиционный анализ
анализ затрат и выгод
анализ ценности и выгоды
экспертные опросы
имитационные расчеты
анализ профиля риска
расчет доплаты
основных тенденций анализ
анализ тенденций затрат
сравнение целевого/фактического значения ^{[ 50 ]}

Контроль проекта — это тот элемент проекта, который позволяет ему следовать графику, вовремя и в рамках бюджета. ^{[ 41 ]} Контроль проекта начинается на ранних этапах проекта с планирования и заканчивается на поздних стадиях проекта обзором после реализации с тщательным участием на каждом этапе процесса. Проекты могут подвергаться аудиту или проверке во время реализации проекта. Формальные аудиты, как правило, основаны на рисках или соблюдении требований, и руководство определяет цели аудита. Проверка может включать сравнение утвержденных процессов управления проектом с тем, как проект фактически управляется. ^{[ 51 ]} Каждый проект должен быть оценен на предмет соответствующего необходимого уровня контроля: слишком сильный контроль требует слишком много времени, слишком слабый контроль очень рискован. Если контроль над проектом реализован неправильно, следует уточнить стоимость для бизнеса с точки зрения ошибок и исправлений.

Системы контроля необходимы для затрат, рисков , качества, коммуникации, времени, изменений, закупок и человеческих ресурсов. Кроме того, аудиторы должны учитывать, насколько важны проекты для финансовой отчетности , насколько заинтересованные стороны зависят от средств контроля и сколько средств контроля существует. Аудиторы должны проанализировать процесс разработки и процедуры их реализации. При необходимости или запросе также можно оценить процесс разработки и качество конечного продукта. Предприятие может захотеть, чтобы аудиторская фирма участвовала в этом процессе, чтобы выявить проблемы на более раннем этапе и облегчить их устранение. Аудитор может выступать в качестве консультанта по средствам контроля в составе группы разработчиков или в качестве независимого аудитора в рамках аудита.

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

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

Характеристики проектов

Существует пять важных характеристик проекта:

(i) Всегда должны быть указаны конкретные даты начала и окончания.

(ii) Они выполняются и завершаются группой людей.

(iii) Результатом является поставка уникального продукта или услуги.

(iv) Они носят временный характер.

(v) Он постепенно дорабатывается.

Примеры: проектирование новой машины или написание книги.

Сложность проекта

Сложность и ее природа играют важную роль в области управления проектами. Несмотря на ряд дискуссий по этому вопросу, исследования показывают отсутствие определения и разумного понимания сложности управления сложными проектами. ^{[ 52 ]}^{[ 53 ]}

Сложность проекта — это свойство проекта, которое затрудняет понимание, прогнозирование и контроль его общего поведения, даже если имеется достаточно полная информация о системе проекта. ^{[ 54 ]}

Идентификация сложных проектов особенно важна для многопроектных инженерных сред. ^{[ 55 ]}

Поскольку считается, что сложность проекта и его производительность тесно связаны, важно определить и измерить сложность проекта, чтобы управление проектом было эффективным. ^{[ 56 ]}

Сложность может быть:

Структурная сложность (также известная как сложность деталей, или комплексность), т.е. состоящая из множества разнообразных взаимосвязанных частей. ^{[ 57 ]} Обычно оно выражается в размерах, разнообразии и взаимозависимости компонентов проекта и описывается технологическими и организационными факторами.
Динамическая сложность относится к таким явлениям, характеристикам и проявлениям, как двусмысленность, неопределенность, распространение, возникновение и хаос. ^{[ 54 ]}

На основе платформы Cynefin , ^{[ 58 ]} Сложные проекты можно разделить на:

Простые (или ясные, очевидные, известные) проекты, системы или контексты. Они характеризуются известными известными, стабильностью и четкими причинно-следственными связями. Их можно решить с помощью стандартных операционных процедур и лучших практик.
Сложный : характеризуется известными неизвестными. Сложная система – это сумма ее частей. В принципе, его можно разобрать на более мелкие и простые компоненты. Несмотря на то, что сложные проблемы теоретически можно решить с помощью дополнительных ресурсов, специализированного опыта, аналитических, редукционистских методов, методов упрощения, декомпозиции, планирования сценариев и следования передовому опыту. ^{[ 59 ]}^{[ 60 ]}
Сложные характеризуются неизвестным неизвестным и возникновением. Закономерности можно обнаружить, но они не очевидны. Сложную систему можно описать утверждением Евклида о том, что целое больше, чем сумма его частей.
Действительно сложные проекты , то есть очень сложные или хаотичные: характеризующиеся непознаваемым. В действительно сложных проектах не просматриваются закономерности. Причины и следствия неясны даже в ретроспективе. Перефразируя Аристотеля , действительно сложная система отлична от суммы своих частей. ^{[ 61 ]}

Применяя открытие в измерении сложности работы, описанное в книге « Необходимая организация и теория стратифицированных систем», Эллиот Жак классифицирует проекты и проектную работу (этапы, задачи) на семь основных уровней сложности проекта на основе таких критериев, как временной интервал усмотрения и сложность проекта. результат проекта: ^{[ 62 ]}^{[ 63 ]}

Проект уровня 1 – улучшить непосредственный результат деятельности (количество, качество, время) в рамках бизнес-процесса с целевым сроком завершения до 3 месяцев.
Проект уровня 2 – разработка и улучшение соответствия бизнес-процессу с целевым сроком завершения от 3 месяцев до 1 года.
Проект уровня 3 – разработка, изменение и улучшение бизнес-процесса с целевым сроком завершения от 1 до 2 лет.
Проект уровня 4 – разработка, изменение и улучшение функциональной системы с целевым сроком завершения от 2 до 5 лет.
Проект уровня 5 – разработка, изменение и улучшение группы функциональных систем/бизнес-функций с целевым сроком завершения от 5 до 10 лет.
Проект уровня 6 – развивать, изменять и совершенствовать всю единую цепочку создания стоимости компании с целевым сроком завершения от 10 до 20 лет.
Проект уровня 7 – разработка, изменение и улучшение нескольких цепочек создания стоимости компании с целевым сроком завершения от 20 до 50 лет. ^{[ 64 ]}

Преимущества измерения сложности проекта заключаются в повышении осуществимости проекта за счет сопоставления уровня сложности проекта с эффективным целевым временем завершения и соответствующим уровнем возможностей менеджера проекта и участников проекта. ^{[ 65 ]}

Положительная, уместная (необходимая) и отрицательная сложность.

Аналогично Закону необходимого разнообразия и Закону необходимой сложности , сложность проекта иногда необходима для того, чтобы проект достиг своих целей, а иногда это приводит к положительным результатам. Основываясь на эффектах сложности, Стефан Морков предложил классифицировать его как положительный, соответствующий или отрицательный. ^{[ 66 ]}^{[ 61 ]}

Позитивная сложность — это сложность, которая повышает ценность проекта и чей вклад в успех проекта перевешивает связанные с этим негативные последствия.
Соответствующая (или необходимая) сложность — это сложность, которая необходима для достижения проектом своих целей, или чей вклад в успех проекта уравновешивает негативные последствия, или стоимость смягчения последствий перевешивает негативные проявления.
Отрицательная сложность — это сложность, которая препятствует успеху проекта.

Менеджеры проектов

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

Менеджер проекта должен понимать порядок выполнения проекта, чтобы правильно его запланировать, а также время, необходимое для выполнения каждой отдельной задачи в рамках проекта. Менеджер проекта — это лицо, ответственное за достижение заявленных целей проекта от имени клиента. Менеджеры проектов, как правило, имеют многолетний опыт работы в своей области. Менеджер проекта должен знать проект от и до, контролируя рабочих во время проекта. Обычно в большинстве строительных, инженерных, архитектурных и промышленных проектов рядом с менеджером проекта работает другой менеджер, который обычно отвечает за выполнение задач на ежедневной основе. Эта должность в некоторых случаях известна как суперинтендант. Суперинтендант и менеджер проекта работают рука об руку, выполняя ежедневные задачи проекта. Ключевые обязанности управления проектом включают создание четких и достижимых целей проекта, формирование требований к проекту и управление тройное ограничение (теперь включающее больше ограничений и называющее его конкурирующими ограничениями) для проектов, то есть стоимость, время, качество и объем для первых трех и около трех дополнительных в текущем управлении проектами. Типичный проект состоит из группы работников, которые работают под руководством менеджера проекта и выполняют задание в пределах запланированного времени и бюджета. Менеджер проекта обычно отчитывается непосредственно перед кем-то более высокого уровня о завершении и успехе проекта.

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

Полный менеджер проекта — термин, впервые введенный Робертом Дж. Грэмом в его моделировании, был расширен Рэндаллом Л. Инглундом и Альфонсо Бусеро. Они описывают полноценного менеджера проекта как человека, который охватывает несколько дисциплин, таких как лидерство , влияние, переговоры, политика, управление изменениями и конфликтами, а также юмор. Все это «мягкие» человеческие навыки, которые позволяют руководителям проектов быть более эффективными и достигать оптимизированных и последовательных результатов.

Многоуровневая структура и критерии успеха: успех проекта и эффективность проекта

Существует тенденция путать успех проекта с успехом управления проектом. Это две разные вещи. «Успех проекта» имеет 2 перспективы:

перспектива процесса, т.е. получение эффективных результатов; обычно называется эффективностью управления проектом или эффективностью проекта.
перспектива результата, т.е. достижение выгодных результатов; обычно называется эффективностью проекта (иногда просто успехом проекта). ^{[ 67 ]}^{[ 68 ]}^{[ 69 ]}^{[ самостоятельно опубликованный источник? ]}

Критерии успеха управления проектами отличаются от критериев успеха проекта. Управление проектом считается успешным, если данный проект завершен в согласованные сроки, соответствует согласованному объему и в пределах согласованного бюджета. Помимо тройных ограничений, для обеспечения успеха проекта были учтены многочисленные ограничения. Однако тройные или множественные ограничения указывают только на показатели эффективности проекта, которые действительно являются критериями успеха управления проектом в течение жизненного цикла проекта.

Априорные критерии не учитывают более важные результаты проекта после завершения, которые включают четыре уровня, а именно: успех продукта (продукта), успех результата (выгоды) и успех воздействия (стратегический) в течение жизненного цикла продукта. Эти апостериорные критерии успеха указывают на показатели эффективности продукта, услуги или результата проекта после завершения и передачи проекта. Эта всеобъемлющая многоуровневая структура успеха проектов, программ и портфелей была разработана Полом Баннерманом в 2008 году. ^{[ 70 ]} Другими словами, проект считается успешным, когда ему удается достичь ожидаемого экономического обоснования, которое необходимо четко идентифицировать и определить на этапе создания и отбора проекта перед началом фазы разработки. Эта многоуровневая структура успеха соответствует теории проекта как трансформации, описываемой как воздействие «вход-процесс/деятельность-выход-результат» с целью создания любой задуманной ценности. Эмануэль Камиллери в 2011 году классифицирует все критические факторы успеха и неудачи на группы и сопоставляет каждый из них с многоуровневыми критериями успеха, чтобы обеспечить ценность бизнеса. ^{[ 71 ]}

Примером показателя эффективности, используемого в отношении управления проектами, является «невыполненные проекты» или «незавершенные проекты». ^{[ 72 ]}

Управление рисками

США Министерство обороны заявляет, что «Затраты, график, производительность и риск» - это четыре элемента, с помощью которых специалисты по закупкам Министерства обороны идут на компромисс и отслеживают статус программы. ^{[ 73 ]} Существуют также международные стандарты . В управлении рисками применяется упреждающее выявление (см. инструменты ) будущих проблем и понимание их последствий, что позволяет принимать прогнозные решения по проектам. Система ERM играет роль в общем управлении рисками. ^{[ 74 ]}

Структура декомпозиции работ и другие структуры декомпозиции

Иерархическая структура работ (WBS) — это древовидная структура , которая показывает подразделение действий, необходимых для достижения цели — например, портфолио, программа, проект и контракт. WBS может быть ориентирована на оборудование, продукцию, услуги или процессы (см. пример в структуре отчетности НАСА (2001) ). ^{[ 75 ]} Помимо WBS для управления содержанием проекта, существуют организационная иерархическая структура (диаграмма) , иерархическая структура затрат и иерархическая структура рисков .

WBS можно разработать, начав с конечной цели и последовательно разделив ее на управляемые компоненты с точки зрения размера, продолжительности и ответственности (например, системы, подсистемы, компоненты, задачи, подзадачи и пакеты работ), которые включают в себя все шаги, необходимые для достижения цели. ^{[ 33 ]}

Структура декомпозиции работ обеспечивает общую основу для естественного развития общего планирования и контроля контракта и является основой для разделения работы на определяемые приращения, на основе которых может быть разработано техническое задание, график, стоимость и трудозатраты. можно установить отчетность. ^{[ 75 ]} Иерархическая структура работ может отображаться в двух формах: в виде таблицы с разделением задач или в виде организационной схемы, нижние узлы которой называются «пакетами работ».

Это важный элемент оценки качества плана и исходный элемент, используемый при планировании проекта. Например, WBS используется при планировании проекта, чтобы можно было записывать и отслеживать использование рабочих пакетов.

Подобно иерархической структуре работ (WBS), другими методами и инструментами декомпозиции являются: иерархическая структура организации (OBS), иерархическая структура продукта (PBS), иерархическая структура затрат (CBS), иерархическая структура рисков (RBS) и иерархическая структура ресурсов (ResBS). ). ^{[ 76 ]}^{[ 61 ]}

Международные стандарты

Существует несколько стандартов управления проектами, в том числе:

Стандарты ISO ISO 9000 , семейство стандартов для систем управления качеством, и ISO 10006 :2003, для систем управления качеством и руководящих указаний по управлению качеством в проектах.
ISO 21500 :2012 – Руководство по управлению проектами . Это первый международный стандарт, связанный с управлением проектами, опубликованный ISO. Другие стандарты семейства 21500 включают 21503:2017 «Руководство по управлению программами» ; 21504:2015 Руководство по управлению портфелем ; 21505:2017 Руководство по управлению ; 21506:2018 Словарь ; 21508:2018 Управление прибавочной стоимостью в управлении проектами и программами ; и 21511:2018 Структуры разбивки работ для управления проектами и программами.
ISO 21502:2020 Управление проектами, программами и портфелями. Руководство по управлению проектами
ISO 21503:2022 Управление проектами, программами и портфелями. Руководство по управлению программами
ISO 21504:2015 Управление проектами, программами и портфелями. Руководство по управлению портфелем
ISO 21505:2017 Управление проектами, программами и портфелями. Руководство по управлению
ISO 31000 :2009 – Управление рисками.
ISO/IEC/IEEE 16326:2009 – Системная и программная инженерия. Процессы жизненного цикла. Управление проектами. ^{[ 77 ]}
Базовый уровень индивидуальной компетентности (ICB) от Международной ассоциации управления проектами (IPMA). ^{[ 78 ]}
Модель зрелости возможностей (CMM) от Института программной инженерии .
GAPPS, Глобальный альянс стандартов эффективности проектов – стандарт с открытым исходным кодом, описывающий КОМПЕТЕНЦИИ для менеджеров проектов и программ.
Метод HERMES , швейцарский общий метод управления проектами, выбранный для использования в Люксембурге и международных организациях.
( Подход логической структуры LFA), популярный в международных организациях развития.
Руководство PMBOK от Института управления проектами (PMI).
ПРИНЦ2 из AXELOS .
ПМ ²: Методология управления проектами, разработанная [Европейской комиссией]. ^{[ 79 ]}
Процедуры разработки и управления проектами (PPFM) Министерства обороны Индии ^{[ 80 ]}
Team Software Process (TSP) от Института программной инженерии .
Структура управления совокупными затратами , методология AACE International для интегрированного управления портфелем, программами и проектами.
V-Model — оригинальный метод разработки систем.

Управление программами и сети проектов

Некоторыми проектами, одинаковыми или разными, можно управлять как программным управлением. Программы — это наборы проектов, которые поддерживают общую цель и набор задач. В то время как отдельные проекты имеют четко определенные и конкретные масштабы и сроки, цели и продолжительность программы определяются с более низким уровнем детализации.

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

Сеть проекта — это временный проект, состоящий из нескольких различных этапов развития, пересекающих организационные границы. Мегапроекты и мегапрограммы определяются как исключительные с точки зрения размера, стоимости, общественного и политического внимания, а также требуемых компетенций. ^{[ 61 ]}

Управление портфелем проектов

Все большее число организаций используют так называемое управление портфелем проектов (PPM) как средство выбора правильных проектов, а затем используют методы управления проектами. ^{[ 81 ]} как средство достижения результатов в виде выгод для действующей государственной, частной или некоммерческой организации.

Портфолио — это коллекции похожих проектов. Управление портфелем поддерживает эффективность масштабирования, повышение показателей успеха и снижение рисков проекта за счет применения аналогичных стандартизированных методов ко всем проектам в портфеле группой специалистов по управлению проектами, которые делятся общими инструментами и знаниями. Организации часто создают офисы управления проектами в качестве организационной структуры для структурированной поддержки управления портфелем проектов. ^{[ 61 ]} Таким образом, PPM обычно выполняется специальной командой менеджеров, организованной в офисе управления проектами предприятия (PMO), обычно базирующейся внутри организации, и возглавляемой директором PMO или главным директором проекта. В тех случаях, когда стратегические инициативы организации составляют основную часть PPM, главу PPM иногда называют главным директором по инициативам.

Программное обеспечение для управления проектами

Программное обеспечение для управления проектами — это программное обеспечение, которое помогает планировать, организовывать и управлять пулами ресурсов, разрабатывать оценки ресурсов и реализовывать планы. В зависимости от сложности программного обеспечения функциональность может включать оценку и планирование, планирование , контроль затрат и управление бюджетом , распределение ресурсов , программное обеспечение для совместной работы , коммуникацию , принятие решений , рабочий процесс , риски , качество, документацию и/или системы администрирования. ^{[ 82 ]}^{[ 83 ]}

Виртуальное управление проектами

Управление виртуальными программами (VPM) — это управление проектом, выполняемое виртуальной командой , хотя оно редко может относиться к проекту, реализующему виртуальную среду. ^{[ 84 ]} Отмечается, что управление виртуальным проектом принципиально отличается от управления традиционными проектами. ^{[ 85 ]} объединение задач удаленной работы и глобального сотрудничества (культура, часовые пояса, язык). ^{[ 86 ]}

См. также

Связанные поля

Списки

Ссылки

^ Филлипс, Джозеф (2004). Профессиональное учебное пособие по управлению проектами PMP . МакГроу-Хилл/Осборн. п. 354. ИСБН 0072230622 .
^ Баратта, Анджело (2006). «Тройное ограничение — тройная иллюзия» . ПМИ . Проверено 22 декабря 2020 г.
^ Ноукс, Себастьян; Келли, Шон (2007). Полное руководство по управлению проектами: быстрый путь к выполнению работы вовремя и в рамках бюджета . Пирсон Образование. Прентис Холл Файнэншл Таймс. ISBN 9780273710974 .
^ «Что такое управление проектами?» . Институт управления проектами . Проверено 4 июня 2014 г.
^ Динсмор, Пол С.; Кук-Дэвис, Теренс Дж. (4 ноября 2005 г.). Правильные проекты, сделанные правильно: от бизнес-стратегии к успешной реализации проектов . Уайли. п. 35. ISBN 0787971138 .
^ Каттани, Г.; Ферриани, С.; Фредериксен, Л.; Флориан, Т. (2011). Проектно-ориентированная организация и стратегическое управление . Достижения в области стратегического управления. Том. 28. Изумруд. ISBN 978-1780521930 .
^ Лок, Деннис. Управление проектами (9-е изд.). ISBN 9780566087721 .
^ Квак, Ён Хун (2005). «Краткая история управления проектами». В Элиасе Г. Караяннисе (ред.). История управления проектами . Академик Блумсбери. ISBN 1567205062 .
^ Клеланд, Дэвид; Гарейс, Роланд (25 мая 2006 г.). «1: Эволюция управления проектами». Руководство по глобальному управлению проектами . Макгроу-Хилл Образование. ISBN 0071460454 .
^ Стивенс, Мартин (2002). Пути управления проектами . Ассоциация управления проектами. п. XXII. ISBN 190349401X .
^ Марш, Эдвард Р. (1975). «Гармонограмма Кароля Адамецкого». Журнал Академии менеджмента . 18 (2): 358–364. дои : 10.2307/255537 . JSTOR 255537 .
^ Витцель, Морген (2003). Пятьдесят ключевых фигур в менеджменте . Психология Пресс. стр. 96–101. ISBN 0415369770 .
^ Клеланд, Дэвид; Гарейс, Роланд (25 мая 2006 г.). Справочник по глобальному управлению проектами: планирование, организация и контроль международных проектов . Макгроу-Хилл Образование. стр. 1–4. ISBN 0071460454 . Это было в 1950-х годах, когда управление проектами было официально признано как особый вклад, вытекающий из управленческой дисциплины.
^ Малькольм, генеральный директор; Роузбум, Дж. Х.; Кларк, CE; Фазар, В. (1959). «Применение метода оценки программ исследований и разработок» (PDF) . Исследование операций . 7 (5): 646–669. дои : 10.1287/opre.7.5.646 .
^ Харрисон, Флорида; Лок, Деннис (2004). Расширенное управление проектами: структурированный подход . Издательство Гауэр. п. 34. ISBN 0566078228 .
^ Саладис, ФП (2006). «Воплощение руководства PMBOK® в жизнь» . Глобальный конгресс PMI . Сиэтл, Вашингтон: Институт управления проектами.
^ «Сертифицированный менеджер по строительству» . СМАА. Архивировано из оригинала 28 ноября 2013 года . Проверено 23 ноября 2013 г.
^ «Сертификат по управлению биотехнологическими проектами» . Университет Вашингтона . Проверено 23 ноября 2013 г.
^ Ша, Мэнди; Иммервар, Стивен (19 февраля 2018 г.). «Перевод опросов: почему и как следует привлекать исследователей и менеджеров?» . Практика опросов . 11 (2): 1–10. дои : 10.29115/SP-2018-0016 .
^ Ша, Мэнди; Чайлдс, Дженнифер Хантер (1 августа 2014 г.). «Применение подхода к управлению проектами для исследовательских проектов, в которых используются качественные методы» . Практика опросов . 7 (4): 1–8. дои : 10.29115/SP-2014-0021 .
^ Эсселинк, Берт (2000). Практическое руководство по локализации . Амстердам/Филадельфия: Издательская компания Джона Бенджамина. п. 428. ИСБН 978-9-027-21956-5 .
^ Месли, Оливье (15 декабря 2016 г.). Осуществимость проекта: инструменты выявления уязвимых мест . CRC Press, Тейлор и Фрэнсис. ISBN 9781498757911 . .
^ См. The Bridger (блог), «Управление проектами: PMP, Prince 2 или итеративный или гибкий вариант»
^ Серра, CEM; Кунц, М. (2014). «Управление реализацией выгод и его влияние на успех проекта и реализацию бизнес-стратегий» . Международный журнал управления проектами . 33 (1): 53–66. дои : 10.1016/j.ijproman.2014.03.011 .
^ «Выход за пределы метода критического пути» . www.pmi.org . Проверено 27 декабря 2021 г.
^ Махмуди, Амин; Багерпур, Мортеза; Джавед, Саад Ахмед (2021). «Управление серой прибавочной стоимостью: теория и приложения» . Транзакции IEEE по инженерному менеджменту . 68 (6): 1703–1721. дои : 10.1109/tem.2019.2920904 . ISSN 0018-9391 . S2CID 202102868 .
^ Хасс, Кэтлин Б. (Китти) (2 марта 2010 г.). «Управление сложными проектами, которые являются слишком большими, слишком длинными и слишком дорогостоящими» . ПМ Таймс . Проверено 27 июня 2017 г.
^ Конфорто, ЕС; Салум, Ф.; Амарал, округ Колумбия; да Силва, SL; Маньянини де Алмейда, LF (июнь 2014 г.). «Может ли гибкое управление проектами быть внедрено в других отраслях, кроме разработки программного обеспечения?». Журнал управления проектами . 45 (3): 21–34. дои : 10.1002/pmj.21410 . S2CID 110595660 .
^ Сноуден, Дэвид Дж .; Бун, Мэри Э. (ноябрь 2007 г.). «Система принятия решений лидером» . Гарвардское деловое обозрение . Проверено 27 июня 2017 г.
^ «Стэнфордское исследование показало, что инновационная инженерия представляет собой настоящую систему «прорывных инноваций»» . Новости ИЕ . 20 июня 2017 г. Проверено 11 августа 2017 г.
^ Высоцкий, Роберт К. (2013). Эффективное управление проектами: традиционное, адаптивное, экстремальное (Седьмое изд.). Джон Уайли и сыновья . ISBN 978-1118729168 .
^ Ройс, Уинстон В. (25–28 августа 1970 г.). «Управление разработкой больших программных систем» (PDF) . Технические документы Western Electronic Show and Convention (WesCon) . Лос-Анджелес. Архивировано из оригинала (PDF) 15 марта 2016 г. {{cite journal}}: CS1 maint: дата и год ( ссылка )
^ Перейти обратно: ^а ^б Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения . О'Рейли Медиа. ISBN 978-0-596-00948-9 . Архивировано из оригинала 9 февраля 2015 года.
^ Маккаффер, Рональд; Харрис, Фрэнк (2013). Современный строительный менеджмент . Уайли-Блэквелл. п. 5. ISBN 978-1118510186 . OCLC 834624541 .
^ Управление государственной торговли (1996) Управление успешными проектами с PRINCE2 , стр. 14
^ «OGC – PRINCE2 – Фон» . Архивировано из оригинала 22 августа 2011 года.
^ Перейти обратно: ^а ^б ^с ^д ^и ^ж «Руководство по управлению проектами» (PDF) . Управление информации и технологий штата Вирджиния . 2003. Архивировано из оригинала 14 января 2009 года. {{cite web}}: CS1 maint: неподходящий URL ( ссылка )
^ Перейти обратно: ^а ^б ^с ПМИ (2010). Руководство к своду знаний по управлению проектами , стр. 27–35.
^ Натан, Питер; Джеральд Эверетт Джонс (2003). Сертификация PMP для чайников , с. 63.
^ Керцнер, Гарольд (2003). Управление проектами: системный подход к планированию, составлению графиков и контролю (8-е изд.). Уайли. ISBN 0-471-22577-0 .
^ Перейти обратно: ^а ^б Льюис, Джеймс П. (2000). Справочник руководителя проекта: подробное руководство по планированию, составлению графиков, оценке и системам проекта . п. 185.
^ Экклс, Роберт Г. (1981). «Квазифирма в строительной отрасли» . Журнал экономического поведения и организации . 2 (4): 335–357. дои : 10.1016/0167-2681(81)90013-5 . ISSN 0167-2681 .
^ Дэвис, Эндрю; Хобдей, Майкл (2005). Бизнес проектов: управление инновациями в сложных продуктах и системах . Издательство Кембриджского университета. ISBN 978-0-521-84328-7 .
^ Ганн, Дэвид; Солтер, Аммон; Доджсон, Марк; Филипс, Нельсон (2012). «Внутри мира проекта барон» . Обзор менеджмента Слоана MIT . 53 (3): 63–71. ISSN 1532-9194 .
^ Мэн, Сяньхай (2012). «Влияние управления взаимоотношениями на эффективность проекта в строительстве» . Международный журнал управления проектами . 30 (2): 188–198. дои : 10.1016/j.ijproman.2011.04.002 .
^ Коэн Каши С., Розенес С. и Бен-Гал И. (2016). «Мониторинг управления проектами на основе энтропии ожидаемой продолжительности» (PDF) . В Энтропии 2020 — 22, 905. {{cite web}}: CS1 maint: несколько имен: список авторов ( ссылка ) CS1 maint: числовые имена: список авторов ( ссылка )
^ Беккер, Джарг; Кугелер, Мартин; Розманн, Майкл (2003). Управление процессами: Руководство по проектированию бизнес-процессов . Спрингер. п. 27. ISBN 9783540434993 .
^ Шлагек, Бернхард (2000). Объектно-ориентированные эталонные модели для управления процессами и проектами: основы – построение – возможные применения . ISBN 978-3-8244-7162-1 , с. 131.
^ Ридл, Йозеф Э. (1990). Контроль проектов в области исследований и разработок . ISBN 978-3-540-51963-8 , с. 99.
^ Штайнле, Брух, Лава (1995). Управление проектом . Деловые книги издательского подразделения ФАЗ, стр. 136–143.
^ Снайдер, Синтия; Фрэнк Парт (2006). Введение в управление ИТ-проектами , стр. 393-397.
^ Абду, Саед М; Йонг, Куан; Осман, Мохаммед (2016). «Влияние сложности проекта на эффективность управления проектом – взгляд Малайзии» . Сеть конференций MATEC . 66 : 00065. doi : 10.1051/matecconf/20166600065 . ISSN 2261-236X .
^ Морков, Стефан; Пинтелон, Лилиан; Кастерс, Роб Дж. (2020). «Определения, характеристики и меры сложности ИТ-проектов — систематический обзор литературы» (PDF) . Международный журнал информационных систем и управления проектами . 8 (2): 5–21. дои : 10.12821/ijispm080201 . S2CID 220545211 .
^ Перейти обратно: ^а ^б Марл, Франк; Видаль, Людовик-Александр (2016). Управление сложными проектами с высоким риском. Руководство по базовому и расширенному управлению проектами . Лондон: Springer-Verlag.
^ Видаль, Людовик-Александр; Марл, Франк; Боке, Жан-Клод (2011). «Измерение сложности проекта с помощью процесса аналитической иерархии» (PDF) . Международный журнал управления проектами . 29 (6): 718–727. дои : 10.1016/j.ijproman.2010.07.005 . S2CID 111186583 .
^ Видаль, Людовик-Александр; Марл, Франк (2008). «Понимание сложности проекта: последствия для управления проектами» (PDF) . Кибернет . 37 (8): 1094–1110. дои : 10.1108/03684920810884928 .
^ Баккарини, Д. (1996). «Понятие сложности проекта, обзор». Международный журнал управления проектами . 14 (4): 201–204. дои : 10.1016/0263-7863(95)00093-3 .
^ Сноуден, Дэвид Дж.; Бун, Мэри Э. (2007). «Система принятия решений лидером» . Гарвардское деловое обозрение . 85 (11): 68–76. {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )
^ Маурер, Майк (2017). Управление сложностью в инженерном проектировании – учебник для начинающих . Берлин, Гейдельберг: Springer.
^ Курц, CF; Сноуден, Дэвид Дж. (2003). «Новая динамика стратегии: осмысление в сложном и запутанном мире». Системный журнал IBM . 42 (3): 462–483. дои : 10.1147/sj.423.0462 . S2CID 1571304 . {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )
^ Перейти обратно: ^а ^б ^с ^д ^и ^ж Морков, С. (2021). «Управление положительной и отрицательной сложностью: разработка и проверка структуры управления сложностью ИТ-проектов» . КУ Левенского университета .
^ Моррис, Питер (1994). Управление проектами . Лондон: Т. Телфорд. п. 317. ИСБН 978-0727725936 . ОСЛК 30437274 .
^ Справочник Гауэра для людей, занимающихся управлением проектами . Лок, Деннис, Скотт, Линдси, 1974–. Фарнхэм, Суррей: Gower Publishing. 2013. с. 398. ИСБН 978-1409437857 . OCLC 855019788 . {{cite book}}: CS1 maint: другие ( ссылка )
^ «ПМО» . www.theprojectmanager.co.za . Проверено 1 марта 2018 г.
^ Комиссия, Государственная служба Австралии. «Структура APS для оптимальных структур управления» . Проверено 1 марта 2018 г.
^ Морков, Стефан; Пинтелон, Лилиан; Кастерс, Роб Дж. (2020). «Управление сложностью ИТ-проектов на основе источников и эффектов: положительные, соответствующие и отрицательные» (PDF) . Труды Румынской Академии - Серия А. 21 (4): 329–336.
^ Даниэль, Пьер А.; Дэниел, Кэрол (январь 2018 г.). «Сложность, неопределенность и ментальные модели: от парадигмы регулирования к парадигме возникновения в управлении проектами». Международный журнал управления проектами . 36 (1): 184–197. дои : 10.1016/j.ijproman.2017.07.004 .
^ Пинто, Джеффри К.; Лебедка, Грэм (1 февраля 2016 г.). «Тревога« устоявшейся науки : прошлое и будущее управления проектами». Международный журнал управления проектами . 34 (2): 237–245. дои : 10.1016/j.ijproman.2015.07.011 .
^ Морков, Стефан (6 апреля 2021 г.). «Успех проекта и эффективность управления проектом» .
^ Баннерман, Польша (2008). «Определение успеха проекта: многоуровневая структура» . Определение будущего управления проектами . Варшава, Польша: Институт управления проектами.
^ Камиллери, Эмануэль (2011). Успех проекта: критические факторы и поведение . Гауэр Паблишинг, ООО
^ Институт КПИ, «КПЭ дня – Бизнес-консалтинг (БК): $ Задел сданных проектов». Журнал Performance Magazine , 16 марта 2021 г. По состоянию на 23 декабря 2022 г.
^ «ДоДД 5000.01» (PDF) . Министерство обороны США. Архивировано из оригинала (PDF) 25 августа 2009 г. Проверено 20 ноября 2007 г.
^ «Устранение риска из управления рисками: целостный подход к управлению рисками предприятия» . Стратегическое направление . 32 (5): 28–30. 1 января 2016 г. doi : 10.1108/SD-02-2016-0030 . ISSN 0258-0543 .
^ Перейти обратно: ^а ^б НАСА НПР 9501.2D . 23 мая 2001 г.
^ Левин, HA (1993). «Виби и оби: новые танцы для менеджеров проектов?» Сеть PM , 7 (4), 35–38.
^ Системы ISO/IEC/IEEE и разработка программного обеспечения – Процессы жизненного цикла – Управление проектами . дои : 10.1109/IEESTD.2009.5372630 . ISBN 978-0-7381-6116-7 .
^ Базовый уровень индивидуальной компетентности для управления проектами, программами и портфелями (PDF) . Международная ассоциация управления проектами (IPMA). 2015. ISBN 978-94-92338-01-3 .
^ Европейская комиссия. ПМ ²: Методология управления проектами, разработанная Европейской комиссией.
^ Мохиндра Т. и Шривастава М. (2019). «Сравнительный анализ рамок управления проектами и предложений для проектно-ориентированных организаций». PM World Journal , VIII (VIII).
^ Гамильтон, Альберт (2004). Справочник по процедурам управления проектами . ТТЛ Паблишинг, ООО ISBN 0-7277-3258-7
^ PMBOK 4ч Эд . PMI, Институт управления проектами. 2008. с. 443. ИСБН 978-1933890517 .
^ Кендрик, Том (2013). Набор инструментов управления проектами: 100 советов и приемов для правильного выполнения работы , третье издание. Книги АМАКОМ. ISBN 9780814433454
^ Керли, Ванда (2011). Виртуальный офис управления проектами: лучшие практики, проверенные методы . Концепции управления Пресс.
^ Хазанчи, Дипак (2005). Модели эффективного управления проектами в виртуальных проектах: предварительное исследование . Институт управления проектами. ISBN 9781930699830 . Архивировано из оригинала 23 октября 2013 года.
^ Велагапуди, Мридула (13 апреля 2012 г.). «Почему нельзя избежать виртуального управления проектами, начиная с 2012 г.» .

Внешние ссылки

Ресурсы библиотеки о
Управление проектом

Рекомендации по управлению проектами Министерства бизнеса, предпринимательства и нормативно-правовой реформы Великобритании (BERR)