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

Project management

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

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

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

История

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

Генри Гантт (1861–1919), отец методов планирования и контроля

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

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

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

Сетевая диаграмма PERT для семимесячного проекта с пятью вехами

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

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

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

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

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

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

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

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

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

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

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

Управление реализацией выгод

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

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

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

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

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

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

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

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

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

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

С этими сложностями лучше справиться с помощью более исследовательского или итеративного и поэтапного подхода.[26] Были разработаны несколько моделей итеративного и инкрементного управления проектами, в том числе: гибкое управление проектами, метод разработки динамических систем, экстремальное управление проектами, и Innovation Engineering®.[27]

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

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

Поэтапный подход

Поэтапный (или поэтапный) подход разбивает и управляет работой через серию отдельных этапов, которые необходимо выполнить, и часто упоминается как «традиционный».[28] или же "водопад".[29] Хотя он может быть разным, обычно он состоит из пяти областей процесса, четырех этапов плюс контроль:

Типовые этапы разработки инженерного проекта
  1. инициация.
  2. планирование и дизайн.
  3. строительство.
  4. мониторинг и контроль.
  5. завершение или закрытие.

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

Хотя поэтапный подход хорошо работает для небольших, четко определенных проектов, он часто приводит к проблемам или неудачам в более крупных проектах, а также в тех, которые являются более сложными или имеют больше двусмысленностей, проблем и рисков.[30]

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

Внедрение процессно-ориентированного управления было обусловлено использованием моделей зрелости, таких как OPM3 и CMMI (интеграция модели зрелости возможностей; см. этот пример предшественника) и ISO / IEC 15504 (SPICE - совершенствование программного процесса и оценка возможностей). В отличие от CMM SEI, модель зрелости OPM3 описывает, как сделать процессы управления проектами способными к успешному, последовательному и предсказуемому выполнению, чтобы реализовать стратегии организации.

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

Управление производством проекта - это приложение управления производством к реализации капитальных проектов. Структура управления производством проекта основана на проекте как представлении производственной системы, в котором проект преобразует вводимые ресурсы (сырье, информация, рабочая сила, оборудование и оборудование) в результаты (товары и услуги).[31]

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

Планирование на основе продуктов - это структурированный подход к управлению проектами, основанный на идентификации всех продуктов (проект Практические результаты), которые способствуют достижению целей проекта. Таким образом, он определяет успешный проект как ориентированный на результат, а не на деятельность или задачу.[32] Наиболее распространенная реализация этого подхода: PRINCE2.[33]

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

Этапы разработки проекта[34]

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

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

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

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

Инициирование процессов группы процессов[34]

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

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

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

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

Планирование проекта обычно состоит из[36]

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

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

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

Выполнение

Выполнение процессов группы процессов[34]

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

Документация по проекту

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

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

Мониторинг и контроль процессов группы процессов[34]

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

Мониторинг и контроль включают:[37]

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

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

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

Сопровождение проекта - это непрерывный процесс, который включает:[2]

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

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

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

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

Закрытие

Закрытие процессов группы процессов.[34]

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

Этот этап состоит из:[2]

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

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

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

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

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

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

  • инвестиционный анализ
  • анализ выгоды и затрат
  • анализ ценности выгод
  • экспертные опросы
  • симуляционные расчеты
  • анализ профиля риска
  • расчеты надбавки
  • веха анализ тренда
  • анализ тенденций затрат
  • целевое / фактическое сравнение[47]

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

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

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

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

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

Есть пять важных характеристик проекта. (i) У него всегда должны быть определенные даты начала и окончания. (ii) Они выполняются и завершаются группой людей. (iii) Результатом является доставка уникального продукта или услуги. (iv) Они носят временный характер. (v) Он постепенно дорабатывается. Пример: проектирование новой машины, написание книги.

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

Сложность и ее характер играют важную роль в области управления проектами. Несмотря на то, что по этому поводу ведется ряд дебатов, исследования показывают отсутствие определения и разумного понимания сложности в отношении управления сложными проектами.[49] Поскольку считается, что сложность проекта и его производительность тесно связаны, важно определить и измерить сложность проекта, чтобы управление проектом было эффективным.[50]

Применяя открытие для измерения сложности работы, описанное в Необходимая организация и теория стратифицированных систем, Д-р Эллиот Жак классифицирует проекты и проектные работы (этапы, задачи) на основные 7 уровней сложности проекта на основе таких критериев, как временной интервал усмотрения и сложность результатов проекта:[51][52]

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

Выгоды от измерения сложности проекта заключаются в улучшении осуществимости проекта для людей за счет:[54]

  • Сопоставьте уровень сложности проекта с эффективным целевым сроком завершения проекта
  • Сопоставьте уровень сложности проекта с соответствующим уровнем возможностей руководителя проекта
  • Сопоставьте уровень сложности задачи проекта с соответствующими возможностями участников проекта

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

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

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

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

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

Многоуровневые рамки и критерии успеха

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

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

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

Министерство обороны США заявляет; «Стоимость, график, эффективность и риск» - это четыре элемента, с помощью которых специалисты Министерства обороны по закупкам находят компромисс и отслеживают статус программы.[57] Это также международные стандарты. Управление рисками применяет проактивную идентификацию (см. инструменты) будущих проблем и понимание их последствий, позволяющих предсказательный решения по проектам.

Иерархическая структура работ

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

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

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

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

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

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

  • Стандарты ISO ISO 9000, семейство стандартов для систем менеджмента качества и ISO 10006: 2003, «Системы менеджмента качества и руководящие принципы управления качеством в проектах».
  • ISO 21500:2012 – Руководство по управлению проектами. Это первый международный стандарт, касающийся управления проектами, опубликованный ISO. Другие стандарты семейства 21500 включают 21503: 2017 Руководство по управлению программой; 21504:2015 Руководство по управлению портфелем; 21505:2017 Руководство по управлению; 21506:2018 Словарный запас; 21508:2018 Управление освоенной стоимостью в управлении проектами и программами; и 21511: 2018 Структуры декомпозиции работ для управления проектами и программами.
  • ISO 31000: 2009 - Управление рисками.
  • ISO / IEC / IEEE 16326: 2009 - Системная и программная инженерия - Процессы жизненного цикла - Управление проектами[59]

Программный менеджмент

Некоторыми проектами, идентичными или разными, можно управлять как программным менеджером, так что менеджер программы отвечает за менеджеров проектов. Следовательно, руководитель программы также известен как руководитель проекта.

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

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

ПО для управления проектами

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

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

Управление виртуальными программами (VPM) - это управление проектом, выполняемое Виртуальный команда, хотя он редко может относиться к проекту, реализующему виртуальную среду[65] Отмечается, что управление виртуальным проектом принципиально отличается от управления традиционными проектами,[66] сочетание задач удаленной работы и глобального сотрудничества (культура, часовые пояса, язык).[67]

Смотрите также

Рекомендации

  1. ^ (2003). Руководство для профессионального обучения PMP Project Management. McGraw-Hill Professional, 2003. ISBN 0-07-223062-2 стр.354.
  2. ^ а б c d PMI (2010). Руководство к своду знаний по управлению проектами стр.27-35
  3. ^ Полное руководство по управлению проектами. Нокс, Себастьян. 2-е изд. Лондон (Financial Times / Prentice Hall): 2007. ISBN 978-0-273-71097-4
  4. ^ «Что такое управление проектами?». Институт управления проектами. Получено 2014-06-04.
  5. ^ Пол С. Динсмор и др. (2005) Правильные проекты сделаны правильно! Джон Вили и сыновья, 2005. ISBN 0-7879-7113-8. стр.35 и далее.
  6. ^ Cattani, G .; Ferriani, S .; Frederiksen, L .; Флориан, Т. (2011). Проектная организация и стратегическое управление. Успехи в стратегическом менеджменте. 28. Изумруд. ISBN 978-1780521930.
  7. ^ Деннис Лок (2007) Управление проектом (9-е изд.) Gower Publishing, Ltd., 2007. ISBN 0-566-08772-3
  8. ^ Ён-Хун Квак (2005). «Краткая история управления проектами». В: История управления проектами. Элиас Г. Караяннис и другие. (9 ред.), Greenwood Publishing Group, 2005. ISBN 1-56720-506-2
  9. ^ Дэвид И. Клиланд, Роланд Гарейс (2006). Справочник по глобальному управлению проектами. Глава 1: «Эволюция управления проектами». McGraw-Hill Professional, 2006. ISBN 0-07-146045-4
  10. ^ Мартин Стивенс (2002). Пути управления проектами. Ассоциация управления проектами. APM Publishing Limited, 2002 г.ISBN 1-903494-01-X p.xxii
  11. ^ Эдвард Р. Марш (1975). «Гармонограмма Кароля Адамецкого». В: Журнал Академии Управления. Vol. 18, No. 2 (июнь 1975 г.), стр. 358. (онлайн)
  12. ^ Морген Витцель (2003). Пятьдесят ключевых фигур в управлении. Рутледж, 2003. ISBN 0-415-36977-0. п. 96-101.
  13. ^ Дэвид И. Клиланд, Роланд Гарейс (2006). Справочник по глобальному управлению проектами. McGraw-Hill Professional, 2006. ISBN 0-07-146045-4. п.1-4 говорится: "Это было в 1950-х годах, когда управление проектами было официально признано отдельным вкладом, вытекающим из управленческой дисциплины."
  14. ^ Малькольм, Д., Roseboom, J.H., Clark, C.E., & Фазар, В. (1959). "Применение методики оценки программ исследований и разработок." Исследование операций, 7(5), 646-669.
  15. ^ Ф. Л. Харрисон, Деннис Лок (2004). Расширенное управление проектами: структурированный подход. Gower Publishing, Ltd., 2004. ISBN 0-566-07822-8. стр.34.
  16. ^ Саладис, Ф. П. (2006). Оживление руководства PMBOK®. Доклад представлен на Глобальном конгрессе PMI® 2006 - Северная Америка, Сиэтл, Вашингтон. Newtown Square, Пенсильвания: Институт управления проектами. Доступны на https://www.pmi.org/learning/library/bringing-pmbok-guide-life-practical-8009
  17. ^ «Сертифицированный менеджер по строительству». CMAA. Получено 23 ноября 2013.
  18. ^ «Сертификат в области управления биотехнологическими проектами». Вашингтонский университет. Получено 23 ноября 2013.
  19. ^ Эсселинк, Берт (2000). Практическое руководство по локализации. Амстердам / Филадельфия: Издательская компания Джона Бенджамина. п. 428. ISBN 978-9-027-21956-5.
  20. ^ Месли, Оливье. (2017). Осуществимость проекта - инструменты для обнаружения уязвимых мест. Нью-Йорк, штат Нью-Йорк: Тейлор и Фрэнсис, CRC Press. 546 страниц. ISBN 9 781498 757911.
  21. ^ Ср. Бриджер (блог), «Управление проектами: PMP, Prince 2 или итеративный или гибкий вариант»
  22. ^ Серра, К. Э. М .; Кунч, М. (2014). «Управление реализацией выгод и его влияние на успех проекта и выполнение бизнес-стратегий». Международный журнал управления проектами. 33 (1): 53–66. Дои:10.1016 / j.ijproman.2014.03.011.
  23. ^ Хасс, Кэтлин Б. (Китти) (2 марта 2010 г.). «Управление сложными проектами, которые являются слишком большими, слишком длинными и слишком дорогостоящими». PM Times. Получено 2017-06-27.
  24. ^ Conforto, E.C .; Salum, F .; Amaral, D.C .; да Силва, С. Л .; Магнанини де Алмейда, Л. Ф. (июнь 2014 г.). «Может ли гибкое управление проектами применяться в других отраслях, помимо разработки программного обеспечения?». Журнал управления проектами. 45 (3): 21–34. Дои:10.1002 / pmj.21410. S2CID 110595660.
  25. ^ Патель, Химаншу (20 апреля 2018 г.). «Объяснение модели водопада в управлении проектами». ItsGuru. Получено 2017-04-20.
  26. ^ Сноуден, Дэвид Дж.; Бун, Мэри Э. (ноябрь 2007 г.). «Рамки лидера для принятия решений». Harvard Business Review. Получено 2017-06-27.
  27. ^ «Стэнфордское исследование показало, что инновационная инженерия - это настоящая система« прорывных инноваций »». IE Новости. 20 июня 2017 г.. Получено 2017-08-11.
  28. ^ Высоцкий, Роберт К (2013). Эффективное управление проектами: традиционное, адаптивное, экстремальное (Седьмое изд.). Джон Уайли и сыновья. ISBN 978-1118729168.
  29. ^ Уинстон В. Ройс (1970). «Управление разработкой больших программных систем» В архиве 2016-03-15 в Wayback Machine в: Технические статьи Western Electronic Show and Convention (WesCon) 25–28 августа 1970 г., Лос-Анджелес, США.
  30. ^ а б Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения. O'Reilly Media. ISBN 978-0-596-00948-9. Архивировано из оригинал на 2015-02-09.
  31. ^ Маккафер, Рональд; Харрис, Фрэнк (2013). Современное управление строительством. Вили-Блэквелл. п. 5. ISBN 978-1118510186. OCLC 834624541.
  32. ^ Управление государственной торговли (1996) Управление успешными проектами с PRINCE2, стр. 14
  33. ^ OGC - PRINCE2 - Фон
  34. ^ а б c d е ж «Руководство по управлению проектами» (PDF). VA Управление информации и технологий. 2003. Архивировано 14 января 2009 года.CS1 maint: неподходящий URL (связь)
  35. ^ Питер Натан, Джеральд Эверетт Джонс (2003). Сертификация PMP для чайников. стр.63.
  36. ^ Гарольд Керцнер (2003). Управление проектами: системный подход к планированию, составлению графиков и контроллингу (8-е изд.). Вайли. ISBN 0-471-22577-0.
  37. ^ а б Джеймс П. Льюис (2000). Справочник руководителя проекта: подробное руководство по планированию, составлению графика, оценке и системам проекта. стр.185
  38. ^ Эклс, Роберт Г. (1981). «Квазифирма в строительной индустрии». Журнал экономического поведения и организации. 2 (4): 335–357. Дои:10.1016/0167-2681(81)90013-5. ISSN 0167-2681.
  39. ^ Дэвис, Эндрю; Hobday, Майкл (2005). Бизнес проектов: управление инновациями в сложных продуктах и ​​системах. Издательство Кембриджского университета. ISBN 978-0-521-84328-7.
  40. ^ Ганн, Дэвид; Солтер, Аммон; Доджсон, Марк; Филипс, Нельсон (2012). «Внутри мира проекта барон». Обзор управления MIT Sloan. 53 (3): 63–71. ISSN 1532-9194.
  41. ^ Мэн, Сяньхай (2012). «Влияние управления взаимоотношениями на выполнение проекта в строительстве». Международный журнал управления проектами. 30 (2): 188–198. Дои:10.1016 / j.ijproman.2011.04.002.
  42. ^ Оливейра, Нуно; Люмино, Фабрис (2017). «Как траектории координации влияют на производительность межорганизационных проектных сетей». Организационная наука. 28 (6): 1029–1060. Дои:10.1287 / orsc.2017.1151. ISSN 1047-7039.
  43. ^ Коэн Каши С., Розенес С. и Бен-Гал И. (2016). «Мониторинг управления проектом на основе энтропии ожидаемой продолжительности» (PDF). В Энтропии 2020, 22, 905.CS1 maint: несколько имен: список авторов (связь)
  44. ^ Йорг Беккер, Мартин Кугелер, Майкл Роземанн (2003). Управление процессами: руководство по проектированию бизнес-процессов. ISBN 978-3-540-43499-3. стр.27.
  45. ^ Бернхард Шлагек (2000). Objektorientierte Referenzmodelle für das Prozess- und Projektcontrolling. Grundlagen - Konstruktionen - Anwendungsmöglichkeiten. ISBN 978-3-8244-7162-1. с.131.
  46. ^ Йозеф Э. Ридл (1990). Projekt - Контроллинг в Forschung und Entwicklung. ISBN 978-3-540-51963-8. стр.99.
  47. ^ Штейнле, Брух, Лава (1995). Projektmanagement. FAZ Verlagsbereich Wirtschaftsbücher. с.136–143
  48. ^ Синтия Снайдер, Фрэнк Парт (2006). Введение в управление ИТ-проектами. стр.393-397
  49. ^ Abdou, Saed M; Юн, Куан; Осман, Мохаммед (2016). «Влияние сложности проекта на эффективность управления проектом - малазийская точка зрения». Сеть конференций MATEC. 66: 00065. Дои:10.1051 / matecconf / 20166600065. ISSN 2261-236X.
  50. ^ Людовик-Александр Видаль, Франк Марл, Видаль (2008). «Понимание сложности проекта: последствия для управления проектом» (PDF). Kybernetes. 37 (8): 1094–1110. Дои:10.1108/03684920810884928.
  51. ^ Г., Моррис, Питер В. (1994). Управление проектами. Лондон: Т. Телфорд. п. 317. ISBN 978-0727725936. OCLC 30437274.
  52. ^ Справочник Gower для специалистов по управлению проектами. Лок, Деннис., Скотт, Линдси, 1974-. Фарнем, Суррей: издательство Gower. 2013. с. 398. ISBN 978-1409437857. OCLC 855019788.CS1 maint: другие (связь)
  53. ^ «ОУП». www.theprojectmanager.co.za. Получено 2018-03-01.
  54. ^ Комиссия Австралийской государственной службы; Комиссия Австралийской государственной службы. «Основа APS для оптимальных структур управления». Получено 2018-03-01.
  55. ^ Баннерман, П. Л. (2008). Определение успеха проекта: многоуровневая структура. Доклад, представленный на исследовательской конференции PMI®: определение будущего управления проектами, Варшава, Польша. Newtown Square, Пенсильвания: Институт управления проектами. Доступны на https://www.pmi.org/learning/library/defining-project-success-multilevel-framework-7096
  56. ^ Эмануэль Камиллери, Успех проекта: критические факторы и поведение, Gower Publishing, Ltd., 2011 г.
  57. ^ "DoDD 5000.01" (PDF). Министерство обороны США. Получено 20 ноября 2007.
  58. ^ а б НАСА NPR 9501.2D. 23 мая 2001 г.
  59. ^ ISO / IEC / IEEE 16326-2009 - Системная и программная инженерия - Процессы жизненного цикла - Управление проектами. Декабрь 2009 г. DOI: 10.1109 / IEEESTD.2009.5372630. ISBN 978-0-7381-6116-7
  60. ^ Базовый уровень индивидуальной компетентности для управления проектами, программами и портфелем (PDF). Международная ассоциация управления проектами (IPMA). 2015 г. ISBN 978-94-92338-01-3.
  61. ^ Свод знаний, 5-е издание, Ассоциация управления проектами, 2006 г., ISBN 1-903494-13-3
  62. ^ Альберт Гамильтон (2004). Справочник по процедурам управления проектами. TTL Publishing, Ltd. ISBN 0-7277-3258-7
  63. ^ PMBOK 4h Ed. 2008. с. 443. ISBN 978-1933890517.
  64. ^ Том Кендрик. Набор инструментов для управления проектами: 100 советов и приемов для правильного выполнения работы, Третье издание. AMACOM Книги, 2013 ISBN 9780814433454
  65. ^ Кёрли, Ванда (2011). Виртуальный офис управления проектами: передовой опыт, проверенные методы.
  66. ^ Хазанчи, Дипак (2005). Паттерны эффективного управления проектами в виртуальных проектах: исследовательское исследование. Институт управления проектами. ISBN 9781930699830. Архивировано из оригинал в 2013-10-23. Получено 2013-10-22.
  67. ^ Велагапуди, Мридула (13 апреля 2012 г.). «Почему нельзя избежать управления виртуальными проектами, начиная с 2012 г.».

внешняя ссылка