28.Управление временными парметрами проекта. Календарный план проекта и его иерархия. Сетевой план на уровне проекта,диаграмма Ганта
Практика показывает, что четкое и оперативное воплощение в жизнь любого масштабного проекта невозможно без составления точного плана действий. Приступая к осуществлению задуманного, руководителю необходимо ясно представлять себе всю последовательность действий, необходимых для реализации поставленной задачи.
Для определения полного перечня работ и установления четких сроков их реализации, составляется календарный план. Календарный план представляет собой документ, отражающий сроки начала и окончания каждого вида работ, необходимых для воплощения проекта в жизнь.
Сетевой план отражает операции проекта, которые необходимо выполнить, логическую последовательность и взаимозависимость этих операций и время начала и окончания самой продолжительной цепочки операций - критический путь.
Сетевой план раскрывает внутренние связи проекта и служит основой для календарного планирования работ и использования оборудования.
Сетевой план дает возможность оценить периоды времени, в течение которых выполнение операций может начинаться и заканчиваться, а также время допустимой задержки их выполнения.
Сетевой план позволяет определить, какие операции являются "критическими" и, следовательно, должны выполняться строго по графику, чтобы проект был завершен в запланированные сроки.
29. Управление ресурсами проекта. Бюджет проекта и ресурсные планы
30. Упр качеством
31. Упр рисками
32. Процессы упр научно-техн проектами и программами
33. Предложение и инициация проекта.
Контроль и управление изменением и содержанием прокта
Инициация проекта - процесс управления проектом, результатом которого является санкционирование начала проекта или очередной фазы его жизненного цикла.
Проект инициирует Проектный комитет после получения информации о необходимости открытия проекта со стороны Генерального директора, Заместителей Генерального директора или Директоров направлений.
При инициации проекта Проектный комитет выполняет следующие действия:
Рассматривает предлагаемую информацию;
Оценивает целесообразность инициации проекта с точки зрения полезности его результатов и соответствия стратегическим ориентирам Компании;
Анализирует экономическую эффективность и финансовую возможность реализации проекта;
Согласует сроки реализации проекта и определяет ключевые показатели эффективности его реализации;
Согласует бюджет проекта, в том числе мотивационный пакет его участников (Куратора проекта, Менеджера проекта и Проектной группы)
Назначает Куратора проекта и утверждает кандидатуру Менеджера проекта;
Организует подготовку комплекта документов по инициации проекта, согласует и утверждает его.
Результатом инициации проекта является комплект документов согласованный и утвержденный к исполнению Проектным комитетом Компании.
Инициация проектов проводится на собрании Проектного комитета, проходящем не реже 1 раза в месяц.
В ходе инициации проектов могут возникнуть следующие исключения:
Для принятия решения об инициации проекта недостаточно исходной информации. В этом случае Проектный комитет запрашивает дополнительные данные у лица ответственного за подготовку всей информации.
Предлагаемый проект не соответствует стратегическим потребностям Компании или его результаты бесполезны для Компании. В данном случае проектный комитет блокирует реализацию проекта своим решением.
Экономическая эффективность проекта низка или отсутствует финансовая возможность его реализации. В данном случае проектный комитет блокирует реализацию проекта своим решением.
Контроль и управление изменениями и содержанием проекта.
Мониторинг и контроль над работами проекта — это процесс непрерывного наблюдения, анализа и регулирования прогресса проекта для достижения целевых показателей эффективности, определенных в плане управления проектом (табл. 4.4).
Управление изменениями представляет собой процесс прогнозирования и планирования будущих изменений, регистрации всех Потенциальных изменений для детального изучения, оценки последствий, одобрения или отклонения, а также организации мониторинга и координации исполнители, реализующих изменения в проекте.
Под изменением понимается замещение одного решения другим вследствие воздействия различных внешних и внутренних факторов при разработке и реализации проекта. Изменения могут вноситься в различные разделы проекта. Инициировать изменения могут и заказчик, и инвестор, и проектировщик, и подрядчик. Заказчик, как правило, вносит изменения, улучшающие конечные технико-экономические характеристики проекта. Проектировщик может вносить изменения в первоначальную проектно-сметную документацию, спецификации. Подрядчик по ходу реализации проекта вносит изменения в календарный план, методы и технологии производства работ, последовательность возведения объектов и т. д.
Управление содержанием проекта включает в себя процессы, обеспечивающие включение в проект всех тех и только тех работ, которые необходимы для успешного выполнения проекта. Оно непосредственно связано с определением и контролем того, что включено или не включено в проект.
5.1 Планирование содержания – создание плана управления содержанием проекта, в котором документируется процесс формулирования, верификации и контроля содержания проекта, а также процесс создания и формулирования иерархической структуры работ (ИСР).
5.2 Определение содержания – разработка подробного описания содержания проекта в качестве основы для принятия будущих решений по проекту.
5.3 Создание ИСР – разбиение крупных результатов поставки проекта и проектных работ на более мелкие, более управляемые элементы.
5.4 Подтверждение содержания – формализация принятия завершенных результатов поставки проекта.
5.5. Управление содержанием – управление изменениями содержания проекта.
Эти процессы взаимодействуют друг с другом, а также с процессами из других областей знаний. Каждый процесс может включать в себя действия одного или нескольких лиц или групп лиц, в зависимости от потребностей проекта. Каждый процесс происходит в каждом проекте как минимум один раз и в одной или нескольких фазах проекта, если проект разбит на фазы. Хотя процессы представлены в виде дискретных элементов с четко выделяемыми границами, на практике они могут накладываться друг на друга и взаимодействовать такими путями, которые здесь не рассматриваются.
Реализация содержания проекта сравнивается с планом управления проектом (раздел 4.3), описанием содержания проекта с ИСР и словарем ИСР, но реализация содержания продукта сравнивается с требованиями к продукту. Управление содержанием проекта должно быть хорошо интегрировано в остальные процессы области знаний, так чтобы результатом проектной работы стало создание заданного содержания продукта.
34. . Интегрированный контроль реализации проектов. Упр отклонениями
Основной целью контроля проекта является обеспечение выполнения плановых
показателей и повышение общей эффективности функций планирования и контроля проекта.
Содержание контроля проекта состоит в определении результатов деятельности на основе
оценки и документирования фактических показателей выполнения работ и сравнения их с
плановыми показателями.
Область знаний об управлении интеграцией проекта включает в себя процессы и операции, необходимые для выявления, определения, объединения, унификации и координации различных процессов и операций управления проектами в рамках групп процессов управления проектами. В контексте управления проектами интеграция включает в себя такие характеристики, как унификация, консолидация, артикуляция и интегративные действия, являющиеся ключевыми для завершения проекта, успешного удовлетворения требований заказчика и других участников проекта, а также управления ожиданиями.
\В контексте управления проектом интеграция — это принятие решений о том, где концентрировать ресурсы на каждую конкретную дату, предугадывание потенциальных проблем, и их решение до того, как эти проблемы станут критическими, и хорошая координация работы проекта в целом. Интеграция также подразумевает нахождение компромиссов между пересекающимися целями и альтернативами. Процессы управления проектами обычно представляются в виде дискретных элементов с хорошо разработанными интерфейсами, в то время как на практике они накладываются друг на друга и взаимодействуют между собой такими путями, которые не могут быть достаточно подробно описаны в Руководстве PMBOK®.
Потребность в интеграции в сфере управления проектами становится очевидной в таких ситуациях, когда имеет место взаимодействие отдельных процессов. К примеру, смета, необходимая для подготовки плана расходов на непредвиденные обстоятельства, предполагает интеграцию процессов планирования, подробно описанных в процессах Управления стоимостью проекта, Управления сроками проекта и Управления рисками проекта. При выявлении дополнительных рисков, связанных с различными альтернативами комплектования персоналом, необходимо обратиться к одному или нескольким этим процессам. Результаты поставки проекта тоже необходимо интегрировать в текущую операционную деятельность исполняющей организации (или заказчика) или в долгосрочное стратегическое планирование, учитывающее будущие проблемы и возможности.
Опытные специалисты в области управления проектами знают, что невозможно управлять проектом каким-то единственным, унифицированным способом. Для достижения желаемой эффективности проекта они применяют свои знания и навыки и соответствующие процессы в области управления проектами в различной последовательности и с различной степенью жесткости. Тем не менее, то, что данный процесс не требуется, вовсе не означает, что его не нужно обсуждать. Менеджер проекта и команда проекта должны обсуждать каждый процесс, и для каждого конкретного проекта должен определяться уровень реализации каждого процесса.
Интегративный характер проектов и управления проектами можно лучше понять, если представить себе другие операции, выполняемые при реализации проекта. Вот какими, к примеру, могут быть операции, выполняемые командой управления проектом:
Проанализировать и понять содержание. Сюда относятся требования, критерии, допущения, ограничения для проекта и продукта, а также прочие относящиеся к проекту влияния и то, как будет осуществляться управление или обсуждение каждого из них в рамках проекта.
Задокументировать конкретные критерии требований к продукту.
Понять, как обработать имеющуюся информацию и трансформировать ее в план управления проектом при помощи группы процессов планирования, описанной в Руководстве PMBOK®.
Создать иерархическую структуру работ.
Принять соответствующие меры по выполнению проекта в соответствии с планом управления проектом, запланированным набором интегрированных процессов и запланированным содержанием.
Оценивать и отслеживать статус проекта, его процессы и продукты.
Анализировать риски проекта.
Зачастую связи между процессами в группах процессов управления проектами неоднократно повторяются. Например, группа процессов планирования на ранней стадии проекта предоставляет группе процессов исполнения подготовленный план управления проектом; впоследствии она участвует в его обновлении по мере появления изменений по ходу выполнения проекта.
Цель интеграции — это прежде всего эффективное интегрирование процессов в группах процессов управления проектами, необходимых для достижения целей проекта в рамках определенных процедур, принятых в организации. На рис. 4-1 представлена общая схема интегративных процессов управления проектом. На рис. 4-2 показана диаграмма зависимостей процессов для этих процессов, их входы, выходы и другие релевантные процессы в области знаний. Интегративные процессы управления проектами включают в себя следующие элементы:
4.1 Разработка Устава проекта — разработка Устава проекта, формально авторизующего проект или фазу проекта.
4.2 Разработка предварительного описания содержания проекта — разработка предварительного описания содержания проекта, включающего в себя самое общее изложение содержания.
4.3 Разработка плана управления проектом — документирование операций, необходимых для определения, подготовки, интеграции всех вспомогательных планов в план управления проектами и их координации.
4.4 Руководство и управление исполнением проекта — выполнение работы, определенной в Плане управления проектом для выполнения требований, определенных в описании содержания проекта.
4.5 Мониторинг и управление работами проекта — мониторинг и управление процессами инициации, планирования, выполнения и завершения проекта для достижения целевых показателей эффективности, намеченных в Плане управления проектом.
4.6 Общее управление изменениями — обработка всех запросов на изменения, утверждение этих изменений и управление ими для оптимизации результатов поставки и активов организационного процесса.
4.7 Закрытие проекта — завершение всех операций во всех группах процессов управления проектами для формального закрытия проекта или проектной фазы.
Общее управление изменениями производится от начала проекта вплоть до его завершения. Управление изменениями необходимо в силу того, что проекты редко когда выполняются строго в соответствии с планом управления проектом. План управления проектом, описание содержания проекта и прочие результаты поставки нужно выдерживать путем аккуратного и непрерывного управления изменениями, либо отклоняя, либо принимая их, так чтобы одобренные изменения попали в отредактированный базовый план. Общее управление изменениями включает в себя следующие операции по управлению изменениями, различающиеся уровнем детализации на основе завершения выполнения проекта:
Идентификация необходимости появления изменения или факта его появления.
Оказание влияния на факторы, ограничивающие общее управление изменениями, так чтобы внедрялись только одобренные изменения.
Рассмотрение и одобрение запрошенных изменений.
Управление одобренными изменениями по мере их появления путем регулирования потока запрошенных изменений.
Поддержание целостности базовых планов путем внесения в продукты и услуги только одобренных изменений и поддержания их конфигурации и плановой документации.
Проверка и одобрение всех рекомендованных корректирующих и предупреждающих действий.
Контроль и обновление содержания, стоимости, бюджета, расписания проекта и требований к качеству на основе одобренных изменений путем координирования изменений по всему проекту. Например, предлагаемое изменение расписания часто оказывает влияние на стоимость, риск, качество и расстановку персонала.
Документирование в полном объеме корректировок, вызванных запрошенными изменениями.
Санкционирование исправлений дефектов.
Контроль качества проекта по стандартам на основе отчетов о качестве.
Предложенные изменения могут потребовать создания новых или редактирования старых смет, последовательностей плановых операций, дат расписания, требований к ресурсам и анализа альтернатив реагирования на риски. Эти изменения могут потребовать корректировок плана управления проектом, описания содержания проекта или результатов поставки проекта. Система управления конфигурацией с управлением изменениями обеспечивает стандартизированный и эффективный процесс централизованного управления изменениями в рамках проекта. Управление конфигурацией с управлением изменениями включает в себя идентификацию, документирование и контроль изменений в базовом плане. Применяемый уровень управления изменениями зависит от области приложения, сложности конкретного проекта, контрактных требований, а также контекста и окружению, в которых выполняется проект.
Применение системы управления конфигурацией, включая процессы управления изменениями, достигает три основных цели:
Создание эволюционного метода последовательной идентификации и запроса изменений по определенным базовым планам и оценки эффективности этих изменений
Создание благоприятных возможностей для непрерывной ратификации и улучшения проекта путем учета влияния каждого изменения
Предоставление команде управления проектом механизма последовательного информирования участников проекта обо всех изменениях.
Вот некоторые операции по управлению конфигурацией, входящие в процесс общего управления изменениями:
Идентификация конфигурации. Обеспечение основы для определения и верификации конфигурации продуктов, маркировки продуктов и документов, управления изменениями и обеспечения учитываемости.
Учет состояния конфигурации. Сбор, хранение и извлечение данных конфигурации, необходимые для эффективного управления продуктом и информацией о продукте.
Верификация и аудит конфигурации. Обеспечение выполнения требований к эффективности и функциональности, определенных в конфигурационной документации.
Каждое задокументированное запрошенное изменение должно быть принято или отклонено лицом с соответствующими полномочиями из команды управления проектом или из сторонней организации, представляющей инициатора, спонсора или заказчика. Зачастую в процессе общего управления изменениями задействован Совет управления изменениями, который отвечает за одобрение и отклонение запрошенных изменений. Роли и обязанности этих Советов четко определяются в рамках процедур управления конфигурацией и управления изменениями и согласуются спонсором, заказчиком и другими участниками проекта. Во многих крупных организациях Советы управления изменениями имеют многоуровневые структуры с разделением обязанностей. Если проект обеспечивается по контракту, то некоторые предложенные изменения должны быть одобрены заказчиком.
Отклонениями называют возникающие несовпадения первоначально согласованного и зафиксированного представления о проекте и того, что получается в действительности.
Управление отклонениями
Модели отклонений
С точки зрения тяжести последствий отклонения могут быть классифицированы, например, следующим образом:
плановые потери (учтены в плане управления проектом);
допустимые потери (незначительные незапланированные затраты);
нежелательные потери (значительные незапланированные затраты);
недопустимые потери (незапланированные затраты, которые являются неприемлемыми для одного или нескольких участников проекта).
Для каждого проекта изначально (пусть приблизительно) может быть определена степень влияния тех или иных изменений на величину вероятных потерь, возникающих при реализации этих изменений. На рис. 4.6 эта информация представлена в виде диаграммы, в которой изменения связаны с областями потерь.
35. Оценивание и закрытие проекта
Процесс закрытия проекта включает в себя выполнение плана управления проекта в части закрытия проекта. В многофазных проектах процесс закрытия проекта закрывает часть содержания проекта и операций, относящихся к данной фазе. Этот процесс включает в себя завершение всех выполненных операций во всех группах процессов управления проектом для формального закрытия проекта или проектной фазы и передачи завершенного или остановленного проекта. Процесс закрытия проекта также определяет процедуры координации операций, необходимых для проверки и документирования результатов поставки проекта, координации и формализации приемки этих результатов поставки заказчиком или спонсором и исследования и документирования причин предпринятых действий при закрытии проекта до его завершения. Для обеспечения необходимого взаимодействия при выполнении операций закрытия всего проекта или фазы проекта разрабатываются две процедуры:
Процедура административного закрытия. Эта процедура детализирует все операции, взаимодействия и обязанности членов команды проекта и других участников, вовлеченных в процедуру административного закрытия проекта. Процесс административного закрытия проекта также включает в себя интегрированные операции, необходимые для сбора отчетных материалов по проекту, анализа его успеха или неудачи, сбора накопленных знаний и архивирования информации по проекту для использования организацией в будущем.
Процедура закрытия контракта. Включает в себя все операции и взаимодействия, необходимые для урегулирования и завершения любого контрактного соглашения, касающегося данного проекта, а также для определения операций, обеспечивающих формальное административное закрытие проекта. Эта процедура включает в себя как верификацию продукта (вся работа выполнена правильно и с удовлетворительным качеством) и административное закрытие (внесение в письменное соглашение изменений, отражающих окончательные результаты, и архивирование этой информации для использования в будущем). Условия контракта могут также оговаривать спецификации для закрытия контракта, которые должны быть выполнены в рамках этой процедуры. Особым случаем закрытия контракта является его преждевременное расторжение; к числу таких случаев относятся, например, непоставка продукта, перерасход бюджета или нехватка необходимых ресурсов. Эта процедура является входом для процесса завершения контракта.
Оценка степени успешности проекта. Иногда успех либо неуспех проекта бывает очевидным. Тем не менее, во многих случаях результат бывает не настолько однозначным. Например, основные результаты поставки могут быть завершены, но бюджет при этом перерасходован. Или же все было поставлено вовремя и в пределах бюджета, но функциональность результата толшько на 80% соответствует требованиям. Ключевым моментом в определении успешности являются критерии, которые должны быть оговорены заранее. Если такие критерии согласованы со спонсором и соответстующим функциональным руководством, то команда проекта может получить однозначную и объективную оценку. Команда сперва сама оценивает свой проект согласно критериям успешности, а затем представляет оценку на утверждение спонсору.
Оценка производительности. Если проект был существенным для организации, по его окончании может иметь смысл оценить производительность всех принимавших в нем участие исполнителей. В таком случае, Спонсор и директор проекта (непосредственный начальник менеджера проекта) оценивают менеджера проекта. В свою очередь, менеджер проекта оценивает непосредственно подотчетных ему участников команды, а те, далее, оценивают остальных подотчетных им участников команды. Иногда команда оценивается в целом, и командная оценка учитывается вместе с индивидуальными оценками. Такой подход помогает установить более четкую связь индивидуальных оценок с фактической производительностью проекта.
36. Упр портфелями проектов. Комплексные пакеты для управления проектами.
Портфель – это набор проектов или программ и других работ, объединенных вместе с целью эффективного управления данными работами для достижения стратегических целей. Проекты и программы портфеля не обязательно являются взаимозависимыми или напрямую связанными. Финансирование и поддержка могут предоставляться на основании категорий риска/награды, особых
направлений бизнеса или общего типа проектов, например, улучшения инфраструктуры и внутренних процессов. Организации управляют своими портфелями в соответствии с конкретными задачами. Одной из задач управления портфелем является максимально увеличить ценность портфеля с помощью тщательного изучения намеченных для включение в портфель проектов и программ и своевременного исключения проектов, не соответствующих стратегическим задачам портфеля.
Другими задачами являются уравновешивание пошаговых и радикальных инвестиций и эффективное использование ресурсов портфеля. Обычно ответственность за управление портфелем в интересах организации берут на себя старшие менеджеры или высшее руководство.
Программное обеспечение для управления проектами —комплексное программное обеспечение, включающее в себя приложения для планирования задач, составления расписания, контроля цены и управления бюджетом, распределения ресурсов, совместной работы, общения, быстрого управления, документирования и администрирования системы, которое используются совместно для управления крупными проектами.
Задачи программного обеспечения для управления проектами
Планирование
Одной из наиболее распространенных возможностей является возможность планирования событий и управления задачами. Требования могут различаться в зависимости от того, как используется инструмент. Наиболее распространенными являются:
планирование различных событий, зависящих друг от друга;
планирование расписания работы сотрудников и управление ресурсами;
расчет времени, необходимого на решение каждой из задач;
сортировка задач в зависимости от сроков их завершения;
управление нескольким проектами одновременно.
Расчёт критического пути
Метод критического пути — эффективный инструмент планирования расписания и управления сроками проекта.
В основе метода лежит определение наиболее длительной последовательности задач от начала проекта до его окончания с учетом их взаимосвязи. Задачи лежащие на критическом пути (критические задачи) имеют нулевой резерв времени выполнения и в случае изменения их длительности изменяются сроки всего проекта. В связи с этим при выполнении проекта критические задачи требуют более тщательного контроля, в частности, своевременного выявления проблем и рисков, влияющих на сроки их выполнения и, следовательно, на сроки выполнения проекта в целом. В процессе выполнения проекта критический путь проекта может меняться, так как при изменении длительности задач некоторые из них могут оказаться на критическом пути.
Программное обеспечение для управления проектами предоставляет большое количество требуемой информации, такой как:
список задач для сотрудников и информацию распределения ресурсов;
обзор информации о сроках выполнения задач;
ранние предупреждения о возможных рисках, связанных с проектом;
информации о рабочей нагрузке;
информация о ходе проекта, показатели и их прогнозирование.
Типы программного обеспечения для управления проектами
Desktop (Настольные)
Программное обеспечение находится на десктопе каждого пользователя. Это предоставляет наиболее гибкий интерфейс. Такие приложения обычно позволяют сохранять информацию в файл, который в дальнейшем может быть выложен в общий доступ для других пользователей или же данные хранятся в центральной базе данных. Как пример, можно привести следующие приложения:
Cerebro — многопользовательское ПО для управление медиа проектами
GanttProject
KPlato — приложение для управления проектами под ОС Linux
Microsoft Project
OpenProj
Open Workbench
TaskJuggler
Web-based (Веб-приложения)
Программное обеспечение является веб-приложением, доступ к которому осуществляется с помощью браузера. Следующие приложения являются примерами веб-приложений:
Basecamp — онлайн-инструмент для управления проектами
Bontq
Easy Projects .NET — многофунциональная (Enterprise) система управления проектами
Kommandcore — веб-сервис для командного управления проектами
LifeTask.ru — система управления проектами.
Мегаплан — система управления проектами
Project Kaiser — система управления проектами
TeamLab — платформа для организации совместной работы и общения
www.conject.com — онлайн-платформа для взаимодействия в строительных проектах
Никсонэт — система управления проектами
Плюсы и минусы:
Доступ может быть осуществлен с любого компьютера, не требуется установка дополнительных приложений
Простой контроль доступа
Многопользовательность
Только одна программа, которая установлена на центральном сервере
Скорость работы ниже, чем у обычных приложений
Проблемы с доступом к серверу или его выход из строя ведут к полной недоступности информации
Персональные
Обычно используются для управлениями домашними проектами. Как правило, это однопользовательские системы с простым интерфейсом.
Однопользовательские
Однопользовательские системы могут использоваться в качестве персональных или для управления небольшими компаниями.
Многопользовательские
Предназначены для координации действий нескольких десятков или сотен пользователей. Обычно строятся по технологии клиент-сервер. К многопользовательским системам относятся:
Easy Projects .NET
FogBugz
LifeTask
OpenProj
ProjectMate
Project Kaiser
Redmine
Trac
TeamLab
37. Единая инф сист упр проектами. Сист упр пр на базе сетевых мод
На сегодняшний день успешная реализация проектной деятельности компании невозможна без применения информационных технологий. В качестве ИТ-составляющей системы управления проектами выступает информационная система управления проектами (ИСУП), которая представляет собой организационно-технологический комплекс технических, программных и информационных средств, направленный на поддержку и повышение эффективности процессов управления проектом.
Основой ИСУП является единое информационное пространство, предполагающее:
единую базу данных планов всех корпоративных проектов;
единый справочник ресурсов, доступных для использования в корпоративных проектах;
единые формы документов, шаблоны проектов и отчетов;
единую базу данных документов всех корпоративных проектов.
Лидирующие позиции среди ИТ-решений для управления проектами занимают системы Microsoft Enterprise Project Management Solution 2010.
Информационная система управления проектами (ИСУП) представляет собой организационно-технологический комплекс методических, технических, программных и информационных средств, направленный на поддержку и повышение эффективности процессов планирования и управления проектами, в основе которого лежит комплекс специализированного программного обеспечения.
Система управления проектами включает в себя комплекс методологических, нормативных документов, а также программно-аппаратных решений.
Информационная система управления проектами (ИСУП) представляет собой стандартизированный набор имеющихся в организации автоматизированных инструментов, интегрированных в систему. ИСУП используется командой управления проектом для подготовки Устава проекта, обеспечения обратной связи на этапе его доработки, управления вносимыми в Устав изменениями и издания утвержденного документа.
Внедрение единой системы планирования и управления проектами поможет существенно повысить эффективность реализации проектов компании. (- из пмбук)
Основными преимуществами использования информационной системы управления проектами являются:
возможность регламентирования процедур управление проектами;
определение и анализ эффективности инвестиций;
использование математических методов расчета временных, ресурсных, стоимостных параметров проектов;
централизованное хранение информации по графику работ, ресурсам и стоимостям;
возможность быстрого анализа влияния изменений в графике, ресурсном обеспечении и финансировании на план проекта;
обеспечение структуры контроля выполнения работ проектов;
учет и управление рисками проектов;
обеспечение контроля качества работ;
управление и контроль поставок и контрактов при обеспечении проектной деятельности;
определение информационных потоков проектной деятельности;
возможность автоматизированной генерации отчетов и графических диаграмм, разработки документации по проекту;
поддержка использования архива проектов и накопления знаний.