Управление проектами — это процесс контроля работы команды для достижения всех целей проекта в рамках заданных ограничений. [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 и Remington Rand для управления проектами по техническому обслуживанию предприятий. Метод оценки и обзора программ (PERT) был разработан Управлением специальных проектов ВМС США совместно с корпорациями Lockheed и Booz Allen Hamilton в рамках программы по подводным ракетам Polaris . [14]
PERT и CPM очень похожи в своем подходе, но все же имеют некоторые различия. CPM используется для проектов, которые предполагают детерминированное время активности; время, в которое будет выполняться каждое действие, известно. PERT, с другой стороны, допускает стохастическое время активности; время, в которое будет выполняться каждое действие, неопределенно или варьируется. Из-за этого основного различия CPM и PERT используются в разных контекстах. Эти математические методы быстро распространились на многие частные предприятия.
В то же время, по мере разработки моделей планирования проектов, развивалась технология оценки стоимости проекта, управления затратами и инженерной экономики, с пионерской работой Ханса Ланга и других. В 1956 году Американская ассоциация инженеров-стоимостников (теперь AACE International ; Ассоциация по развитию стоимостной инженерии ) была сформирована ранними практиками управления проектами и связанными с ними специальностями планирования и составления расписания , оценки затрат и контроля проектов. AACE продолжила свою пионерскую работу и в 2006 году выпустила первый интегрированный процесс для управления портфелем, программой и проектом ( структура управления общей стоимостью ).
В 1969 году в США был создан Институт управления проектами (PMI). [15] В 1996 году PMI публикует оригинальную версию Руководства к своду знаний по управлению проектами (Руководство PMBOK) с Уильямом Дунканом в качестве основного автора, в котором описываются практики управления проектами, которые являются общими для «большинства проектов, большую часть времени». [16]
Методы управления проектами могут быть применены к любому проекту. Они часто адаптируются к определенному типу проекта в зависимости от размера проекта, характера, отрасли или сектора. Например, строительная отрасль, которая фокусируется на поставке таких вещей, как здания, дороги и мосты, разработала свою собственную специализированную форму управления проектами, которая называется управлением строительными проектами и в которой менеджеры проектов могут пройти обучение и сертификацию. [17] Индустрия информационных технологий также развивалась, чтобы разработать свою собственную форму управления проектами, которая называется управлением ИТ-проектами и которая специализируется на поставке технических активов и услуг, которые должны проходить через различные фазы жизненного цикла, такие как планирование, проектирование, разработка, тестирование и развертывание. Управление биотехнологическими проектами фокусируется на тонкостях исследований и разработок в области биотехнологий. [18] Управление проектами локализации включает применение многих стандартных практик управления проектами к переводческим работам, хотя многие считают этот тип управления совершенно другой дисциплиной. Например, менеджеры проектов играют ключевую роль в улучшении перевода, даже если они не говорят на языке перевода, потому что они хорошо знают цели исследования, чтобы принимать обоснованные решения. [19] Аналогично, управление научными исследованиями также может применять подход управления проектами. [20] Существует управление государственными проектами, которое охватывает все общественные работы правительства, которые могут выполняться государственными агентствами или передаваться по контракту подрядчикам. Другая классификация управления проектами основана на жестком (физическом) или мягком (нефизическом) типе.
Общим для всех типов управления проектами является то, что они фокусируются на трех важных целях: время, качество и стоимость. Успешные проекты завершаются по графику, в рамках бюджета и в соответствии с ранее согласованными стандартами качества, т.е. соответствуют Железному Треугольнику или Тройному Ограничению, чтобы проекты считались успешными или неудачными. [21]
Для каждого типа управления проектами менеджеры проектов разрабатывают и используют повторяющиеся шаблоны, которые специфичны для отрасли, с которой они имеют дело. Это позволяет планам проектов стать очень подробными и высокоповторяемыми, с конкретным намерением повысить качество, снизить затраты на доставку и сократить время на получение результатов проекта.
Исследование, проведенное в 2017 году, показало, что успех любого проекта зависит от того, насколько хорошо четыре ключевых аспекта согласованы с контекстуальной динамикой, влияющей на проект. Их называют четырьмя «П» : [22]
Существует ряд подходов к организации и выполнению проектных мероприятий, включая поэтапный, бережливый, итеративный и инкрементальный. Также существует несколько расширений для планирования проектов, например, основанное на результатах (основанное на продукте) или мероприятиях (основанное на процессе).
Независимо от используемой методологии необходимо тщательно продумать общие цели проекта, сроки и стоимость, а также роли и обязанности всех участников и заинтересованных сторон . [23]
Управление реализацией выгод (BRM) улучшает обычные методы управления проектами, фокусируясь на результатах (выгодах) проекта, а не на продуктах или выходах, а затем измеряя степень, в которой это происходит, чтобы удерживать проект на пути. Это может помочь снизить риск того, что завершенный проект окажется неудачным, предоставляя согласованные требования (выходы), т. е. успех проекта, но не предоставляя выгоды (результаты) этих требований, т. е. успех продукта. Обратите внимание, что хорошее управление требованиями гарантирует, что эти выгоды будут зафиксированы как требования проекта, и их достижение будет отслеживаться на протяжении всего проекта.
Кроме того, практики BRM направлены на обеспечение стратегического соответствия между результатами проекта и бизнес-стратегиями. Эффективность этих практик подтверждается недавними исследованиями, свидетельствующими о влиянии практик BRM на успех проекта со стратегической точки зрения в разных странах и отраслях. Эти более широкие эффекты называются стратегическим воздействием. [24]
Примером поставки проекта в соответствии с требованиями может быть соглашение о поставке компьютерной системы, которая будет обрабатывать данные о персонале и управлять записями о заработной плате, отпуске и персонале в более короткие сроки и с меньшим количеством ошибок. В рамках BRM соглашение может заключаться в достижении определенного сокращения рабочего времени и ошибок, необходимых для обработки и поддержания данных о персонале после установки системы по сравнению с отсутствием системы.
Метод критического пути (CPM) — это алгоритм для определения графика проектных мероприятий. Это традиционный процесс, используемый для прогнозного планирования проектов. Метод CPM оценивает последовательность мероприятий, требуемые трудозатраты, взаимозависимости и результирующее резервное время на последовательность строк для определения требуемой продолжительности проекта. Таким образом, по определению, критический путь — это путь задач на сетевой диаграмме, на котором нет дополнительного времени (или очень мало дополнительного времени)». [25]
Управление проектами по методу критической цепи (CCPM) представляет собой применение теории ограничений (TOC) к планированию и управлению проектами и призвано устранять неопределенности, присущие управлению проектами, принимая во внимание ограниченную доступность ресурсов (физических, человеческих навыков, а также управленческого и вспомогательного потенциала), необходимых для выполнения проектов.
Цель состоит в том, чтобы увеличить поток проектов в организации ( пропускную способность ). Применяя первые три из пяти фокусирующих шагов TOC, определяются системные ограничения для всех проектов, а также ресурсы. Чтобы использовать ограничения, задачам в критической цепочке отдается приоритет над всеми другими видами деятельности.
Управление заработанной стоимостью (EVM) расширяет управление проектами с помощью методов улучшения мониторинга проекта. [26] Оно иллюстрирует прогресс проекта по направлению к завершению с точки зрения работы и стоимости (стоимости). Earned Schedule является расширением теории и практики EVM.
В критических исследованиях управления проектами было отмечено, что поэтапные подходы не очень подходят для крупномасштабных и многофирменных проектов [27] с неопределенными, неоднозначными или быстро меняющимися требованиями [28] или для проектов с высокой степенью риска, зависимости и быстро меняющимися технологиями. Конус неопределенности объясняет часть этого, поскольку планирование, сделанное на начальной фазе проекта, страдает от высокой степени неопределенности. Это становится особенно актуально, поскольку разработка программного обеспечения часто является реализацией нового или новаторского продукта.
С этими сложностями лучше справляться с помощью более исследовательского или итеративного и инкрементального подхода. [29] Развилось несколько моделей итеративного и инкрементального управления проектами, включая гибкое управление проектами , метод разработки динамических систем , экстремальное управление проектами и Innovation Engineering®. [30]
Бережливое управление проектами использует принципы бережливого производства , чтобы сосредоточиться на создании ценности с меньшими потерями и сокращением времени.
Жизненный цикл проекта состоит из пяти фаз, известных как группы процессов. Каждая группа процессов представляет собой ряд взаимосвязанных процессов для управления работой посредством ряда отдельных шагов, которые необходимо выполнить. Этот тип подхода к проекту часто называют «традиционным» [31] или « водопадом ». [32] Пять групп процессов:
.png/1280px-Project_Management_(phases).png)
Некоторые отрасли могут использовать вариации этих этапов проекта и переименовывать их, чтобы лучше соответствовать организации. Например, при работе над проектированием и строительством из кирпича и бетона проекты обычно проходят такие этапы, как предварительное планирование, концептуальное проектирование, схематическое проектирование, разработка проекта, строительные чертежи (или контрактная документация) и управление строительством.
Хотя поэтапный подход хорошо работает для небольших, четко определенных проектов, он часто приводит к проблемам или неудачам в более крупных проектах или тех, которые более сложны или имеют больше неопределенностей, проблем и рисков [33] — см. пародию на «шесть фаз большого проекта».
Внедрение управления на основе процессов было обусловлено использованием моделей зрелости, таких как OPM3 и CMMI (интеграция модели зрелости возможностей; см. Изображение: Модель зрелости возможностей.jpg)
Управление производством проекта — это применение управления операциями к реализации капитальных проектов. Структура управления производством проекта основана на проекте как на видении производственной системы, в которой проект преобразует входы (сырьевые материалы, информацию, рабочую силу, завод и оборудование) в выходы (товары и услуги). [34]
Планирование на основе продукта — это структурированный подход к управлению проектами, основанный на определении всех продуктов ( результатов проекта ), которые способствуют достижению целей проекта. Таким образом, оно определяет успешный проект как ориентированный на результат, а не на деятельность или задачу. [35] Наиболее распространенная реализация этого подхода — PRINCE2 . [36]
Традиционно (в зависимости от используемой методологии управления проектами) управление проектами включает ряд элементов: четыре-пять групп процессов управления проектами и систему контроля. Независимо от используемой методологии или терминологии, будут использоваться одни и те же основные процессы управления проектами или этапы разработки. Основные группы процессов обычно включают: [38]
В проектных средах со значительным исследовательским элементом (например, исследования и разработки ) эти этапы могут быть дополнены точками принятия решений (решения «идти/не идти»), в которых обсуждается и решается вопрос о продолжении проекта. Примером может служить модель «фаза-ворота» .
Управление проектами опирается на широкий спектр совещаний для координации действий. Например, есть стартовое совещание, которое широко вовлекает заинтересованных лиц на начальном этапе проекта. Совещания по проекту или проектные комитеты позволяют команде проекта определять и контролировать планы действий. Руководящие комитеты используются для перехода между фазами и решения проблем. Обзоры портфеля проектов и программ проводятся в организациях, работающих над параллельными проектами. Совещания по извлеченным урокам проводятся для консолидации знаний. Все эти совещания используют методы, найденные в науке о встречах , в частности, для определения цели, списка участников и методов содействия.
Процессы инициирования определяют характер и масштаб проекта. [39] Если этот этап не выполнен должным образом, маловероятно, что проект будет успешно удовлетворять потребностям бизнеса. Ключевыми элементами управления проектом, необходимыми здесь, являются понимание бизнес-среды и обеспечение того, чтобы все необходимые элементы управления были включены в проект. Любые недостатки должны быть сообщены, и должны быть даны рекомендации по их устранению.
Начальная стадия должна включать план, охватывающий следующие области. Эти области могут быть записаны в серии документов, называемых документами по инициированию проекта. Документы по инициированию проекта представляют собой серию запланированных документов, используемых для создания заказа на весь срок проекта. Они, как правило, включают:
После этапа инициации проект планируется на соответствующем уровне детализации (см. пример блок-схемы ). [37] Основная цель — адекватно спланировать время, стоимость и ресурсы для оценки необходимой работы и эффективного управления рисками во время выполнения проекта. Как и в случае с группой процессов инициации, неспособность адекватно спланировать значительно снижает шансы проекта на успешное достижение его целей.
Планирование проекта обычно состоит из [40]
Также обычно рекомендуются дополнительные процессы, такие как планирование коммуникаций и управления объемом работ, определение ролей и обязанностей, определение того, что необходимо закупить для проекта, и проведение стартового совещания.
Для проектов по разработке новых продуктов концептуальное проектирование эксплуатации конечного продукта может выполняться одновременно с мероприятиями по планированию проекта и может помочь группе планирования информировать ее при определении результатов и планировании мероприятий.
При выполнении мы должны знать, какие запланированные условия должны быть выполнены . Фаза выполнения/реализации гарантирует, что результаты плана управления проектом будут выполнены соответствующим образом. Эта фаза включает в себя правильное распределение, координацию и управление человеческими ресурсами и любыми другими ресурсами, такими как материалы и бюджеты. Результатом этой фазы являются результаты проекта.
Документирование всего в проекте является ключом к успеху. Для поддержания бюджета, объема, эффективности и темпа проект должен иметь физические документы, относящиеся к каждой конкретной задаче. При правильной документации легко увидеть, были ли выполнены требования проекта. В дополнение к этому, документация предоставляет информацию о том, что уже было выполнено для этого проекта. Документация на протяжении всего проекта обеспечивает бумажный след для тех, кому нужно вернуться и сослаться на прошлую работу. В большинстве случаев документация является наиболее успешным способом мониторинга и контроля определенных фаз проекта. При правильной документации успех проекта можно отслеживать и наблюдать по мере его выполнения. При правильном выполнении документация может стать основой успеха проекта
Мониторинг и контроль состоят из тех процессов, которые выполняются для наблюдения за выполнением проекта, чтобы потенциальные проблемы могли быть своевременно выявлены и корректирующие действия могли быть предприняты, когда это необходимо, для контроля выполнения проекта. Ключевое преимущество заключается в том, что производительность проекта наблюдается и измеряется регулярно для выявления отклонений от плана управления проектом.
Мониторинг и контроль включают в себя: [41]
Два основных механизма поддерживают мониторинг и контроль в проектах. С одной стороны, контракты предлагают набор правил и стимулов, часто подкрепленных потенциальными штрафами и санкциями. [42] С другой стороны, ученые в области бизнеса и управления обратили внимание на роль интеграторов (также называемых проектными баронами) в достижении целей проекта. [43] [44] В свою очередь, недавние исследования в области управления проектами поставили под сомнение тип взаимодействия между контрактами и интеграторами. Некоторые утверждают, что эти два механизма мониторинга работают как заменители [45], поскольку один тип организации уменьшит преимущества использования другого.
В многофазных проектах процесс мониторинга и контроля также обеспечивает обратную связь между фазами проекта для реализации корректирующих или предупреждающих действий с целью приведения проекта в соответствие с планом управления проектом.
Техническое обслуживание проекта — это непрерывный процесс, который включает в себя: [38]
.png/1280px-Project_Management_(project_control).png)
На этом этапе аудиторы должны обратить внимание на то, насколько эффективно и быстро решаются проблемы пользователей.
В ходе любого строительного проекта объем работ может измениться. Изменение является нормальной и ожидаемой частью процесса строительства. Изменения могут быть результатом необходимых изменений проекта, различных условий на площадке, доступности материалов, запрошенных подрядчиком изменений, стоимостной инженерии и воздействия третьих лиц, и это лишь некоторые из них. Помимо выполнения изменения на месте, изменение обычно должно быть задокументировано, чтобы показать, что было фактически построено. Это называется управлением изменениями. Следовательно, владелец обычно требует окончательную запись, чтобы показать все изменения или, более конкретно, любые изменения, которые изменяют ощутимые части завершенной работы. Запись делается в контрактных документах — обычно, но не обязательно ограничиваясь, проектными чертежами. Конечным продуктом этих усилий является то, что отрасль называет чертежами as-built или, проще говоря, «as built». Требование их предоставления является нормой в строительных контрактах. Управление строительной документацией — это очень важная задача, выполняемая с помощью онлайн- или настольной программной системы или поддерживаемая посредством физической документации. Повышение законности ведения правильной документации в строительной отрасли привело к увеличению потребности в системах управления документами.
Когда в проект вносятся изменения, жизнеспособность проекта должна быть переоценена. Важно не упускать из виду первоначальные цели и задачи проектов. Когда изменения накапливаются, прогнозируемый результат может не оправдать изначально предложенные инвестиции в проект. Успешное управление проектами определяет эти компоненты, отслеживает и контролирует прогресс, чтобы оставаться в рамках времени и бюджета, уже обозначенных в начале проекта. Были предложены точные методы для определения наиболее информативных точек мониторинга на протяжении жизненного цикла проекта относительно его прогресса и ожидаемой продолжительности. [46]
Закрытие включает в себя официальное принятие проекта и его завершение. Административная деятельность включает в себя архивацию файлов и документирование извлеченных уроков.
Эта фаза состоит из: [38]
В эту фазу также включен обзор после внедрения. Это жизненно важный этап проекта для команды проекта, чтобы извлечь уроки из опыта и применить его в будущих проектах. Обычно обзор после внедрения состоит из рассмотрения того, что прошло хорошо, и анализа того, что прошло плохо в проекте, чтобы извлечь уроки.
Контроль проекта (также известный как Cost Engineering ) должен быть установлен как независимая функция в управлении проектами. Он реализует функции проверки и контроля во время обработки проекта для укрепления определенной производительности и формальных целей. [47] Задачи контроля проекта также:
Выполнение и реализация этих задач может быть достигнута путем применения определенных методов и инструментов управления проектами. Могут быть использованы следующие методы управления проектами:
Контроль проекта — это элемент проекта, который позволяет ему идти по плану, в срок и в рамках бюджета. [41] Контроль проекта начинается на ранних этапах проекта с планирования и заканчивается на поздних этапах проекта с проверки после внедрения, тщательно вовлекая каждый шаг в процесс. Проекты могут проверяться или проверяться в ходе выполнения проекта. Официальные аудиты обычно основаны на рисках или соответствии, и руководство будет определять цели аудита. Проверка может включать сравнение утвержденных процессов управления проектами с тем, как проект фактически управляется. [51] Каждый проект следует оценивать на предмет соответствующего необходимого уровня контроля: слишком большой контроль требует слишком много времени, слишком малый контроль очень рискован. Если контроль проекта реализован неправильно, следует прояснить стоимость для бизнеса с точки зрения ошибок и исправлений.
Системы контроля необходимы для затрат, риска , качества, коммуникации, времени, изменений, закупок и человеческих ресурсов. Кроме того, аудиторы должны учитывать, насколько важны проекты для финансовой отчетности , насколько заинтересованные стороны зависят от контроля и сколько существует контроля. Аудиторы должны проверять процесс разработки и процедуры для того, как они реализуются. Процесс разработки и качество конечного продукта также могут оцениваться при необходимости или по запросу. Бизнес может захотеть, чтобы аудиторская фирма была вовлечена на протяжении всего процесса, чтобы выявлять проблемы на более ранних стадиях, чтобы их можно было легче устранить. Аудитор может выступать в качестве консультанта по контролю в составе группы разработчиков или в качестве независимого аудитора в рамках аудита.
Иногда предприятия используют формальные процессы разработки систем. Это помогает гарантировать, что системы разрабатываются успешно. Формальный процесс более эффективен для создания сильного контроля, и аудиторы должны проверять этот процесс, чтобы подтвердить, что он хорошо разработан и соблюдается на практике. Хороший формальный план разработки систем описывает:
Существует пять важных характеристик проекта:
(i) Он всегда должен иметь конкретные даты начала и окончания.
(ii) Они выполняются и завершаются группой людей.
(iii) Результатом является поставка уникального продукта или услуги.
(iv) Они носят временный характер.
(v) Он постепенно совершенствуется.
Примеры: проектирование нового автомобиля или написание книги.
Сложность и ее природа играют важную роль в области управления проектами. Несмотря на ряд дискуссий по этому вопросу, исследования показывают отсутствие определения и разумного понимания сложности в отношении управления сложными проектами. [52] [53]
Сложность проекта — это свойство проекта, которое затрудняет понимание, предвидение и контроль его общего поведения, даже при наличии достаточно полной информации о системе проекта. [54]
Определение сложных проектов особенно важно для многопроектных инженерных сред. [55]
Поскольку считается, что сложность проекта и его эффективность тесно связаны, важно определить и измерить сложность проекта, чтобы управление проектами было эффективным. [56]
Сложность может быть:
На основе фреймворка Cynefin [58] сложные проекты можно классифицировать следующим образом:
Применяя открытие в измерении сложности работы, описанное в «Теории необходимой организации и стратифицированных систем», Эллиотт Жак классифицирует проекты и проектную работу (этапы, задачи) по семи основным уровням сложности проекта на основе таких критериев, как временной интервал дискреции и сложность результата проекта: [62] [63]
Преимущества измерения сложности проекта заключаются в улучшении осуществимости проекта людьми путем сопоставления уровня сложности проекта с эффективным целевым временем завершения, с соответствующим уровнем возможностей менеджера проекта и участников проекта. [65]
Аналогично с Законом необходимого разнообразия и Законом необходимой сложности , сложность проекта иногда требуется для того, чтобы проект достиг своих целей, а иногда она имеет полезные результаты. Основываясь на эффектах сложности, Стефан Морков предложил ее классификацию как Положительную, Уместную или Отрицательную. [66] [61]
Менеджер проекта — это профессионал в области управления проектами. Менеджеры проектов отвечают за людей в проекте. Люди — это ключ к любому успешному проекту. Без нужных людей в нужном месте и в нужное время проект не может быть успешным. Менеджеры проектов могут нести ответственность за планирование, выполнение, контроль и закрытие любого проекта, обычно связанного со строительной отраслью , инжинирингом, архитектурой, вычислениями и телекоммуникациями. Во многих других областях производственной инженерии, проектирования и тяжелой промышленности есть менеджеры проектов.
Менеджер проекта должен понимать порядок выполнения проекта, чтобы правильно составить график проекта, а также время, необходимое для выполнения каждой отдельной задачи в рамках проекта. Менеджер проекта — это лицо, ответственное за выполнение заявленных целей проекта от имени клиента. Менеджеры проектов, как правило, имеют многолетний опыт работы в своей области. Менеджер проекта должен знать проект от и до, контролируя рабочих вместе с проектом. Обычно в большинстве строительных, инженерных, архитектурных и промышленных проектов менеджер проекта имеет другого менеджера, работающего вместе с ним, который обычно отвечает за выполнение задачи на ежедневной основе. Эта должность в некоторых случаях известна как суперинтендант. Суперинтендант и менеджер проекта работают рука об руку, выполняя ежедневные задачи проекта. Ключевые обязанности по управлению проектами включают в себя создание четких и достижимых целей проекта, разработку требований проекта и управление тройным ограничением (теперь включающим больше ограничений и называющим их конкурирующими ограничениями) для проектов, которые являются стоимостью, временем, качеством и объемом для первых трех, но около трех дополнительных в текущем управлении проектами. Типичный проект состоит из команды работников, которые работают под руководством менеджера проекта, чтобы выполнить задание в установленные сроки и бюджет. Менеджер проекта обычно отчитывается непосредственно перед кем-то более высокого ранга о завершении и успехе проекта.
Менеджер проекта часто является представителем клиента и должен определить и реализовать точные потребности клиента, основываясь на знании фирмы, которую он представляет. Способность адаптироваться к различным внутренним процедурам контрагента и устанавливать тесные связи с назначенными представителями имеет важное значение для обеспечения того, чтобы ключевые вопросы стоимости, времени, качества и, прежде всего, удовлетворенности клиента могли быть реализованы.
Полный менеджер проекта, термин, впервые введенный Робертом Дж. Грэмом в его моделировании, был расширен Рэндаллом Л. Энглундом и Альфонсо Бусеро. Они описывают полного менеджера проекта как человека, который охватывает несколько дисциплин, таких как лидерство , влияние, переговоры, политика, управление изменениями и конфликтами, а также юмор. Все это «мягкие» навыки людей, которые позволяют руководителям проектов быть более эффективными и достигать оптимизированных, последовательных результатов.
Существует тенденция путать успех проекта с успехом управления проектом. Это две разные вещи. «Успех проекта» имеет 2 перспективы:
Критерии успешности управления проектами отличаются от критериев успешности проекта. Управление проектами считается успешным, если данный проект завершен в согласованные сроки, соответствует согласованному объему и в рамках согласованного бюджета. После тройных ограничений были рассмотрены множественные ограничения для обеспечения успешности проекта. Однако тройные или множественные ограничения указывают только на показатели эффективности проекта, которые на самом деле являются критериями успешности управления проектами в течение жизненного цикла проекта.
Априорные критерии не учитывают более важные результаты после завершения проекта, которые включают четыре уровня, а именно: выходной (продуктовый) успех, конечный (выгодный) успех и влияние (стратегический) успех в течение жизненного цикла продукта. Эти апостериорные критерии успеха указывают на меры эффективности продукта, услуги или результата проекта после завершения проекта и передачи. Эта всеобъемлющая многоуровневая структура успеха проектов, программ и портфелей была разработана Полом Баннерманом в 2008 году. [70] Другими словами, проект считается успешным, когда он успешно достигает ожидаемого бизнес-кейса, который должен быть четко идентифицирован и определен во время начала и выбора проекта до начала фазы разработки. Эта многоуровневая структура успеха соответствует теории проекта как трансформации, изображенной как вход-процесс/деятельность-выход-результат-влияние для того, чтобы создать любую предполагаемую ценность. Эмануэль Камиллери в 2011 году классифицирует все критические факторы успеха и неудач по группам и сопоставляет каждый из них с многоуровневыми критериями успеха для того, чтобы обеспечить ценность для бизнеса. [71]
Примером показателя эффективности, используемого в отношении управления проектами, является «отставание по заказам проектов» или «отставание по проектам». [72]
Министерство обороны США утверждает, что «Стоимость, График, Производительность и Риск» — это четыре элемента, с помощью которых специалисты по закупкам Министерства обороны делают компромиссы и отслеживают статус программы. [73] Существуют также международные стандарты. Управление рисками подразумевает проактивное выявление (см. Инструменты ) будущих проблем и понимание их последствий, что позволяет принимать прогнозные решения по проектам. Система ERM играет роль в общем управлении рисками. [74]
Структура декомпозиции работ (WBS) представляет собой древовидную структуру , которая показывает подразделение действий, необходимых для достижения цели, например портфолио, программу, проект и контракт. WBS может быть ориентирована на оборудование, продукт, услугу или процесс (см. пример в структуре отчетности NASA (2001) ). [75] Помимо WBS для управления объемом проекта существуют организационная структура декомпозиции (схема) , структура декомпозиции затрат и структура декомпозиции рисков .
Схему работ по выполнению работ можно разработать, начав с конечной цели и последовательно разделив ее на управляемые компоненты с точки зрения размера, продолжительности и ответственности (например, системы, подсистемы, компоненты, задачи, подзадачи и пакеты работ), которые включают все шаги, необходимые для достижения цели. [33]
Структура декомпозиции работ обеспечивает общую основу для естественного развития общего планирования и контроля контракта и является основой для разделения работы на определяемые приращения, на основе которых может быть разработано техническое задание, а также может быть установлена техническая, календарная, стоимостная и трудозатратная отчетность. [75] Структура декомпозиции работ может быть отображена в двух формах: в виде таблицы с подразделением задач или в виде организационной схемы, нижние узлы которой называются «пакетами работ».
Это существенный элемент оценки качества плана и начальный элемент, используемый при планировании проекта. Например, WBS используется при планировании проекта, чтобы можно было записывать и отслеживать использование рабочих пакетов.
Аналогично структуре декомпозиции работ (WBS) существуют и другие методы и инструменты декомпозиции: структура декомпозиции организации (OBS), структура декомпозиции продукта (PBS), структура декомпозиции затрат (CBS), структура декомпозиции рисков (RBS) и структура декомпозиции ресурсов (ResBS). [76] [61]
Существует несколько стандартов управления проектами, в том числе:
Некоторые проекты, как идентичные, так и разные, могут управляться как управление программами. Программы представляют собой наборы проектов, поддерживающих общую цель и набор задач. В то время как отдельные проекты имеют четко определенные и конкретные масштаб и сроки, цели и продолжительность программы определяются с более низким уровнем детализации.
Помимо программ и портфелей, существуют дополнительные структуры, объединяющие их различные характеристики: проектные сети, мегапроекты или мегапрограммы.
Проектная сеть — это временный проект, сформированный из нескольких различных отдельных развивающихся фаз, пересекающих организационные линии. Мегапроекты и мегапрограммы определяются как исключительные с точки зрения размера, стоимости, общественного и политического внимания и требуемых компетенций. [61]
Все большее число организаций используют так называемое управление портфелем проектов (PPM) как средство выбора правильных проектов, а затем используют методы управления проектами [81] как средство предоставления результатов в виде выгод для исполняющей государственной, частной или некоммерческой организации.
Портфели представляют собой наборы схожих проектов. Управление портфелями поддерживает эффективность масштаба, повышает показатели успешности и снижает риски проектов, применяя схожие стандартизированные методы ко всем проектам в портфеле группой специалистов по управлению проектами, которые используют общие инструменты и знания. Организации часто создают офисы управления проектами как организационную структуру для поддержки управления портфелем проектов структурированным образом. [61] Таким образом, PPM обычно выполняется специальной группой менеджеров, организованной в офисе управления проектами предприятия (PMO), обычно базирующемся в организации и возглавляемом директором PMO или главным директором проекта. В случаях, когда стратегические инициативы организации составляют основную часть PPM, руководитель PPM иногда называется главным директором по инициативам.
Программное обеспечение для управления проектами — это программное обеспечение, используемое для планирования, организации и управления пулами ресурсов, разработки оценок ресурсов и реализации планов. В зависимости от сложности программного обеспечения функциональность может включать в себя оценку и планирование, составление расписания , контроль затрат и управление бюджетом , распределение ресурсов , программное обеспечение для совместной работы , коммуникацию , принятие решений , рабочий процесс , риск , качество, документацию и/или административные системы. [82] [83]
Управление виртуальными программами (VPM) — это управление проектом, выполняемое виртуальной командой , хотя оно редко может относиться к проекту, реализующему виртуальную среду [84]. Отмечается, что управление виртуальным проектом принципиально отличается от управления традиционными проектами [85], объединяя в себе проблемы удаленной работы и глобального сотрудничества (культура, часовые пояса, язык). [86]
В 1950-х годах управление проектами было официально признано отдельным направлением управленческой дисциплины.
/File:Capability_Maturity_Model.jpg){kind=link}
/File:NASA_NF_533_reporting_structure.jpg){kind=link}
{{cite journal}}: CS1 maint: date and year (link){{cite web}}: CS1 maint: unfit URL (link){{cite web}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link){{cite journal}}: CS1 maint: multiple names: authors list (link){{cite journal}}: CS1 maint: multiple names: authors list (link){{cite book}}: CS1 maint: others (link)
Медиа, связанные с управлением проектами на Wikimedia Commons