Управление проектами В производственной деятельности можно выделить два принципиально различных вида: Серийный выпуск товаров - процессы управления сводятся к поддержке заданных параметров производственной системы, а продолжительность выпуска товара зависит от наличия и величины спроса Производство единичных, уникальных продуктов - процесс создания уникального продукта требует применения специфических методов управления, объединяемых методологией управления проектами Экстенсивное и интенсивное развитие Основные отличия проектной деятельности от операционной Ограничения по срокам (временная деятельность). Большое количество рисков (в том числе критических). Большое количество изменений (в том числе существенных). Команда формируется для одного проекта (как правило). По оценкам мировых экспертов сегодня свыше 25 млн. специалистов и практиков во всем мире вовлечено в проектно-ориентированную деятельность По оценкам мировых экспертов на проекты и программы ежегодно к концу 2020 года будет расходоваться около 30% мирового бюджета По оценкам экспертов в США около 60% бизнес-деятельности управляется через проекты В России аналогичная оценка относится к 10-15% Базовые понятия Проект – это временное предприятие (мероприятие), предназначенное для создание уникального продукта, услуги или результата (РМВОК) Понятие "временное предприятие" означает, что у любого проекта имеется определенный старт (начало) и финиш (окончание). Окончание проекта наступает в том случае, если достигнуты цели проекта; или ответственными лицами признаётся, что цели проекта не могут быть или не будут достигнуты; или по какой-то причине исчезла необходимость в проекте. Управление проектами — это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Ключевым фактором успеха проектного управления является наличие четкого заранее определенного плана, минимизация рисков и отклонений от плана, эффективное управление изменениями Признаки проекта Уникальность, не цикличность, новизна (для компании) деятельности Ограниченность во времени (с определенным концом и началом) Утвержденный бюджет Повышенный уровень рисков Ограниченность в ресурсах Направленность на достижение конкретных целей, определенных результатов Ориентация на удовлетворение потребностей заказчика Особенности проектных работ Проекты, независимо от сферы деятельности, обладают целым рядом одинаковых особенностей: • • • Распределение затрат времени и ресурсов в проекте описывается S-образной кривой, причем до 90% затрат приходится на этапы разработки-реализации. Стоимость внесения изменений в проект экспоненциально нарастает к концу проекта Зависимость от окружения, в котором проекты исполняются Три вида деятельности Планирование Определение требований, желаемых результатов Разработка графика выполнения работ Расчет необходимых ресурсов Организация Распределение ролей и обязанностей Управление: Перераспределение работ и ролей Руководство работами и контроль результатов Решение возникающих проблем Обмен информацией с заинтересованными лицами Около 70% проектов терпят неудачу !!! Основная причина отсутствие методологии УП Критерии успешности проекта Так как каждый проект уникален, то с точки зрения методологии, для каждого проекта можно определить различное количество критериев успешности, но главными являются следующие: если проект завершен в установленные сроки (on-time) если проект завершен в рамках выделенного бюджета (within the budget) если проект завершен при удовлетворении заказчика (with customer satisfaction) Треугольник компромиссов проекта Воздействие рисков Основная обязанность РП – работа с ограничениями Качество проекта Содержание Ограничения проекта тесно связаны между собой В ходе проекта изменения содержания влияют на другие стороны треугольника: сроки и бюджет Области знаний Для эффективного управления проектами необходимо, чтобы команда управления проектами понимала и использовала знания и навыки как минимум пяти экспертных областей: Свод знаний по управлению проектами Знания, стандарты и нормативные акты, относящиеся к данной области приложения Понимание окружения проекта Знания и навыки в области общего менеджмента Навыки межличностных отношений Искусство и технологии в управлении проектами Заинтересованные стороны проекта Заинтересованные стороны проекта (стейкхолдеры) – физические лица или группы лиц, юридические лица или компании, а также органы власти всех уровней и организации, заинтересованные в осуществлении проекта, либо находящиеся под воздействием проекта Команда управления проектом должна выявить как внутренние, так и внешние заинтересованные стороны проекта, чтобы определить требования, предъявляемые к проекту, и ожидания всех вовлеченных сторон. Заинтересованные стороны: спонсор проекта, Члены проектной команды, Заказчики, Руководители смежных подразделений, Пользователи результатов проекта, Общественность, Подрядчики, Государственные органы, Местная администрация … Участники проекта Участники проекта – это лица или организации, либо активно участвующие в проекте, либо на чьи интересы могут повлиять результаты исполнения или завершения проекта. К ключевым участникам любого проекта относятся: Менеджер проекта – лицо, ответственное за управление проектом. Заказчик/пользователь - лицо или организация, которые будут использовать продукт проекта. Команда проекта – совокупность отдельных лиц, групп и/или организаций, привлеченных к выполнению работ проекта и ответственных перед руководителем проекта за их выполнение. Команда управления проектом – члены команды проекта, непосредственно занятые в управлении его операциями. Спонсор - лицо или группа лиц, предоставляющая финансовые ресурсы –деньгами или в натуральном выражении – для проекта. Источники влияния - лица или группы, которые напрямую не связаны с получением или использованием продукта проекта, но которые, в связи с их положением в организации-заказчике или исполняющей организации, могут положительно или отрицательно повлиять на ход выполнения проекта Стандарты в управлении проектами являются руководством к действию, и необходимы для того, чтобы обеспечить в компании: Концентрацию лучшей практики. Стандарты в области управления проектами содержат лучший мировой опыт в этой области. Взаимодействие. Стандарты являются основой взаимодействия, особенно в крупных проектах. Сертификацию. Стандарты являются основой сертификации специалистов в области управления проектами. Ответ на вопрос "Что делать?" Стандарты описывают общепринятый подход, лучшую практику, рекомендации. Стандарт отвечает на вопрос "что нужно делать, чтобы эффективно управлять проектами?", оставляя свободу в выборе ответа на тот вопрос. Положения стандарта носят рекомендательный характер. Ответ на вопрос "как делать?". Ответ на этот вопрос содержится в регламентирующих документах (положениях, инструкциях, приказах, методологиях), обязательных для исполнения в организации или проекте и соответствующих (не противоречащих) выбранному стандарту. Стандарты управления проектами Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge), Project Management Institute, 2012 Международные требования к компетенции специалистов в сфере управления проектами (International Competence Baseline (ICB)), Международная ассоциация управления проектами (International Project Management Association IPMA), 2006 Международный стандарт ISO 21500:2012 «Руководство по управлению проектами» Национальные Требования Компетентности , Российская ассоциация управления проектами СОВНЕТ. Стандарты управления проектами С 1 сентября 2012 года в России введены в действие три ГОСТа, устанавливающих требования к проектному менеджменту в области управления проектами, управления программами и управления портфелями проектов: ГОСТ Р 54869 – 2011 Проектный менеджмент. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПРОЕКТОМ; ГОСТ Р 54870 – 2011 Проектный менеджмент. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПОРТФЕЛЕМ ПРОЕКТОВ; ГОСТ Р 54871 – 2011 Проектный менеджмент. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПРОГРАММОЙ Эти документы по методическому подходу и основным соответствуют подходу PMBOK® и стандарту ISO 21500:2012. процессам Project Management Body of Knowledge (PMBOK) Подход PMI Институт Управления проектами PMI основан в 1969 г., более 380000 членов, представлен в более 170 странах через отделения PMI разрабатывает стандарты в различных областях управления проектами, профессиональную сертификацию, конференции … Московское отделение PMI создано в 1998 г., объединяет более 800 человек Что такое Project Management Body of Knowledge (PMBOK) Сборник «лучших практик» в области управления проектами Стандарт для управления проектами без привязки к конкретной отрасли бизнеса Не включает в себя знания в области общего менеджмента и прикладные решения Содержит общий словарь терминов Является американским национальным стандартом Свод знаний по управлению проектами PMBOK В своде знаний по управлению проектами описаны знания, уникальные для управления проектами Руководство PMBOK является частью свода знаний по управлению проектами. Знания по управлению проектами, описанные в Руководстве PMBOK, включают в себя следующие элементы: • Определение жизненного цикла проекта • Пять групп процессов управления проектом PMBOK • Девять областей знаний Жизненный цикл проекта Жизненный цикл проекта - полный набор (последовательных) фаз проекта от ее начала до момента завершения, название и число которых определяется исходя из технологии реализации проекта и потребностей контроля со стороны организаций, вовлеченных в проект Фаза проекта – набор логически взаимосвязанных работ проекта, в процессе завершения которых достигается один из значимых промежуточных или окончательных результатов проекта Фаза проекта не является группой процессов управления проектом. Отношения между участниками проекта и проектом Группы процессов Процесс – это набор взаимосвязанных действий и операций, осуществляемых для получения заранее определенного продукта, результата или услуги. Управление проектом по стандарту PMBOK выполняется с помощью 42 процессов, которые объединены в пять групп, называемых "группы процессов управления проектом": Группа процессов инициации Группа процессов планирования Группа процессов исполнения Группа процессов мониторинга и управления Группа завершающих процессов Группы процессов управления проектами связаны посредством выходов, которые они производят. Выход одного процесса, как правило, становится входом для другого процесса или является результатом проекта. Активность групп процессов в течении жизненного цикла проектов Группы процессов редко бывают как дискретными, так и единовременными событиями; они являются пересекающимися действиями, происходящими на протяжении всего проекта. Если проект разделен на фазы, группы процессов взаимодействуют в рамках каждой фазы. Области знаний проекта Управление интеграцией проекта Управление содержанием проекта (процессы, обеспечивающие включение в проект тех и только (процессы, необходимые для определения, уточнения, комбинирования, объединения и координации различных процессов и действий по управлению проектом в рамках групп процессов управления проектами) тех работ, которые необходимы для успешного завершения проекта) Управление сроками проекта (процессы, обеспечивающие своевременное завершение проекта) Управление стоимостью проекта (процессы, выполняемые в ходе планирования, разработки бюджета и управления расходами и обеспечивающие завершение проекта в рамках утвержденного бюджета) Управление качеством проекта (включает в себя процессы и действия исполняющей организации, политику в области качества, цели и сферы ответственности в области качества таким образом, чтобы проект удовлетворял тем нуждам, ради которых он был предпринят) Управление человеческими ресурсами (включает в себя процессы организации, управления и руководства командой проекта. Команда проекта состоит из людей, которым определены роли и ответственность за выполнение проекта) Управление коммуникациями проекта (включает в себя процессы, необходимые для своевременного создания, сбора, распространения, хранения, получения и, в конечном счете, использования информации проекта) Управление рисками проекта (включает в себя процессы, относящиеся к планированию управления рисками, их идентификации и анализу, реагированию на риски, а также контролю и управлению рисками в рамках проекта) Управление поставками проекта (включает в себя процессы покупки или приобретения тех необходимых продуктов, услуг или результатов, которые производятся вне исполняющей организации) Взаимодействие групп процессов и областей знаний Инициация проекта В рамках процессов инициации: • Определяются изначальные цели и содержание, и фиксируются изначальные финансовые ресурсы. • Определяются внутренние и внешние заинтересованные стороны проекта, которые будут взаимодействовать и влиять на общий результат проекта. • Выбирается менеджер проекта, если он еще не назначен. Данная информация закрепляется в Уставе проекта. • После утверждения Устава проекта считается, что проект официально авторизован. Инициация проекта ставит своей целью провести анализ осуществимости проекта, и в случае утвердительного ответа, авторизовать проект для исполнения в компании Авторизация проекта – получение официального разрешения на использование ресурсов компании в проекте. Авторизация производиться путем подписания руководством компании Устава проекта. Руководитель проекта должен быть назначен на этапе инициации. Цели, продукт и содержание проекта Материальная или иная сущность, производимая в ходе выполнения проекта, создание и использование которой обеспечит в итоге достижение целей проекта Желаемые результаты (эффекты, выгоды) достигаемые при успешном выполнении проекта при заданных требованиях и условиях их осуществления Цели проекта Действия, выполняемые для создания продукта проекта Продукт проекта Задачи и работы проекта Цели проекта – должны быть сформированы заказчиком. Учитывая сложность и многогранность процесса формулирования целей, менеджер проекта должен уточнить и при необходимости доработать цели Методология целеполагания SMART S (specific) конкретные - Вы должны знать ответ на вопрос: : Что я хочу достигнуть? M (measurable) измеримые– Вы должны знать ответ на вопрос: Как как я узнаю, что достиг нужного результата? A (attainable) достижимые - Вы должны знать ответ на вопрос: Обладаю ли я нужными ресурсами (внутренними и внешними), чтоб достигнуть желаемого результата? R (relevant) обоснованные - Вы должны знать ответ на вопрос: Актуальны ли те или иные способы и задачи, которыми я хочу достичь цели? T (time-framed) ограниченный во времени - Вы должны знать ответ на вопрос: Когда цель должна будет достигнута? SMARTFORME F (focused) – сфокусированные: все цели должны быть взаимосвязаны и подчинены достижению некой общей укрупненной цели. Не распыляйтесь O (Optimistic) – оптимистичные: Вы ведь хотите достичь чего-нибудь хорошего? R(Ready) – готовы к достижению: не ставьте перед собой цели, которые очень сильно зависят от других людей и обстоятельств, которые Вы не контролируете M (Meaningful) – наполненные смыслом: они должны иметь для Вас значение. Они должны приносить пользу. Бессмысленные цели трудно достичь, да и зачем? E (Exciting) – яркие: цели должны вдохновлять. Если цель вызывает у Вас зевоту – плохо дело. А вот если Вы обдумывайте цель даже, когда обедаете, значит она Вас увлекла. Устав проекта Устав проекта – документ, позволяющий всем заинтересованным сторонам на самом раннем этапе зафиксировать общее понимание проекта Причины разработки устава проекта: • • • необходимость «легализации» проекта в компании фиксация основных характеристик проекта назначение руководителя проекта Вход: Описание работ, описание результата, экономическое обоснование, условия договора … Инструменты: Экспертные оценки Выход: Устав проекта Примерная структура устава проекта 1. Название проекта и краткое описание 2. Цели проекта 3. Требования к проекту 4. Обоснование проекта 5. Причина возникновения проекта 6. Бюджет (ориентировочный) проекта 7. Допущения проекта – основные предложения по проекту 8. Ограничения проекта (по срокам, содержанию, бюджету) 9. Расписание контрольных точек 10. ФИО руководителя проекта Планирование проекта Планирование - самая большая группа процессов в PMBOK Хорошо спланированный проект позволяет точно оценить сроки и стоимость, риски, определить процедуры изменений, спланировать качество и описать все это в документации В начале процесса планирования используем данные полученные на процессе инициации (соглашение с заказчиком о проекте) Планируем иерархическую структуру работ. Планируем ресурсы проекта Составляем расписание Определяем предварительную оценку проекта Разработка плана проекта Сбор требований Описание содержание проекта Построение иерархической структуры работ Планирование ресурсов Определение состава работ Определение взаимосвязей между работами Определение длительностей работ Разработка расписания Разработка бюджета Определение рисков, оценка рисков и стратегий реагирования Оптимизация расписания Составление плана управления проектом Утверждение плана (базового) Проведение стартового совещания Сбор требований Организовать сбор требований к продукту проекта у основных заинтересованных лиц. Использовать разные технологии сбора требований (анкеты, интервью, фокусгруппы и т.д.). Зафиксировать все требования в реестре требований. Определить приоритеты с учетом требований заказчика, пользователей и разработчиков (заказчики и пользователи определяют важную функциональность, которую они хотят получить в первую очередь и согласовывают её с разработчиками). Включить в объем проекта список требований адекватный срокам и бюджету проекта. Описание содержание проекта Цели проекта Описание продукта проекта Требования к проекту Ограничения и допущения Основные результаты Критерии приемки продукта проекта Требования к одобрению результатов проекта Сметная стоимость … Создание иерархической структуры работ ИСР (структурная декомпозиция работ - Work BreakDown Structure WBS) ИСР – это согласованная с результатами проекта иерархическая декомпозиция работ, которые команда проекта должна выполнить для достижения целей проекта и создания оговоренных результатов В ИСР включают работы, указанные в текущем одобренном описании содержания проекта. Основные правила формирования ИСР Проводим разбиение сложного проекта на понятные пакеты работ (принцип есть слона по кусочкам) Показываем разбиение на первом уровне по жизненному циклу проекта или по другим соображениям (например по кварталам) Используем принцип декомпозиции, т.е. у одного родителя могут быть много потомков, но у каждого потомка может быть один родитель Каждый элемент ИСР должен заканчиваться осязаемым результатом, т.е. по его реализации можно в плане ставить ключевую точку То что входит в проект – выполняем. То что в ИСР не входит – не выполняем Отдельно показывается ветка по управлению проектом. Она показывает, что эта деятельность необходима для проекта и требует соответствующих ресурсов Строительство жилого комплекса Управление проектом Внешний анализ Анализ соц-экон. среды Макроэкономический анализ Анализ конкуренции Анализ емкости рынка Анализ структуры рынка Исследования Маркетинговые исследования Геодезические исследования Внутренний анализ Организация исследований ПИР Общестроительные работы Закупка оборудования Декомпозиция работ Декомпозиция работ превращает объем работ во множество сравнительно небольших, обозримых задач, которые называют пакетами работ Декомпозиция помогает: Отразить содержание проекта с достаточно высокой степенью детализации Отслеживать ход выполнения работ Получить точные оценки затрат и расписания проекта Успешное формирование проектной команды за счет указания каждому члену команды конкретного объема работ Составление сетевой диаграммы 12. Определить не состоится ли предполагаемое завершение проекта раньше даты обязательства 13. Подкорректировать расписание или дату обязательства 14. Получить одобрение расписания 1. Создать перечень операций, которые должны быть включены в расписание 2. Определить длительность каждой операции 11. Отрегулировать расписание в соответствии с ограничениями на ресурсы 10. Запросить ресурсы и определить ограничения на ресурсы 3. Определить предшествующую операцию для каждой операции Создание сетевой диаграммы 4. Рассчитать с помощью прямого прохода раннее расписание для каждой операции 9. Подкорректировать расписание или дату обязательства 8. Определить, не состоится ли предполагаемое завершение проекта раньше даты обязательства 7. Определить критический путь 6. Вычислить временной резерв для каждой операции 5. Рассчитать с помощью обратного прохода позднее расписание для каждой операции Сетевая диаграмма Сетевая диаграмма – графическое отображение работ проекта и их взаимосвязей. Диаграмма предшествования, является наиболее распространенным представлением сети: вершина – работа, дуга – взаимосвязь работ Особенности: • отображение логической структуры проекта • представление взаимосвязей работ, составляющих весь проект в целом • не отображает входы, процессы и выходы и не допускает повторяющихся циклов или петель При разработке сетевого графика целесообразно придерживаться следующих правил: Сетевой график разворачивается слева направо. Ни одна операция не может быть начата, пока все предшествующие связанные с ней операции не будут выполнены. Стрелки в сетевом графике отображают отношения предшествования и следования. На рисунке стрелки могут пересекаться. Каждая операция должна иметь свой собственный номер. Номер последующей операции должен быть больше номера любой предшествующей операции. Образование петель недопустимо (другими словами, не должно происходить зацикливания хода выполнения установленного набора операций) Условные переходы от одной операции к другой не допускаются (имеется в виду определение последовательности хода выполнения операций условиями типа: «Если будет достигнут успех, сделайте то–то...; если нет –ничего не предпринимайте»). Опыт показывает, что когда существует несколько исходных операций проекта, то может быть определен общий узел начала всего комплекса работ. Точно так же один узел может быть использован для четкого обозначения окончания проекта. Определение взаимосвязей Связь окончание – начало (Работа последователь может начаться только после окончания работыпредшественника) Связь начало-начало (Работа последователь может начаться только после того как начнется работа-предшественник) Связь окончание – окончание (Работа последователь может завершиться только после того как завершится работа-предшественник) Связь начало- окончание (Работа последователь может завершиться только после того как начнется работа-предшественник Виды зависимости между операциями Жесткая зависимость – последовательность операций не может изменяться Нежесткая зависимость – последовательность операций определяется командой проекта и может изменяться Внешняя зависимость – последовательность операций определяется внешними по отношению к проекту воздействиями. Обычно не поддаются контролю со стороны команды проекта Определение длительностей (оценка продолжительности, которое вероятно необходимо для выполнения каждой конкретной работы) Методы оценки: Экспертная оценка Оценка по аналогии Форма экспертной оценки, которая использует информацию по оценке подобной работы в этом проекте или ранее проведенном проекте Метод оценки «сверху-вниз» Обычно выполняется «снизу-вверх» Выполняется заинтересованными сторонами Используется когда проекты подобны по фактическому составу работ, специалист проводящий оценку должен быть экспертом в данной предметной области Используется, когда отсутствует детализация ряда работ проекта Параметрическая оценка Используется для повторяющихся задач Анализ сетевого графика Сетевой график проекта располагает операции в подходящей последовательности для расчета времени начала и окончания операции. Прямой анализ – Определение ранних сроков начала операций Как скоро может начаться операция? Как скоро она может закончиться? Как скоро может быть завершен проект в целом? Обратный анализ – Определение поздних сроков завершения операций Каковы самые поздние сроки начала операции? Каковы самые поздние сроки завершения операции? Какие операции составляют критический путь? Это самый длинный путь, при задержке выполнения операций на этом пути задерживается выполнение проекта. На какое время может быть задержано выполнение операции? Ранние даты начала и окончания работ рассчитываются от конкретной даты старта Поздние даты начала и окончания работ рассчитываются от определенной в ходе первоначального расчета финиша. Ранний старт Длительность Ранний финиш Задача Поздний старт Резерв Поздний финиш Метод критического пути (Critical Path Method, CPM) Критический путь проекта – последовательность определяющих max продолжительность проекта. плановых операций, Метод критического пути – вычисляет критический путь проекта и единственные, даты раннего и позднего начала для каждой работы на основе специальной последовательной сетевой логики и единственной оценки длительности Основные понятия: Длительность проекта (Duration of Project) Ранние даты проекта - (Early Start, Early Finish) Поздние даты проекта - (Late Start, Late Finish) Резервы работ (частные и общие) - (Slack) Расчёт критического пути Ранние сроки вычисляют с помощью прямого использованием установленной даты начала. прохода по сети, с Поздние сроки вычисляют с помощью обратного прохода, начиная от установленной даты завершения проекта (обычно даты раннего завершения проекта, вычисленной путем прямого прохода по сети). Длительность работы обозначается внутри прямоугольника, обозначающего её. Ранние сроки начала и окончания проекта пишутся вверху прямоугольников, обозначающих работы. Поздние сроки начала и окончания пакетов работ пишутся в нижней части прямоугольников, обозначающих работы. 0 2 Подготовка зала 2д 1 3 0 3 Печать материалов 3д 0 8 9 Встреча и регистрация гостей 1д 3 10 3 8 Подготовка техники 5д 3 8 11 8 11 Подключение оборудования 0 4 Рассылка приглашений 4д 6 10 3д 8 11 Задание: постройте сетевой график по данным и рассчитаете критический путь РАБОТА Непосредственно предшествующая работа Время, дней Ресурсы A - 8 Инженер B - 10 Маляр, столяр, прораб C - 6 D A, B 8 E B,C 9 F C 14 G D, E 14 H F, G 6 Название ресурса Стоимость ресурса (стоимость 1 часа, стоимость 1 единицы материала) Трудоемкос ть Трудозат раты инженер 500 руб/ч 64 часа 64*500= кирпич 20 руб/шт 10000 шт 10000*20 = Итого 5000000 (кол-во часов проекта, кол-во штук) Диаграмма Гантта Диаграмма Гантта (Gantt Chart) - частная разновидность линейного графика, отображающая план работ во времени. График Гантта является поэтапным изображением продолжительности работ во времени. В левой части диаграммы отражается перечень работ проекта. В правой – их длительность и взаимосвязи. Пример диаграммы Гантта Сжатие расписания Самый легкий способ Самый трудный способ Выравнивание ресурсов Сокращение содержания проекта Сжатие расписания Параллельное выполнение работ Минус: рост рисков и рост бюджета Привлечение дополнительных ресурсов Минус: рост бюджета Сжатие расписания сокращает длительность проекта без изменения содержания проекта, временных ограничений, статусных дат или иных целевых параметров расписания. Методы сжатия расписания включают в себя: Сжатие. Метод сжатия расписания, в котором анализируются компромиссы между стоимостью и расписанием, чтобы определить, каким образом возможно максимально сжать сроки при минимальных затратах. Эффективно для операций, где дополнительные ресурсы способны сократить длительность. Быстрый подход. При этом методе сжатия расписание фазы или операции, обычно выполняемые последовательно, выполняются параллельно. Применим только в том случае, когда операции могут накладываться одна на другую для сокращения длительности. Алгоритм ресурсного планирования Определение ресурсов (описание ресурса и определение максимально доступного количества данного ресурса). Соответствие ресурсов задачам. Анализ расписания проекта и разрешение противоречий, возникших между требуемым количеством ресурса и его количеством, имеющимся в наличии Должны получить набор доступных ресурсов. Определение ресурсов (люди, оборудование, материалы) Календарь ресурсов – подсказывает Вам какой ресурс доступен и в какое время Критерии оценки человеческих ресурсов: Доступность: какие человеческие ресурсы доступны сейчас, какие будут доступны после и в какое время? Способность: Какая у этих ресурсов квалификация? Опыт работы: Имеют ли эти люди опыт работы такой или подобной работы? Заинтересованность: Интересно ли людям работать над данным проектом? Стоимость: Сколько надо будет платить каждому члену команды? Процесс назначения ресурсов заключается в указании для каждой работы требуемых ресурсов и определении их необходимого количества. Разработка бюджета расходов Бюджет – директивный документ, представляющий собой график планируемых расходов и доходов, распределенных по статьям в рамках проекта. Бюджетирование затрат представляет собой процесс структуризации расходов проекта: по видам работ, статьям затрат, по отчетным периодам, по иной структуре. В бюджет расходов могут включаться управленческие резервы (на непредвиденные обстоятельства) Разработка бюджета расходов Разработка бюджета расходов включает в себя объединение оценок стоимости отдельных плановых операций с целью создания общего базового плана по стоимости для определения эффективности исполнения бюджета. Базовый план по стоимости представляет собой распределенный по времени бюджет, по которому производиться сверка, мониторинг и контроль использования денежных средств всего проекта. Сводный план проекта WBS проекта Ресурсный план Расписание проекта Матрица ответственности План управления качеством Бюджет План коммуникаций План по рискам План управления стоимостью План поставок Исполнение проекта Основные процессы на фазе исполнение проекта 7. Проводим постоянное улучшение 1. Работаем по плану управления проектом 6. Соблюдаем процессы управления проектом 2. Обмениваемся информацией. Исполнение проекта 5. Разрабатываем 3. Укрепляем изменения и корректирующие действия 4. Проводим совещания по оценке текущего состояния команду Мониторинг и контроль проекта Мониторинг и контроль проекта Этапа мониторинга и контроля, как выделенного во времени, не существует - эти процессы присутствуют в течение всего срока работы над проектом Среди процессов мониторинга и контроля выделяют: Управление изменениями Управление содержанием Управление стоимостью Управление рисками Мониторинг и контроль качества Управление участниками проекта Получение отчетности Основные процессы на фазе мониторинга и контроля проекта 1. Сравнивайте 9. Проводите подтверждение содержания (акты, документы) выполнение с базовым планом 8. Проводите аудит рисков 2. Определяйте отклонения и необходимость в корректирующих действиях Мониторинг и контроль 7. Разрабатывайте прогнозы 3. Предлагайте изменения и исправления 6. Управляйте конфликтами 5. Управляйте резервами 4. Отчитывайтесь исполнении в Точки контроля проекта В каждом проекте необходимо задать точки контроля, для каждой из которых необходимо определить: Дату Объект контроля (что контролируем) Субъект контроля (кто контролирует) Параметры контроля и их численные измерители, целевые показатели, допустимые отклонения Тип контроля (вертикальный итоговый, вертикальный предварительный, вертикальный текущий, горизонтальный функциональный) Способ контроля (контроль, мониторинг) Следствия контроля (функциональные, мотивирующие) Точки контроля рекомендуется ставить: на всех вехах если в сетевом графике есть «гамак» на работах критического пути на работах с малыми резервами времени Отчетность об исполнении Отчетность по исполнению предусматривает сбор всех данных базового плана и предоставления участникам проекта информации о выполнении работ Три вида текущих отчетов: Отчет статуса (описывает текущую ситуацию в проекте) Отчет о прогрессе (описывает, что сделано с прошлой отчетной даты) Прогноз (прогнозирует будущий статус и прогресс проекта) Отчет по исполнению Описывает состояние проекта в разрезе: содержания, расписания, стоимости, качества Завершение проекта Закрытие проекта 8. Обновите базу накопленных знаний 1. Убедитесь, что выполненная работа соответствует требованиям 7. Сдайте документацию по проекту в архив 2. Передайте заказчику готовый продукт 6. Освободите ресурсы Закрытие проекта 3. Получите формальное подтверждение приемки проекта 5. Подготовьте финальный отчет 4. Закройте контракты Главные причины провала проекта Требования заказчика отсутствуют / не полны / подтверждены частым изменениям Отсутствие рабочего взаимодействия с заказчиком Отсутствие необходимых ресурсов и опыта Неполнота планирования «Забытые работы» Ошибки в оценках трудоемкостей и сроков работ Уход из проекта или из компании ключевых сотрудников Управление содержанием проекта Управление содержанием проекта включает в себя процессы, обеспечивающие включение в проект всех тех и только тех работ, которые необходимы для успешного выполнения проекта. Причины изменений: Неточно определенное на этапе планирования содержание проекта Плохо определённые характеристики продукта Изменения, которые добавляют ценность Внешние события Просьба клиентов Запросы и решения проектной команды Действия риска Управление содержанием проекта заключается в воздействии на факторы, создающие изменения содержания проекта, и контролировании производимого этими изменениями эффекта Управление изменениями Управление изменениями производится в течение всего срока работы над проектом и связано с тем, что проект очень редко идет в полном соответствии с намеченным планом. Планы редко выполняются на 100% Отклонения можно погасить… Или изменить план Все отклонения и изменения должны управляться интегрировано Поддержание целостности базовых планов Отражение изменений в текущих планах Координацию изменений с другими частями проекта и другими проектами Все изменения обязательно должны быть зарегистрированы в письменной форме и переданы в систему управления изменениями Следует различать управление изменениями и потерю контроля Управление изменениями - это совокупность заранее оговоренных процедур и правил, в соответствии с которыми изменения вносятся в проект. Любое изменение, прежде чем оно будет внесено в план проекта, вначале рассматривается лицами, имеющими соответствующие полномочия, которые ответственны за внесение изменений. После рассмотрения изменение либо принимается, либо отвергается (или откладывается до выяснения обстоятельств). Необходимо оповещать участников проекта о произошедших изменениях в проекте (это оповещение должно быть запланировано заранее, в плане управления коммуникациями) Типичная схема внесения изменений в проект Алгоритм внесения изменения Внести на рассмотрение предложение об изменении Принять предложение к рассмотрению Проанализировать предложение Утвердить или отклонить предложение на соответствующем уровне согласно процедуре Предложение принято? Зафиксировать отклонение предложения Изменить цели и/или план проекта Сообщить инициатору об отклонении Сообщить участникам об изменении Управление командой процесса Согласно РМВОК управление командой проекта включает в себя контроль за деятельностью членов команды, обеспечение обратной связи, решение проблем и координацию изменений, направленных на повышение эффективности исполнения проекта. Управление командой проекта Необходимость управления командой: В начале совместной работы – сотрудники воодушевлены и настроены оптимистично. Далее могут возникнуть сложности, снижение мотивации, сомнения, конфликты. 4 стадии развития команды Э ф ф е к т и в н о с т ь Стадия 4. Выход на проектную мощность Стадия 3. Нормирование Стадия 2. Притирка Стадия 1. Формирование команды Время 4 фазы становления команды должны циклически повторяться, чтобы обеспечит циклический рост эффективности 5 пороков команды Безразличие к результатам Нетребовательность Безответственность Боязнь конфликта Недоверие Матрица ответственности За все происходящее в проекте отвечает один человек - руководитель проекта. Но, поскольку задач в проекте много, а руководитель - один, ему приходится делегировать ответственность за отдельные задачи и группы задач другим членам команды. Матрица ответственности определяет степень ответственности каждого члена команды за ту или иную задачу, если он имеет к ней некоторое отношение. Степени ответственности (РМВОК): Ответственный (О) Исполняющий (И) Утверждающий (У) Согласующий (С) . Матрица ответственности (МО) МО - позволяет легко видеть взаимосвязи между членами команды и возложенными на них обязательствами Люди приходят и уходят из проекта. Обязанности лучше разрабатывать не под конкретных людей, а под их роли Назначение нескольких ответственных может привести к конфликтам На каждую задачу необходимо назначить ответственного Если слишком утверждающих, решение приниматься долго много то будет Как предотвратить истощение сил ресурсов проекта Истощением сил является состояние, при котором выполняемая работа перестает казаться особо важной. Перерывы (руководитель проекта должен обеспечить регулярные перерывы для сглаживания ситуаций и выделения времени на размышления) Устранение стресса (руководитель проекта нацелен на конкретную причину стресса и истощения сил. Если в проекте есть проблема, то руководитель проекта должен полностью ее устранить и не позволять ей оставаться, пока она не вызовет истощение сил в проекте) Контрольные точки (Регулярные контрольные точки для группы на протяжении всего проекта помогут всем передохнуть и расслабиться перед переходом к следующей фазе или задаче. контрольная точка должна быть включена в график) Реалистичные требования (к ресурсам в проекте нужно относиться с уважением, что включает в себя реалистичные требования к работе, которую можно сделать. Требование, чтобы люди работали 60 или 70 часов в неделю и укладывались в нереалистичные сроки, навязанное деспотично, приводит к истощению сил группы, независимо от того, сколько контрольных точек или перерывов руководитель проекта делает) Управление коммуникациями Управление коммуникациями Если сотрудники, занятые в проекте, не знают, в чем состоят их задачи или как выполнять их, то весь проект застопорится. Если РП не знает, что делают занятые в проекте сотрудники, то вы не сможете отслеживать прогресс проекта. Если РП неизвестно, чего от вас ожидает заказчик, то ваш проект даже не сдвинется с места. Эффективность коммуникаций По оценкам экспертов в области общения: • 10% информации передается через слова • 30% передается через интонацию • 60% передается через язык мимики и жестов. Наиболее эффективные коммуникации – если люди находятся в одной комнате В виртуальных командах эффективность коммуникаций снижается как минимум вдвое Планирование коммуникаций Планирование коммуникаций представляет собой процесс выявления потребностей заинтересованных сторон проекта в информации и определения подхода к коммуникациям. В процессе планирования коммуникаций определяются информация и взаимодействия, необходимые заинтересованным сторонам проекта. План коммуникаций является составной частью плана проекта. План управления коммуникациями включает: план сбора информации, в котором определяются источники информации и методы ее получения; план распределения информации, в котором определяются потребители информации и методы доставки; детальное описание каждого документа, который должен быть получен или передан, включая формат, содержание, уровень детальности и используемые определения; расписание и частота взаимодействия; метод внесения изменений в план коммуникаций. Пять основных коммуникативных навыков руководителей проектов Активное выслушивание - Внимание к словам и к смыслу, лежащему за этими словами, без перебиваний и попыток сменить тему, умение задавать вопросы для проверки правильности понимания, наблюдение за невербальными сигналами Создание взаимоотношений на основе доверия и уважения - Доверие и уважение заслуживаются трудом и приходят с опытом из нашей честности, добросовестности и компетенции. Доверие побуждает людей предлагать идеи, рекомендовать способы улучшения работы, высказывать свои опасения и давать советы Задание четких приоритетов - способность руководителя проекта объяснить стратегию для своей группы – путем задания целей, планирования и расстановки очередности. Это относится к таким вопросам относительно проекта, как - «что?», «кто?», «когда?», «где?», «почему?» и «как?». Члены группы должны понимать общую картину и более низкие уровни технических задач (приоритетов). Организация сотрудничества - В среде, поощряющей сотрудничество, члены группы поддерживают и воодушевляют друг друга, а не сосредотачиваются по отдельности на своих задачах и обязанностях. Они готовы сотрудничать и делиться информацией, идеями и средствами, чтобы помогать друг другу. Результат может быть лучше, чем сумма его частей. Объяснение перспективы организации - Объяснение общей картины помогает членам группы понять, каким образом проект соответствует общим целям вашего подразделения и организации. Высшее руководство сосредоточено на принципе триединства - финансы, среда, репутация. Они ожидают, что ваш проект внесет положительный вклад в эту сферу. Сбор и распределение информации В рамках проекта возникает потребность в осуществлении различных видов коммуникаций: внутренних (внутри команды проекта) и внешних (с руководством компании, заказчиком, внешними организациями и др.); формальных (отчеты, запросы, совещания) и неформальных (напоминания, обсуждения); письменных и устных; вертикальных и горизонтальных. Механизмы сбора информации: Неформальные встречи Переговоры Презентации Неформальные отчеты и письма Официальная отчетность Графики Интернет/интранет Корпоративная система знаний Распространение информации – это процесс предоставления необходимой информации заинтересованным сторонам проекта в соответствии с планом. Он осуществляется на всем протяжении жизненного цикла проекта и во всех процессах управления. Управление рисками Риск – неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта (PMI). Риск – возможность воздействия на проект и его элементы непредвиденных событий, которые могут нанести определенный ущерб и препятствовать достижению целей проекта. Риск – это степень опасности подвергнуться воздействию негативных событий и их возможных последствий. (IPMA) Риск – это событие, которое, если наступит, приведет к несоответствию факта плану. И наоборот, в основе любого несоответствия факта плану лежат реализовавшиеся риски. Управление рисками по PMI Известные риски Неизвестные риски Планирование реагирования Резерв на возможные потери Активно можно управлять только известными рисками. К характеристикам риска относятся: • • • • • Причина или источник Симптомы риска Вероятность риска Последствия риска Влияние риска Планирование управления рисками Планирование управления рисками – это процесс определения подходов и планирования операций по управлению рисками проекта. Планировать нужно для того, чтобы: Выделить достаточное количество времени и ресурсов для выполнения операций по управлению рисками Определить общее основание для управления рисками Повысить вероятность успешного завершения проекта. В план управления рисками может входить: Методология управления рисками Роли и ответственности участвующих в управлении рисками Бюджет для управления рисками Определение периодичности процедур управления рисками Критерии для распознавания наступления риска Категории риска Матрица вероятности и воздействия рисков Планирование управления рисками Идентификация рисков План реагирования Качественный анализ Количественный анализ Стратегии управления рисками: • Принятие рисков (ничего не делать) • Уклонение от рисков • Снижение рисков • Передача рисков • Страхование рисков Идентификация рисков Определение рисков, способных повлиять на проект, и документальное оформление их характеристик. Цель – получить максимально полный СПИСОК РИСКОВ ПРОЕКТА, включающий их описания, причины и условия возникновения. Иерархическая структура рисков Методы идентификации рисков Анализ документации, заключается в анализе материалов проекта, разработанных до проведения данного анализа (анализируется качество планов, согласованности планов, соответствие требованиям заказчика, допущения проекта, отчеты о выполнении аналогичных проектов) Методы сбора информации (мозговой штурм, метод Дельфи, опрос экспертов, карточки Кроуфорда, SWOT-анализ) Анализ контрольных списков Анализ допущений Анализ с использованием диаграмм Реестр рисков (После идентификации рисков из нужно записать!) Реестр рисков (Risk Register) Список рисков (ID риска, Наименование риска) Дата записи риска Точки уязвимости (первопричины) Вероятность возникновения риска Последствия риска в случае его возникновения Ранг риска Стратегии снижения риска Реестр рисков входит в ТОП-10 самых известных документов с точки зрения западного проектного менеджмента. Оценка рисков проекта Вероятность риска (В) Последствия риска (П) Это число от 0 до 1, представляющее возможность наступления риска. Риск с вероятностью 0 – не считается риском, с вероятностью 1 – риском не является, так как его появление достоверно Это стоимость риска, если он случиться. Количественные оценки последствий идентифицированного риска выражаются через деньги, дни расписания и т.д. Ожидаемое значение риска (О) О=В*П Стратегии реагирования на отрицательные риски Планирование реагирования на риски – это процесс разработки путей и определение действий по увеличению возможностей и снижению угроз для целей проекта. Уклонение от риска Передача рисков Изменить план проекта для устранения риска Использовать апробированную технологию вместо инновационной Модифицировать расписание с учетом проблем Добавить дополнительные задачи, чтобы повысить вероятность успеха Страхование Аутсорсинг Снижение риска Применить менее сложный процесс Провести больше тестов Выбрать надежного поставщика Добавить ресурсов … Стратегии реагирования на положительные риски Использование риска Совместное использование риска Привлечение лучших ресурсов для обеспечения приемлемого срока и качества Обход бюрократических процедур, которые типичны для «нормального» проекта Создание партнерств Передача лицензий третьей стороне Усиление риска Изменение «размера» риска путем увеличения его вероятности и позитивного результата Общая стратегия реагирования на отрицательные и положительные риски Принятие риска Стратегия, при которой риск принимается, команда проекта не делает ничего, что может повлиять на риск Рискнуть, т.е. осознанно принять риск, означает следующее: Мы знаем, чем и ради чего мы рискуем Мы знаем все принятые риски и их параметры. Мы знаем, что лежит в основе рисков. Мы можем подготовиться к тому, что они реализуются и смягчить их возможные последствия Управление конфликтами Конфликт – столкновение противоречащих интересов, целей, желаний людей в ходе их взаимодействия Объект конфликта - является причиной конфликта Участники конфликта – могут являться как отдельными людьми, так и группами людей. Участники конфликта могут иметь внутреннюю так и внешнюю позицию в конфликте. Внутренняя позиция – совокупность истинных интересов, мотивов и ценностей, которые принуждают человека или группу включаться в конфликт. Внешняя позиция – представляет собой ту мотивировку участия в конфликте, которую открыто представляет каждая из сторон своим оппонентам. Управление конфликтами Источники конфликтов Способы разрешения Дает решение конфликта Приоритеты • Решение проблемы • Нахождение компромиссов Технические решения • Принуждение Противоречивые требования Возможности команды Стоимость и бюджет Способы разрешения Временная Несправедливое распределение • Уклонение мера ресурсов • Сглаживание Неудовлетворительные коммуникации Польза для личных целей Польза для взаимоотношений Принуждение Большая Малая Сглаживание Малая Большая Компромисс Умеренная Умеренная Решение Большая Большая Уклонение Малая Малая Шаги по разрешению конфликтов: Признать, что конфликт есть Отделить проблему от людей: конкурируют не идеи, а люди Договориться об общем: формулировка проблемы, разделяемые цели Сформулировать видение проблемы каждой из сторон Собрать объективные данные о ситуации Выдвинуть и рассмотреть максимум альтернативных решений Выбрать оптимальное решение, взаимовыгодное для всех сторон Проинформировать о решении всех участников проекта, которых оно касается Алгоритм управления конфликтами Изучение причин и хода развития конфликта Ограничение числа участников Привлечение экспертов, консультантов, медиаторов Прояснение предмета противоречий, разницы и общности в целях и потребностях сторон Определение областей доверия и угрозы Переход от взаимных обвинений к поиску возможности сотрудничества Поиск решения: перераспределение обязанностей, полномочий, ресурсов … Примерение сторон Как правильно запустить и закончить проект (правила Ашманова) Решение о запуске проекта должны принимать ответственные лица Для начала проектов нужно использовать процедуру запуска проектов Без энтузиаста любой проект мертв Проект нельзя обсуждать без обоснования Не бывает проекта без руководителя Руководитель должен быть один Проект нельзя запускать без ресурсов В начале проекта всегда бывает торможение. Чтобы преодолеть его нужны терпение и настойчивость Вполнакала проекты не делаются Только коррекцией проекта в контрольных точках можно удержать проект от срывов Неправильный проект и его лечение (правила Ашманова) Риск неудачи всегда есть Наведение порядка в проекте всегда начинается с головы Важно вовремя узнать паттерн неудачного проекта – симптомы надвигающейся болезни Когда в проекте идет что-то не так, начальство предпринимает титанические бесполезные усилия по наведению порядка Бессмысленно муштровать исполнителей, нужно муштровать менеджеров … Основные документы для управления проектами 1 – Устав проекта. Этот документ будет гарантировать, что вы и ваш клиент понимаете общие цели проекта. Чтобы получить эту информацию, встретьтесь с вашим клиентом и задайте 3 основных вопроса: Каковы цели вашего проекта? Что вы хотите производить или поставлять? Какое основание для этого проекта? После встречи запишите ответы на эти вопросы в Уставе проекта, отправьте это обратно клиенту и попросите его подтверждения. 2 – Детализированный план проекта. Он будет включать в себя перечень работ, которые необходимо сделать, кто будет это делать, стоимость работы, обзор того, что может пойти не так-«Оценкой риска». 3 – Отчет о проделанной работе. Постоянно и обо всём, еженедельный и месячный отчёт о проделанной работе, который необходимо предоставлять вашему клиенту. Они хотят знать, какая работа была сделана, когда и сколько было на это потрачено. Ваша основная задача просто сбор этой информации, так что регулярно составляйте отчёт о проделанной работе. Корпоративная система управления проектом (КСУП) Понятие КСУП КСУП – комплекс организационных, методических и информационных средств, поддерживающих управление проектами в организации Для чего компании создают корпоративную систему управления проектами? В любой организации собираются люди с различным опытом, в том числе и с опытом управления проектами. Введение единого регламента (методологии), шаблонов, глоссария позволяет подвести общий знаменатель под этот опыт, ввести единое понятийное и информационное пространство, что существенно повышает взаимодействие и взаимопонимание в проектах. Цели внедрения КСУП Стандартизовать управление проектами компании, повысить прозрачность проектной деятельности Усилить контроль над проектной деятельностью и повысить качество управления проектами Накапливать, систематизировать и эффективно использовать опыт компании в управлении проектами Целевые эффекты проекта 1 2 3 4 • Единая система планирования и контроля • Система оценки результативности проектов • Механизм управления проблемами проектов • Подготовка, согласование и контроль исполнения бюджетов проектов Преимущества внедрения КСУП по оценке зарубежных экспертов Сокращение сроков реализации проектов на 25-35% Сокращение бюджетов на реализацию проектов на 20-25% Снизить трудозатраты функциональных руководителей на управление проектами на 25-75% Повысить оперативность принимаемых решений на 2-4 недели Сократить время составления отчетов по проектам на 50-85% Повысить эффективность управления рисками на 20-25% Составляющие КСУП Стандарт управления проектами Регламенты и процедуры Методики и инструкции Организационные структуры проектов Роли и должностные инструкции Информационная система управления проектами ПО для корпоративного планирования и контроля ПО для корпоративного документооборота Настроенные рабочие места Интеграционные модули с другими корпоративными ИС Внедрение КСУП: этапы проекта Этап 1 Этап 2 Разработка концептуал Разработка ьного регламенто решения в взаимодейс твия при реализации проектов Этап 3 Этап 4 Формирова ние Развертыва проектного ние ИСУП офиса Этап 5 Внедрение ИСУП 1 этап: Разработка концептуального решения Концепция КСУП План развертывания КСУП Защита концепции 2 этап: Разработка регламентов взаимодействия Стандарт компании по управлению проектами Регламенты и процедуры Ролевые инструкции Набор типовых шаблонов проектов Регламент (методология) должен содержать (как минимум) требования к инициации, планированию, контролю исполнения и завершению проектов. В регламенте (методологии) должны быть описаны процедуры контроля изменений в проектах. Минимальный набор шаблонов: Устав проекта, Описание содержания, План управления проектом, Запрос на именение, Шаблон закрытия проекта (фазы). 3 этап: Формирование проектного офиса Сформированное подразделение проектного офиса Положение о подразделении Должностные инструкции персонала 4 этап: Развертывание ИСУП Настроенные функциональные рабочие места и сервеве ИСУП Основная ошибка внедрения КСУП заключается в том, что внедрение начинается с инсталляции информационной системы управления проектами. Вначале нужно создать проектный офис, регламент (методологию) управления проектами и только потом (можно и одновременно) выбирать и инсталлировать ИСУП, как вспомогательное средство. ИСУП - не главный и не первоочередной компонент. ИСУП помогает проектному офису и управляющему комитету реализовывать методологию управления проектами. Проектный офис в структуре организации Проектный офис и офис проекта Проектный офис – центр управление проектами компании Офис проекта – центр управления одним проектом, обеспеченный необходимыми ресурсами и возглавляемым менеджером проекта. Проектный офис – является постоянно действующей единицей (при этом лишь часть сотрудников может работать на постоянной основе), а офис проекта – временной структурой. Задачи проектного офиса Варианты расположения проектного офиса в компании Функции проектного офиса: Планирование и контроль работ в соответствии с заданными сроками Создание, развитие и контроль исполнения корпоративного регламента (методологии) управления проектами. Аналитическая и методологическая помощь руководителям проектов. Организация обучения персонала и менеджеров. Ведение архивов проекта, накопление опыта компании. Администрирование и поддержка ИСУП. Подготовка отчетов о проектах руководству. Управление ресурсами в проектах.
