Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

История [ править ]

До 1900 года проектами гражданского строительства, как правило, руководили творческие архитекторы, инженеры и сами мастера-строители , например, Витрувий (I век до н.э.), Кристофер Рен (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 и Booz Allen Hamilton в рамках программы создания подводных ракетных лодок Polaris [14].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление прибавочной стоимостью (EVM) расширяет управление проектами с помощью методов, улучшающих мониторинг проекта. Он иллюстрирует продвижение проекта к завершению с точки зрения трудозатрат и стоимости (стоимости). Earned Schedule - это расширение теории и практики 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]

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

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

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

Инициирование [ править ]

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

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

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

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

Планирование [ править ]

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

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

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

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

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

Выполнение [ править ]

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

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

Документация по проекту [ править ]

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

Мониторинг и контроль [ править ]

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

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

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

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

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

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

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

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

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

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

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

Закрытие [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Характеристики проектов [ править ]

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

Сложность проекта [ править ]

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

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

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

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

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

Руководители проектов [ править ]

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

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

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

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

Многоуровневая структура и критерии успеха [ править ]

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

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

Управление рисками [ править ]

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

Структура декомпозиции работ [ править ]

Структура работ (ИСР) представляет собой древовидную структуру , которая показывает подразделение деятельности , необходимой для достижения объективного - например , портфолио, программы, проекта, и контракта. WBS может быть ориентирована на оборудование, продукты, услуги или процессы (см. Пример в структуре отчетности NASA (2001) ). [59] Помимо WBS для управления содержанием проекта, существует организационная структура (диаграмма), структура распределения затрат и структура распределения рисков.

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

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

Это важный элемент при оценке качества плана и начальный элемент, используемый при планировании проекта. Например, 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 - Системная и программная инженерия - Процессы жизненного цикла - Управление проектами [60]
  • Базовый уровень индивидуальной компетентности (ICB) от Международной ассоциации управления проектами (IPMA). [61]
  • Модель зрелости возможностей (CMM) от Института программной инженерии .
  • GAPPS, Глобальный альянс по стандартам эффективности проектов - стандарт с открытым исходным кодом, описывающий КОМПЕТЕНЦИИ для руководителей проектов и программ.
  • Метод HERMES , швейцарский общий метод управления проектами, выбранный для использования в Люксембурге и международных организациях.
  • Логический рамочный подход (LFA), который пользуется популярностью в международных организациях по развитию.
  • Руководство PMBOK от Института управления проектами (PMI).
  • PRINCE2 от AXELOS .
  • Team Software Process (TSP) от Института программной инженерии .
  • Общие принципы управления затратами , Методология AACE International для интегрированного управления портфелем, программами и проектами.
  • V-Model , оригинальный метод разработки систем.

Управление программой [ править ]

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

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

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

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

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

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

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

См. Также [ править ]

Ссылки [ править ]

  1. ^ (2003). Профессиональное учебное пособие по управлению проектами PMP . McGraw-Hill Professional, 2003. ISBN  0-07-223062-2 p.354.
  2. ^ Баратта, Анджело (2006). «Тройное принуждение - тройная иллюзия» . PMI . Проверено 22 декабря 2020 .
  3. ^ Полное руководство по управлению проектами . Нокс, Себастьян. 2-е изд. Лондон (Financial Times / Prentice Hall): 2007. ISBN 978-0-273-71097-4 
  4. ^ "Что такое управление проектами?" . Институт управления проектами . Проверено 4 июня 2014 .
  5. ^ Пол С. Динсмор и др. (2005) Правильные проекты сделаны правильно! Джон Вили и сыновья, 2005. ISBN 0-7879-7113-8 . стр.35 и далее. 
  6. ^ Каттани, G .; Ferriani, S .; Frederiksen, L .; Флориан, Т. (2011). Проектная организация и стратегический менеджмент . Успехи в стратегическом менеджменте. 28 . Изумруд. ISBN 978-1780521930.
  7. ^ Деннис Лок (2007) Управление проектами (9-е изд.) Gower Publishing, Ltd., 2007. ISBN 0-566-08772-3 
  8. ^ Young-Hoon Квак (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 стр. Xxxii 
  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. ^ Malcolm, DG , Roseboom, JH, Clark, CE, & Fazar, W. (1959). « Применение методики для оценки программ исследований и разработок» . Исследование операций, 7 (5), 646-669.
  15. Перейти ↑ FL Harrison, Dennis Lock (2004). Расширенное управление проектами: структурированный подход . Gower Publishing, Ltd., 2004. ISBN 0-566-07822-8 . стр.34. 
  16. ^ Saladis, FP (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. ^ Esselink, Берт (2000). Практическое руководство по локализации . Амстердам / Филадельфия: Издательство Джона Бенджамина. п. 428. ISBN 978-9-027-21956-5.
  20. ^ Месли, Оливье. (2017). Осуществимость проекта - инструменты для выявления уязвимых мест. Нью-Йорк, Нью-Йорк: Тейлор и Фрэнсис, CRC Press. 546 страниц. ISBN 9 781498 757911 . 
  21. ^ Ср. The Bridger (блог), «Управление проектами: PMP, Prince 2 или итеративный или гибкий вариант»
  22. ^ Серра, CEM; Кунч, М. (2014). «Управление реализацией выгод и его влияние на успех проекта и выполнение бизнес-стратегий» . Международный журнал управления проектами . 33 (1): 53–66. DOI : 10.1016 / j.ijproman.2014.03.011 .
  23. Хасс, Кэтлин Б. (Китти) (2 марта 2010 г.). «Управление сложными проектами, которые являются слишком большими, слишком длинными и слишком дорогостоящими» . PM Times . Проверено 27 июня 2017 .
  24. ^ Конфорто, ЕС; Salum, F .; Амарал, округ Колумбия; да Силва, SL; Магнанини де Алмейда, Л. Ф. (июнь 2014 г.). «Может ли гибкое управление проектами применяться в других отраслях, помимо разработки программного обеспечения?». Журнал управления проектами . 45 (3): 21–34. DOI : 10.1002 / pmj.21410 . S2CID 110595660 . 
  25. Патель, Химаншу (20 апреля 2018 г.). «Объяснение модели водопада в управлении проектами» . ItsGuru . Проверено 20 апреля 2017 .
  26. ^ Сноуден, Дэвид Дж ; Бун, Мэри Э. (ноябрь 2007 г.). «Рамки лидера для принятия решений» . Harvard Business Review . Проверено 27 июня 2017 .
  27. ^ «Стэнфордское исследование обнаружило, что инновационная инженерия - это настоящая система« прорывных инноваций »» . IE Новости . 20 июня 2017 года . Проверено 11 августа 2017 .
  28. ^ Высоцкий, Роберт K (2013). Эффективное управление проектами: традиционный, адаптивный, экстремальный (седьмое изд.). Джон Вили и сыновья . ISBN 978-1118729168.
  29. ^ Уинстон В. Ройс (1970). «Управление разработкой больших программных систем». Архивировано 15 марта 2016 г. на Wayback Machine в: Технические документы Western Electronic Show and Convention (WesCon) 25–28 августа 1970 г., Лос-Анджелес, США.
  30. ^ a b Стеллман, Эндрю; Грин, Дженнифер (2005). Управление прикладными программными проектами . O'Reilly Media. ISBN 978-0-596-00948-9. Архивировано из оригинала на 2015-02-09.
  31. ^ Маккафер, Рональд; Харрис, Фрэнк (2013). Современное управление строительством . Вили-Блэквелл. п. 5. ISBN 978-1118510186. OCLC  834624541 .
  32. ^ Управление государственной торговли (1996) Управление успешными проектами с PRINCE2 , p14
  33. ^ OGC - PRINCE2 - Фон
  34. ^ a b c d e f "Руководство по управлению проектами" (PDF) . VA Управление информации и технологий . 2003. Архивировано 14 января 2009 года. CS1 maint: unfit URL (link)
  35. ^ а б в PMI (2010). Руководство к своду знаний по управлению проектами стр.27-35
  36. ^ Питер Натан, Джеральд Эверетт Джонс (2003). Сертификация PMP для чайников . стр.63.
  37. ^ Гарольд Керцнер (2003). Управление проектами: системный подход к планированию, составлению графиков и контроллингу (8-е изд.). Вайли. ISBN 0-471-22577-0.
  38. ^ a b Джеймс П. Льюис (2000). Справочник менеджера проекта: исчерпывающее руководство по планированию, составлению графика, оценке и системам проекта. стр.185
  39. ^ Эклс, Роберт Г. (1981). «Квазифирма в строительной индустрии» . Журнал экономического поведения и организации . 2 (4): 335–357. DOI : 10.1016 / 0167-2681 (81) 90013-5 . ISSN 0167-2681 . 
  40. ^ Дэвис, Эндрю; Hobday, Майкл (2005). Бизнес проектов: управление инновациями в сложных продуктах и ​​системах . Издательство Кембриджского университета. ISBN 978-0-521-84328-7.
  41. ^ Ганн, Дэвид; Солтер, Аммон; Доджсон, Марк; Филипс, Нельсон (2012). «Внутри мира проекта барон» . Обзор управления MIT Sloan . 53 (3): 63–71. ISSN 1532-9194 . 
  42. ^ Мэн, Xianhai (2012). «Влияние управления взаимоотношениями на выполнение проекта в строительстве» . Международный журнал управления проектами . 30 (2): 188–198. DOI : 10.1016 / j.ijproman.2011.04.002 .
  43. ^ Оливейра, Нуно; Люмино, Фабрис (2017). «Как траектории координации влияют на производительность межорганизационных проектных сетей» . Организационная наука . 28 (6): 1029–1060. DOI : 10.1287 / orsc.2017.1151 . ISSN 1047-7039 . 
  44. ^ Cohen Каши С., Rozenes С. и Бен-Гал, I. (2016). «Мониторинг управления проектом на основе энтропии ожидаемой продолжительности» (PDF) . В Энтропии 2020, 22, 905. CS1 maint: multiple names: authors list (link)
  45. ^ Йорг Беккер, Мартин Кугелер, Майкл Роземанн (2003). Управление процессами: руководство по проектированию бизнес-процессов. ISBN 978-3-540-43499-3 . стр.27. 
  46. ^ Бернхард Schlagheck (2000). Objektorientierte Referenzmodelle für das Prozess- und Projektcontrolling. Grundlagen - Konstruktionen - Anwendungsmöglichkeiten. ISBN 978-3-8244-7162-1 . стр.131. 
  47. ^ Йозеф Э. Ридл (1990). Projekt - Контроллинг в Forschung und Entwicklung. ISBN 978-3-540-51963-8 . стр.99. 
  48. ^ Steinle, Брух, Lawa (1995). Projektmanagement. FAZ Verlagsbereich Wirtschaftsbücher. с.136–143
  49. Синтия Снайдер, Фрэнк Парт (2006). Введение в управление ИТ-проектами. стр.393-397
  50. ^ Абду, Саед М; Юн, Куан; Осман, Мохаммед (2016). «Влияние сложности проекта на эффективность управления проектом - малазийская перспектива» . Сеть конференций MATEC . 66 : 00065. DOI : 10,1051 / matecconf / 20166600065 . ISSN 2261-236X . 
  51. Перейти ↑ Ludovic ‐ Alexandre Vidal, Franck Marle, Vidal (2008). «Понимание сложности проекта: влияние на управление проектом» (PDF) . Кибернетес . 37 (8): 1094–1110. DOI : 10.1108 / 03684920810884928 .
  52. ^ Г., Моррис, Питер У. (1994). Управление проектами . Лондон: Т. Телфорд. п. 317. ISBN 978-0727725936. OCLC  30437274 .
  53. ^ Справочник Гауэра для специалистов по управлению проектами . Лок, Деннис., Скотт, Линдси, 1974-. Фарнем, Суррей: издательство Gower. 2013. с. 398. ISBN 978-1409437857. OCLC  855019788 .CS1 maint: others (link)
  54. ^ "ОУП" . www.theprojectmanager.co.za . Проверено 1 марта 2018 .
  55. ^ Комиссия Австралийской государственной службы. «Структура APS для оптимальных структур управления» . Проверено 1 марта 2018 .
  56. Перейти ↑ Bannerman, PL (2008). Определение успеха проекта: многоуровневая структура. Доклад, представленный на исследовательской конференции PMI®: определение будущего управления проектами, Варшава, Польша. Newtown Square, Пенсильвания: Институт управления проектами. Доступно на https://www.pmi.org/learning/library/defining-project-success-multilevel-framework-7096
  57. ^ Emanuel Камильрайте успех проекта: Критические факторы и Поведение, Gower Publishing, Ltd., 2011
  58. ^ "DoDD 5000.01" (PDF) . Министерство обороны США . Проверено 20 ноября 2007 года .
  59. ^ а б НАСА NPR 9501.2D . 23 мая 2001 г.
  60. ^ ISO / IEC / IEEE 16326-2009 - Системная и программная инженерия - Процессы жизненного цикла - Управление проектами. Декабрь 2009 г. DOI: 10.1109 / IEEESTD.2009.5372630. ISBN 978-0-7381-6116-7 
  61. ^ Базовый уровень индивидуальной компетентности для управления проектами, программами и портфелем (PDF) . Международная ассоциация управления проектами (IPMA). 2015. ISBN.  978-94-92338-01-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. ^ Curlee, Ванда (2011). Виртуальный офис управления проектами: передовой опыт, проверенные методы .
  66. ^ Khazanchi, Дипак (2005). Паттерны эффективного управления проектами в виртуальных проектах: исследовательское исследование . Институт управления проектами. ISBN 9781930699830. Архивировано из оригинала на 2013-10-23 . Проверено 22 октября 2013 .
  67. ^ Velagapudi, Мридула (13 апреля 2012). «Почему нельзя избежать управления виртуальными проектами, начиная с 2012 г.» .

Внешние ссылки [ править ]

  • Руководство по управлению проектами Министерства бизнеса, предпринимательства и регуляторной реформы Великобритании (BERR)
  • PM Foundation PM БЛОГ
  • СМИ, связанные с управлением проектами на Викискладе?

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