Руководство по управлению проектами для профессионалов в
реклама
Руководство по управлению проектами для профессионалов в сфере развития (PMD Pro) Документ опубликован разработчиками «PM4NGOs» («Управление проектами для неправительственных организаций») © Copyright 2011 PM4NGOs ISBN: 978-0-9962090-2-1 «PMD Pro» и символы «PMD Pro» являются торговыми марками «PM4NGOs». Информация о публикации: Это рецензированное «Руководство по управлению проектами для профессионалов сферы развития» (PMD Pro). Версия 1.3 от 26 марта 2012 года (последующая после пилотной) Предшествующие версии и история издания: Версия 1.2 от 5 марта 2012 –заменена. Версия 1.1 от 8 февраля 2012 –заменена. Версия 1 от 9 декабря 2011 –заменена. Guide to the PMD Pro стр. 2 из 12 Выражение признательности Этот документ был разработан при поддержке целого ряда экспертов, которые внесли свой вклад в создание, рецензирование и редактирование «Руководства». Среди них, мы выражаем особую благодарность Крису Каттавей, Роджеру Стил, Берни Ледбитер, Джону Фишеру, Джону Дэвидсону, Алану Харфарм, Лиз Берриман, Каталин Ханникер, Джону Кроппер, Анне Кондакчан, Эрике Берг, Ричарду Кондоу, Годфри Калиббала, Хуану Мануэль Паласиос, Дарио Моцци, Адонису Сукалит, Джерон Боллужит, Трейси Стов, Бобу Юкер, Фелипе Чапарро, Линн Каррен, Гретхен Регер, Родольфо Силес, Наоми Джонс, Джефф Райс, Гай Шаррок, Амос Думбос, Роберту Суитман, Мари-Лор Кюри, Дэвиду Палазитс, Саймону Ирли, Вадиму Узвитскому, Карен Коннер, Мариан Абернети, и Терри Исэ. Также, мы выражаем признательность за поддержку сотрудникам и добровольцам, связанным с Образовательным Фондом Института Управления Проектами, чья помощь имела важнейшее значение для создания учебных материалов, связанных с «Руководством». Мы также обязаны многим организациям, на документы и материалы которых были сделаны ссылки, и которые были адаптированы для использования в «Руководстве PMD Pro1». Мы хотели бы выразить особую признательность Католической Службе Помощи за их неоценимую серию документов «ProPack», организации «World Vision International» за документы «Обучение оценке и планированию» (LEAP), а также Европейской Комиссии за документ «Правила оказания помощи», из которых широко использовались примеры для изучения практики. Мы также благодарим Международный Институт Обучения, компанию «True Solutions Inc.» и компанию «Versatile» за их щедрое предоставление учебных материалов и поддержку. Полный список литературы можно найти в конце документа. Наконец, эта деятельность была бы невозможна без вдохновения и поддержки, оказанной Ричардом Фарро и его командой из «APM Group». Только благодаря их финансовой, организационной и технической поддержке это стало возможным. Майкл Куллиган, Стивен Маркс, Тревор Нельсон, Лия Радстон, и Эрик Верзух. Guide to the PMD Pro стр. 3 из 12 Содержание Информация о публикации: ................................................................................................................................... 2 Введение .................................................................................................................................................................. 6 Раздел. 1. Проекты в секторе развития. ........................................................................................................ 10 1.1. Управление проектами требует напряжения сил и стойкости. ................................................. 10 1.2. Вы не одиноки! .................................................................................................................................... 11 1.3. Терминология. ..................................................................................................................................... 12 1.4. Проекты, программы и портфели. .................................................................................................. 14 1.5. Искусство и наука управлять проектами. ..................................................................................... 15 1.6. Модель компетентности управления проектами «PMD PRO». ................................................ 16 Раздел 2. Фазы срока действия проекта развития. ...................................................................................... 19 2.1. Сбалансированное управление проектом в течение срока действия проекта. ...................... 19 2.2. Модель фаз проекта «PMD Pro» ...................................................................................................... 19 2.2.1. Фаза 1. Идентификация и разработка проекта. ....................................................................... 22 2.2.1.1. Сбор данных. ................................................................................................................................ 24 2.2.1.1.1. Определение потребностей проекта. ................................................................................... 24 2.2.1.1.2. Виды данных. ........................................................................................................................... 26 2.2.1.2. Анализ данных. ........................................................................................................................... 28 2.2.1.2.1. Анализ текущего состояния. ................................................................................................. 28 2.2.1.2.2. Анализ будущего состояния. ................................................................................................. 29 2.2.1.3. Определение логики внедрения проекта. .............................................................................. 31 2.2.1.3.1. Варианты логической структуры проекта. ....................................................................... 31 2.2.1.3.2. Интерпретация матрицы логической структуры. ........................................................... 32 2.2.1.4. Управление проектными решениями. ................................................................................... 36 2.2.2. Фаза 2. Открытие проекта. .......................................................................................................... 39 2.2.2.1. Цель ............................................................................................................................................... 39 2.2.2.2. Создание структуры руководства проектами. ...................................................................... 39 2.2.2.3. Официальное разрешение начала проекта............................................................................ 41 2.2.2.4. Сообщение о запуске проекта. .................................................................................................. 42 2.2.3. Фаза 3. Планирование проекта. .................................................................................................. 43 2.2.3.1. Цель ............................................................................................................................................... 43 2.2.3.2. Планирование реализации проекта должно быть сбалансированным. .......................... 45 2.2.3.3. Планирование должно быть всесторонним. .......................................................................... 45 2.2.3.4. Планирование реализации должно быть интегрированным. ........................................... 47 2.2.3.5. Планирование реализации должно быть совместным. ....................................................... 47 2.2.3.6. Планирование является повторяющимся процессом. ........................................................ 48 2.2.4. Фаза 4. Реализация проекта. ........................................................................................................ 49 2.2.4.1. Управление проблемами. .......................................................................................................... 49 2.2.4.2. Управление людьми. .................................................................................................................. 51 2.2.4.3. Управление системами внутреннего контроля. ................................................................... 52 2.2.5. Фаза 5. Мониторинг, оценка и контроль. ................................................................................. 53 2.2.5.1. Дифференциация мониторинга, оценки и контроля. .......................................................... 54 2.2.5.2. План мониторинга и оценки проекта. .................................................................................... 55 2.2.5.3. Подход к оценке проекта. .......................................................................................................... 58 2.2.5.4. Контроль проекта. ...................................................................................................................... 58 2.2.5.5. Изменения проекта: допустимость и изменение полномочий по решению проблем.... 59 2.2.6. Фаза 6. Переходный период проекта после завершения. ....................................................... 62 2.2.6.1. Стратегия управления проектом в переходный период. .................................................... 63 2.2.6.2. Проверка объема и содержания проекта и принятие ожидаемых результатов. ............ 64 2.2.6.3. Полное административное, финансовое и контрактное закрытие. .................................. 64 2.2.6.4. Изученный опыт на момент окончания проекта. ................................................................ 65 2.2.6.5. Празднование достижений. ....................................................................................................... 65 Guide to the PMD Pro стр. 4 из 12 Раздел 3. Дисциплины управления проектами............................................................................................ 66 3.1. Дисциплина 1. Управление деятельностью проекта. ................................................................. 66 3.1.1. Определение содержания продукции и проекта. ...................................................................... 67 3.1.2. Инструменты для определения сферы деятельности проекта. ............................................. 68 3.2. Дисциплина 2. Управление временем. .......................................................................................... 70 3.2.1. Определение деятельности и ее последовательности. ............................................................. 71 3.2.2. Оценка ресурсов для осуществления деятельности. ............................................................... 72 3.2.3. Оценка продолжительности деятельности. ............................................................................... 72 3.2.4. Разработка плана-графика. .......................................................................................................... 73 3.2.5. Управление планом-графиком проекта. .................................................................................... 75 3.3. Дисциплина 3: управление ресурсами проекта. ........................................................................... 77 3.3.1. Почему эффективное управление ресурсами так важно? ...................................................... 77 3.3.2. Управление финансами проекта. ................................................................................................ 78 3.3.3. Разработка бюджета. ...................................................................................................................... 79 3.3.4. Бюджетирование на основе видов деятельности. ..................................................................... 80 3.3.5. Определение смет. ........................................................................................................................... 81 3.3.6. Мониторинг финансового исполнения проекта. ...................................................................... 82 3.3.6.1. Контроль затрат проекта через анализ освоенного объема. .............................................. 84 3.3.7. Управление поставками. ............................................................................................................... 85 3.3.7.1. Управление закупками. ............................................................................................................. 86 3.3.7.1.1. Планирование закупок. ......................................................................................................... 87 3.3.7.1.2. Определение поставщиков.................................................................................................... 87 3.3.7.1.3. Выбор, переговоры и заключение контрактов. ................................................................ 87 3.3.7.2. Управление логистикой (материально-техническим обеспечением)............................... 88 3.3.7.2.1. Управление запасами и складами. ...................................................................................... 88 3.3.7.2.2. Транспортировка материалов. ............................................................................................. 88 3.3.7.3. Управление активами. ............................................................................................................... 88 3.3.8. Управление кадрами. ..................................................................................................................... 89 3.4. Дисциплина 4. Управление рисками. ............................................................................................. 90 3.4.1. Идентификация риска. .................................................................................................................. 91 3.4.1.1. Определение категории риска.................................................................................................. 91 3.4.1.2. Определение конкретных рисков. ........................................................................................... 92 3.4.2. Оценка риска. .................................................................................................................................. 93 3.4.3. Ответные меры на риски. ............................................................................................................. 94 3.4.4. Мониторинг и контроль риска. ................................................................................................... 96 3.5. Дисциплина 5. Управление обоснованием проекта. .................................................................... 96 3.5.1. Определение потребностей по проблемам или активам. ........................................................ 96 3.5.2. Переход от проблем к стратегии внедрения. ............................................................................. 97 3.6. Дисциплина 6. Управление заинтересованными сторонами. ................................................. 100 3.6.1. Идентификация заинтересованных сторон. ............................................................................ 101 3.6.2. Анализ заинтересованных сторон. ............................................................................................ 102 3.6.3. Вовлечение заинтересованных сторон. .................................................................................... 104 3.6.4. Обмен информацией с заинтересованными сторонами. ....................................................... 105 Раздел 4. Адаптация “PMD Pro” ................................................................................................................... 107 4.1. Основы адаптации ............................................................................................................................ 107 4.2. Факторы для рассмотрения при применении «PMD PRO». .................................................... 108 Раздел 5. Приложения ..................................................................................................................................... 112 5.1. Приложение 1. Термины и определения. .................................................................................... 112 5.2. Приложение 2. Результаты изучения «PMD PRO» ................................................................... 115 5.3. Приложение 3. Список использованной литературы. .............................................................. 127 Guide to the PMD Pro стр. 5 из 12 Введение Изменение мира через проекты Как вы мечтаете изменить мир? Копать колодцы, чтобы обеспечить питьевой водой деревни? Создавать микро банки, которые помогают женщинам выбраться из бедности? Защищать находящиеся под угрозой исчезновения экологические системы? Восстанавливать школы? Создавать сельские клиники в общинах, где их нет? Распределять продукты голодным? Не удивительно, что мало, кто ответит "Я бы хотел управлять проектами!" И все же, в то время как миллионы работников в сфере развития изменяют мир каждый день через деятельность в сельском хозяйстве, здравоохранении, микрофинансировании, сохранении природы, жилищном строительстве, образовании, в сфере инфраструктуры и прав человека, все они имеют нечто общее, что объединяет их: они изменяют мир через проекты! Организации развития управляют своей работой через проекты. Они имеют сотрудников, которые руководят коллективами проектов. Их сотрудники пишут проектные предложения, разрабатывают проектные планы, отслеживают ход выполнения проекта, оценивают воздействие проекта. Затем, что самое главное, бенефициарные сообщества, получатели помощи вкладывают свое время, энергию и ресурсы в проекты. Они вверяют исполнение проектов коллективной силе для укрепления тех областей жизни, где есть сравнительные слабости, для решения проблем, которые в другом случае могли бы быть рассмотрены без их участия и контроля. И все же, в то время как средства к существованию сотен миллионов людей зависят от способности организаций развития эффективно доставлять результаты проектов, управление проектами редко определяется как стратегический приоритет этих организаций. Как правило, организации развития сосредоточены на технических программных областях своих проектов. Организации обычно нанимают программных специалистов (агрономов, специалистов общественного здравоохранения, экономистов и т.д.), которых затем просят управлять проектами и возглавлять проектные коллективы. Эти программные специалисты, как правило, имеют большой опыт в определении правил лечения болезней, в разработке учебных программ для школ и усовершенствованных сельскохозяйственных систем, а также в анализе причин бедности. Однако они не так часто имеют большой опыт и навыки в области управления проектами. Правильны ли проектные расчеты? Учтены ли риски, и тщательно ли они контролируются? Являются ли планы проекта всеобъемлющими и подробными? Отслеживается ли ход реализации проекта на всех уровнях? Определены ли проблемы, отслеживаются и решаются ли они? И все ли аспекты проекта активно управляются на протяжении всего срока реализации проекта? Достигаются ли социальные изменения, на которые проект рассчитан? Целью «Руководства PMD Pro» является повышение квалификации профессионалов в сфере управления проектами в области развития. «Руководство» представляет собой контекстуальный, сбалансированный, всеобъемлющий и адаптированный источник информации, помогающий повышению эффективности и результативности проектов в секторе развития. «Руководство PMD Pro» дает начальное независимое исследование управления проектами в контексте сектора развития. Оно предназначено для аудитории, которая включает в себя: • Менеджеров проектов и сотрудников, которые являются новичками в управлении проектами; • Менеджеров проектов и сотрудников, которые являются новичками в секторе международного развития; • Профессионалов сектора международного развития, которые намерены получить профессиональные полномочия в области управления проектами; • Консультантов и сотрудников, работающих по контрактам в сфере международного развития. Guide to the PMD Pro стр. 6 из 12 Как организовано данное «Руководство». «Руководство» состоит из четырех разделов. Раздел Первый: Проекты в секторе развития. Проекты пронизывают культуру организаций развития. В результате, управление проектами является одной из важнейших компетенций специалистов развития. Часть Первая представляет собой вводный обзор проектов в данном секторе, отвечая на вопросы: • Почему проекты имеют значение? • Как определить проекты и управление проектами? • Как проекты вписываются в более широкую стратегическую культуру организаций развития? • Какова роль / ответственность руководителя проекта и проектного коллектива? • Какие компетенции необходимы, чтобы быть успешным менеджером проектов? Раздел Второй: Этапы проектов развития. В управлении проектами, как и в жизни, секрет успеха заключается в сбалансированном подходе. Во втором разделе «Руководства» рассматривается важность сбалансированного управления проектами на протяжении всего жизненного цикла проекта. После краткого вступления вводится понятие фазы (или этапа) в жизни проекта. Раздел 2 «Руководства» рассматривает каждый из шести этапов в жизни проекта, в том числе: • Определение и разработку проекта. • Учреждение или открытие проекта. • Планирование проекта. • Реализацию проекта. • Мониторинг, оценку и контроль над проектом. • Переходный период проекта по завершению. Раздел Третий: Дисциплины управления проектами. Чтобы добиться успеха руководителям проектов в секторе развития необходимо разработать целый ряд управленческих дисциплин, которые должны применяться в течение всего срока реализации проекта. Часть третья рассматривает шесть различных дисциплин для руководителей проектов в секторе развития, в том числе такие дисциплины, как: • Управление сферой деятельности проекта. • Управление временем. • Управление ресурсами проекта. • Управление рисками. • Управление обоснованием проекта. • Управление заинтересованными сторонами. Раздел 4. Адаптация «PMD Pro». «Руководство PMD Pro» НЕ является шаблоном, который следует применять без разбора ко всем проектам и всем организациям. Важно помнить, что каждая организация развития является уникальной. Кроме того, в рамках одной организации проекты будут значительно различаться в стоимостном выражении, по сложности и рискам. Даже в ситуации, когда два проекта, кажется, похожи, условия, в которых реализуются проекты, являются непредсказуемыми, и реальность на местах может значительно отличаться от сценария ожиданий, которые были заложены в план месяцем раньше. Признавая, что организации развития и их проекты являются уникальными, Раздел 4 рассматривает подходы, которые руководители проектов могут использовать для адаптации «Руководства PMD Pro» к контексту, в котором их проекты работают. Guide to the PMD Pro стр. 7 из 12 Пять принципов управления проектами в секторе развития. По мере чтения «Руководства для PMD Pro» читатели увидят выделенные текстовые поля, которые относятся к ключевым концепциям, которые «PMD Pro» определяет как «Пять принципов управления проектами в секторе развития». Каждое поле содержит краткую аннотацию, тематическое исследование или наблюдение, которое подчеркивает важность включения принципов в разработку, планирование и реализацию проектов развития. Иллюстрация 1. Пять принципов «PMD Pro» в управлении проектами. Сбалансированное управление проектами - проекты должны осуществляться на сбалансированной основе, с одинаковой тщательностью на всех этапах жизненного цикла проекта. Всестороннее управление проектами - дисциплины управления проектами должны применяться последовательно и сознательно в управлении всеми работами проекта на протяжении всего срока проекта. Интегрированное управление проектами - все аспекты управления проектами должны быть согласованы и скоординированы в качестве средства обеспечения спокойной и бесперебойной реализации всех элементов разработки, планирования и мониторинга проекта. Совместное управление проектами – управление включает различных заинтересованных сторон в определение, проектирование, планирование, осуществление и мониторинг проектов, что помогает обеспечить прозрачность, улучшить качество, повысить человеческий потенциал и укрепить совместное участие на всех уровнях. Итеративное управление проектами – многократный пересмотр и повтор процессов управления проектами в течение всего срока реализации проекта, чтобы убедиться, что разработка проекта, проектные планы и целевые результаты по-прежнему актуальны. Эта практика также дает возможность повысить точность текущей оценки и расчетов проекта и планировать дальнейшие шаги в рамках проекта. Программа сертификации PMD Pro В любой отрасли, которая полагается на проекты для завершения работы, сертификация гарантирует, что управляющие лица готовы эффективно управлять своими проектами в любой стране мира. «Руководство по управлению проектами для НПО» (PM4NGOs), издатель «Руководства PMD Pro», предлагает трехуровневую программу сертификации для практиков, работающих в секторе развития. Таблица в Иллюстрации 2 показывает структуру и содержание Программы сертификации PMD Pro1. Три уровня сертификации по программе сертификации «PM4NGOs»: Сертификация 1-го уровня. Сертификации требует, чтобы проектные практики успешно прошли сертификационный экзамен «PMD Pro 1». Это тест из 75 вопросов, который выполняется через Интернет, требующий, чтобы кандидаты продемонстрировали, что они знают и понимают содержание «Руководства PMD Pro». Учебные задачи по экзамену «PMD Pro 1» содержатся в Приложении 2 к «Руководству PMD Pro». Сертификация 2-го уровня. Второй уровень Сертификации «PM4NGOs» преследует две цели: 1. Получение полномочий для контекстуального управления проектами в сфере развития. 2. Получение базовых знаний или платформы, с которой практикующие специалисты в сфере развития могут продолжить повышение своей квалификации в области управления проектами через получение международно-признанной профессиональной квалификации. Помня об этом, кандидаты на сертификацию Уровня 2 должны получить две квалификации: 1 Подробности о Программе Сертификации PMD Pro можно посмотреть на сайте: www.pm4ngos.org Guide to the PMD Pro стр. 8 из 12 Сертификат PMD Pro2 – экзамен по «PMD Pro2» проходят по Интернету. От кандидата требуется показать умение применять и анализировать содержание «Руководства PMD Pro». Каждый из вопросов экзамена по «PMD Pro2» базируется на сценариях проектов развития и предназначен для тестирования обучающих задач «PMD Pro2», приведенных в Приложении 2 к «Руководству PMD Pro». Начальный уровень квалификации, подтвержденной независимым, международнопризнанным сертифицирующим органом. Существует целый ряд сертификатов, дающих полномочия профессионалам, работающим с проектами, и подтверждающих их профессиональный уровень в области управления проектами. К ним относится аттестат «CAPM» Института Управления Проектами, аттестат Фонда «Prince2» от APMG, сертификат IPMD Уровня D, и многое другое. От кандидатов 2-го уровня сертификации ожидается выполнение и получение, как минимум, одного из этих сертификатов начального уровня. Независимо от конкретного отдельного выбранного сертификата, цель получения независимой и международно-признанной квалификации - создать связь между конкретным обучением по «PMD Pro» и обширной совокупностью знаний, имеющихся у менеджеров проектов, работающих в других секторах. Примечание: не существует обязательного порядка, в котором сертификаты 2-го уровня должны быть получены. Однако кандидаты на сертификацию Уровня 2 должны завершить 1-й уровень сертификации «PMD Pro» до прохождения сертификации «PMD Pro2». Сертификация 3-го уровня. Сертификация 3 уровня находится в стадии разработки и будет оценивать, в какой степени кандидаты на «PMD Pro3» применяют содержание «Руководства по PMD Pro» в своих проектах развития. В дополнение к завершению контекстуальной сертификации по «PMD Pro3» кандидаты на 3-й уровень должны продолжать развитие своего профессионального карьерного роста посредством получения более высокой квалификации от независимого, международно-признанного органа сертификации, такого как, например, сертификат РМР Института Управления Проектами, сертификат IPMA уровня C, или сертификат практика «Prince2». Контекстуальный PMD Pro 3 Как минимум «PMP», «IPMA» уровень C или «Prince 2 Practitioner» Контекстуальный PMD Pro 2 Как минимум «САРМ», «IPMA» уровень D или «Prince 2 Foundation» Контекстуальный PMD Pro 1 Уровень 3 Уровень 2 Уровень 1 Иллюстрация 2. Программы сертификации PMD Pro Guide to the PMD Pro стр. 9 из 12 Раздел. 1. Проекты в секторе развития. 1.1. Управление проектами требует напряжения сил и стойкости. Управление проектами в секторе развития далеко не простое дело. Операционная среда носит комплексный характер. Проблемы многочисленны. Отношения в проекте сложные. И цена ошибки велика. Короче говоря, есть многое, что может пойти не так! Представленные иллюстрации показывают лишь некоторые из многих проблем, которые могут поставить под угрозу успех проекта развития. Каждое изображение демонстрирует лишь один из многих сценариев, который может произойти, если разработка, планирование или реализация проекта плохо продуманы, или плохо исполнены. К сожалению, перечень проблем, представленных в Иллюстрации 3, не исчерпывающий. Есть много, много более того, что «может пойти не так» в проекте развития. Например, возникает вопрос: имеется ли стабильный обменный курс? Является ли динамика коллектива функциональной? Дает ли система мониторинга полезную, точную и своевременную информацию? Поставщики проекта надежные? Есть ли политическая нестабильность? Существуют ли заинтересованные стороны, которые подрывают проект? Чтобы добиться успеха, руководитель проекта должен активно и решительно управлять этими проблемами. Слишком часто неудавшиеся проекты списываются на обстоятельства, которые были «вне нашего контроля». Иногда это объяснение может быть действительным, но слишком часто оно используется в качестве предлога, и не признает, что следовало предвидеть риски, анализировать их и активно управлять ими. Иллюстрация 3. Проектные риски в секторе развития. Неправильное, неадекватное понимание потребностей Неадекватные ресурсы Неадекватные возможности Guide to the PMD Pro Плохая разработка проекта Задержки в работе проекта Нереальный бюджет Нереальные ожидания Стихийные бедствия Материалы низкого качества стр. 10 из 12 Чтобы сохранить контроль над своими проектами, и тем самым способствовать успеху проекта, руководителям проекта необходимо развивать навыки, необходимые для эффективного выявления проблем, которые могут повлиять на их проект, и эффективно управлять своими проектами, даже если эти проблемы возникают. Это те навыки, которые мы рассмотрим в «Руководстве PMD Pro». 1.2. Вы не одиноки! В то время как задачи, стоящие перед проектами развития, обширные и сложные, они ни в коем случае не являются исключительными для проектов, управляемых в секторе развития. Возьмем, к примеру, информацию, представленную в графике и сопроводительной таблице Иллюстрации 4. Каждый год Группа Стендиш проводит исследование под названием «Отчеты о хаосе», собирая мнения более чем 10000 проектов по информационным технологиям (ИТ). В отчете определяется процент проектов ИТ, оцениваемых, как успешные, проблемные или не удавшиеся2. Год за годом результаты «Отчетов о хаосе» показывают, что большинство ИТ проектов, опрошенных Группой Стендиш, оценивается, как проблемные или неудавшиеся, и только относительно небольшой процент считается успешным. В 2008 году, например, процент успешных проектов составил 32%; неудачных (которые определились в результате прекращения проекта в середине срока) - 24%, а оставшиеся 44% проектов были завершены, но имели перерасход средств, задержки по срокам и/или не смогли поставить все товары или услуги по проекту. Следует заметить, что «Отчеты о хаосе» не рассматривают проекты развития. Исследования были разработаны и проведены фирмой, предоставляющей услуги по изучению результатов проектов в сфере ИТ. Тем не менее, результаты доклада полезны тем, что они подчеркивают проблемы реализации успешных проектов, и они предоставляют данные, которые помогают нам ответить на ключевой вопрос: «Каковы ключевые проблемы, которые приводят к проблемным и неудачным проектам?» Согласно анализу «Отчета о хаосе» за 2009 год существуют три проблемы, которые наиболее часто приводят к проблемным проектам3: 1. Неполные требования и спецификации. 2. Отсутствие планирования управления рисками. 3. Неспособность учиться на ошибках. Звучит знакомо? Что поражает в анализе проблемных проектов в секторе ИТ, так это то, насколько они аналогичны проблемам в секторе развития. В конце концов, несмотря на множество 2 Успешные - проекты выполняются в полном объеме, в соответствии с бюджетом и сроками. Проблемные - проекты завершены, но не соответствуют первоначальному объему, бюджету или срокам. Неудавшиеся - проекты прекращены досрочно. 3 С другой стороны «Отчет о хаосе» указывает, что, скорее всего, определителями успеха проекта были такие вещи как участие пользователя, поддержка исполнительного руководства и четкое изложение требований. Guide to the PMD Pro стр. 11 из 12 различий между секторами, которые управляют своей работой в первую очередь через проекты (например, в строительстве, телекоммуникациях, информационных технологиях, разработке программного обеспечения и т.п.), эти проекты имеют схожие проблемы, в том числе такие как: 1. Доставка результатов проектов в контексте ограничений по времени, бюджету, качеству, возможностям, рискам и общественной пользы. 2. Разработка комплексных и подробных планов проектов и управление ими в течение всего срока проекта. 3. Управление проектами, которые часто выполняются с помощью подрядчиков, субподрядчиков и поставщиков. 4. Выявление потенциальных рисков и создание процессов для избежания этих рисков и обеспечения, чтобы был получен предполагаемый общий полезный результат или экономический эффект проекта. Однако, несмотря на общие черты, которые существуют между этими секторами, есть некоторые особенности, которые делают управление проектами в секторе развития уникальным и, порой, особенно сложным. Некоторые из этих уникальных характеристик: • Проекты развития несут ответственность не только за доставку ощутимых результатов, но и за доставку менее ощутимых результатов, связанных с социальными переменами и/или изменением поведения. Проекты развития меньше ориентированы на достижение конкретных продуктов, чем на конечные цели проекта. Вместо этого, они считают эти продукты средством, которое приводит к улучшению благосостояния целевого населения проекта. • Проекты развития направлены на решение сложных проблем нищеты, неравенства и несправедливости. • Проекты развития, как правило, работают в исключительно сложных условиях (ограниченность ресурсов, высокие риски, сложные сети закупок, нестабильные политические и финансовые условия, небезопасная окружающая среда). • Реализация проекта часто управляется через сложный комплекс отношений с заинтересованными сторонами (учреждениями партнеров, министерствами, общественными организациями, подрядчиками, глобальными консорциумами). • Проектный подход зачастую также важен, как сами результаты (в том числе высокий приоритет подхода, основанного на совместном участии и правах участников). • Передача знаний и обучения целевых групп населения является одним из приоритетных подходов во время каждой фазы проекта. 1.3. Терминология. Но мы забегаем вперед. Прежде чем продолжить обсуждение проблем, связанных с управлением проектами в отрасли развития, важно сначала определить некоторые ключевые термины4. Проект представляет собой временные усилия, предпринятые, чтобы создать уникальный продукт, услугу или результат5. Если взять за основу это определение, цель управления проектами заключается в планировании, организации и управлении ресурсами для успешного достижения конкретных целей, результатов и продуктов проекта. Практика всестороннего квалифицированного управления высокого качества является незаменимой, помогающей организациям управлять целенаправленными, эффективными и производительными проектами. В контексте управления проектами руководитель (менеджер) проекта несет ответственность за обеспечение общего успеха проекта. Однако это не означает, что руководитель проекта несет персональную ответственность за завершение работ по проекту. В самом деле, это бывает редко в секторе развития. Вместо этого, ответственностью руководителя проекта является тесное сотрудничество с кругом заинтересованных сторон для завершения работ по проекту. Эти заинтересованные стороны включают членов коллектива проекта, организации исполнителей, подрядчиков, общественные группы и других лиц, которые должны работать совместно для 4 См. Словарь терминов с подробными определениями в «Руководстве PMD Pro». Руководящие принципы совокупности знаний (A Guide to the Project Management Body of Knowledge) (PMBOK Guide), 3-е издание, Институт Управления Проектами. 5 Guide to the PMD Pro стр. 12 из 12 разработки, осуществления и контроля над всеми аспектами проекта. Как и во многих секторах, от менеджеров проектов в секторе развития часто требуется управлять заинтересованными сторонами, с которыми они не имеют официальных иерархических отношений. Очень часто заинтересованные стороны в рамках одного проекта имеют разную этническую принадлежность, разные языки, культуру и национальности. Задача управления группами в рамках такого контекста может быть особенно сложной. На практике задача руководителя проекта по успешному осуществлению проекта всегда будет решаться в контексте проектных ограничений. Исторически сложилось, что существует три главных элемента, которые ограничивают проекты, которые совместно именуются «тройное ограничение». Чтобы понять тройное ограничение, представьте себе треугольник, где каждая сторона обозначена следующим образом: Иллюстрация 5. Треугольник ограничительных условий. Объем / Качество: какие товары / услуги будет производить проект, и какая работа необходима для получения результатов? Затраты / Ресурсы: какими деньгами, материалами и усилиями можно реализовать проект для получения продуктов / услуг и завершения всех комплексных работ по проекту? Время / План-график: сколько времени необходимо для завершения компонентов проекта? Работа руководителя проекта заключается в том, чтобы обеспечить, чтобы треугольник тройного ограничения оставался сбалансированным. Каждое из ограничивающих условий связано с другим. Всякий раз, когда одно из этих условий расширяется или ограничивается, другие ограничительные условия также должны быть расширены или ограничены. Руководитель проекта должен понимать взаимосвязь и компромиссы, которые существуют между ограничительными условиями. Классификация трех основных ограничительных условий: Негибкость указывает на то, что ограничивающее условие имеет решающее значение и должно быть обязательным. Адаптация указывает на то, что ограничивающее условие является предметом переговоров, но должно быть оптимизировано, насколько возможно. Допустимость означает ограничивающее условие, при котором можно пойти на компромисс, чтобы управлять негибким ограничением или оптимизировать адаптируемое ограничение. Уточняя классификацию каждого из ограничительных условий, руководитель проекта может вступить в переговоры с участниками проекта для совместного обсуждения и расстановки приоритетов. Важно договориться и согласовать приоритеты со всеми заинтересованными сторонами в самом начале проекта. Пытаться договориться о компромиссах после того, как проект начался, часто бывает очень трудно или невозможно. Как только люди укрепляются в своем понимании компромисса о запланированных задачах и названных ресурсах, требуется гораздо больше усилий и становится гораздо сложнее изменить эти компромиссы. Guide to the PMD Pro стр. 13 из 12 1.4. Проекты, программы и портфели. В рамках лексики развития часто используются термины «проект», «программа» и «портфель», но не всегда со всей строгостью и точностью. Иногда эти термины используются даже как взаимозаменяемые. При отсутствии последовательного и точного определения этих терминов роли и обязанности руководителей проектов в том, как они относятся к каждому из этих уровней управления, могут быть неясны, и могут быть неправильно истолкованы. Управление проектом - это дисциплина планирования, организации и управления ресурсами в целях успешной реализации конкретных целей, результатов и продуктов. Основная задача управления проектом - достижение всех целей проекта, результатов и продуктов с учетом заранее установленных ограничений проекта, касающихся объема и содержания работ, бюджета, сроков и качества. Управление программой - это процесс согласованного управления группой связанных проектов для достижения общего полезного результата или экономического эффекта и контроля, которые невозможны при управлении ими по отдельности. Программы, в отличие от проектов, часто управляются с помощью централизованного управления, целью которого является координация группы проектов для достижения стратегических целей и результатов программы. Управление программами особенно важно в рамках сектора развития, поскольку проекты, управляемые по согласованной программе, имеют потенциал реализовать изменения (или достичь общего полезного результата), которые были бы невозможны, если бы эти проекты управлялись по отдельности. Некоторые области потенциального группирования программ: • Географический район - проекты часто работают бок о бок в одном регионе или в стране, и одной из центральных задач руководителя программы является сбалансировать ресурсы нескольких проектов, работающих в одном географическом районе, чтобы они использовались с наибольшим результатом, чем в каждом из них по отдельности. Обычно программы работают в одной стране, хотя все чаще программы охватывают несколько стран или имеют глобальный характер. • Область внедрения - в то время как проекты, как правило, работают в одной отрасли в короткие сроки, программы часто охватывают несколько секторов и работу в течение более длительного времени. • Цели - путем координирования целей и задач нескольких проектов на основе скоординированной программы организация обладает большим потенциалом для достижения целей более высокого уровня.· • Финансирование - часто одна организация не может управлять несколькими проектами за счет средств одного институционального донора. В этом случае существует возможность координации этих проектов в рамках контекста одной программы, что может привести к экономии, обусловленной ростом масштабов деятельности, и дать положительный эффект от масштаба.· • Целевые группы населения - организации часто пересекаются в работе с целевыми группами населения при реализации проектов в различных областях (здравоохранение, водоснабжение, образование и т.д.). Координация этих проектов через программный подход позволяет организации связать проекты посредством общих показателей, общих ресурсов и процессов, которые помогают сообществам постоянно оценивать, «правильное» ли вмешательство происходит со стороны организаций.· • Управление - в то время как сотрудники отдельных проектов основное внимание уделяют реализации мероприятий, которые вносят непосредственный вклад в продукты и результаты в рамках компетенции проекта, на программном уровне руководители сосредоточены на задаче согласования проектов, сбалансированности привлечения ресурсов нескольких проектов и повышении эффективности программы. Guide to the PMD Pro стр. 14 из 12 Управление портфелем контролирует работу проектов и программ организации. Портфели, как правило, управляются старшим руководством на самом высоком уровне организации или специальным подразделением организации (региональным офисом или штаб-квартирой). Управление портфелем не занимается повседневными задачами проектов; вместо этого оно сосредоточено на выборе, инициировании и общем управлении группой проектов в целях достижения стратегических целей организации6. Управление портфелем часто заключается в выборе, какие проекты не делать, с какого проекта начинать раньше, или какой проект надо прекратить для того, чтобы оптимизировать стратегическое соответствие проектов, предпринимаемых для выполнения миссии организации. Чаще всего портфель не входит в обязанности руководителя проекта. Однако это не означает, что сотрудникам не нужно заботиться о вопросах, связанных с управлением портфеля. Ресурсы, имеющиеся для инвестирования в проекты, часто ограничены или очень малы, и различные подразделения организации могут вступить в конкуренцию за эти ресурсы. Поэтому процесс управления портфелем пытается расставить приоритеты и сбалансировать возможности и риски в отношении спроса и предложения на ресурсы таким образом, чтобы цели организации были достигнуты. Учитывая конкуренцию за ограниченные ресурсы, руководители проектов и их команды должны быть в состоянии четко сформулировать, в чем их проект: − поддерживает стратегию своей организации; − придает ценность или значение программам и/или портфелю организации. Иллюстрация 6. Взаимосвязь между проектами, программами и портфелем. Портфель Суб-портфель Программы Проекты Программы Проекты Проекты Программы Проекты Проекты Проекты 1.5. Искусство и наука управлять проектами. Кто из нас не знает таких руководителей проекта, которые не очень гармоничны? Это часто менеджеры, которые обладают сложными навыками управления проектами, но боятся или не способны работать с коллективом или с участниками проекта. Например, такой менеджер проекта может отлично уметь работать с электронными таблицами, умело организует работу и планирует сценарии будущего, но не умеет передавать сообщения или информацию, и чувствует себя неудобно в общении. В результате проектная команда теряется, а заинтересованные лица жаждут лидерства и информации. Такое положение вещей естественно вызывает вопрос: что такое эффективное управление проектом? Это искусство или наука? Требуется ли «мягкое искусство» взаимодействия и обращения с человеческим поведением или нужен набор более жестких "научных" навыков, 6 Портфель, в свою очередь, может включать суб-портфели инициатив и видов деятельности, которые сгруппированы и управляются совместно. Эти суб-портфели могут быть сгруппированы по программным сферам (здравоохранение, образование, с/х, и т.п.) или по географическому району, в котором они работают. Guide to the PMD Pro стр. 15 из 12 сосредоточенных на техническом управлении результатами и продуктами проектов? Не удивительно, что ответ на этот вопрос – и то, и другое. В управлении проектами, как в большинстве случаев в жизни, секрет успеха заключается в балансе. Искусство управления проектами фокусируется на людских элементах проекта. Искусство управления проектами требует опыта, который позволяет руководителям проектов возглавлять, давать возможности, мотивировать и общаться с людьми. Творческий руководитель проекта может направить коллектив, когда в работе происходят изменения, пересмотреть приоритеты, когда меняются условия реальности на местах, решить конфликт, когда он возникает, и определить, какую информацию надо распространить, когда и кому. Наука управления проектами направлена на планирование, оценку, учет и контроль. Наука охватывает вопросы «кто, что делает, когда»: • В каком статусе находится исполнение проекта? • Какова прогнозная стоимость проекта? • Какими ресурсами необходимо активно управлять? • Есть ли риски, которые угрожают проекту? • Когда проект будет завершен? Ключом к успешной реализации проекта является уравновешенный руководитель проекта, который хорошо справляется с наукой и искусством управления проектами. 1.6. Модель компетентности управления проектами «PMD PRO». Классификация навыков управления проектами по категориям "искусство" и "наука" является полезной, однако она является лишь первым шагом в определении характеристик успешного руководителя проекта. Более полная модель компетенций управления проектами поможет определить необходимые навыки менеджеров проектов и может служить инструментом для оценки уровня квалификации, выявления областей, требующих улучшения, и для составления планов развития карьеры. Существует несколько моделей компетентности менеджеров проектов, но модель «PMD Pro» организует компетенции по управлению проектами в четырех областях: • Техническая компетентность часто именуется «наукой» управления проектом. Может ли руководитель проекта определить, выбрать и использовать правильные инструменты и процессы для обеспечения успешного управления проектом? • Компетентность в лидерстве / межличностном общении часто именуется «искусством» управления проектами. Например, как руководитель проекта сообщает, вдохновляет или решает конфликтные ситуации?· • Личностная компетентность или самоуправление - умение руководителя проекта управлять собой. Например, умеет ли руководитель проекта эффективно определять приоритеты, управлять временем и организовать работу?· • Конкретная компетентность для сектора развития - способность применять технические, управленческие, межличностные и личные знания в контексте проектов развития. Например, может ли менеджер проекта определить, выбрать и использовать правильные инструменты и процессы, которые являются уникальными и характерными для сектора развития? В дополнение к этим четырем общим областям компетенций, руководители проектов должны обладать компетентностью для эффективной работы в культуре своей организации. Может ли руководитель проекта направлять и планировать управленческую структуру своей организации, организационную культуру, сети бизнес процессов / систем и человеческих ресурсов? Культура организации определяет ее идентичность (марку) и отличает ее от других организаций, управляющих подобными проектами. Guide to the PMD Pro стр. 16 из 12 Иллюстрация 7. Показательные элементы четырех компетенций. Компетентность Техническая компетентность Компетентность в лидерстве / межличностном общении Личностная компетентность или самоуправление Конкретная компетентность для сектора развития Показательные элементы Ø Активное управление объемами и содержанием работ. Ø Всестороннее определение мероприятий, необходимых для успеха проекта. Ø Управление общим планом-графиком для обеспечения работы в срок. Ø Определение и сбор показателей для измерения хода выполнения проекта. Ø Определение, отслеживание, управление и решение проблем проекта. Ø Активное распространение информации о проекте всем заинтересованным сторонам. Ø Определение, управление и смягчение рисков проекта. Ø Создание логистических систем (систем материально-технического обеспечения) проектов. Ø Обеспечение, чтобы результаты проекта обладали приемлемым качеством. Ø Видение «большой картины» проекта в рамках портфеля организации. Ø Защита проекта (содействие участию). Ø Распространение видения - установка разумных ожиданий трудностей. Ø Обеспечение своевременной и полезной обратной связи с членами команды. Ø Содействие продуктивной коллективной среде. Ø Активное устное и письменное общение, в том числе умение слушать. Ø Мотивирование коллектива в желании исполнять указания и достигать цели. Ø Организаторские способности. Ø Внимание к деталям. Ø Способность выполнять множественные задачи. Ø Логическое мышление. Ø Аналитическое мышление. Ø Самодисциплина. Ø Управление временем. Ø Понимать ценности и парадигмы (систему взглядов) сектора развития. Ø Понимать различные заинтересованные стороны, участвующие в проектах развития. Ø Понимать и ориентироваться в сложной среде развития. Ø Эффективно работать с целым рядом партнеров. Ø Справляться с уникальным давлением среды развития. Ø Проявлять культурную деликатность. Как следует ожидать, уровень квалификации руководителя проекта, необходимый в каждой из этих сфер компетенций, будет варьироваться в соответствии с размером, сложностью и рисками проекта. Однако, несмотря на их различия, все проекты выиграют от проектного подхода, нацеленного на то, чтобы: • виды деятельности были всесторонне определены и расставлены по приоритетам в определенной последовательности; • расписания и графики были полноценными и определяли взаимосвязанные элементы проектного плана; • процессы закупок (материально-технического обеспечения) (материалов и подрядчиков) были определены и выполнены; • имелся и исполнялся порядок сообщений с соответствующими заинтересованными сторонами; • имелась система кадров для работы с сотрудниками, волонтерами и партнерами; • риски были учтены и отслеживались; • имелась система обеспечения соответствия проекта приемлемым стандартам качества; • имелся процесс управления изменениями в управлении. Guide to the PMD Pro стр. 17 из 12 Поскольку обязанности руководителей проектов увеличиваются от относительно простых проектов к более сложным проектам, необходимые знания, навыки и модели поведения в каждой из этих сфер компетенций, должны соразмерно расти. Более того, одной из заметных способностей, которую с течением времени приобретают менеджеры проектов, является искусство определения, какие существуют альтернативы для решения проблем (перерасход бюджета, конфликты в коллективе, неоднозначные роли, смещение графика, непредвиденные риски), а также, какие компетенции (инструменты, навыки, процессы) будут наиболее подходящими для удовлетворения уникальных потребностей каждой конкретной ситуации. Хотя все четыре компетенции в области управления проектами имеют решающее значение для обеспечения успеха проекта, содержание «Руководства PMD Pro» уделяет особое внимание технической области компетенции руководителей проектов. Разделы 2-4 «Руководства» сосредотачивают внимание на процессах, инструментах и механизмах, которые могут быть использованы для укрепления разработки, планирования, реализации, мониторинга, контроля и закрытия проекта. Неоспоримо, что руководители проекта должны также работать над укреплением своей личной, межличностной и отраслевой компетентности в сфере развития, однако целью данного документа не является подробное обсуждение сферы профессионального развития. Guide to the PMD Pro стр. 18 из 12 Раздел 2. Фазы срока действия проекта развития. 2.1. Сбалансированное управление проектом в течение срока действия проекта. Чтобы проекты развития были успешными, важно, чтобы весь спектр компетенций управления проектами применялся сбалансированным образом на протяжении всего жизненного цикла проекта. Для этого многие организации в области развития разрабатывают диаграммы жизненного цикла проекта, которые они используют, чтобы определить фазы, через которые их проекты должны пройти от начала до конца. Вместе эти фазы жизненного цикла проекта определяют логическую последовательность действий, которые осуществляются для достижения целей или задач проекта. Иллюстрация 8, например, представляет жизненный цикл проекта Организации ООН по вопросам продовольствия и сельского хозяйства (ФАО). В данном случае жизненный цикл проекта представляет собой ряд взаимосвязанных циклов («пересекающихся петель»). Это, однако, только один подход, который организации развития используют для информирования о жизненных циклах их проекта. Другие организации развития принимают иные модели жизненного цикла проекта: круговые, линейные, или модифицированные спиральные модели. Точная последовательность и описания диаграмм жизненного цикла проектов могут существенно различаться между предприятиями и организациями, однако их цели одинаковы. Иллюстрация 8. Цикл осуществления проекта ФАО. Группируя деятельность в последовательности жизненного цикла проекта, руководитель проекта и основная группа работников проекта может: • определить этапы, которые связывают начало реализации проекта с его завершением; • определить процессы, которые проектная группа должна реализовать по мере продвижения по фазам жизненного цикла проекта; • показать, как цикл осуществления проекта может быть использован для моделирования управления проектами; • смоделировать, как проекты работают в среде «ограничений», где изменения в любом из ограничивающих условий приводят к соответствующим изменениям других параметров проекта. 2.2. Модель фаз проекта «PMD Pro» Признавая, что существуют многочисленные диаграммы жизненных циклов проекта у разных организаций в секторе развития, «PMD Pro» придерживается собственной шестиступенчатой модели фаз проекта (Иллюстрация 9). Эта модель не предназначена для замены какой-либо конкретной модели жизненных циклов проекта, и не служит стандартом для отрасли. Ее цель – предоставить Guide to the PMD Pro стр. 19 из 12 сбалансированную и комплексную модель этапов проекта, которая охватывает весь срок реализации проекта. Иллюстрация 9. Модель проектных фаз по «PMD Pro» Модель фаз проектов «PMD Pro» разрабатывалась таким образом, чтобы она была сбалансированной и всесторонней. Сбалансированность и полнота проектной модели особенно важны в контексте сектора развития. Слишком часто организации развития уделяют особое внимание разработке проекта, мониторингу и оценке (в английской аббревиатуре - DM & E), но этот акцент иногда затеняет важность других этапов жизненного цикла проекта. Понятно, что хорошо выполняемые DM&E являются необходимым элементом. Тем не менее, этого не достаточно, чтобы гарантировать успех проекта. Проект должен не только вкладывать средства в сильный, последовательный мониторинг и контроль, но также обеспечить аналогичный уровень ресурсов и усилий на всех этапах деятельности проекта. В модели фаз проекта «PMD Pro», например, деятельность по мониторингу, оценке и контролю проекта постоянно присутствует на фоне всей деятельности проекта. Тем не менее, это лишь один из шести компонентов модели этапов проекта, которые включают следующие фазы: Определение проекта и разработка: именно во время этой фазы сотрудники проекта определяют потребности, исследуют возможности, анализируют окружающую среду и альтернативные варианты для разработки проекта. Решения, принимаемые на стадии идентификации и разработки проекта, устанавливают стратегические и оперативные рамки, в которых проект будет в дальнейшем работать. Открытие проекта: именно во время этой фазы проект официально одобряется, его общие параметры определяются, и информация о начале его деятельности доводится до сведения основных заинтересованных сторон проекта. Кроме того, на этом этапе коллектив проекта создает квалифицированную структуру управления проекта. Планирование проекта: начиная с документов, разработанных на более ранних этапах проекта, в ходе этапа планирования команда разрабатывает всеобъемлющий и подробный план реализации, который обеспечивает модель для всех работ по проекту. Этот план пересматривается в течение всего срока реализации проекта и обновляется, если необходимо, чтобы отразить изменения условий проекта. Guide to the PMD Pro стр. 20 из 12 Реализация проекта – повседневная работа по реализации проекта заключается в руководстве и управлении правильным применением плана реализации проекта: руководство коллективом, решение проблем, лидерство в проекте и творческое интегрирование различных элементов плана проекта. Мониторинг, оценка и контроль - эта фаза проходит через весь проект, постоянно измеряет прогресс в проекте и определяет соответствующие корректирующие действия в ситуациях, когда эффективность проекта значительно отклоняется от плана. Переходный период проекта при окончании – эта фаза включает в себя реализацию всех переходных мероприятий, которые должны произойти в конце проекта, в том числе (но не ограничиваясь) подтверждение результатов с бенефициарами, обобщение полученного опыта, и завершение административных, финансовых и договорных мероприятий по закрытию. Модель этапов проекта «PMD Pro» производит впечатление, что фазы проекта являются обособленными и последовательными, на самом деле, на практике они взаимодействуют и пересекаются между собой. Например: − уже на стадии определения и разработки проекта проводится обширная работа по подготовке элементов планирования для реализации проекта; − на этапе начала проекта создаются системы, которые будут определять деятельность по мониторингу, оценке и контролю; − в ходе этапа осуществления проекта проводятся мероприятия, которые определят позицию проекта для эффективного закрытия, когда наступит переходный период проекта при окончании. Управление проектами имеет итерационный (повторяющийся) характер Логическая схема выбора решения. Время и место принятия решений По мере продвижения проекта по шести этапам рекомендуется, чтобы проектная команда несколько раз вернулась к обоснованию и планированию проекта через ряд формальных схем выбора решения (в модели фаз проекта «PMD Pro» они обозначены треугольниками). В каждой такой логической схеме решений команда проекта имеет возможность решить, является ли начальное обоснование проекта правильным, требуются ли существенные изменения, или нужно прекратить все инвестиции в проект. Каждый проект и организация имеют свой подход к принятию решений. Наиболее часто используемая логика обоснования решения, как правило, применяется на ранних стадиях проекта. Сюда относятся концептуальные документы и проектные предложения, которые представляют собой вводные документы, позволяющие решить, стоит ли двигаться вперед с потенциальными проектами. Желательно, однако, включать логику решений в более поздние этапы проекта. На этапе осуществления, например, полезно формально выборочно проверять, что те потребности, на которых строится, или которыми занимается проект, все еще существуют, что логика внедрения остается в силе, и что планы по реализации по-прежнему точны. Хотя в целом верно, что определенные фазы проекта имеют место только после завершения других этапов (очевидно, что переходный этап завершения проекта происходит после разработки проекта), однако некоторые фазы происходят одновременно или параллельно. Например, как показывает Иллюстрация 10, значительная работа вкладывается в планирование проекта еще до того, как проект официально начинается. Точно так же, мероприятия по переходу проекта начинаются за некоторое время до того, как проект завершен. Guide to the PMD Pro стр. 21 из 12 Иллюстрация 10. Взаимосвязь проектных фаз. Идентификация и разработка проекта Исполнение проекта Планирован ие проекта Уровень рабочих ресурсов Мониторин г, оценка, контроль проекта Начало проекта Начало Переходный период проекта Срок проекта Конец 2.2.1. Фаза 1. Идентификация и разработка проекта. Иллюстрация 11. Фаза определения и разработки проекта Все проекты начинаются, как идея: оцениваются и анализируются необходимость или возможности, которые в конечном итоге развиваются в проект, и которые управляются в течение всего срока действия проекта. Именно в ходе этого процесса мы начинаем отвечать на критический вопрос: нужный ли проект мы реализуем? Если мы принимаем неправильное решение в этот момент, проект будет неправильным в течение длительного времени, даже если вся работа по проекту запланирована и исполняется хорошо. Если мы принимаем правильное решение в этот момент, можно считать, что мы на полпути к успешной реализации. Guide to the PMD Pro стр. 22 из 12 Во многих секторах, которые опираются на культуру управления проектами, проект официально начинается с официального одобрения. Как правило, это не относится к сектору развития, где деятельность проекта чаще всего начинается с идентификации проекта и стадии разработки. Во время идентификации и проектного этапа время, ресурсы, работа вкладываются в определение потребностей, изучение возможностей, анализ окружающей среды, развитие отношений, доверия, партнерства и альтернативных вариантов проекта. Решения, принимаемые в ходе стадии определения и разработки проекта, тесно связаны с существующей стратегией, и определяют общие рамки, в пределах которых проект будет развиваться в дальнейшем. Одна из причин, почему идентификация проектов и проектно-конструкторский этап имеет такое большое значение, потому что он обеспечивает наиболее экономически эффективную возможность ответить на фундаментальные вопросы о параметрах проекта. Как показано в Иллюстрации 12, самое хорошее время для внесения изменений в проект - в начале проекта. Если сотрудники проекта хотят изменить цели, время или бюджет проекта, это легче сделать ДО того, как проект начнет исполняться (т.е. до того, как начнут тратиться деньги, до того, как определены календарные даты и вложены средства для выполнения работы). По мере исполнения проекта будут и другие возможности вернуться к вопросам объема и содержания, качества, бюджета, ресурсов, сроков и дат. Однако, как только начинается реализация проекта (персонал нанят, мероприятия начаты, бюджет выделен, и результаты начинают становиться ощутимыми), стоимость изменений этих параметров проекта увеличивается, и становится намного сложнее управлять такими изменениями. Поэтому важно, чтобы руководитель проекта собрал и обработал данные для информированного решения в ходе идентификации и разработки проекта, а общим подходом к этой фазе является открытость для творческого поиска, коллективные обсуждения, обсуждения видения и стратегий. Управление проектами строится на совместном участии! Консультации с заинтересованными сторонами на раннем этапе Фаза определения и разработки проекта дает возможность на ранних стадиях жизни проекта создать нормы участия. В то время как совместный подход к разработке и развитию проекта может потребовать больше времени и ресурсов, конечный результат выиграет от следующих преимуществ: • заинтересованные лица имеют возможность управлять своими процессами развития; • конечная разработка проекта будет лучше; • возросшая ответственность за проект среди заинтересованных сторон. Иллюстрация 12. Возможности экономически эффективно управлять изменениями. Guide to the PMD Pro стр. 23 из 12 Несмотря на разнообразные виды деятельности, которые могут быть завершены на этом этапе, в общих чертах работа на этом этапе может быть разбита на три категории: 1. Сбор данных. 2. Анализ данных. 3. Определение логики (обоснования) внедрения проекта. 2.2.1.1.Сбор данных. Первым шагом в определении того, что вы "делаете правильный проект", является сбор данных. Цель сбора данных - широко изучить большое число и разнообразие вопросов, информация по которым после анализа даст возможность определить приоритеты и определить мероприятия, которые будут решать проблемы в целевой области. 2.2.1.1.1. Определение потребностей проекта. В рамках этого широкого процесса исследований сотрудникам проекта будет необходимо собрать данные, идентифицирующие потребности сообщества в области потенциального внедрения. Однако данные не должны быть ограничены исключительно рассмотрением вопросов, связанных с потребностями населения. Другие вопросы также должны быть изучены, включая современное состояние предоставления услуг, существующие сильные стороны сообщества, заинтересованные стороны, присутствующие в области внедрения, и многое другое. Одна из проблем при сборе данных состоит в том, что процесс может быть весьма субъективным. Люди (как личности, и как члены общественных и заинтересованных групп) могут иметь радикально отличающиеся идеи о том, что должно быть определено как «потребность», а что нет. В результате, процесс определения потребностей в одном месте может привести к существенно различным результатам в зависимости от того, кто проводит консультации, и какой подход применяется в работе. Чтобы снизить субъективность определения проблемы и разобраться в различных пониманиях «реальных» потребностей, следует применить метод триангуляции оценки данных. Триангуляция представляет собой метод, который облегчает подтверждение правильности данных через перекрестную проверку информации не менее чем из двух источников. Например, если исследование использует только один метод сбора данных или одну точку зрения, есть сильный соблазн поверить в результаты. Если исследователь использует два метода или различные мнения, результаты могут оказаться противоречивыми. Используя три метода или точки зрения для получения ответов на вопросы, есть надежда, что результаты, по крайней мере, двух из трех подтверждают друг друга. С другой стороны, если есть три противоречивых ответа, исследователь знает, что необходимо изменить вопрос или пересмотреть метод опроса, или и то, и другое. По сути, триангуляционный подход повышает доверие и достоверность результатов исследования. Объединив различные точки зрения и методы, исследователи могут надеяться на преодоление слабых аспектов и субъективности, а также проблем, которые обозначены лишь одним методом или одной точкой зрения эксперта, тем самым, увеличивая достоверность и обоснованность результатов. Один из способов триангуляции процесса идентификации потребностей - использовать подход, введенный американским социологом, Джонатаном Брэдшоу, который считал, что оценка потребностей должна изучить четыре вида потребностей в обществе, и что наличие всех четырех видов потребностей будет указывать на "реальные" потребности. Следующая Иллюстрация 13 показывает пример триангуляции потребностей по классификации Бредшоу. Guide to the PMD Pro стр. 24 из 12 Иллюстрация 13. Триангуляция потребностей по классификации Бредшоу. Потребности по восприятию сообщества: группа людей из сообщества указывает, что им нужна поликлиника Выраженная потребность: женщины ходят за 10 км в ближайшую поликлинику Нормативная потребность: врач указывает, что детская смертность превышает установленные нормы. Сравнительная потребность: исследования показывают, что уровень вакцинации ниже, чем в других сообществах Как показано в Иллюстрации 13, четыре категории социальных потребностей по Брэдшоу включают: • Нормативные потребности – сравнение текущей ситуации с набором профессиональных или экспертных стандартов. Часто это потребности, определенные профессионалами или экспертами - врачами, инженерами, работниками государственного здравоохранения, и т.п. Например, санитарный эксперт может определить, что уровень фекального содержимого в бытовой воде превышает нормы, установленные Министерством здравоохранения. • Сравнительные потребности – сравнение текущей ситуации с положением других. Одним из наиболее общих применений этого подхода является сравнение доступа людей к ресурсам. Этот подход признает, что потребность - понятие относительное, и поэтому любая дискуссия о потребностях должна проходить в контексте сравнения между людьми. Например, члены рыболовного кооператива могут наблюдать, что рыбные запасы больше в соседнем селении, где имеются производственные помещения для хранения рыбы. • Потребности по восприятию сосредоточены на мыслях и мечтах самого сообщества, т.е. это то, что, по мнению самих людей, является или должно быть приоритетом. Ощущаемая потребность может быть субъективной; она лучше всего описывается, как "желание". Ощущаемая потребность обязательно зависима от знаний и ожиданий личностей, которые могут быть нереалистичными и/или слишком дорогими. Например, матери могут выражать недовольство беспорядком и нездоровыми условиями, которые являются результатом отсутствия санитарно-гигиенических условий, но могут быть не осведомлены об альтернативах, которые существуют для изменения текущего состояния. • Выраженные потребности выводятся из наблюдений за действиями сообщества. Например, если существует большая очередь на получение определенной услуги, это указывает на то, что сообщество отдает приоритет этой потребности. Иногда выраженные потребности согласуются с ощущаемыми потребностями (потребностями по восприятию). Однако временами такие потребности не выражаются конкретно публично (как ощущаемая потребность) в результате политического/культурного давления или потому, что никто не спрашивает. Например, семьи, возможно, не выражают свое недовольство в связи с Guide to the PMD Pro стр. 25 из 12 отсутствием санитарно-гигиенических условий, но начинают определять места для бытовых отходов (мусорных ям). Когда организации изучают потребности сообщества, задача состоит в том, чтобы процесс определения был точным и честным. Часто отдельные лица и группы уже имеют представление, основанное на наблюдениях и опыте, о том, какой проект или услуга является предпочтительной для определенной организации развития. Организации развития должны принять меры против такой динамики, когда побуждения ведут отдельных лиц и групп лиц представлять свои потребности таким образом, чтобы лучше всего соответствовать приоритетам организаций развития, и таким образом быть выбранными для участия в проекте и получить преимущество. Например, если организация развития известна, как поддерживающая, прежде всего, проекты в области водоснабжения, то участники проекта, скорее всего, будут выражать свои проблемы и решения таким образом, чтобы соответствовать потенциальным возможностям участия в предпочитаемом проекте такой организации развития – проекте водоснабжения. 2.2.1.1.2. Виды данных. Процесс сбора данных, однако, не ограничивается только определением потребностей. Чтобы полностью понять контекст проекта, сотрудникам проекта нужно будет собирать данные о целом ряде областей, связанных с окружающей средой проекта, включая, но не ограничиваясь только этим, данные, относящиеся к: • заинтересованным сторонам проекта; • сильным сторонам, возможностям и видению сообщества; • успехам и потенциалу; • биологической/физической среде; • организационным сетям; • инфраструктуре; • правовым и политическим институтам; • социальным и культурным условиям. В каждой из этих областей могут быть собраны три типа данных: • Вторичные данные - информация доступна из опубликованных и неопубликованных источников, в том числе литературных обзоров, оценок, отчетов неправительственных организаций, агентств ООН, международных организаций и правительственных учреждений. Вторичные данные могут быть экономически эффективными, и должны быть первыми источниками данных оценки. К сожалению, доступ к вторичным документам часто ограничен, и необходима осторожность при интерпретации вторичных данных. Иногда необходим выборочный сбор первичных данных для проверки надежности и значимости вторичных данных для конкретных условий либо для получения более глубокой, более специальной информации. • Первичные количественные данные. В ситуации, когда вторичные источники не обеспечивают достаточную информацию для оценки, организации могут собирать данные с помощью метода количественной оценки - с помощью опросов, анкетирования, тестов, стандартизированных инструментов наблюдения, которые сконцентрированы на информации, которую можно подсчитать, и которая подвергается статистическому анализу. Сила метода сбора количественных данных заключается в следующем: - масштабируемости или варьируемости с изменением масштаба, т.е. обработка результатов из большого числа тем или субъектов, что позволяет сделать обобщение результатов; - объективности и точности результатов - меньше личной предвзятости в сборе и интерпретации данных; Guide to the PMD Pro стр. 26 из 12 - стандартизации – собиратели данных используют стандартные подходы, результаты которых могут сравниваться с другими данными. Недостаток количественных данных заключается в том, что этот подход иногда упускает глубину ситуации, а собрать необходимую контекстную информацию может быть трудно. • Первичные качественные данные - в отличие от количественного подхода в сборе данных, качественный подход стремится охватить опыт участников, используя слова, рисунки и объекты (и даже невербальные сигналы, подаваемые теми, кто предоставляет данные). Сила метода сбора качественного данных заключается: - в глубине и деталях - качественные данные часто содержат подробные описания ситуаций, давая весь спектр контекста, который отсутствует в количественных данных; если качественный метод используется наряду с количественным сбором данных, он может объяснить, почему был дан тот или иной конкретный ответ; - в открытости - поощряя людей давать пространные ответы, можно открыть новые тематические области, которые первоначально не рассматривались; - в имитации личного опыта людей - можно создать детальную картину, почему люди ведут себя определенным образом, и каковы их ощущения и восприятия таких действий. Качественные данные чаще всего собираются в незаконченном описательном виде в отличие от типичной формы опроса в виде вопросов и ответов, анкет или тестов. Иллюстрация 14. Инструменты сбора данных. Вторичные данные • Обзор литературы. • Обзор отчетов. • Существующие статистические данные. • Индексы. • Правительственные документы. • Другие документы НПО. Первичные количественные данные • Знания, практика и масштабные исследования. • Обследование домохозяйств. • Стандартные тесты и обзоры. • Стандартизированные инструменты наблюдения. • Антропометрические измерения. Первичные качественные данные • Обсуждения в группах. • Группировочная диаграмма схожести. • Фокус группы. • Исторические повествования. • Сроки. • Круг уполномоченных лиц. • Видение. • Отображение местности. • Полу-структурированные интервью. • Интервью с ключевыми информантами. • Задачи по упорядочению данных. Следует быть внимательными при выборе наиболее подходящих (и экономически эффективных) инструментов и подходов в сборе информации. Здравый смысл показывает иногда, что некоторые подходы в сборе данных лучше, чем другие. Например, первичные данные часто воспринимаются предпочтительнее, чем вторичные данные. Однако на практике ясно, что почти во всех процессах оценки находится место для нескольких источников информации и смешанных методов. В то время как сбор первичных данных может быть специально нацелен на конкретные потребности предлагаемого проекта, сбор первичных данных может занять много времени, денег, и вовлечь много людей. По этой причине многие организации рекомендуют, чтобы первый раунд оценки полагался на вторичные данные, а последующие раунды использовали подход по сбору первичных данных, чтобы заполнить пробелы, которые не охвачены вторичными данными. Кроме того, в то время как часто предполагают, что качественные данные менее точны, чем количественные данные, количественные подходы часто несут риск завышения ожиданий местных сообществ и партнеров, и могут быть особенно затратными. Качественная оценка данных, в свою очередь, может быть точной, если запланирована и осуществляется с соответствующими знаниями, и Guide to the PMD Pro стр. 27 из 12 может выявить причины, стоящие за тенденциями, которые определяются посредством вторичных и количественных подходов. Сочетание вторичного и первичного методов (в том числе количественных и качественных инструментов) в одном процессе сбора данных может предоставить более полную, целостную картину, по которой принимается решение. В конце концов, речь идет о принятии решений. Перед началом сбора данных следует задать вопрос, как данные будут использоваться. Если нет приемлемого ответа на этот вопрос, не надо двигаться дальше. Время и ресурсы слишком дорого стоят, чтобы тратить их на бесполезные упражнения. К сожалению, множество осуществленных оценок собрали большое количество данных, на основе которых было произведено множество документов, которые лежат на полке и собирают пыль. Эти документы свидетельствуют о неэффективном использовании ресурсов, могут быть насильственным вторжением в жизнь заинтересованных сторон, а также создать ложные ожидания, которые могут испортить важные отношения с партнерами и/или бенефициарами. 2.2.1.2.Анализ данных. В то время как целью сбора данных является широкое изучение большого числа и разнообразия вопросов, целью анализа данных является упорядочение и организация исходных данных таким образом, чтобы можно было извлечь полезную информацию. В частности, проекты развития имеют тенденцию сосредотачиваться на двух широких категориях анализа: − на анализе текущего состояния; − на анализе будущего состояния. 2.2.1.2.1. Анализ текущего состояния. Анализ текущего состояния является отправной точкой для хорошей разработки проекта. Это процесс понимания статуса, состояния, тенденций и ключевых вопросов, затрагивающих людей и средства к существованию людей, экосистемы или учреждения в данном географическом контексте. Существуют различные инструменты для проведения анализа данных. Каждый из них предназначен для определенной цели, и сотрудники проекта должны выбрать методы/инструменты, основанные на предполагаемой цели анализа. Иллюстрация 15. Инструменты анализа. Цель Организовать информацию Определить приоритеты данных. оценки Определить текущее состояние предоставления услуг. Способствовать развитию критического мышления у заинтересованных сторон проекта. Исследовать причинно-следственные взаимосвязи. Инструмент Матрицы уязвимости. Картографирование идей. Группировочная диаграмма7 Матрицы и упражнения по упорядочению данных. Анализ пробелов в оценке. Сопоставление. Семинары. Фокус группы. Обсуждение в группах. Анализ имеющихся сил на местах. «Дерево» проблем. Каждый из инструментов анализа в Иллюстрации 15 является важным, и все они могут быть использованы для обработки информации, полученной в процессе сбора данных. Например, если задача направлена на организацию и классификацию информации оценки, потребуется иной инструмент анализа, чем в случае, если целью является способствовать более критическому 7 Группировочная диаграмма - графический инструмент, применяемый, в частности, при мозговой атаке: члены группы пишут свои ответы на поставленный вопрос или проблему, потом ответы уточняются так, чтобы их смысл стал понятен все; по полученным результатам составляется диаграмма. (Прим. переводчика). Guide to the PMD Pro стр. 28 из 12 мышлению заинтересованных сторон проекта. На практике, однако, маловероятно, что проектная команда будет использовать все инструменты анализа в каждом проекте, который она реализует. Хотя это не является задачей «PMD Pro» - изучить все методы и инструменты анализа в деталях, руководителям проектов рекомендуется: • определить различные существующие инструменты, которые могут быть использованы для выполнения различных задач, являющихся частью анализа проблемы; • выбрать наилучший инструмент для каждой задачи по анализу проблемы; • развить (со временем) навыки и модели поведения, необходимые для использования различных инструментов по анализу проблем с различными группами. 2.2.1.2.2. Анализ будущего состояния. После того, как анализ текущего состояния завершен, следующий шаг будет заключаться в анализе будущего состояния проекта. Это включает в себя вопросы о том, как проект улучшит уровень жизни, экосистемы или учреждения участников проекта. Анализ будущего состояния помогает создать картину или описание того, куда приведет проект: • Что изменится в будущем, если этот проект успешно удовлетворит ожидания? • Что бенефициары проекта смогут делать из того, что вы не можете сделать сейчас? • Какие социальные изменения произойдут? На практике анализ будущего состояния не так прост. В то время как анализ будущего состояния может выявить широкий спектр потенциальных сфер действия для проекта, редко случается, что организация может осуществить все мероприятия, предусмотренные анализом будущего состояния. В данное время организациям развития следует учитывать три критических стратегических вопроса: • Какие элементы будут включены при внедрении проекта? • Какие элементы не будут включены в сферу действия проекта? • Каковы критерии, которые будут использоваться, чтобы принять эти решения? Эти вопросы неизбежно окажутся трудными, и организации будут сталкиваться с многочисленными альтернативами. Они должны будут принять конкретные решения, касающиеся сферы деятельности проекта. Где будет внедряться проект? Какие услуги будут предоставлены? Кому будут предоставляться услуги? Консенсус по этим вопросам может быть труднодостижимым, а процесс принятия решения имеет потенциал стать довольно сложным и спорным. Следовательно, важно, чтобы проектная команда четко определяла и устанавливала приоритеты из множества соображений, которые появляются при принятии решения о том, что будет включаться в окончательный проект, а что не будет. Иллюстрация 16. Критерии определения, что включается в проектное внедрение Категория Приоритет потребностей. Рассмотрение внешних факторов Уместность Институциональный потенциал Наличие ресурсов Guide to the PMD Pro Показательные критерии Какие потребности получили самый высокий уровень внимания при оценке и анализе? Осуществление каких потребностей имеет самый высокий потенциал влияния? Кто еще работает в предлагаемой зоне внедрения? Каковы сильные стороны их программы? Какие существующие виды деятельности дополняют анализ дерева целей? Предлагаемый подход приемлем для целевого населения и основных групп заинтересованных сторон? Например, программа репродуктивного здоровья уместна и согласуется с религиозными и культурными нормами? В чем сила вашей организации? Каков уровень потенциала вашего исполняющего партнера? Имеется ли финансирование? Имеется ли потенциал для роста? Какие имеются возможности для балансирования ресурсов? стр. 29 из 12 Финансовая и экономическая осуществимость Техническая осуществимость и устойчивость Внутренние программные соображения Соображения по портфелю Уровень возврата на инвестиции приемлемый? Может ли предлагаемая работа быть реально выполнена? Работа проекта сможет оставаться и поддерживаться в будущем самостоятельно? Каковы стратегические приоритеты вашей организации в регионе? В стране? Иное? Каковы сильные аспекты вашей организации? Какие приоритеты имеет ваша организация в отношении географии? Бенефициаров? Иное? Данный проект «вписывается» в полный портфель проектов организации? Обратите внимание, что указанные выше категории могут быть объединены в две группы. Первая группа категорий (приоритетные потребности, внешние факторы программы, уместность, институциональный потенциал) использует информацию, собранную при оценке потребностей и анализе видов деятельности для принятия решения, как, и надо ли организации внедряться. Эти категории исследуют, есть ли приоритетные потребности, которыми следует заниматься независимо от того, есть ли другие программы, предоставляющие дополнительные услуги, есть ли исполняющие партнеры, которые имеют потенциал для выполнения проекта, и является ли предлагаемая деятельность уместной. Вторая группа категорий (наличие ресурсов, финансовая/экономическая осуществимость, технические возможности, внутренние соображения программы) направлена не столько на результаты оценки потребностей, сколько на критерии, связанные с организационными соображениями. Например, есть ли доноры, заинтересованные в финансировании проекта? Имеются ли ресурсы? Имеет ли организация потенциал для работы в области предлагаемой программы? Вписывается ли проект в общий портфель проектов организации? Как только станет ясно, какие потенциальные цели проекта отвечают критериям, можно начинать квалифицированную разработку проекта. Как указывалось ранее, не все потенциальные цели проекта могут рассматриваться в рамках одного проекта. Области, которые не отвечают критериям, будут исключены из сферы внедрения. Возьмем в качестве примера вымышленное сообщество «Муниципалитет Реки Дельта». Последние оценки, проведенные в муниципалитете, обнаружили, что ухудшение качества воды привело к истощению запасов рыбы, снижению улова и доходов среди рыбацких семей, и значительному росту числа заболеваний, переносимых водой, особенно среди бедных семей и детей в возрасте до пяти лет. В воде присутствует высокий уровень фекальных, бытовых и промышленных отходов, а некоторые из многочисленных факторов, дополняющих проблему, включают: • низкую осведомленность общественности об опасности свалки бытовых отходов; • низкий доступ к использованию санитарно-технических сооружений для удаления фекальных отходов; • слабый надзор (неэффективный и коррумпированный) Агентства по охране окружающей среды за местной текстильной промышленностью; • недостаточный государственный бюджет в результате неэффективного обращения с промышленными отходами (там, где существуют услуги), а сточные воды не соответствуют экологическим стандартам. Очевидно, что в этом случае, есть много потенциальных областей, где проект может вмешаться (поднятие уровня сознательности общественности, утилизация отходов, обработка отходов бизнеса, пропаганда увеличения бюджета, системы утилизации фекальных отходов, и т.д.) В действительности, однако, проект должен конкретно определить, где он будет внедряться, а где нет. В конечном счете, это должно быть решение о стратегии и распределении ресурсов, которое должно определить приоритетные направления внедрения. В данном случае критерии таковы: Guide to the PMD Pro стр. 30 из 12 • Приоритетные потребности: домохозяйства показывают, что требуется срочное вмешательство. • Внешние факторы программы: работа над санитарными сооружениями соответствует политике местных органов власти и исполнительного агентства. • Соображения по существующему потенциалу: организация-исполнитель не обладает способностью выполнить работы в области инженерной очистки воды, но имеет большой опыт в работе по изменению поведения, связанного с утилизацией бытовых отходов. • Наличие ресурсов: пятилетний план для региона основных международных доноров включает ресурсы для улучшения здоровья в регионе. Исходя из этих соображений, было принято решение о разработке проекта, нацеленного на оборудование и сооружения гигиены и санитарии и повышение осведомленности об опасности свалки отходов. Управление проектами носит повторяющийся характер! Сбор и анализ данных за время действия проекта. В то время как сбор и анализ данных обычно ассоциируется с фазой определения и разработки проекта, эти виды деятельности могут и должны проводиться на разных этапах проекта. Например, инструменты сбора и анализа особенно полезны: • когда происходит расширение или изменение сферы существующего проекта; • при проведении мониторинга и оценки деятельности; • при завершении мероприятий по изучению опыта на стадии переходного периода проекта при его окончании. 2.2.1.3.Определение логики внедрения проекта. Когда процесс сбора данных и анализа завершен, следующим шагом будет определение логики проекта или его логического обоснования. Одним из основных инструментов, используемых для установления логики проектов развития, является матрица логической структуры (логическая основа). Логическая структура является аналитическим инструментом для планирования, контроля и оценки проектов. Она получила свое название от логических связей, устанавливаемых планировщиками, для соединения средств проекта с его целями. 2.2.1.3.1. Варианты логической структуры проекта. Есть несколько вариантов моделей логической структуры, которые используются в секторе развития. Многие из этих моделей используют разные термины для определения результатов проекта. Некоторые определяют цели и задачи, другие определяют результаты и последствия. Кроме того, нет единого мнения о количестве уровней в матрице логической структуры. Некоторые организации используют матрицу из четырех уровней, другие – из пяти. Таблица в Иллюстрации 17 может служить источником для сравнения логических моделей нескольких международных доноров и организаций развития. Если посмотреть содержание таблицы, сразу становятся очевидными различия в количестве уровней в каждой модели, и различия в использовании терминологии. Тем не менее, несмотря на существующие различия в логических моделях, терминах и структурах, все они предназначены для исполнения похожих целей, служа в качестве: • методического инструмента для организации проектного мышления и выявления взаимосвязей между ресурсами, мероприятиями и результатами проектов; • наглядного способа представления и обмена мнений о логике внедрения проекта; • инструмента для выявления и оценки рисков, присущих предложенному проекту; • инструмента для измерения прогресса на основе показателей и методов контроля. Guide to the PMD Pro стр. 31 из 12 Иллюстрация 17. Терминология логической структуры организаций профиля развития. Орг-я Промежуточные изменения ЕС Конечные перемены Цель и воздействие Программная цель Общая цель ФАО Общая цель Промежуточ ная цель НОРАД ЮСАИ Д ВБ Цель Цель Стратегическая Промежуточный результат цель Цель/влияние развития Цель/ последствия Программная Цель проекта Последствия цель AusAid CARE World Vision Цель/послед ствия Конечная цель проекта Цель проекта Цель компонента Промежуточная цель Специфическая цель Цель Существующие изменения Результат Специфическое внедрение Программа работ/Задач Результат Мероприятие Вклад Ожидаемый результат Результат Мероприятие Вклад Мероприятие Вклад Результат Результат Мероприятие Мероприятие Вклад Вклад Результат Процесс/ Мероприятие Мероприятие Вклад Результат Вклад 2.2.1.3.2. Интерпретация матрицы логической структуры. Матрица логической структуры определяет и передает логические связи в проекте путем отслеживания вертикальных и горизонтальных причин (обоснований), которые соединяют уровни матрицы. Отношения между элементами на каждом уровне логической схемы показывают вертикальную логику, которая ведет к достижению конечной цели проекта. Хотя существует множество версий логической основы проектов, «PMD Pro» поддерживает четырехуровневую логическую модель, которая включает в себя следующие конечные результаты: 1. Деятельность – это исполняемые мероприятия, посредством которых мобилизуются вклады (финансовые, людские, технические, материальные и временные ресурсы) для получения результатов проекта (подготовка кадров, строительство и т.п.), за которые сотрудники несут ответственность, и которые в совокупности производят конечный продукт или результат. 2. Продукты - это ощутимые результаты деятельности проекта. Они включают в себя продукцию, товары, услуги и изменения (например, люди, прошедшие подготовку, обладающие возросшими знаниями и навыками; качество построенных дорог), которые в совокупности вносят вклад в конечные результаты. 3. Последствия - это то, чего проект ожидает достичь на уровне получателя (например, использование знаний и навыков на практике в течение долгого времени; перевозка грузов по построенным дорогам с течением времени;), и каким изменениям способствует на уровне населения (уменьшение недоедания, более высокие доходы, повышение урожайности, и т.п.), что в совокупности помогает добиться выполнения целей и достичь целевого влияния с течением времени. 4. Цели – это желаемые конечные результаты или последствия самого высокого уровня (преобразование, устойчивость, средства к существованию, благополучие и т.п.), которым проект способствует (это конечная цель многих логических обоснований). Guide to the PMD Pro стр. 32 из 12 Иллюстрация 18. Вертикальная логика логического обоснования. Описание проекта Показатели Цель Средства проверки Допущения Если происходят последствия, это и будет вкладом в общую цель. Последствия Если произведены продукты, будут последствия. Продукты или результаты Мероприятия или деятельность Если проводятся мероприятия или деятельность, продукты или результаты будут произведены. Если обеспечены адекватные ресурсы/вклад, будут проведены мероприятия/деятельность. После того, как цели проекта, последствия, результаты и мероприятия определены, приходит время следующего вопроса: какие внешние риски (вне контроля проекта) потенциально могут вмешаться в вертикальную логику проекта? На каждом уровне логической структуры есть внешние факторы, которые могут повлиять на успех проекта. Например, если засуха продлится еще один год, семена не прорастут, и не будет результата (урожая), который можно продать. Или, если дети будут болеть диарей из-за плохой питьевой воды, даже если они будут есть больше, результат будет тот же – вес каждого ребенка не будет увеличиваться, и питания будет недостаточно. Эти важные внешние факторы должны быть занесены в раздел «допущений» или «предположений». Вы не сможете ничего поделать с некоторыми рисками (маловероятно, что местное НПО может предотвратить войну), но важно предвидеть возможные проблемы. Перечень рисков и предположений может помочь объяснить, почему проект не достигает всех своих целей. Допущения определяют горизонтальную логику матрицы, создавая взаимосвязь по типу «если – то», которая обозначает, что если допущения, сделанные на каждом уровне логического обоснования, верны и сохраняются, то путь вертикального развития проекта, вероятно, будет успешным, как показано в Иллюстрации ниже. Иллюстрация 19. Горизонтальная логика структуры обоснования. Описание проекта Цель Последствия Продукты или результаты Показатели Средства проверки Допущения Если горизонтальная логика соблюдена и допущения выполняются, проект, скорее всего, будет успешным Мероприятия или деятельность Особенно важно сосредоточить внимание на предположениях в правой ячейке логической структуры. Предположения в этой ячейке составляют суть логики внедрения проекта. Именно здесь происходит связь между ощутимыми последствиями, производимыми на уровне продуктов/результатов, и социальными изменениями, которые требуются на итоговом уровне (на уровне производимых последствий). Например, если продуктами/результатами проекта является 1) Guide to the PMD Pro стр. 33 из 12 построение туалетов и 2) проведение информационной кампании по расширению использования туалетов, тогда предположение на уровне последствий заключается в повышении доступности туалетов и возросшей осведомленности о наличии уборных, что позволит значительно увеличить использование туалетов, тем самым, улучшая качество воды и здоровья населения. После того, как цели установлены, и связанные с ними риски и предположения определены, последним элементом логической структуры будут показатели достижений и средства контроля для каждого уровня логической структуры. Показатель (или индикатор) – это количественная мера или качественное наблюдение, которое применяется для описания изменений. Чтобы показатель мог измерять изменения, он должен иметь базовую линию отсчета, т.е. меру или описание текущей производительности организации, и/или компаратор8 в качестве начальной точки отсчета. Исходные данные должны быть определены в начале проекта. Производительность в ходе реализации проекта оценивается относительно поставленной цели (улучшение, изменение или достижение, которое по ожиданиям произойдет в ходе реализации проекта) с учетом базового уровня. Индикаторы показывают, в какой степени проект выполняет запланированный вклад, результаты, последствия, цели. Они передают в конкретной, измеримой форме эффективность, которая должна быть достигнута на каждом уровне изменений. Индикаторы также помогают устранить расплывчатые и неточные формулировки о том, что можно ожидать от проектных мероприятий. Иллюстрация 20 содержит рекомендации по разработке индикаторов для каждого уровня логической структуры. Иллюстрация 20. Руководящие принципы индикаторов по уровням логической структуры Элементы. Руководство по созданию индикаторов (показателей) Цель – это конечная цель или высокий конечный результат или влияние, которому проект способствует. Показатели - это долгосрочное воздействие, которое не относится к одному проекту. Скорее, они являются программной, подотраслевой или секторальной целью, которой несколько других проектов и переменных величин также будут способствовать. Например: преобразование, устойчивость, средства к существованию и благосостояние. Индикаторы на этом уровне имеют решающее значение, но их труднее определить. Изменение должно произойти среди расширенного числа бенефициаров, целевого населения, сотрудничающих учреждений и местных партнеров. Например: применение знаний и навыков на практике с течением времени; транспортировка товаров по построенным дорогам с течением времени; снижение недоедания; улучшение доходов и повышение урожайности. Индикаторы на этом уровне легче обозначить, чем на уровне общих последствий, поскольку они представляют собой материальные товары и услуги, которые должны быть поставлены проектом. Все продукты должны быть выполнены к концу реализации проекта в срок в соответствии с графиком, включенным в проектный план. Например: люди обучены и имеют улучшенные знания и навыки; построены качественные дороги; поставлены товары и услуги. Последствия – это то, что проект планирует совершить на бенефициарном уровне, в совокупности помогая добиться достижения целей и воздействия с течением времени. Результаты (продукты) - это ощутимые результаты, полученные от деятельности по проекту, которые в значительной степени находятся под контролем руководства проекта, и которые в совокупности способствуют последствиям. Мероприятия – действия, посредством которых мобилизуются вклады для производства результатов, за которые несет ответственность персонал, и которые в совокупности дают результаты. Не все организации развития разрабатывают показатели на уровне мероприятий. Индикаторы на этом уровне почти напрямую связаны с описанием самой деятельности. Например: работа персонала, фактические расходы по сравнению с бюджетом, использование оборудования, компоненты обучения и компоненты строительства. 8 Компаратор - это процедура, или программа, или модуль сравнения. Когда сравнение двух величин реализуется программно, название выбирается в зависимости от того, как это реализовано. Прим. переводчика. Guide to the PMD Pro стр. 34 из 12 При разработке показателей нормой является использование критериев СМАРТ (SMART9) для концептуализации показателей эффективности, что значит: • Конкретные – индикаторы или показатели должны быть количественными и измеримыми: что именно проект намерен изменить? Индикаторы должны давать детальные параметры: o Количество, т.е. ожидаемое численное представление о том, что должно быть достигнуто; o Качество, т.е. повествовательное или описательное раскрытие ожидаемых достижений; o Месторасположение, т.е. географические границы ожидаемых достижений. • Измеримые - индикаторы должны быть количественными и измеримыми: можно ли измерить показатель объективно и независимо? • Достижимые, т.е. показатели должны быть достижимыми в рамках треугольника ограничений проекта (бюджета и ресурсов, времени и бюджета, масштабов и качества). • Существенные или значимые, т.е. индикаторы должны точно измерять изменения, которые проект стремится произвести. Показатели должны быть практически применимыми и экономически эффективно измерять именно то, что следует знать сотрудникам проекта. • Привязанные к срокам, т.е. индикаторы должны указывать конкретную дату и время: будет ли показатель исполнен или достигнут в указанные временные рамки? В таблице 21 показан частичный результат логической структуры на примере проекта «Дельта реки». Содержание этой логической структуры дает пример вертикальной и горизонтальной логики проекта, а также примеры предположений и показателей на каждом уровне логической структуры. Описание Показатели Средства проверки Улучшение здоровья детей в возрасте до пяти лет, особенно среди малоимущих семей, которые проживают на берегу реки. Сокращение заболеваемости, связанной с некачественной водой у детей до 5 лет на 30% к 2012 году. Документы городской больницы и клинические данные, собранные мобильными медицинскими бригадами. Уменьшение объема фекальных отходов, сбрасываемых в реку. Сокращение концентрации кишечной палочки на 20% по сравнению с уровнем + 2003 года. Соответствие национальным стандартам здравоохранения и санитарии к 2012 году. 60% бытовых фекальных отходов удаляются через систему туалетов и канализацию. Ежемесячные исследования качества воды, проведенные Агентством по охране окружающей среды и органами управления водными ресурсами. Ежегодные выборочные исследования, проводимые муниципалитетом между 2009 и 2012 годами. Последствия Цель Иллюстрация 21. Логическая структура Проекта «Дельта реки» Допущения или предположения 9 SMART является аббревиатурой от английских слов: Specific, Measureable, Achievable, Relevant, Time-bound. Прим. переводчика Guide to the PMD Pro стр. 35 из 12 Результаты Мероприятия Качественные туалеты построены и используются членами сообщества, и т.п. Количество завершенных туалетов. Количество туалетов, прошедших проверку качества. Количество женщин, мужчин, девочек и мальчиков, пользующихся туалетами регулярно, и т.п. Кадастровые данные по форме волонтеров из сообщества, проводящих исследования. Интервью с основными информаторами, и т.п. Качество воды в верховье реки остается без изменений. Чистая вода реки является ключевым фактором, определяющим состояние здоровья детей до 5 лет Проведение кампании по просвещению о санитарии. Мобилизация сообщества для строительства туалетов. Подготовка инженерных спецификаций. Определение оптимального места для строительства туалетов, и т.п. Число проведенных встреч с общественностью. Кол-во человек, получивших информацию. Число людей, присутствующих на собраниях. Завершенные инженерные планы. Планы, утвержденные Министерством общественных работ. Количество определенных строительных площадок. Клиенты удовлетворенные предложенными участками, и т.п. Журнал учета деятельности персонала и волонтеров. Журнал посещаемости мероприятий. Копия утвержденного плана. Форма разрешения от Министерства общественных работ. Карта строительных площадок с документированным обоснованием вклада клиентов, и т.п. Повышение осведомленности обеспечит использование уборных. Использование туалетов будет адекватно уменьшать объем сбросов отходов в реку, и т.п. 2.2.1.4.Управление проектными решениями. Сейчас наступило время, когда внимательный читатель должен задать вопрос: «На данный момент мы уже вложили значительное время / деньги / усилия в определение и разработку проекта без какихлибо гарантий того, что наш проект получит финансирование. Разве это не значительный риск?». Вопрос уместен, и лежащее в его основе беспокойство правильное на 100%. Всегда есть риск, что организация вложит значительные ресурсы на стадии определения и разработки проекта, а потом выяснится, что проект официально не утвержден. В идеале, сотрудникам проекта надо создать систему, посредством которой они могли бы получить четкую информацию о том, что проект будет (или не будет) разрешен ДО того, как значительные средства инвестируются в идентификацию и разработку проекта. Проектные команды желают избежать ситуаций, когда имеются «совершенные, но отклоненные» сценарии, при которых организация уже потратила тысячи (и даже десятки тысяч) долларов на идентификацию и разработку проекта, а проект, в конечном счете, не поддержан ключевыми заинтересованными сторонами (внутри организации, в сообществе, среди государственных служащих, или предполагаемыми донорами). Одной из «лучших практик», используемых для управления риском "совершенного, но отклоненного" сценария, является применение процесса принятия решения по времени и месту, который состоит из серии одобрений на различных этапах проекта. С помощью такого процесса принятия решений организации определяют ряд моментов в проекте, которые требуют решения: приступить к следующему этапу проекта, изменить объем и содержание, масштаб, план-график или бюджет проекта, или прекратить проект сразу же. Каждое принимаемое последующее решение основывается на работе, проведенной на предыдущем этапе. Guide to the PMD Pro стр. 36 из 12 Управление проектами основано на совместном участии! Консультации заинтересованных сторон По мере того, как команда разрабатывает документы, связанные с каждым решением (бизнес документы, концептуальный документ, письмо о заинтересованности, проектное предложение и т.д.), она должна привлечь заинтересованных сторон для изучения центральных вопросов, связанных с потенциальным проектом, но не ограниченных только этими: • Объем и содержание проекта были рассмотрены и приняты конечными бенефициарами проекта? • Квалифицированный план-график проекта соответствует ожиданиям и ограничениям заинтересованных сторон? • Договорились ли заинтересованные стороны о минимальных требованиях к уровню качества? • Квалифицированный масштаб проекта, план-график и бюджет были рассмотрены совместно с организациями исполнителями, которые будут осуществлять деятельность по проекту? Эти и другие вопросы обеспечивают точки проверки на ранней стадии процесса разработки проекта, помогая обеспечить, чтобы официальное проектное предложение было осуществимым и целесообразным. Управление большой группой заинтересованных сторон на основе ряда решений часто требует значительного времени и несет риск проблемы обмена информацией. Несмотря на эту сложность и риск, однако, есть преимущества в прогрессивных решениях: • Это помогает гарантировать, что организация не вкладывает большого объема времени, денег, кадрового потенциала и организационного капитала в разработку проектных предложений, которые не имеют приверженности и поддержки со стороны ключевых лиц, принимающих решения (доноров, партнеров, ответственных за принятие решений лиц внутри агентства). • Это поддерживает надежный анализ концепции проекта, давая различные точки зрения и стимулируя коллективную ответственность за проект, когда начнется реализация. Это отображает процесс, посредством которого проект должен быть проверен, чтобы убедиться, что он имеет поддержку (как внутреннюю, так и внешнюю), которая требуется, чтобы, в конечном счете, проект был утвержден. В рамках модели фаз проекта «PMD Pro», время и место принятия решений представлены треугольниками, расположенными между фазами проектов. Иллюстрация 22. Пример логической схемы выбора решения на протяжении срока действия проекта. Guide to the PMD Pro стр. 37 из 12 Как было сказано, число логических решений в проекте будет меняться в зависимости от проекта, его сложности и ключевых заинтересованных сторон. По этой причине модель фаз проекта предназначена для использования в качестве иллюстративной модели, показывающей время и место принятия решений. Некоторые проекты могут иметь большее количество моментов принятия решений, другие, возможно, меньше. Однако в любом случае должно быть ясно, что система принятия решений помогает гарантировать, что инвестиции в проект не производятся без участия ключевых заинтересованных сторон. Распределение времени принятия решений через регулярные промежутки (например, в начале каждого года реализации проекта) позволяет: • поддерживать внимание проекта на потребностях, которые проект изначально определил, как приоритетные; • гарантировать, что контекст и предположения, которые изначально привели к утверждению проекта, все еще существуют; • предоставить возможность для команды проекта и ключевым заинтересованным сторонам решать, следует ли: o продолжать проект, как это задумано в начале; o изменить плана проекта; o прекратить проект (что не обязательно является провалом, если дальнейшее вмешательство не нужно, не осуществимо, или в нем нет необходимости). В приведенном ниже примере определяются три логические схемы принятия решений в рамках проекта «Дельта реки» на стадии определения и разработки проекта. ПРИМЕЧАНИЕ: Важно понимать, что логика принятия решений в проекте «Дельта реки» представляет лишь ОДНУ из МНОГИХ последовательностей, которые могут существовать в проектах развития, и этот пример только определяет логику решений на стадии определения и разработки проекта. √ Пример для изучения. Логическая схема выбора решения в проекте «Дельта реки». Результатами фазы идентификации и разработки проекта будут в этом случае следующие решения: Логическая схема выбора решения 1. Концепция проекта. Этот документ представляется внутренним заинтересованным сторонам в целях внутреннего разрешения проведения мероприятий по исследовательской оценке и анализу, а также для получения мнений и отзывов относительно разработки потенциального предложения. Логическая схема выбора решения 2. Выражение интереса. Настоящий документ представляется потенциальным донорам для получения зеленого света со стороны ключевых внешних заинтересованных сторон. Данный документ должен быть разработан в относительно короткий период времени с использованием ограниченных ресурсов и предназначен для обсуждения квалифицированной разработки проекта и получения мнения о проекте ДО выделения значительных ресурсов для разработки расширенного проектного предложения. Логическая схема выбора решения 3. Проектное предложение. На данном этапе разрабатывается официальный документ для получения одобрения финансирования проекта. Этот документ должен быть четким и более точным в описании стоимости, объема, сроков и качества10. Формат процесса разработки проектного предложения может варьироваться значительно в зависимости от размера проекта и требований доноров. 10 В английской аббревиатуре - CSSQ от английских слов «Cost», «Scope», «Schedule» and «Quality». Прим. переводчика Guide to the PMD Pro стр. 38 из 12 2.2.2. Фаза 2. Открытие проекта. Иллюстрация 23. Фаза открытия проекта. 2.2.2.1.Цель Каждый успешный проект начинается с тщательно спланированной и выполненной фазы открытия. Цели проекта на этой стадии включают в себя: 1. Создание структуры управления проектом. 2. Официальное разрешение на запуск проекта. 3. Информирование о запуске проекта. 2.2.2.2.Создание структуры руководства проектами. К сожалению, термин "руководство" часто вызывает в воображении образы бюрократических процедур и протоколов. Это не является намерением или умыслом в случае управления проектами. В контексте управления проектами руководство определяет рамки управления, в которых принимаются решения по проекту. Крепкая структура руководства разъясняет: Полномочия: кто имеет право принимать решения, и в каких допустимых уровнях; Ответственность: кто несет ответственность за успех проекта: при отсутствии четкой системы отчетности нет ни одного лица или движущей силы для решения проблем в проекте в целях успешной реализации проекта. Структуры руководства могут принимать различные формы. В своей простейшей форме структура руководства состоит из одного человека - спонсора проекта, и этого может быть достаточно. В этом случае ответственность спонсора проекта будет заключаться в следующем: • обеспечить исполнение организационных обязательств и ответственность за проект; • принимать решения о предлагаемых изменениях в проекте (объеме и содержании, бюджете, плане-графике, других), которые выходят за рамки допущений, согласованных с руководителем проекта; • осуществлять надзор за проектом, обеспечивать ресурсы, направление и понимание сути происходящего по мере необходимости; Guide to the PMD Pro стр. 39 из 12 • отслеживать непрерывную жизнеспособность проекта, принимать решение о прекращении проекта, если это необходимо; • поддерживать и консультировать руководителя проекта в управлении проектом, особенно по вопросам, которые выходят за пределы диапазона управления руководителя проекта; • вести работу по получению необходимой организационной поддержки и ресурсов для проекта; • гарантировать, что организация "владеет" процессами и результатами проекта, т.е. несет ответственность. И все же, в то время как структура руководства, состоящая из одного спонсора, может быть простой, она часто не представляет различные ракурсы проектов развития. Мы все знаем, однако, что проекты развития редко бывают простыми. В рамках проекта команда должна управлять различными заинтересованными сторонами, включая (но не ограничиваясь ими) доноров, исполняющих организаций, бенефициарных сообществ и поставщиков проекта. В этих сложных условиях один спонсор проекта не сможет оказывать поддержку команде проекта, которая требуется для достижения успеха. Более эффективной структурой руководства будет совет или правление проекта, в которое входят представители нескольких заинтересованных сторон, участвующих в проекте. Не существует какой-то одной определенной нормы для создания правления проекта, но следующие рекомендации дают представление о том, как правление или совет может быть структурирован и управляем. Размер: Не существует стандартного размера правления или совета проекта. Как минимум, должно быть два человека. Часто правление состоит из трех, четырех или пяти представителей. Как уже упоминалось, группы меньших размеров способствуют эффективному сотрудничеству и принятию решений. Тем не менее, часто бывает полезно расширить состав совета, когда управление заинтересованных сторон является сложным. Например, если есть несколько доноров, несколько групп получателей помощи, или несколько организаций, работающих над одним проектом. Состав: Члены совета или правления должны обеспечить наличие следующих особых знаний и опыта в управлении: • Руководящая перспектива, т.е. оценка, представляет ли проект ценность в целом, и обеспечивает ли финансовые средства и ресурсы, необходимые для достижения требуемой ценности. В правлении должен быть один представитель с руководящим взглядом. • Перспектива старшего пользователя – умение установить, что проект удовлетворяет потребностям людей, которые будут непосредственно работать с результатами или продуктами проекта. В правлении может быть несколько представителей с перспективой пользователей. Как вариант, можно создать "старшую группу пользователей" проекта, которая в свою очередь назначит одного представителя в правление представлять мнение всех групп пользователей. • Перспектива старшего поставщика – умение обеспечить, чтобы результаты проекта (из которых извлекается ценность) были достигнуты с имеющимися ресурсами и на должном уровне качества. В правлении может быть несколько представителей с перспективой старшего поставщика. Как вариант, можно создать "старшую группу поставщиков" проекта, которая в свою очередь назначит одного представителя в правление представлять мнение всех членов группы. Каждая перспектива или точка зрения членов правления отражает иное измерение проекта с точки зрения оценки средств, выделяемых на проект, понимания потребностей организации, пользователей и разработчиков (для принятия решений по непрерывной жизнеспособности проекта), а также взвешенной оценки результатов проекта. Каждый из них имеет свою собственную оценку того, что означает «успех», а все точки зрения в совокупности определяют успех проекта. Обязанности: Правление проекта коллективно отвечает за проект и в его обязанности входит: Guide to the PMD Pro стр. 40 из 12 • принимать решения о предлагаемых изменениях в проекте (объеме и содержании, бюджете, плане-графике, других), которые выходят за рамки допущений, согласованных с руководителем проекта; • осуществлять надзор за проектом, обеспечивать ресурсы, направление и понимание сути происходящего по мере необходимости; • отслеживать непрерывную жизнеспособность проекта, принимать решение о прекращении проекта, если это необходимо; • представлять интересы перспектив, которые они представляют; • поддерживать и консультировать руководителя проекта в управлении проектом, особенно по вопросам, которые выходят за рамки компетенции руководителя проекта; • вести работу по получению необходимой организационной поддержки и ресурсов для проекта; Совещания: Рекомендуется проводить регулярные совещания по проекту, на которых повестка дня устанавливается руководителем проекта в сотрудничестве с представителем руководящей перспективы. Важные пункты повестки дня включают рассмотрение журналов учета проблем и рисков, которые будут обсуждаться позже. Кроме того, заседания правления проекта необходимы на всех этапах принятий решений. Иногда возникает замешательство, должно ли правление проекта действовать как простая демократия, когда каждый член совета имеет равный голос при голосовании по важнейшим решениям. Важно признать, что не все голоса в правлении имеют равные полномочия по всем решениям. Если, например, есть необходимость запросить увеличения бюджета или продления срока проекта, возможно, опрашивается мнение всех членов правления, но конечное решение принадлежит исключительно одному члену правления (скорее всего, в этом примере, члену с руководящей перспективой), или небольшой группе членов совета. Следует помнить, что эффективность принятия решения может быть обратно пропорциональной размеру группы людей, принимающих решение. Большая группа может быть не только не в состоянии своевременно принять решение, но и качество решения может зависеть от проблем управления группой. 2.2.2.3.Официальное разрешение начала проекта. Если проект следует модели логической схемы принятия решений, решения типа «двигаться вперед» или «не двигаться вперед», будет принято до этапа открытия проекта, например, когда разрабатывается концептуальный документ, или когда делается заявление об интересе в проекте, или когда рассматривается и утверждается проектное предложение. На этапе начала проекта важно гарантировать, что проект официально разрешен руководящим органом проекта (который может состоять из спонсора проекта или правления проекта). Это разрешение должно быть документировано посредством разработки устава проекта, документа, который обеспечивает квалифицированное описание проекта, и который подписывается руководящим органом проекта. Содержание устава может быть разным, но обычно включает в себя заявления в отношении: • цели проекта, в том числе формулировку потребностей, которыми будет проект заниматься. • результатов проекта - формулирование объема и содержания проекта, включая цель проекта, продукты и основные последствия. • квалифицированной проектно-сметной документации, в том числе квалифицированные заявления: Ø о проектной деятельности; Ø о плане-графике проекта; Ø о бюджете проекта, и Ø предварительный перечень ролей и навыков, необходимых для выполнения требуемых работ. Guide to the PMD Pro стр. 41 из 12 • рисков проекта - выявление потенциальных проблем / рисков, с которыми проект может столкнуться. • проектных допустимых отклонений - формулирование допустимых отклонений от продуктов проекта, плана-графика, затрат и рисков. • управления изменениями проекта - создание процесса обработки исключений, когда проект превышает допустимые отклонения в любой из этих областей. Как только устав разработан и подписан, важно, чтобы он не был положен на полку и забыт. Устав проекта очень полезный документ, который можно использовать для выполнения следующих задач: • для официального разрешения начала проектной деятельности и использования ресурсов для осуществления проекта; • для обеспечения общего понимания параметров проекта среди основных заинтересованных лиц и спонсоров проекта (внутренних и внешних); • для документирования общей приверженности целям проекта и ресурсов / мероприятий, необходимых для успеха проекта. Кроме того, устав следует считать действующим, рабочим документом: если руководящий орган проекта утверждает крупные изменения в проекте (сфера действия, бюджет, график или иные), устав должен обновляться и подписываться в соответствии с новыми параметрами проекта. Таким образом, устав проекта является помощником руководителя проекта, и в отсутствии уставного документа проектная команда рискует тем, что: • сотрудники начнут тратить время, деньги, материалы, персонал и организационный капитал на выполнение проекта с неопределенными обязательствами и поддержкой со стороны ключевых лиц, принимающих решения (доноров, партнеров, лиц, принимающих решения внутри организации); • ключевые заинтересованные стороны не будут иметь общего понимания проекта о сфере деятельности, бюджете, плане, общественно-полезных результатах и рисках. 2.2.2.4.Сообщение о запуске проекта. Одной из основных задач начала проекта является сообщение о запуске проектной деятельности многим заинтересованным сторонам, которые имеют интерес во внедрении. Эти заинтересованные стороны могут включать бенефициарное сообщество, НПО, работающих в области внедрения, представителей министерств, общественности и многих других лиц. Есть множество информационных средств, которые могут использоваться для объявления о запуске проекта сообществу заинтересованных сторон. Однако, независимо от механизма, цель мероприятий по распространению информации о запуске проекта остается неизменной: • официально признать начало проекта; • обеспечить, чтобы основные заинтересованные стороны имели согласованное понимание проекта; • ввести заинтересованных сторон в проект. Во многих отношениях подписанный устав проекта является идеальным документом, через который официально сообщается о запуске проекта широкому кругу лиц. Благодаря своей краткой, сжатой форме, устав проекта особенно хорош для информирования об основных параметрах проекта. В результате, этот документ очень удобен в работе с некоторыми людьми, у которых наблюдается непреднамеренная или иная забывчивость. Распространение устава проекта большому сообществу заинтересованных сторон является не только эффективной практикой информирования, но также является способом обеспечения прозрачности и подотчетности в проекте. Однако если у сотрудников проекта есть основания не делиться всеми элементами устава проекта с большим сообществом заинтересованных сторон, есть другие варианты и механизмы информации. Guide to the PMD Pro стр. 42 из 12 Если есть важная информация, она может быть включена в измененный вариант устава проекта, который может быть предоставлен широкой общественности. Кроме того, статьи в газетах, прессконференции, ознакомительные поездки, встречи и мероприятия, посвященные запуску проекта, также могут быть использованы для информирования большого сообщества. Информация в таких сообщениях может меняться в зависимости от аудиторий и их связи с проектом. Важно, однако, чтобы, по крайней мере, важные параметры проекта стали известны заинтересованным сторонам, прежде чем начнется реализация проекта. 2.2.3. Фаза 3. Планирование проекта. Иллюстрация 24. Фаза планирования проекта. 2.2.3.1.Цель Обычно к тому времени, когда проект официально вступает в стадию планирования, сотрудники уже имеют ряд разработанных документов (например, логическую основу проекта, устав, и т.п.), которые имеют достаточный уровень деталей, относящихся к проекту: • Цель, результаты, последствия. • Масштаб (объем и содержание) деятельности. • Показатели и средства проверки. • Бюджет. • План-график. Важно, однако, не путать проектное предложение, логическое обоснование проекта или иные документы, разработанные на этапе идентификации и инициирования проекта, с проектным планом. План проекта значительно отличается от других документов по формату, целям, аудитории, по уровню детализации, участию, срокам и ограничениям графика. Хотя некоторые считают, что логическое обоснование проекта и/или проектное предложение дает приемлемый уровень информации, чтобы такой документ мог служить в качестве плана проекта, эти документы редко дают достаточный уровень деталей для исполнения проекта, т.к. они написаны для других целей. Возьмем, например, проектное предложение в сравнении с планом реализации проекта. Иллюстрация 25 показывает разницу между двумя документами с точки зрения целей, формы, уровня деталей Guide to the PMD Pro стр. 43 из 12 (обратите внимание, что точно также можно сравнить логическую основу проекта и план реализации проекта). Иллюстрация 25. Сравнение проектного предложения с планом реализации проекта. Цель Формат Уровень детализации Участие Аудитория Сроки и планграфик Проектное предложение Получить одобрение и финансирование для проекта, придавая особое значение четкой сжатой информации об идеях, которые «продают» проект финансирующим заинтересованным сторонам. Формат часто определяется требованиями доноров и агентств заинтересованных сторон, ответственных за инвестиционные решения. Предложение часто ограничено в уровне детализации из-за цели, формата, ожиданий, расписания и сроков предложения. Часто пишется небольшой группой в результате временных ограничений, которые ограничивают участие. Направлено на доноров и заинтересованных лиц, которые распределяют ресурсы. Часто пишется в условиях ограниченного времени, иногда в течение месяцев (или даже нескольких лет) до реализации. План реализации проекта Обеспечить, чтобы проект исполнялся вовремя в соответствии с объемом, содержанием, бюджетом и установленными параметрами качества, придавая особое значение всестороннему логическому планированию и моделированию проекта для рассмотрения проектной группой и другими заинтересованными сторонами. Формат определяется проектной командой и ключевыми заинтересованными сторонами. Уровень детализации разрабатывается командой проекта и ключевыми заинтересованными сторонами Существует возможность расширения участия для включения целого ряда заинтересованных сторон, включая специалистов и технических консультантов. Ориентирован на потребности группы, реализующей деятельность по проекту. Существует возможность пересмотреть предложение для дальнейшей разработки, пересмотра, обновления планов в начале реализации проекта или в ключевых моментах жизненного цикла проекта. Несмотря на то, что существуют значительные различия между целью, процессом и содержанием предложения по проекту и планом реализации проекта, многие организации развития используют проектное предложение в качестве плана реализации проекта. Это особенно часто случается, когда формат предложения основан на требованиях доноров, в результате чего предложение очень приближено к проектному плану с точки зрения размера и уровня детализации. Обратите внимание, что даже самые пространные предложения по проектам (а многие из них могут превышать 100 страниц) все же имеют недостатки, которые ограничивают их эффективность в планировании реализации проекта. Формат и элементы планов реализации проекта варьируются в зависимости от организации, донора и/или проекта. Однако, независимо от формата документа, все планы реализации проекта (по сравнению с результатами, которые инициируются на более ранних этапах) должны учитывать принципы управления проектами «PMD Pro»: − Планирование реализации проекта должно быть сбалансированным! − Планирование реализации проекта должно быть всесторонним! − Планирование реализации проекта должно быть интегрированным! − Управление проектами должно быть с совместным участием! Guide to the PMD Pro стр. 44 из 12 − Управление проектами является итерационным! 2.2.3.2.Планирование реализации проекта должно быть сбалансированным. Помните! В модели проектов «PMD Pro» существует шесть фаз. Управление проектами должно быть сбалансированным для обеспечения, чтобы все виды деятельности, бюджет и календарные сроки, необходимые для проведения работ, связанных с каждой из этих фаз, выполнялись. Очевидно, что план реализации будет включать в себя информацию, необходимую для завершения работ на стадии реализации. Кроме того, важно, чтобы этот план включал другие планы, необходимые для управления другими фазами проекта, в том числе: • Планирование начала проекта: к тому времени, когда разработан подробный план реализации проекта, большинство мероприятий по запуску проекта уже будут завершены. Тем не менее, не стоит забывать, что управленческая деятельность, которая начата в начале проекта, должна продолжаться в течение всего срока реализации проекта. Это может означать, например, составление расписаний и бюджета заседаний правления проекта. • Планирование планов проекта: планы проекта не являются статичными. Рекомендуется пересматривать планы на регулярной основе и обновлять их с учетом последних данных мониторинга. В таком случае практика пересмотра планов проекта должна включать в себя возможность и ресурсы, чтобы сотрудники и ключевые заинтересованные стороны могли вернуться к планам, чтобы убедиться, что планы являются надлежащими, точными и реалистичными. • Планирование реализации проекта: очевидно, что реализация займет большую часть документа планирования, который должен включать детальный план реализации, привязанный к срокам по каждому компоненту проекта, в том числе конкретные действия, необходимые для достижения целей проекта развития. • Планирование мониторинга и оценки проекта: мероприятия, связанные с мониторингом и оценкой, имеют решающее значение для успеха проекта. Чтобы они состоялись, такие мероприятия обязательно должны быть включены в план проекта. Критические вопросы, на которые должны иметься ответы в плане, включают вопросы: кто отвечает за сбор данных; обработку данных мониторинга; анализ данных; документирование результатов; передачу информации; когда будут проводиться мероприятия; как будут данные использоваться; будет ли проводиться оценка данных, и если да, когда, и какая; какие ресурсы будут необходимы для исполнения оценки. • Планирование переходного периода проекта: какие шаги должны быть предприняты в конце проекта? Какие мероприятия необходимо провести для административного и контрактного закрытия? Будет ли проект передаваться другим заинтересованным сторонам? Если да, какие вложения нужно сделать, чтобы передача была успешной? 2.2.3.3.Планирование должно быть всесторонним. В дополнение к сбалансированному планированию план должен комплексно охватывать все работы, необходимые для обеспечения успеха проекта. Всесторонний или всеобъемлющий план проекта включает в себя все элементы планирования, необходимые для доставки прямых результатов проекта (построенные туалеты; обученные медицинские работники; принятые методы сельскохозяйственных работ; и т.п.), а также элементы планирования, необходимые для завершения косвенных работ, связанных с проектом. В частности, комплексный план проекта будет включать в себя подробную информацию о каждом из следующих элементов управления проектами. Guide to the PMD Pro стр. 45 из 12 Иллюстрация 26. Элементы всестороннего проекта. • Планирование управления масштабами (объемом и содержанием) проекта: как будут управляться и контролироваться содержание и объемы проекта (продукция, услуги и работы, необходимые для достижения этих результатов) на протяжении всей жизни проекта? • Планирование управления сроками проекта: какие процессы и инструменты должны быть использованы для оценки требований к срокам проекта, и как календарь проекта будет управляться в течение действия проекта? • Планирование управления обоснованием проекта: какими потребностями будет заниматься проект, какие ресурсы, потребляемые проектом (деньги, время, репутация организации, усилия) способствуют эффективному вкладу в реализацию общественно-экономической пользы? • Планирование управления заинтересованными лицами проекта: кто является отдельными лицами, группой лиц или учреждений, на чьи интересы положительно или отрицательно может повлиять выполнение или отмена проекта? Как эти заинтересованные стороны будут вовлечены в проект в течение всего срока его реализации? • Планирование управления рисками проекта: как проект будет выявлять, анализировать, отслеживать и управлять проектными рисками? • Планирование управления ресурсами проекта: какие процессы и системы существуют для приобретения и управления оборудованием и материалами, для управления финансами, а также для управления человеческими ресурсами? Какие критерии должны быть соблюдены для того, чтобы план-график был успешно выполнен? В центре этих шести элементов комплексного плана проекта находится планирование координирования проекта. План проекта должен также включать план, как различные заинтересованные стороны будут работать вместе. Что является нормой совместной работы? Понятны ли роли и обязанности? Как сотрудники проекта будут сообщать обновленную информацию заинтересованным сторонам? Какие механизмы сообщений будут использоваться? Кто отвечает за связь? Формат планов реализации будет значительно отличаться. В некоторых случаях элементы комплексного плана включаются в единый документ плана реализации проекта. В других случаях план реализации проекта состоит из нескольких документов. Обычно основной план проекта дополняется отдельными планами, которые обеспечивают более глубокий уровень детализации по конкретной области планирования проекта. Например, проект может иметь основной план Guide to the PMD Pro стр. 46 из 12 реализации и конкретный план по мониторингу и оценке проекта. Точно также, в зависимости от размера, сложности и рисков проекта, команда может решить иметь отдельные документы, которые непосредственно направлены на проектные закупки, связь, управление кадрами, и т.п. Каждый из этих планов должен быть согласован и связан с другими документами, которые составляют комплексный план реализации проекта. Целью плана реализации проекта является обеспечение модели проекта. Это обеспечивает сотрудников проекта средой с низким уровнем риска и низкими затратами, в которой они могут изучить и тестировать альтернативы проекта, определить сценарии «на случай, если…», и рассмотреть альтернативные подходы ДО того, как затрачены ресурсы проекта, и время ушло. 2.2.3.4.Планирование реализации должно быть интегрированным. Помните треугольник ограничений проекта? Одной из главных мыслей изображенного треугольника является то, что ограничения связаны между собой, что делает невозможным изменить одно без влияния на другие. Эта динамика продолжается в контексте плана реализации проекта. Каждый из элементов плана реализации проекта связан с другими. Это проявляется в том, что обширные связи существуют между различными элементами комплексного плана реализации, некоторые из которых включают следующее: − Решения, касающиеся бюджета, зависят от решений, которые должны быть сделаны по объемам и содержанию работ. − Решения, связанные с календарными датами, зависят от решений, которые должны быть сделаны по материально-техническому обеспечению или логистике. − Решения, связанные с сообщениями, зависят от решений, которые должны быть сделаны по кадрам. − Решения, связанные с мониторингом, зависят от выбора, сделанного в связи с рисками. Этот перечень содержит лишь несколько примеров связей, существующих в комплексном проектном плане. Эти примеры подчеркивают, однако, важность обеспечения того, чтобы все эти области деятельности были интегрированы в план реализации. 2.2.3.5.Планирование реализации должно быть совместным. Участие и процессы участия поощряются и имеют приоритет на каждом этапе проектного цикла в секторе развития. Тем не менее, во время идентификации и разработки проекта нередко можно встретить ситуации, когда процесс разработки проектного предложения включает лишь ограниченное участие заинтересованных сторон. Это нежелательный сценарий, и он часто связан с рядом причин: • График разработки предложения по проекту часто ускорен из-за нехватки времени. Часто спонсоры дают организации только один или два месяца между объявлением возможностей финансирования и датой подачи заявки (в чрезвычайных условиях этот срок может быть равен 24 часам). В таких ситуациях организация вынуждена завершить все шаги по оценке проекта, анализу и логическому проектированию, а также определить первоначальное время и место принятия решений, требуемых для разработки и подачи проектного предложения в очень короткие сроки. Одним из многих негативных влияний таких временных ограничений является то, что они не дают возможности организации проконсультироваться и интенсивно сотрудничать с ключевыми заинтересованными сторонами проекта на этапе идентификации и разработки проекта. • Проектные предложения часто разрабатываются небольшими группами людей. Учитывая, что аудитория проектного предложения это, как правило, заинтересованные стороны, которые обладают властью принятия решений о финансировании (внешние доноры или группы лиц внутри организации), команда разработки проектного предложения часто больше сосредоточена на том, как лучше «продать» проект. Поэтому в ней работают люди, которые лучше всего умеют писать предложения и определять процесс подачи заявки. Это может привести к снижению внимания, общения и сотрудничества с основными заинтересованными сторонами в процессе разработки заявки. Guide to the PMD Pro стр. 47 из 12 • Проектное предложение не призвано служить всеобъемлющим документом планирования. В то время как определенный уровень детализации (от среднего до высокого) включается в проектное предложение, часто детали проекта не прорабатываются до тех пор, пока не разработан план реализации. В это время люди наиболее близкие к реализации проекта имеют неоценимое значение для проведения точных расчетов (время, деньги, ресурсы и персонал), необходимых для выполнения работы по проекту. По всем этим причинам важно, чтобы сотрудники проекта воспользовались возможностью, которую предлагает процесс планирования реализации проекта, для интенсивного вовлечения заинтересованных сторон более широко и всесторонне, чем это было возможно при идентификации проекта и на этапе разработки проекта. Процесс планирования проекта должен вовлекать всех членов коллектива, а также соответствующих заинтересованных сторон в зависимости от их влияния на проект и его результаты. Участие в процессе планирования имеет несколько преимуществ, в том числе следующие: 1. Заинтересованные лица имеют опыт и знания, которые могут быть полезны для разработки точных расчетов и оценок в отношении бюджета, требований времени, уровня усилий и других ресурсов, необходимых для завершения работы над проектом. 2. Заинтересованные стороны проекта часто находятся в лучшем положении для выявления потенциальных рисков проекта и составления планов по смягчению их последствий. 3. Новый персонал и/или сотрудники партнера могут извлечь выгоду из улучшенной ориентации проекта, когда они участвуют в планировании деятельности. Эти мероприятия помогают обеспечить общее понимание результатов и последствий проекта. 4. Заинтересованные стороны, вовлеченные в процесс планирования проекта, скорее всего, возьмут на себя руководство, ответственность и участие в деятельности проекта. В это же время сотрудники проекта могут переубедить лиц, которые выступают против проекта, в результате обсуждения вопросов, вызывающих их беспокойство, и пересмотра сферы деятельности (или элементов проекта) для устранения их обеспокоенности. 2.2.3.6.Планирование является повторяющимся процессом. На протяжении проекта важно относиться к плану реализации, как к «живому» документу, а не как к статическому и неизменному. Модель фаз проектов «PMD Pro» явно представляет этап планирования как часть цикла, включающего реализацию, мониторинг, оценку и контроль. Вместе эти три фазы дают понимание и знания, необходимые для плана реализации проекта и его обновлений. Со временем изменения в плане реализации проекта помогают обеспечить более подробные графики, затраты и ресурсы, необходимые для достижения определенного объема проекта. Этот повторяющийся процесс повышения уровня детализации плана исполнения проекта с течением времени часто называют «волнообразное планирование». Итерация, по определению, является актом повторения задачи два, три или более раз для достижения желаемого результата. Волнообразное планирование может быть особенно полезно в ситуациях, когда информацию о проекте трудно собрать, или она меняется очень быстро (например, при работе с высоким риском или в аварийных условиях). В этих ситуациях по мере получения новой информации о проекте будут определяться дополнительные зависимости, требования, риски, возможности, допущения и ограничения. Существенные изменения в любой из этих областей, происходящих в течение жизненного цикла проекта, могут вызвать необходимость изменения одного или нескольких элементов плана реализации проекта. Волнообразное планирование, однако, не ограничивается исключительно чрезвычайными условиями. Одна из организаций, которая использует политику подвижного планирования проектов развития – это Межамериканский Банк Развития. Каждый из его проектов утверждается через многолетнее предложение. Получатели проекта, однако, должны представлять годовые планы работы для каждого года проекта. Эти ежегодные планы служат не только гарантией того, что расчеты по проектной работе являются точными и актуальными, но и служат основой для принятия решения, стоит ли продолжать проект, задуманный в многолетнем Guide to the PMD Pro стр. 48 из 12 плане, или надо пересмотреть план, если это необходимо. Процесс рассмотрения и утверждения ежегодных планов является возможностью проверить предположения, которые легли в основу разработки проекта, а также подтвердить наличие необходимых ресурсов, оценить внешний контекст проекта / риск, и проследить за вертикальной логикой проекта. 2.2.4. Фаза 4. Реализация проекта. Иллюстрация 27. Фаза реализации проекта. Повседневной работой в реализации проекта является руководство и управление применяемым планом реализации проекта. Эта задача может быть относительно простой, а может стать чрезвычайно сложной, в зависимости от характера проекта. В управлении проектами успешная реализация частично является искусством (искусством управления людьми, руководства коллективом, четкой передачи сообщений), но также и наукой. В простом виде ответственность руководителя проекта заключается в исполнении плана проекта. Однако при ближайшем рассмотрении становится ясно, что руководитель проекта должен применять ряд технических навыков, чтобы преуспеть в ходе реализации. Эти навыки включают в себя: • умение управлять проблемами; • умение управлять людьми; • умение управлять внутренними системами контроля. 2.2.4.1.Управление проблемами. В мире бокса говорится, что «у каждого есть план, пока он не получит удар». Такая же динамика существует при управлении проектом. Так же, как у боксера на ринге, жизнь руководителя проекта является рискованной, сложной, а иногда и просто беспорядочной. Даже при наличии всеобъемлющего и подробного плана будут «удары», т.е. проблемы, которые бросают вызов проекту при его реализации. Как и любой хороший боксер, руководитель проекта должен научиться управлять проблемами, ориентироваться в сложностях и адаптировать планы для отражения последней реальности. Проблемой является нерешенный вопрос, непринятое решение, ситуация или проблема, которая может существенно повлиять на проект, и которую сотрудники проекта не могут сразу решить. Управление проблемами состоит из процесса выявления этих проблем и управления ими, пока они не будут решены. Решение вопросов часто находится вне компетенции сотрудников. Однако даже если вопрос должен быть передан на следующий уровень или делегирован другому лицу для решения, он все же должен отслеживаться руководителем проекта. Руководитель проекта должен быть готов на протяжении всего этапа реализации проекта применять ресурсы для решения проблем. Управление проблемами является совместной деятельностью. Следовательно, каждый сотрудник проекта несет ответственность за следующее: Guide to the PMD Pro стр. 49 из 12 • выявление проблем в проекте; • содействие решению проблем (обратите внимание, опыт показывает, что люди, находящиеся ближе всего к работе, обычно лучше знают, как решить возникшие проблемы, поэтому работа руководителя проекта заключается в создании такой среды, в которой каждый член команды в состоянии решить многие вопросы на своем уровне); • передачу информации о важных вопросах руководителю проекта в кратчайшие сроки. Несмотря на то, что управление проблемами является совместной деятельностью, руководитель проекта, в конечном счете, несет ответственность за управление проблемами (напомним, что в схеме распределения ответственности (RACI) указан только один человек, ответственный за конкретную задачу или мероприятие). Хорошо документированный процесс управления проблемами имеет решающее значение для информирования и распространения процесса среди всех сотрудников. Если проблемы не решены, могут возникнуть негативные последствия: • невозможность исполнить проект в указанные сроки, с указанной стоимостью и с определенным планом-графиком; • плохое или неприемлемое качество проекта; • плохая репутация среди общества, доноров и иных лиц; • разногласия после реализации. Как человек, управляющий всеми вопросами, руководитель проекта должен управлять всеми процессами урегулирования проблем. 1. Определение и отслеживание проблем: выявление нерешенных вопросов, решений и других проблем до того, как они начнут отрицательно влиять на проект. Таким образом, процесс идентификации и отслеживания проблем тесно связан с темой управления рисками (который рассматривается в главе, посвященной мониторингу, оценке и контролю в этом документе). Таким образом, этапы реализации, мониторинга, оценки и контроля тесно связаны и обычно работают параллельно. 2. Анализ проблем, т.е. руководитель должен иметь достаточное понимание вопроса, чтобы учесть будущие последствия плана действий, направленных на решение вопроса. 3. Информация о проблеме: сообщать вопросы на нужный уровень организации для решения. Кроме того, важно также сообщать, когда и как проблема решена. 4. Контроль и управление проблемами: руководитель проекта несет ответственность за создание среды, в которой сотрудники проекта и партнеры могут осуществлять меры по обеспечению решения проблем своевременным и эффективным образом. Процесс управления проблемами тесно связан с мониторингом, оценкой и контролем над деятельностью, и должен включать в себя создание и отслеживание плана для решения проблем. Наиболее важным инструментом контроля является журнал учета проблем, в котором обобщены вопросы, описывается их текущее состояние и определяется, кто является ответственным за решение этого вопроса. Журнал может иметь различные технические формы: от бумажной формы до полностью интегрированной базы данных. Пример формата можно найти в таблице ниже. Иллюстрация 28. Журнал учета проблем. Проблема Кем сообщена Guide to the PMD Pro Описание Когда доложена (дата) Передана для решения (кому) Дата назначения Статус Дата статуса Решение стр. 50 из 12 Помните, что совершенная система управления проблемами дорого стоит, если ее вообще можно создать. Нормальным считается некоторый уровень несовершенства из расчета компромисса между ценой, затратами, общественно-экономической пользой, рисками и временем. 2.2.4.2.Управление людьми. Важность сильного управления людьми не может быть переоценена. Руководители проектов работают в коллективе и часто могут достичь своих целей только в результате обязательств, сотрудничества и вклада людей, составляющих команду проекта. В результате, управление людьми может стать наиболее важной и самой трудной работой руководителя проекта. Чаще всего, когда мы думаем о руководителях проектов, которые особенно талантливы в управлении людьми, мы склонны обращать внимание на их, так называемые, «второстепенные» или «мягкие»11 навыки управления людьми. Такие руководители проектов особенно эффективны в мотивации членов команды, в передаче видения, расширении полномочий и возможностей сотрудников, они признают достижения, умеют слушать людей, руководят на примерах, разрешают конфликты и укрепляют доверие. Все эти "мягкие навыки" относятся к межличностной компетенции менеджера проекта и чрезвычайно важны для успеха проекта. Поэтому руководители проектов должны стремиться к повышению своей способности вести за собой, мотивировать, вдохновлять, быть посредниками, общаться и поощрять. Это не означает, однако, что не существует «жестких навыков» в управлении людьми. Комплексный план проекта не может полагаться исключительно на межличностные навыки руководителя проекта для обеспечения успеха в управлении людьми. Напротив, комплексный план проекта должен определить конкретные мероприятия, необходимые для активного управления всеми элементами коллектива проекта. Эти конкретные мероприятия будут осуществляться в течение фазы реализации проекта. Они включают: • Приобретение персонала для проекта: в рамках функции управления коллективом руководитель проектной группы должен знать системы идентификации кандидатов, уметь проводить собеседования с кандидатами, определять критерии отбора и принимать окончательные решения в выборе сотрудников проекта. • Написание должностных инструкций для персонала: описание должностных инструкций включает перечень обязанностей по проекту, роли и обязанности членов команды. Должностные инструкции могут использоваться не только в процессе найма, ориентации и управления персоналом, но также используются при проведении оценки работы каждого сотрудника. • Документирование организационных схем проекта: схемы проекта представляют систему подотчетности между членами коллектива проекта. • Развитие персонала проекта: какие навыки необходимы, каковы потребности в обучении, есть ли требования по сертификации? • Проведение оценки работы: оценка работы – это документированная официальная или неофициальная оценка деятельности сотрудников проектной группы. После анализа информации руководители проектов могут выявлять и решать проблемы, снижать конфликты, а также улучшать общую работу команды. • Создание норм общения между сотрудниками: как лидер команды проекта, руководитель проекта должен конкретно планировать общение (через встречи, семинары, доклады, записки, информационные бюллетени, блоги и т.д.), что позволяет команде проекта обмениваться информацией, активно проводить работу по выявлению проблем и конфликтов, а также взаимодействовать творчески для решения проблем. 11 «Мягкими навыками» называются желаемые качества человека, которые не зависят от приобретенных знаний: здравый смысл, способность поддерживать отношения с людьми, позитивное гибкое отношение. Прим. переводчика Guide to the PMD Pro стр. 51 из 12 2.2.4.3.Управление системами внутреннего контроля. Одной из задач руководителя проекта является наблюдение за ценными активами, которые выделены для проведения работ по проекту. Для оказания помощи в этом вопросе у организации должны иметься системы внутреннего контроля для обеспечения достаточной уверенности в ответственном использовании активов проекта. Процессы внутреннего контроля должны быть разработаны с целью: − содействия эффективности и результативности деятельности; − повышения достоверности результатов проекта; − содействия соответствию с действующими законами и правилами; − защиты ресурсов организации, как материальных (например, техники и имущества), так и нематериальных (например, репутации, интеллектуальной собственности); − снижения риска мошенничества и коррупции. Внутренний контроль включает процессы, посредством которых ресурсы организации распределяются, отслеживаются и измеряются. Они играют важную роль в предотвращении и выявлении случаев мошенничества и защите ресурсов организации, как физических (например, техники и имущества), так и нематериальных (например, репутации или интеллектуальной собственности, такой как товарные знаки). На организационном уровне цели внутреннего контроля связаны с достоверностью финансовой отчетности, своевременной обратной связью о достижении оперативных и стратегических целей, и соблюдением законов и правил. Ключевой компонент организационного потенциала проекта включает в себя создание систем внутреннего контроля, которые комплексно занимаются всеми системами поддержки, административными и логистическими системами, необходимыми для успешной реализации проекта. Ниже перечислены отделы и компоненты проектов, для которых внутренний контроль имеет большое значение. • Системы и потенциал кадров: √ Имеются ли кадровые политики в соответствии с местными законами и правилами организации? √ Имеются ли системы учета рабочего времени, проверки производительности, отстранения сотрудников? • Закупки √ Имеется ли система выбора поставщиков? √ Есть ли критерии выбора поставщиков? √ Имеется ли система управления поставщиками? √ Имеется ли подобная система для консультантов? • Финансы √ Имеется ли система управления денежными средствами? Управления расходами? Финансовой отчетности? √ Есть разделение обязанностей по финансовым ролям? • Товарно-материальные запасы √ Имеется ли система определения и отслеживания запасов? √ Имеется ли система использования / передачи / распоряжения оборудованием после завершения проекта? • Договоры и соглашения √ Имеется ли система управления грантами? √ Какая система существует для управления отношениями с организациями-исполнителями? • Инфраструктура √ Какая система связи существует? Телефон, Интернет, радио? √ Какая имеется система для управления транспортными средствами и транспортом? • Протоколы безопасности Guide to the PMD Pro стр. 52 из 12 √ Есть ли необходимость в специальных мерах безопасности? В руководстве для поездок? Для сопровождения программ? Других? • Управление автопарком √ Имеются ли журналы учета пробега и контроля за использованием служебных автомобилей? • Управление информацией √ Имеется ли система хранения документов (бумажных / электронных)? √ Какие политики и стандарты существуют для управления информацией? √ Имеются ли в наличии документы, договоры и квитанции для удовлетворения требований аудита проекта? Таким образом, важно признать, что внутренний контроль может обеспечить только разумную уверенность, но не абсолютную уверенность, в отношении достижения целей организации. Кроме того, плохой или чрезмерный внутренний контроль снижает производительность, повышает сложность систем, увеличивает время, необходимое для завершения процессов, и не добавляет ценности для деятельности. Хороший внутренний контроль необходим для обеспечения выполнения целей и задач. Он помогает обеспечить эффективные и действенные операции, достижения целей проекта, а также защищать сотрудников и активы. 2.2.5. Фаза 5. Мониторинг, оценка и контроль. Иллюстрация 29. Мониторинг, оценка и контроль. Даже хорошо продуманные, всесторонне запланированные, полностью обеспеченные ресурсами и тщательно выполненные проекты будут сталкиваться с проблемами. Эти проблемы могут иметь место в любой точке жизненного цикла проекта, и проектная команда должна постоянно возвращаться к разработке, планированию и реализации проекта в целях подтверждения, что они действительны, и для определения, какие корректирующие действия должны быть предприняты, когда исполнение проекта значительно отклоняется от своего предназначения и плана. Это и есть цель фазы мониторинга, оценки и контроля. Не удивительно, что три основных вида деятельности происходят во время фазы мониторинга, оценки и контроля: • Мониторинг проекта; • Оценка проекта; • Контроль Эти мероприятия должны происходить непрерывно и постоянно на протяжении срока действия проекта. Поэтому модель фаз проекта «PMD Pro» включает в себя фазу мониторинга, оценки и контроля фазы в качестве фона, который простирается от первых задач по идентификации и разработке проекта до последней задачи в период фазы завершения проекта. Например, самые ранние Guide to the PMD Pro стр. 53 из 12 показатели проекта разрабатываются уже в ходе определения и разработки проекта, план мониторинга разрабатывается на этапе планирования, мониторинговые посещения проводятся на этапе реализации проекта, а многие виды мероприятий по оценке проводятся в конце проекта в фазе переходного периода. 2.2.5.1.Дифференциация мониторинга, оценки и контроля. Прежде чем рассматривать каждую из трех категорий деятельности на этапе мониторинга, оценки и контроля в деталях, надо определить различие между ними. Мониторинг прогресса отслеживает оперативную работу по проекту. Он отвечает на вопросы типа: выполнены ли мероприятия, как планировалось; результаты получены, как ожидалось; работа по проекту идет, как прогнозировалось? На фундаментальном уровне это пассивный процесс, он ничего не меняет. Он сообщает руководителю проекта, в каком состоянии находится работа по проекту в денежном выражении, по времени, рискам, качеству и другим компонентам реализации проекта. По сути, цели, задачи, сроки и мероприятия по мониторингу хода выполнения проекта, возможно, лучше всего определяются по следующей таблице. Что Зачем Когда Как Иллюстрация 30. Вопросы мониторинга: что, зачем, когда и как. Постоянная проверка прогресса проекта на уровне мероприятий и результатов (продукции). Время определения необходимых коррективных действий. Для анализа текущей ситуации, для определения проблем и поиска решений. Для обнаружения направлений и моделей. Для поддержания мероприятий проекта по графику. Для измерения прогресса по результатам. Для принятия решений по людским, финансовым и материальным ресурсам. Постоянно. Посещения на места работы. Записи. Отчеты. Если вы исследуете показатели в логической схеме проекта, мероприятия по мониторингу прогресса в первую очередь соответствуют нижним двум уровням логической структуры (мероприятия и результаты). Ниже приводится таблица, показывающая некоторые потенциальные индикаторы мониторинга в трех различных программных областях внедрения: сельское хозяйство, микрофинансирование и водоснабжение. Иллюстрация 31. Примеры показателей мониторинга. Сельское Микрофинансирование хозяйство Результаты Кол-во созданных Кол-во клиентов, материальные фермерских групп. получающих и продукты или Компетентность правильно услуги фермеров использующих кредит. Кол-во клиентов, участвующих в программе сбережений. Мероприятия – Кол-во посещений Кол-во посещений задачи или фермерских деревень сотрудниками. действия, хозяйств. Кол-во учебных сессий предпринятые Кол-во по банковским вопросам для исполнения организованных – компетентность внедрения обучающих сессий. обучающихся. проекта. Guide to the PMD Pro Водоснабжение Кол-во установленных и хорошо работающих новых систем водоснабжения. Кол-во сообществ, организованных для установления систем водоснабжения. стр. 54 из 12 Оценка проекта имеет тенденцию сосредотачиваться на отслеживании прогресса на более высоких уровнях логической структуры - то есть на уровне результатов проекта. Оценки, как правило, исследуют такие вопросы, как: является ли проект успешным в достижении своих результатов, способствует ли проект своей конечной цели? Данные оценки собираются и анализируются реже, и часто требуют более формального вмешательства (зачастую технических консультантов или внешних оценщиков), чтобы показать результаты проекта. Иллюстрация 32. Примеры показателей оценки. Цели: результаты проекта вносят вклад во влияние на целевые сообщества? Результаты: приводят ли результаты к желаемым последствиям проекта? Сельское хозяйство Процент семей, производящих продукты для обеспечения в тяжелые времена. Снижение числа детей с недоеданием. % семей, принявших улучшенные методы ведения с/х. % га, обработанных новыми методами Микрофинансирование Водоснабжение Увеличение чистого дохода семей. Положительные перемены в модели домашнего потребления. Снижение числа смертных случаев в результате потребления грязной воды. % семей с увеличенным оборотным капиталом. % семей, использующих безопасное водоснабжение. Увеличение потребления на душу населения Примечание: хотя проекты должны внести свой вклад в достижение показателей на уровне целей, ответственностью проекта не является достижение (или контроль за достижением) целей. Контроль проекта включает в себя создание систем и процессов принятия решений для управления отклонениями в планах проекта (в пересчете на объем, стоимость, сроки и т.д.) и реалий реализации проекта. Он также включает в себя определение, как отклонения и изменения в проекте управляются, документируются и передаются заинтересованным сторонам. 2.2.5.2.План мониторинга и оценки проекта. Одним из важнейших элементов всеобъемлющего плана реализации проекта является план по мониторингу и оценке, который определяет систему отслеживания и измерения прогресса проекта, эффективности и результативности. Соответствующее время для разработки формального плана по мониторингу и оценке - после того, как проект утвержден на финансирование, но до начала деятельности по проекту. Тем не менее, подготовительная работа, которая вносит свой вклад в этот план, начинается задолго до этого времени. Хорошая разработка проекта облегчает создание и согласование комплексных систем мониторинга и оценки. План по мониторингу и оценке распространяется на первоначальные показатели прогресса, представленные в логической структуре и проектном предложении, и дает дополнительные детали по каждому из уровней логической структуры проекта. Хотя формат плана мониторинга и оценки проектов меняется, обычно он включает в себя следующую информацию: • Какие показатели отслеживаются и оцениваются? • Какая информация необходима для отслеживания показателя? • Каковы источники информации? • Какие методы сбора данных подходят? Guide to the PMD Pro стр. 55 из 12 • Кто будет собирать информацию? • Как часто информация будет собираться? • Кто будет получать и использовать результаты? Хотя есть много соображений, которые надо иметь в виду, когда собираются данные по плану мониторинга и оценки проекта (бюджет, ресурсы, требования доноров, и т.д.), самое важное полезность данных. При определении показателей команда проекта должна ставить перед собой вопросы: о чем говорит информация, и какие улучшения ожидаются в процессе принятия решений в результате этих данных? Управление проектом имеет повторяющийся характер Связь между логической структурой и планом по мониторингу и оценке Как указано в модели фаз проекта «PMD Pro», фаза мониторинга, оценки и контроля распространяется на весь срок реализации проекта. Логическая структура проекта является первым шагом в разработке полного плана мониторинга и оценки проекта. Показатели и средства контроля, которые включены в логические рамки, будут служить, в конечном счете, строительными блоками для полного плана мониторинга и оценки проекта. Иллюстрация 33. Пример формата плана мониторинга и оценки проекта. Иерархическая Показатель структура Определение Требуемая Источник Метод Кто Частота Пользова ключевых информация данных сбора собирает сбора тели сроков данных Цель Последствия Результаты Мероприяти я Вклад* *Обратите внимание, что некоторые планы контроля и оценки не только отслеживают прогресс в мероприятиях, результатах, последствиях и целях, которые должны соответствовать логической структуре проекта, но также отслеживают вклады или ресурсы, которые необходимы для осуществления деятельности по проекту. Метод сбора данных по показателям будет зависеть от нескольких критериев, два из которых следующие. Какой тип данных проект пытается собрать? √ Количественные методы сосредоточены на широте внедрения, давая объективную и достоверную информацию, которая позволяет сделать обобщение результатов для широких слоев населения. Наиболее часто используемый количественный метод – это стандартизированная анкета или вопросник, который распространяется среди случайных выборочных лиц или домохозяйств в целевой группе населения. √ Качественные методы сосредоточены на прямом и углубленном взаимодействии с участниками, обеспечивая глубокие и подробные данные. Обычно используемые качественные методы включают в себя методы участия в сельской оценке, фокус-группы, интервью в сообществах или с ключевыми информантами, и наблюдения. Что такое приемлемый уровень затрат и сложности сбора данных? Guide to the PMD Pro стр. 56 из 12 Специальные или «точечные» изучения Ресурсы √ Стоимость и сложность сбора данных может значительно Исследования изменяться в зависимости от метода конкретных сбора информации. На приведенном ниже графике представлено сравнение нескольких методов сбора примеров данных (количественных и качественных) с точки зрения стоимости и сложности. Обычная статистика Обсуждения в зрения стоимости и сложности. Иллюстрация 34. Сравнение методов сбора данных с точки фокус-группах Наблюдения Имеющиеся записи (например, статистические списки домохозяйств) Интервью с ключевыми информантам и Затраченные усилия должны соответствовать улучшениям в принятии решений Сложность Независимо от конечного формата, который использует проект для создания плана по мониторингу и оценке, как минимальный стандарт, рекомендуется, чтобы каждая система мониторинга прогресса включала в себя шесть основных элементов. Иллюстрация 35. Шесть элементов системы мониторинга. Показатели Планграфик и бюджет Сотрудники и партнеры Полный цикл данных Управление данными Связь со следующим уровнем Четко определенные. Базовые. Систематически измеряемые. Время и деньги выделены для мониторинговых задач. План-график детально описывает процессы сбора данных, проверок, итогов, анализа и опроса мнений. Четко определенная ответственность за мониторинг. Компетенция. Запланированные мероприятия по мониторингу с сообществом. Формирование потенциала членов сообщества в местной системе мониторинга. Использование методов мониторинга с совместным участием. Сбор и проверка данных мониторинга. Обработка мониторинговых данных. Включая полный цикл управления данными мониторинга: 1) Сбор 2) Проверка 3) Суммирование 4) Анализ 5) Обмен мнениями Процедуры созданы и используются для обеспечения целостности данных и надлежащего хранения данных. Система мониторинга проекта связана со следующим уровнем программы или портфеля организации. Guide to the PMD Pro стр. 57 из 12 Управление проектом является всесторонним! Мониторинг прогресса проекта и проектных рисков В то время как внимание плана мониторинга и оценки направлено на отслеживание прогресса проекта в достижении показателей на каждом из уровней логической структуры проекта, команда проекта также должна отслеживать риски проекта в течение всего срока реализации проекта. Мониторинг риска, по сравнению с мониторингом прогресса, включает в себя непрерывное исследование перспектив и прогнозирования возможности того, что что-то может пойти не так, как планировалось. Руководитель проекта должен постоянно и всесторонне исследовать риски, которые потенциально угрожают успеху проекта, и активно управлять этими угрозами на протяжении всей жизни проекта. Практика управления рисками является одной из шести дисциплин управления проектами, которые обсуждаются более подробно в Разделе 3 «Руководства для PMD Pro». 2.2.5.3.Подход к оценке проекта. При планировании деятельности по оценке проекта для включения в план мониторинга и оценки проекта организации должны выбрать свой подход к оценке, основанный на своих целях познания. Три подхода к оценке, которые широко используются в секторе развития, это окончательная оценка, среднесрочная оценка, и фактическая оценка. Окончательная или конечная оценка часто предусмотрена финансирующим учреждением или требуется по политике самой организации развития. Она проводится в конце проекта. Общие вопросы могут включать в себя такие вопросы, как: √ √ √ √ Добился проект успеха в достижении желаемых результатов, целей и последствий? Был ли проект соответствующим, эффективным и действенным? Есть ли у проекта потенциал быть устойчивым в своей деятельности и влиянии? Поддерживается ли теория, выраженная в логической структуре? Среднесрочная оценка предлагает преимущество ответов на многие из вопросов, поставленных на завершающем этапе оценок, а также дает возможность дать предложения по улучшению эффективности проекта и его влияния в то время, когда деятельность его продолжается. Фактическая оценка изучает влияние проекта за определенный период времени после завершения проекта, иногда через год после официального закрытия проекта. Иногда ее еще называют оценкой устойчивого воздействия. Фактическая оценка измеряет, в какой степени результаты проекта и последствия были реализованы через участников. Фактическая оценка результатов может быть особенно полезным способом использования доказательств улучшения подхода к развитию. Например, отчет по фактической оценке использовался одной организацией развития, чтобы убедить доноров поддержать обучение счету и грамоте в рамках программы микрофинансирования. 2.2.5.4.Контроль проекта. Размышляя об эволюции, Чарльз Дарвин заметил, что «…не самые сильные виды животных выживают, и не самые умные, а те, которые способны реагировать на изменения». Точно также руководители проектов должны признать, что изменения будут часто, или почти всегда, необходимы для того, чтобы их проекты имели успех. Эти изменения являются нормальными, приемлемыми и иногда Guide to the PMD Pro стр. 58 из 12 даже желательными. Проектные планы не предназначены быть статичными документами, и необходимо сделать все, чтобы они не рассматривались как статические или чрезмерно трудно меняемые документы. Коллективы проектов должны помнить, что план реализации проекта – это средство для достижения цели, а не сама цель – план не является самоцелью! В частности, команда должна осознавать недостатки, которые существуют, когда проектные планы рассматриваются как статические документы, в том числе: − неспособность признать, что первоначальные планы ошибочны; − страх признания перед внешними (и внутренними) донорами, что первоначальный план не работоспособный; − нежелание пересмотреть оригиналы документов для разработки новых, более соответствующих планов; − отсутствие ясности в отношении того, что процесс должен сопровождаться обновлением проектной документации. Однако когда дело доходит до управления запросами на изменение, руководитель проекта должен умело сбалансировать два соображения. С одной стороны, проектная документация не должна рассматриваться как неизменяемая независимо от меняющейся реальности проекта. С другой стороны, следует проявлять осторожность, чтобы не вносить изменения небрежно или без строгого рассмотрения. Чтобы управлять этим балансом, руководителям проектов необходимо установить нормы, которые позволят им гибко вносить изменения в проект в случае необходимости, но они также должны обеспечить, чтобы предлагаемые изменения проекта управлялись через строгий, интегрированный процесс управления изменениями, что гарантирует, что любые изменения в проекте: a. управляются через официальный процесс управления изменениями; b. проанализированы, чтобы последствия этих изменений были продуманы до мелочей; c. документально оформлены и иллюстрируют их полное воздействие на все интегрированные элементы проекта; d. доведены до сведения заинтересованных сторон проекта. 2.2.5.5.Изменения проекта: допустимость и изменение полномочий по решению проблем. Вопрос, на который нужно ответить при управлении проблемами: находится ли предлагаемое изменение проекта в пределах диапазона полномочий руководителя проекта? Если этот вопрос и предлагаемые изменения находятся в пределах полномочий руководителя проекта, то следующим шагом руководителя проекта будет принять меры для решения проблемы. Если руководитель проекта не обладает полномочиями для реализации предлагаемых изменений, вопрос должен быть передан на следующий уровень. Задача состоит в том, чтобы различать, какие проблемы и предлагаемые решения находятся в рамках компетенции руководителя проекта, а какие нет. Чтобы ответить на этот вопрос, важно сначала изучить тему допусков и определить, какой уровень допуска установлен для этого проекта. Проектные допуски определяют пределы действий, в которых руководитель проекта может сохранить автономию. Положительные отклонения от проекта или допуски (сумма, на которую можно перейти) являются наиболее распространенными. Тем не менее, отрицательные отклонения также важны. Например, быть строго в рамках бюджета означает, что финансирование компании излишне связано с временными рамками. Допустимые отклонения играют ключевую роль в возможности руководителя проекта работать автономно. Наличие допуска означает, что руководитель проекта имеет определенную степень гибкости в отношении проектных ограничений. Практически это означает, что проект может быть более или менее изменен, и не придется постоянно обращаться к правлению (или совету) проекта (или спонсору), чтобы просить разрешения на изменения в проекте. Два наиболее часто используемых допустимых отклонения касаются бюджета и времени, хотя отклонения могут быть также в любой из следующих областей: Guide to the PMD Pro стр. 59 из 12 Допустимые отклонения по времени: количество времени, на которое завершение проекта может быть позже или раньше запланированной даты. Допустимые отклонения по стоимости: процент или сумма денежных средств, на которую проект может быть больше или меньше запланированного бюджета. Допустимые отклонения по объему и содержанию работ: измеряются как согласованные отклонения от описанного продукта. Любые потенциальные изменения должны быть задокументированы в структуре описания продуктов. Допустимые отклонения по рискам: служат ориентиром, какие риски должны быть переданы на рассмотрение правления проекта. Допустимые отклонения по качеству: диапазоны, которые характеристики для продукта, задокументированного в описании продуктов. определяют приемлемые Допустимые отклонения в общественно-экономической пользе: диапазон приемлемых характеристик проекта на уровне последствий. Допуски должны быть установлены на этапе начала проекта для определения параметров, в пределах которых исполнение проекта будет приемлемым, т.е. общий уровень допустимых отклонений. Допуски должны быть определены и утверждены высшим органом структуры управления проектом. Это может быть правление проекта, однако, если правления не существует, допуски должны быть установлены спонсором проекта или донором. Если в любой момент в ходе мониторинга реализации проекта руководитель проекта понимает, что уровень допустимого отклонения может оказаться превышенным, он должен получить консультацию у руководящего органа. Процесс запроса одобрений на изменения. Как только станет ясно, какой уровень полномочий требуется для принятия решения о запросе на изменение проекта, следующим шагом надо ответить на такие дополнительные вопросы: • Допустим ли запрос на изменение в рамках существующих соглашений? • Изучены ли последствия запроса на изменение для графика, ресурсов, затрат и качества? • Проведены ли консультации с заинтересованными сторонами проекта в отношении предлагаемых изменений? • Обновлен ли всесторонний и комплексный план проекта для документирования последствий предлагаемых изменений? • Имеются ли ресурсы (время, материалы, деньги, люди) для осуществления предлагаемых изменений? Схема запроса на изменение, как представлено в Иллюстрации 36, может быть полезным ресурсом для определения и контроля над процессом управления изменениями в проектном плане. Guide to the PMD Pro стр. 60 из 12 Иллюстрация 36. Пример схемы процесса запроса на изменение проекта Несмотря на то, что карта процесса, как показано в Иллюстрации 36, полезна, чрезвычайно важно понимать, что карта процесса запросов на изменения будет существенно различаться в зависимости от структуры управления проекта, отношений с донорами, договорных требований, партнеров и многого другого. Таким образом, важно выстроить диаграмму процесса в соответствии с реальностью операционного контекста проекта. Независимо от конкретной карты процесса запросов на изменения, особенно важно, чтобы любые изменения осуществлялись на основе комплексного подхода, т.е. с гарантией, что любые изменения в проектных планах четко определяют последствия, которые могут оказать влияние на другие разделы плана управления проектом. Лица, знакомые с каждой из областей в планах проекта (объем, стоимость, графики, риски, закупи, качество и т.д.), должны оценить влияние предлагаемых изменений на весь план проекта. Когда согласовано, что предлагаемое изменение будет выгодно, и что последствия являются приемлемыми, то запрос на изменение может быть утвержден. После утверждения пересмотренный план проекта должен быть доведен до сведения всего коллектива проекта, чтобы все работали по обновленному плану. Использование модели итерационного планирования для управления изменениями. Не знаком ли вам такой сюжет: трехлетний проект вступил во второй год реализации. В целом проект работает хорошо. Логика внедрения проекта остается в силе, и результаты по-прежнему жизнеспособны. Существует, однако, серьезная проблема с планом проекта. Реальность места исполнения проекта на Guide to the PMD Pro стр. 61 из 12 втором году реализации имеет мало общего с тем, что прогнозировалось и планировалось 20 месяцев назад. Становится все более очевидным, что некоторые оценки бюджета были значительно занижены, в то время как другие статьи бюджета больше не нужны из-за изменений ролей партнеров-исполнителей. Хотя эти проблемы могут быть решены посредством комбинации вопросов управления и запросов на изменения, некоторые проекты решают их через стратегию итеративного планирования проекта. В итерационной модели планирования первоначальный план проекта создается, когда проект одобрен. Однако, учитывая, что реальность места реализации проекта может / будет меняться с течением времени, детальный план проекта выпускается позже. Вместо создания единого детального плана реализации, проекты предпочитают использовать модель планирования, которая включает периодическое обновление планов исполнения проекта. В проектах развития эти периодические планы, как правило, составляются на ежегодной основе и называются «Ежегодный операционный план». В проектах помощи в чрезвычайных ситуациях период времени для обновления планов может быть значительно короче. Организация ECHO (Европейская Комиссия Гуманитарной Помощи и Гражданской Защиты), например, позволяет делать корректировку проектных предложений раз в три месяца на основе понимания о том, кто должен санкционировать изменения для каждого из уровней логической структуры. Приняв итеративный подход планирования, организация имеет больше гибкости в приспособлении к изменениям. Проектная группа может вернуться к плану реализации проекта в начале каждого проектного периода, чтобы: − подтвердить логику, риски, возможности, допущения и ограничения; − обновить и проверить мероприятия, сроки и ресурсы проекта; − убедиться, что деятельность по внедрению проекта учитывает риски и проблемы, которые представляют непосредственную угрозу успеху проекта. 2.2.6. Фаза 6. Переходный период проекта после завершения. Иллюстрация 37. Переходный период проекта. Проект по определению является временным предприятием, имеющим начало и конец, обычно с ограничивающими датами, финансированием или определенными результатами. Временный характер проектов отличает их от нормальных бизнес операций организаций, которые являются постоянной, повторяющейся или полупостоянной функциональной работой организации, производящей продукты или услуги. В сфере развития, однако, встречаются проекты, которые исполняются годами, когда последующие фазы продолжают работу предшествующих фаз. Это наблюдение привело к осознанию реальности, что конец проекта в секторе развития часто точнее характеризуется как переходная фаза, а не строго определенное закрытие проекта. Guide to the PMD Pro стр. 62 из 12 На практике существует четыре сценария переходного периода, которые применимы к проектам развития. Эти сценарии представлены в таблице ниже. Прекращение* Проект официально закончен и все мероприятия по закрытию проекта завершены. Продолжение Расширение Переработка Ведутся переговоры Определение Продолжение через о добавочном элементов для новую фазу с времени для повторения в новой модифицированным завершения проекта целевой территории внедрением или (за счет или с новым деятельностью дополнительных населением. затрат или за счет тех же средств). *Прекращение может также означать передачу проектной деятельности местному партнеру, учреждению или сообществу. К сожалению, в то время как переход проекта имеет большое значение, часто это упускается из виду и / или оставляются недостаточные ресурсы. С учетом необходимости переходить на новые проекты и назначать сотрудников на другие виды деятельности, наиболее практичный способ обеспечить полное закрытие проекта - включить его в план проекта. 2.2.6.1.Стратегия управления проектом в переходный период. Как уже отмечалось в ходе обсуждения фазы планирования проекта, комплексные планы проекта должны включать план на переходный период проекта, который описывает, как проект намерен развиваться после завершения проекта по календарю, обеспечивая при этом, чтобы прогресс в достижении целей продолжался. План перехода может включать в себя несколько сценариев или непредвиденных обстоятельств, связанных с рисками, а также может выделить дополнительные ресурсы, когда невозможно полностью прекратить деятельность. Сектор развития считает переход особенно важным, т.к. главная забота развития состоит в том, чтобы деятельность оставалась устойчивой после окончания проекта. Одним из инструментов, используемых для планирования длительной устойчивости проекта, является матрица планирования перехода, подробно описанная ниже. Иллюстрация 38. Матрица планирования перехода. Компонент Главный вопрос 1. Запланировать √ Какой тип перехода предвидится? √ В какие сроки, и какие основные вехи? переход от ранних фаз проекта. 2. Создать партнерские отношения и местные связи. 3. Сформировать организационны й и людской потенциал. Guide to the PMD Pro √ Выбор правильных партнеров. √ Что привносят партнеры? √ Какие способности требуются? √ Какие способности имеются? Руководящие принципы Ø Постоянный обзор и проверка проекта. Ø Прозрачность, особенно в отношении финансирования. Ø Разнообразие: может потребоваться иной вклад от проекта. Ø Четкие и общие цели. Ø Формирование на имеющихся способностях, если возможно. Ø Создание среды для поддержания потенциала. Задачи Сохранить баланс между твердыми обязательствами и гибкостью. Дать адекватное время для развития потенциала. Выравнивание потребностей и задач различных заинтересованных сторон. Поддержка местных партнеров. Разработка мониторинга для отслеживания формирования потенциала. Дать стимулы и сохранить опытный персонал. стр. 63 из 12 4. Мобилизовать местные и внешние ресурсы. 5. Дифференцирова ние фаз по различным видам мероприятий. 6. Дать возможность развитию отношений и ролей после перехода. √ Какой вклад и ресурсы требуются для поддержания работы? √ Общественноэкономическая польза сможет оставаться устойчивой без продолжающихся вкладов? √ Какие элементы проекта наиболее важные? √ Какие элементы зависят от других? √ Какой вид длительной поддержки (консультации, наставничество, техническая помощь и т.п.) требуется? √ Как длительная поддержка будет финансироваться? Ø Закупить местные ресурсы, где возможно. Ø Увеличивать привлечение внешних ресурсов под местным контролем. Трудности в поиске адекватных или имеющихся местных ресурсов. Другие финансирующие лица не участвуют и не разделяют первоначальных целей. Ø Гибкость. Последовательность дифференцирования может меняться с течением реализации. Ø Предотвратить снижение целевых результатов проекта посредством включения их в продленный, расширенный или переработанный проект. В проектном цикле предоставлено достаточно времени для обзора целевого влияния и последствий. Наличие финансирования для длительной поддержки. Наличие персонала, который сможет уделять значительное время и усилия для длительной поддержки. 2.2.6.2.Проверка объема и содержания проекта и принятие ожидаемых результатов. Когда проект входит в фазу переходного периода, руководитель проекта должен связаться с внутренними и внешними заинтересованными сторонами (в том числе с советом, правлением или спонсором проекта), чтобы убедиться, что сфера деятельности проекта завершена, и что результаты приняты. Зачастую проверка объема и содержания измеряется в окончательной оценке, которая проводится по проекту. Тем не менее, в ситуациях, когда окончательная оценка не проводится, проверка ожидаемых результатов должна проводиться. Это обычно происходит в два этапа. • Команда реализации проекта проводит совещание для перекрестной сверки завершенной работы относительно плана реализации проекта. Могут быть, например, мероприятия, которые были задержаны в начале проекта, а позже так и не были выполнены.· • Встречи с основными заинтересованными сторонами (донорами, общественными группами) для: o обзора достижений в отношении плана проекта и получения документального признания или иного официального принятия результатов; o получения свидетельства о том, что они удовлетворены не только техническими аспектами проекта, но и общими последствиями (это часто происходит на уровне восприятия, поскольку речь идет о наличии результатов или продуктов, и достижении последствий). 2.2.6.3.Полное административное, финансовое и контрактное закрытие. Если проект будет проверяться аудиторами спустя два года после закрытия, что произойдет? Имеются ли системы, которые обеспечивают, чтобы административные, финансовые и договорные элементы закрытия проекта были полностью выполнены? Эти системы имеют решающее значение не только потому, что они помогают избежать проблем с аудитом проекта, но и уменьшить риск споров с поставщиками, сотрудниками, и донорами о состоянии счетов. Должны быть в наличии системы для оказания помощи в каждой из следующих трех областей деятельности: Закрытие контракта: • Все ли контракты закрыты? С поставщиками? С субподрядчиками? С донорами? С другими лицами? С исполняющими организациями? • Проверил ли донор и принял результаты проекта? Финансовое закрытие: Guide to the PMD Pro стр. 64 из 12 • Все разрешенные средства были получены от донора? • Вся дебиторская задолженность (авансы, командировочные, авансы поставщикам) ликвидирована или переведена на другой номер или учетный код проекта? • Вся кредиторская задолженность оплачена? Административное закрытие: • Сотрудники проекта уволены или переведены? • Оборудование, транспортные средства, офисы перераспределены? Проданы? Переданы? • Отчеты по проекту и документы закрытия закончены? • Архив и/или файлы в порядке? 2.2.6.4.Изученный опыт на момент окончания проекта. Полученный опыт или уроки в ходе реализации проекта являются банком памяти организации. В идеале, команда проекта должна иметь журнал учета полученного опыта, который создается на этапе начала проекта, и который отслеживает все полученные уроки по мере возникновения, или, по крайней мере, в основных моментах оценки или этапах на протяжении всего проекта. По мере вхождения в фазу переходного периода проекта при его окончании важно, чтобы полученный опыт был детально описан, записан, и был легко доступен. Кроме того, важно, чтобы руководитель проекта распространил полученный опыт и уроки всем, кому это может понадобиться. Не имея системы отражения опыта проекта на момент его завершения, организация будет постоянно изобретать колесо каждый раз, когда принимается решение об осуществлении аналогичного проекта. Доноры часто заинтересованы в том, чтобы обучение распространялось по всему сектору, чтобы новые проекты могли воспользоваться опытом других проектов, которые они финансируют. В настоящее время НПО часто публикуют отчеты об оценке, а также есть базы данных, которые включают тысячи отчетов по оценке различных организаций. Обзор опыта, который также называется «Обзор последействий» - это простой, быстрый и универсальный способ познавательной деятельности, который может быть использован для выявления и отражения уроков и знаний, вытекающих из проекта. Обзоры опыта относительно просты по своей организации и выполнению. В ходе обзора задаются вопросы, которые помогают участникам понять, что планировалось, а что фактически было осуществлено: • Что мы намеривались сделать? • Чего мы достигли? Уделяйте больше внимания фактам, чем мнениям. • Что пошло не очень хорошо? Опять же, посмотрите на факты. Почему это хорошо? Сравните план с реальностью. • Что могло быть сделано лучше? Сравните план с реальностью. Что помешало сделать больше? • Какой урок или опыт мы можем извлечь из этого? Преимущество обзора опыта заключается в том, что он может относительно быстро и без затрат значительных ресурсов собрать полезную информацию. Содействие обзору должно быть быстрым, открытым и не направленным на глубокие размышления и обсуждения. Основной целью является информирование для принятия решений по деятельности, разработки политик или стратегий в отношении текущих и будущих мероприятий программы. 2.2.6.5.Празднование достижений. Подобно тому, как важно сделать общественное объявление о начале проекта, точно также руководитель проекта должен надлежащим образом отпраздновать и официально признать конец проекта или его переходный период в связи с завершением. Необходимо: • отметить работу сотрудников; • признать вклад основных заинтересованных сторон в проект; • выразить признательность отдельным лицам и группам, которые имели решающее значение для успеха проекта. Признание достижений проекта в рамках организации и перед внешним миром также может способствовать положительным связям с общественностью и подготовить почву для будущих возможностей для бизнеса. Guide to the PMD Pro стр. 65 из 12 Раздел 3. Дисциплины управления проектами. Не существует единого пути в управлении проектами. Каждый проект уникален своими собственными целями, контекстом, ресурсами, отношениями и проблемами. И все же, в то время как не существует двух одинаковых проектов, успешное управление проектами требует, чтобы все проектные команды всесторонне и активно применяли разнообразный набор дисциплин по управлению проектами в течение всего срока действия конкретного проекта. «PMD Pro» выделяет шесть дисциплин в управлении проектами, которые имеют особое значение при управлении проектами в секторе развития: • Управление масштабом и содержанием проекта. • Управление временем. • Управление рисками. • Управление обоснованием проекта. • Управление заинтересованными сторонами. Третий раздел «Руководства» рассматривается каждую дисциплину с указанием подробностей об инструментах и механизмах, которые особенно полезны при управлении каждой дисциплиной. Кроме того, признавая, что каждая дисциплина взаимодействует с другими, в «Руководстве» также рассматриваются подходы к управлению дисциплинами на комплексной основе, когда каждая дисциплина надлежащим образом совмещена и связана с другими. 3.1.Дисциплина 1. Управление деятельностью проекта. Американская легенда бейсбола, Йоги Берра, как известно, говорил: «Если вы не знаете, куда вы идете, вы заблудитесь». Именно поэтому управление содержанием и объемами деятельности по проекту, или иными словами, контроль объема работ, очень важен для успешных проектов. Четко определенные рамки проекта не только укажут сотрудникам проекта, куда они двигаются, но также объяснят, каким образом проект намеривается туда добраться. По сути, управление деятельностью состоит из двух компонентов: Объем или содержание продукции включает в себя все требуемые результаты проекта, отвечающие согласованным спецификациям: что будет выполнено? Масштаб или объем проекта включает все работы, необходимые для доставки продукта: как будут ожидаемые результаты создаваться и осуществляться? Обе эти составляющие очень важны для успеха проекта, и ими необходимо управлять надлежащим образом. В отсутствие четкого определения масштабов и содержания могут возникнуть следующие проблемы. • Неясные ожидания: неоднозначность сферы деятельности приводит к путанице среди участников проекта в отношении того, чего ожидать, и чего не ожидать от проекта. Ясно определенная деятельность помогает заинтересованным сторонам иметь общее понимание общественноэкономической пользы проекта и работы, необходимой для успешного осуществления результатов и последствий проекта. Заинтересованные стороны должны на 100% ясно понимать объемы, масштабы и содержание деятельности, чтобы они не имели неправильных или нереалистичных ожиданий о том, какие товары / услуги будут осуществляться и доставляться. • Неточные оценки: ошибки в определении сферы деятельности часто приводят к проектам, которые не смогли идентифицировать все работы, необходимые для завершения проекта (и наоборот, плохо сформулированные виды деятельности могут привести к включению ненужной работы в проект). Эти ошибки могут произвести эффект «домино», вызывая в результате ошибки в Guide to the PMD Pro стр. 66 из 12 бюджете и в оценке времени, которые в свою очередь приведут к неправильному графику работ и, следовательно, в конце концов, к перерасходу средств. • Расползание рамок деятельности проекта: целью определения сферы деятельности является четкое описание и согласие о пределах проекта и результатов работы по проекту. Неспособность управлять этими границами приводит к размыванию сфер деятельности, т.е. к главной причине задержек в проекте и потенциальным «нескончаемым» проектам. Чтобы избежать этого, масштабы должны быть документированы и управляемы на протяжении всего проекта в рамках официального процесса изменений. Управление проектами является всесторонним (и подробным)! Предупреждение относительно определения сферы деятельности проекта. В то время как у руководителя проекта может возникнуть соблазн считать, что документы, разработанные на этапе определения и разработки проекта (логическая структура, проектное предложение, и т.п.) достаточны для определения сферы деятельности и рамок проекта, это не так! Помните, что логическая структура и предложение по проекту были написаны для очень конкретных целей. Эти документы особенно важны для изложения квалифицированной логики проекта и продажи проекта донорам. Они не предназначены для использования в качестве руководства по исполнению проекта для сотрудников. До того, как начнется фактическая работа над проектом, руководитель проекта должен подтвердить, что объемы и содержание деятельности проекта являются всесторонними и детальными. Особое внимание следует уделить тому, чтобы информация о косвенной работе по проекту вошла в общее содержание, например, детали, связанные с закупками, координацией, коммуникациями, с управлением человеческими ресурсами и рисками. 3.1.1. Определение содержания продукции и проекта. Признавая тонкое, но существенное различие между двумя элементами рамок проекта, давайте рассмотрим эти два определения более подробно. Содержание продукции описывает результаты проекта. Полное определение содержания продукта будет однозначным и полным описанием и спецификациями товаров / услуг, которые должны быть доставлены. Уровень детализации содержания продукта должен быть достаточным, чтобы противостоять любым возможным будущим разногласиям о том, что было задумано. Содержание продукта является ориентированным на клиента, а это означает, что его определение должно быть согласовано с заказчиком (спонсорами и пользователями) результатов проекта. Сфера действия (масштаб) проекта описывает работу проекта. Полное определение масштаба проекта обеспечивает всестороннее и подробное описание работ, которые необходимо выполнить для доставки результатов проекта. Масштаб проекта является ориентированным на исполнителя или провайдера, т.е. он зависит от того, как проектная группа решит, какой способ доставки продукта будет наиболее подходящим. После того, как проектная группа определила продукты и масштаб проекта, руководитель проекта должен проверить формулировку определения сферы деятельности для обеспечения следующего: • Завершенность формулировки: сотрудники должны точно знать, что их просят осуществить. • Недвусмысленность: различные заинтересованные стороны должны иметь одинаковое понимание того, что просят. • Ресурсы: требования по ресурсам должны быть понятны и определены. Guide to the PMD Pro стр. 67 из 12 Система управления Система управления Система отслеживания фекального уровня Нарастающий уровень детализации Проект «Дельта реки» по водоснабжению и санитарии отходами • фекальными Соглашение: сотрудники согласны бытовыми с предполагаемыми результатами. отходами • Жизнеспособность: сотрудники должны быть способны производить согласованные результаты. Компания • просвещения Принятие: междуСтроительство сотрудниками и заинтересованными участниками есть согласие о том, что Другие туалетов общественности составляет приемлемые продукты или результаты. 3.1.2. Инструменты для определения сферы деятельности проекта. Подготовка к Подготовка строительству Закупки владельцев домов 12 Структура декомпозиции работ (СДР) или пооперационный перечень работ является главным инструментом, который руководители проектов используют для определения масштаба проекта. Декомпозиция представляет Изучение собой иерархическое разложение работ проекта. Проще говоря, эта Одобрены План, утвержденный инженерные и содержание деятельности в схему или иерархию «групп работ»13 или министерствомструктура организует объемы грунтовых вод спецификации комплекса работ. Формат структуры обычно имеет один из двух следующих стилей. Графический формат дает легко читаемое визуальное расположение соответствующих уровней работ проекта. Это изображение позволяет партнерам и сотрудникам видеть взаимосвязь между элементами пооперационного перечня работ, а также, как мелкие компоненты проекта разворачиваются в более крупные. Кроме того, графический формат можно легко использовать вместе с бумажными наклейками, которые легко перемещать с места на место. В целях презентации этот формат способствует регулированию глубины деталей, которая подходит для различных аудиторий. Иллюстрация 39. Структура декомпозиции работ проекта «Дельта» (частичное воссоздание в графическом формате). 12 В английской аббревиатуре - WBS от английского Work Breakdown Structure. Примечание переводчика. Группа работ - последнее звено в системе разделения труда или заданий, которое объединяет сходные трудовые или технологические операции, которые могут быть, как например, в строительстве, классифицированы как наряд, и переданы для выполнения подрядчику. Прим. переводчика 13 Guide to the PMD Pro стр. 68 из 12 Индентный формат имеет преимущество, т.к. его легче создавать и редактировать на компьютере, легче загружать в компьютерную программу управления проектами, такую как Microsoft Project, а также печатать отчеты и осуществлять компьютерный мониторинг. Иллюстрация 40 дает пример, как будет выглядеть частичная декомпозиция работ проекта «Дельта реки» в индентном формате. Иллюстрация 40. Структура декомпозиции работ проекта «Дельта». 1. Система управления фекальными отходами. 1.1. Система отслеживания фекального уровня. 1.2. Компания просвещения общественности. 1.3. Строительство туалетов. 1.3.1. Подготовка к строительству. 1.3.1.1. План, утвержденный министерством. 1.3.1.2. Одобрение инженерных спецификаций. 1.3.1.3. Исследования грунтовых вод. 1.3.2. Подготовка владельцев домов. 1.3.3. Закупки. 2. Система управления бытовыми отходами. 3. Другое Инструмент декомпозиции работ хорошо известен в различных секторах управления, но сравнительно неизвестен в секторе развития. Когда руководители проектов начинают применять WBS в качестве инструмента для определения проектов, услуг и работ по проекту, неизбежно появляется ряд вопросов. Какой формат выбрать? В конечном счете, предпочтения, которые сотрудники проекта и заинтересованные стороны имеют в интерпретации информации, скорее всего, повлияют на формат структуры. Некоторые люди могут работать с данными легче, когда они видят их графическое отображение; другие предпочитают перечисления, упорядоченные по пунктам. Иногда бывает полезно иметь и то и другое. Часто графический формат разрабатывается сначала в качестве групповой работы участников проекта. Затем готовится индентный формат для работы над планом реализации проекта. Кто должен участвовать? Участие всей команды проекта и ключевых заинтересованных сторон важно в процессе создания структуры декомпозиции работ. Ни один человек или небольшая группа людей не имеют достаточно знаний, чтобы обеспечить достаточный уровень полноты и детализации WBS. Например, рекомендуется, чтобы сотрудники, отвечающие за финансовохозяйственную деятельность и закупки по проекту, принимали участие не только в целях предоставления информации для создания качественной декомпозиции работ, но и для гарантии, что они понимают ту деятельность, за которую они отвечают. Сколько уровней? Структура декомпозиции работ может существенно отличаться по количеству уровней. Хотя нет никаких правил, которые предусматривают точное количество уровней, структура должна быть достаточно подробной, чтобы все промежуточные результаты и действия могли быть успешно проконтролированы. Что должно быть включено в декомпозицию работ? Очень важно, чтобы WBS была комплексной, включающей все мероприятия, необходимые для успеха проекта. Это включает управленческую деятельность, которая часто упускается в проектных предложениях и в логической структуре (планирование и контроль проектов, обучение заинтересованных сторон, передача информации, отчетность, закупки и деятельность в переходный период проекта). Guide to the PMD Pro стр. 69 из 12 Управление проектами является интегрированным! Глаголы или существительные? Чаще всего, структура декомпозиции работ определяется как схема, ориентированная на продукт, а это означает, что все формулировки в ней написаны в форме существительных. Тем не менее, некоторые определения структуры позволяют ее формулировать с ориентиром на процессы или выражать глаголами. С точки зрения «PMD Pro» формулировки СДР могут быть выражены существительными или глаголами. Важно обеспечить, чтобы содержание СДР было всеобъемлющим и подробным. Хорошо построенная структура декомпозиции работ может быть использована для: • направления процесса деятельности и последовательности; • для обеспечения базы для: Ø точной оценки продолжительности проекта; Ø точной оценки стоимости проекта; Ø точной оценки ресурсов (транспортных средств, людей, материалов, строительных материалов); • определения необходимых ведомственных, субподрядных услуг и поставщиков; • сообщения и согласования продукции и масштабов проекта с заинтересованными сторонами проекта; • демонстрации иерархии работ, необходимых для завершения проекта, а также указания взаимосвязи между ними; • делегирования пакетов работ членам проектной группы, партнерам и поставщикам. Связь логической структуры со структурой декомпозиции работ. Обратите внимание, что основные категории работ в СДР согласуются с содержанием логической основы проекта. Однако СДР включает уровень полноты и деталей, который часто отсутствует в логической схеме. В СДР могут быть включены дополнительные категории работ, которые не были включены в логическую структуру. СДР также предназначена для обеспечения того уровня конкретных деталей, которые часто отсутствуют в логической структуре. 3.2.Дисциплина 2. Управление временем. Представьте проект с проблемным графиком. В чем заключалась проблема? Проект выделил недостаточно времени для завершения ожидаемых результатов? Ключевые задачи проекта выполнялись с опозданием? План-график проекта был основан на оценке ресурсов (рабочей силы, техники, и др.), которые не были реалистичными? Своевременное исполнение проектов является одной из самых больших проблем, возникающих в управлении проектами. Чтобы успешно управлять временем, руководители проектов должны уметь разрабатывать точные графики и осуществлять их на протяжении всей деятельности проекта. Первым шагом в успешном управлении временем является планирование графика. Этапы процесса планирования графиков: Определение видов деятельности: всестороннее определение деятельности и мероприятий, которые должны быть выполнены для создания ожидаемых результатов проекта. Последовательность мероприятий: выявление отношений, которые существуют между различными видами деятельности по графику. Оценка ресурсов деятельности: выделение типа и количества ресурсов, необходимых для выполнения каждой деятельности по графику. Оценка продолжительности деятельности: оценка времени, необходимого для завершения деятельности по проекту. Разработка плана-графика: создание плана-графика проекта на основе деятельности, последовательности, длительности, ресурсов и ограничений по плану-графику. Guide to the PMD Pro стр. 70 из 12 Управление проектами является интегрированным! Управление временем не происходит в вакууме! Помните треугольник ограничений проекта? Все стороны этого треугольника связаны, и невозможно управлять одним из важных ограничений (временем, датами, стоимостью, ресурсами, объемами, качеством), не принимая во внимание другие. Например, если ваш проект имеет негибкие временные ограничения, такие как «Проект должен быть сделан за один год!», надо убедиться, что требования и ресурсы были запланированы (деньги, люди и материалы) для обеспечения реалистичного графика работ. С другой стороны, если происходит одно из ключевых ограничений в проекте (по бюджету, объему деятельности, или по тому и другому), надо понимать, что, скорее всего, эти ограничения повлияют на даты исполнения проекта. 3.2.1. Определение деятельности и ее последовательности. Начиная с СДР, проектная группа разрабатывает перечень видов деятельности, который всесторонне отражает все мероприятия в рамках проекта (или в рамках конкретного комплекса работ по проекту). Далее, проектная группа разрабатывает сетевую диаграмму, которая наглядно представляет последовательность, связи и зависимости между видами деятельности по структуре декомпозиции работ. На примере проекта «Дельта реки» Иллюстрация 41 показывает частичную сетевую диаграмму компонента строительства туалетов. Заметим, что схема на рисунке 41, не полная, потому что нужно вставить единицы времени под каждым мероприятием. Каждый прямоугольник в сетевой диаграмме определяет деятельность в рамках проекта. Они связаны стрелками, которые указывают на их зависимости. Эти зависимости определяют, как проектные мероприятия связаны друг с другом в рамках календаря, и последовательность, через которую мероприятия должны быть завершены. В некоторых случаях последовательность действий является линейной, подразумевая приоритет отношений, когда требуется, чтобы один вид деятельности был завершен до того, как начнется другой. Параллельные квадраты могут располагаться в любой последовательности независимо друг от друга. Иллюстрация 41. Использование сетевого графика для отражения последовательности деятельности по строительству туалетов. Какую информацию можно извлечь из диаграммы проекта строительства туалетов: − сотрудники проекта должны подождать, пока будет сделана крыша туалета, прежде чем ее можно будет устанавливать; Guide to the PMD Pro стр. 71 из 12 − сотрудникам проекта не нужно ждать завершения крыши уборной для того, чтобы выкопать яму; − мероприятия по обучению могут проводиться независимо от строительных работ уборной. Примечание: если обучение требуется в качестве предварительного условия для участия в строительной деятельности, то квадрат с указанием мероприятий по обучению должен быть размещен в другом месте, а не там, где он находится в вышеприведенной схеме. 3.2.2. Оценка ресурсов для осуществления деятельности. После того, как определена последовательность действий, есть соблазн сразу перейти к установлению продолжительности деятельности. Сначала, однако, важно оценить ресурсы. По сути, оценка ресурсов и продолжительности происходит интуитивно. Всем известно, что один человек будет дольше копать яму, чем бригада из пяти человек. Также известно, что оценка продолжительности зависит от того, будет ли яма копаться лопатой, пневматическим инструментом или с помощью динамита. Короче говоря, это вопрос ресурсов. Они являются одним из центральных факторов, влияющих на оценку продолжительности проекта. Таким образом, решения о ресурсах должны быть приняты до того, как производится оценка продолжительности. Решения, относящиеся к количеству и качеству ресурсов, выделяемых для деятельности, в свою очередь, зависят от ряда факторов, в том числе (но не ограничиваются ими) от следующих факторов. Время: если сроки очень сжатые, проект может решить привлечь персонал, материалы и капитальное оборудование самого высокого уровня, чтобы уложиться в сроки. И наоборот, если сроки являются свободными, проект может решить привлечь ресурсы более низкого уровня для деятельности. Бюджет: если денег выделено мало, проект может решить сделать вложения в сочетание ресурсов "низкой стоимости". Например, больше ручного труда и меньше машин является предпочтительной недорогой альтернативой. Такое решение по ресурсам, однако, продлит срок деятельности по строительству уборных. Правила и организационные политики: часто проекты ограничены трудовым законодательством и/или внутренними политиками организации, которые ограничивают график работы (определенное количество часов в день, в неделю, годовой отпуск, отгулы по семейным причинам, и т.п.). Эти ограничения влияют на наличие ресурсов и, следовательно, на оценку продолжительности. Другие факторы, влияющие на доступность ресурсов: ряд других факторов, влияющих на доступность ресурсов, которые могут влиять на оценку продолжительности деятельности. Например: − Погодные ограничения препятствуют сельскохозяйственным проектам, когда участие общественности невозможно в период уборки урожая. − Материальные трудности препятствуют жилищному проекту, который требует дефицитных строительных материалов, что делает необходимым принятие альтернативной стратегии, которая является более трудоемкой. − Ограничения по логистике препятствуют доступу проекта по оказанию чрезвычайной помощи к транспорту, что увеличивает время, необходимое для заполнения продовольственных складов. − Ограничения в кадрах препятствуют проекту по здравоохранению в наличии квалифицированной рабочей силы, что увеличивает сроки продолжительности технически сложных видов деятельности. 3.2.3. Оценка продолжительности деятельности. После того, как завершена оценка ресурсов, сетевая диаграмма может быть пересмотрена и добавлены расчеты продолжительности деятельности. Возвращаясь к проекту «Дельта реки», окончательная сетевая диаграмма проекта по строительству туалетов будет выглядеть, как показано на рисунке 42. Guide to the PMD Pro стр. 72 из 12 Иллюстрация 42. Сетевая диаграмма проекта по строительству туалетов. Теперь сетевая диаграмма завершена и может быть использована сотрудниками проекта, чтобы определить: Критический путь проекта: критический путь – это ряд задач, который определяет минимальное количество времени, необходимое для завершения проекта, или последовательность работ, показывающую минимально необходимое время для завершения проекта. На рисунке 42 критический путь выделен голубым цветом. Почему такая последовательность действий? Потому что эта последовательность задач представляет самый длинный путь между началом проекта и его концом, в данном случае 23 дня. В этом примере критический путь говорит нам, что невозможно завершить проект меньше, чем за 23 дня, если только другие ограничения в треугольнике ограничений проекта не изменились (деньги, ресурсы, объемы или качество). Время задержки проекта: в управлении проектами время задержки или резерв времени – это количество времени, на которое задание в сетевой диаграмме проекта может быть отложено, не вызывая задержки в дате завершения проекта. В проекте по строительству туалетов указан ноль на критическом пути. Тем не менее, мероприятие по строительству крыши туалета может быть отложено на срок до восьми дней без ущерба для графика проекта. Также, мероприятия по обучению могут быть отложены на срок до 20 дней без ущерба для сроков реализации проекта. Если деятельность по проекту, которая не находится на критическом пути, задерживается после указанной даты начала, это может означать, что критический путь, который установлен в проектном плане, больше не является критическим путем14 3.2.4. Разработка плана-графика. На основании оценок и расчетов, полученных в результате предыдущих этапов, команда проекта теперь может разработать график проекта. В секторе развития предпочтительный инструмент для разработки графика проекта - диаграмма Ганта. Планирование и осуществление проектов легче, если их рассматривать как небольшие управляемые единицы, зависимости которых наглядно иллюстрируются, параллельные процессы очевидны, и общий график изображен графически. Диаграмма Ганта использует столбцы для графического отображения графика деятельности по проекту, в том числе даты начала, даты 14 В модели критического пути - это максимальный период, на который может быть задержано выполнение операции без нарушения срока выполнения последующих операций или исполнения проекта в целом. Резерв времени проекта – это разница между самым ранним возможным временем завершения проекта и самым поздним допустимым временем его завершения, которое может быть определено для каждого вида работ, исходя из той работы, которая занимает наибольшую продолжительность. Прим. переводчика. Guide to the PMD Pro стр. 73 из 12 окончания и ожидаемой длительности. Сложность и комплексность диаграммы Ганта может меняться. По своей сути, этот инструмент имеет преимущество в том, что его относительно легко сделать, читать и использовать. Тем не менее, важно понимать, что задачи проекта могут быть достаточно сложными, и много зависимостей может существовать между ними. Один из способов сохранить простоту в диаграмме Ганта, даже если задачи и зависимости носят сложный характер, организовать широкую, всестороннюю деятельность проекта в суммарную диаграмму Ганта с дальнейшими деталями, развернутыми в подробный график. Суммарная диаграмма Ганта отличается от подробной диаграммы Ганта уровнем подробностей и целью ее применения. Суммарная диаграмма Ганта особенно полезна для квалифицированного обсуждения хода реализации проекта с заинтересованными сторонами (членами правления проекта, основными заинтересованными сторонами, донорами и т.д.) Целью детальной диаграммы Ганта является не столько информирование, сколько операционное планирование, осуществление и мониторинг деятельности. Здесь надо сосредоточиться на сотрудниках, исполняющих партнерах проекта и поставщиках, ответственных за выполнение групп проектных работ и задач. Рисунок 43: Диаграмма Ганта для проекта по строительству туалетов. Мероприятия Год 1 (в месяцах) 1 1.1. 1.1.1. 1.1.2. 1.2. 1.2.1. 1.2.1.1. 1.2.1.2. 1.2.1.3. 1.2.2. 1.3. 1.3.1. 2 3 4 5 6 7 8 9 1 0 1 1 12 Мониторинг фекальных отходов Базовые исследования Исследование качества Кампания просвещения Подготовка материалов Определение сообщений Создание материалов Публикация материалов Проведение кампании Строительство туалетов И т.п. В этом примере пакеты работ, задач и подзадач находятся на оси ординат, а время - на оси абсцисс. Столбики показывают, когда задача должна начинаться, и когда она будет закончена. Отмеченные квадратики дают суммарный график пакета работ. Темные столбики показывают задачи, которые были завершены. Светлые клетки показывают работы, которые должны быть сделаны. Заметим, что диаграмма Ганта предназначена для обновления, обеспечивая проектную группу инструментом, позволяющим следить не только за тем, какие мероприятия запланированы на какие месяцы, но также предоставляет собой визуальный инструмент для отслеживания, какие виды деятельности завершены, а какие нет. В диаграмме Ганта по проекту строительства туалетов таблица построена с использованием компьютерной программы. В проектах развития другие средства также могут быть использованы. Например, часто диаграмму Ганта рисуют от руки либо на бумаге, либо на доске, которую вывешивают в офисе проекта. Еще один вариант разработки диаграммы Ганта в управлении проектами и программами – использование программы «Microsoft Project» или любой из десятков других программ на коммерческом рынке. Есть много факторов, которые следует учитывать при принятии решения, какой инструмент использовать для разработки диаграммы Ганта. Следует основываться на следующих критериях: Guide to the PMD Pro стр. 74 из 12 • • • • • Доступ к программному обеспечению; Компьютерные навыки и программное обеспечение; Стоимость и сложность проекта; Объем функций; Гибкость в изменениях в управлении проектом и обновлении планов проекта. Часто организации развития упускают из виду первый и второй критерии из списка выше при принятии решения. Реальность такова, что проектным группам в отрасли развитии, как правило, не хватает доступа к программному обеспечению или опыта в использовании таких программ. По этой причине проектные команды, как правило, управляют своими проектами вручную или с помощью текстового редактора и электронных таблиц. Такое решение является обоснованным, однако, важно признать, что по мере того, как растет уровень сложности проектов и их рисков, коммерческие программы управления проектами включают передовые характеристики, которые особенно полезны. Например, диаграмма Ганта программного обеспечения по управлению программами включает в себя функции, которые позволяют проектным группам: • определять связи между зависимостями проекта, т.е. автоматически определять, какие задачи должны быть завершены, прежде чем начнут выполняться другие, а также определять, когда внесение изменений в завершение одной задачи приведет к задержкам в инициировании других видов деятельности; • отслеживать деятельность по критическому пути, т.е. автоматически маркировать, когда задержки в деятельности на критическом пути угрожают задержать общий график сроков реализации проекта; • связывать диаграмму Ганта с другими важными документами управления проектами, т.е. автоматически выявлять, когда изменение в диаграмме Ганта требует интегрированных изменений в других документах, таких как бюджет проекта и структура декомпозиции работ. 3.2.5. Управление планом-графиком проекта. Руководители проекта должны регулярно следить за планом-графиком для соблюдения календарных сроков. Если график проекта начинает меняться, команда проекта будет иметь несколько вариантов, чтобы вернуть проект к плану. Например, сроки могут быть отложены, или масштаб проекта может быть уменьшен. Однако если проектные сроки являются фиксированными, и масштаб проекта не может быть изменен, возможно, не получится вернуться к плану-графику с помощью обычных методов управления графиком. Когда масштабы и даты проекта не являются гибкими, есть два альтернативных метода: быстрое средство достижения или ускорение графика, и критическое время или интенсификация (минимально необходимое время для выполнения конкретной работы). Ускорение графика15 (быстрое средство достижения): график проекта включает в себя деятельность, которая обычно выполняется последовательно вместо того, чтобы выполняться параллельно. Чтобы максимально ускорить деятельность, проектные группы должны, прежде всего, сконцентрироваться на задачах на критическом пути, поскольку деятельность на критическом пути обеспечивает наибольший потенциал для ускорения общего графика проекта. Например, в сетевой диаграмме проекта по строительству туалетов по первоначальному плану строительство помещения уборной должно было происходить после того, как выкопана яма для туалета. В сценарии ускорения графика (Иллюстрация 44), сетевая диаграмма и, следовательно, диаграмма Ганта, изменились настолько, что помещение уборной теперь строится одновременно с земляными работами по копанию ямы. При выполнении мероприятий параллельно, критический путь проекта оказался сокращенным по сравнению с первоначальным планом с 23-х дней до 17 дней, что позволяет проекту наверстать упущенное время. 15 Метод, средство или процесс, позволяющий достигнуть какой-либо цели или результата быстрее, чем обычно. Прим. переводчика Guide to the PMD Pro стр. 75 из 12 Иллюстрация 44. Ускорение графика по проекту строительства туалетов. Ускорение проекта – сокращение критического пути Выкопать яму 14 День 0 Установить крышу 1 Установить структуру 1 Построить крышу 6 Проверка качества 1 17 дней Построить структуру 6 Обучить комитет по водоснабжению и санитарии 1 Обучить сообщество 1 Интенсификация означает добавление дополнительных ресурсов для критического пути в целях ускорения прогресса, но не обязательно с высоким уровнем эффективности. Например, скажем, по первоначальному плану строительства туалета нужен был один человек, работающий 14 дней, чтобы вырыть яму. Для уменьшения этого срока одним из вариантов будет добавить еще одного человека для копания ямы. Это, скорее всего, увеличит скорость завершения мероприятий по копанию ямы. Однако не следует думать, что удвоение ресурсов увеличивает производительность. Часто производительность дополнительного ресурса бывает ниже. Заниженная производительность маргинальных ресурсов может возникнуть в результате целого ряда причин. Например, в пространстве ямы может быть недостаточно места для двух человек, чтобы эффективно работать, или у проекта нет материалов (лопат, ведер, кирки, веревки и т.д.) для поддержки работы двух землекопов. В случае реализации проекта строительства туалетов добавление второго землекопа к бригаде земляных работ сокращает время, затрачиваемое на копание ямы с 14 дней до 10 дней. Таким образом, в результате критического времени в проекте критический путь сократился с 23 дней до 19 дней. Guide to the PMD Pro стр. 76 из 12 Иллюстрация 45. Критическое время проекта (интенсификация) проекта по строительству туалетов Выкопать яму 10 День 0 Установить крышу 1 Установить структуру 7 Построить крышу 6 Проверка качества 1 19 дней Построить структуру 6 Обучить комитет по водоснабжению и санитарии 1 Обучить сообщество 1 3.3.Дисциплина 3: управление ресурсами проекта. Как следует из названия, управление ресурсами проекта – это организация и распределение ресурсов, имеющихся у проекта. Ресурсы проекта обычно включают в себя финансы, материалы, инвентарь, людское время, навыки, вклад, оборудование и информационные технологии. 3.3.1. Почему эффективное управление ресурсами так важно? Одной из самых важных и самых трудных задач руководителя проекта является действенно и эффективно организовать все ресурсы, задействованные в проекте. Само собой разумеется, что сложность этой задачи будет сильно зависеть от масштабов и характера проекта. Но во всех случаях это критический фактор успеха или неудачи. В любой момент времени руководитель проекта должен знать, как эффективно совмещать многочисленные ресурсы проекта. Менеджер должен знать, как создать и придерживаться бюджета, на что средства выделены, где они необходимы, и эффективно организовать рабочих и персонал проекта с тем, чтобы правильно распределить соответствующие задачи сотрудникам. Кроме того, надо иметь эффективное распределение услуг, расходных материалов и инвентаря таким образом, чтобы проект имел доступ к тому, что ему нужно, когда, и где это нужно, и по наиболее подходящей цене. Эффективная и быстрая связь со вспомогательными услугами является жизненно важной для успеха проекта. Часто говорится, что «управление проектами слишком важно, чтобы оставлять его на проектный персонал». Вспомогательный персонал имеет критические навыки и опыт. Они должны начать участвовать в проекте, как можно раньше. Неспособность привлечь их, как правило, приводит к неточному и/или неполному планированию и, как следствие, плохой реализации и доставки результатов проекта. Guide to the PMD Pro стр. 77 из 12 Управление проектами является интегрированным! Сотрудничество со вспомогательным персоналом Одной из наиболее важных задач в управлении ресурсами проекта является обеспечение, чтобы руководитель проекта вместе с сотрудниками поддержки (например, финансовыми сотрудниками, отделом кадров, ИТ, и цепочками поставок) и их руководители были тесно связаны и объединены. Такие взаимоотношения должны начинаться на этапе определения и проектирования проекта. Когда исходный проект сформулирован, соответствующий обслуживающий персонал должен быть вовлечен в создание квалифицированных бюджетных параметров, выявление навыков и определение потребностей в поставках. Когда проект входит в фазу планирования, вспомогательный персонал может быть особенно полезным в обеспечении, чтобы формат бюджета был правильным, чтобы оценки были точны, чтобы список статей бюджета являлся всеобъемлющим и, чтобы бюджет был детальным. Они будут обеспечивать, чтобы планы цепочек поставок были точными, и чтобы план набора и развития навыков был включен в планы проекта. Позже, когда проект входит в фазу мониторинга, оценки и контроля, вспомогательный персонал будет иметь решающее значение для обеспечения того, чтобы проектная финансовая отчетность была точна, своевременна и полезна. Только при такой информации проектная группа сможет получить полное понимание того, как движется исполнение проекта. «PMD Pro» фокусируется на трех сферах управления ресурсами проекта: управление финансами, управление цепочками поставок и управление людскими ресурсами (кадрами). Эти три сферы формируют ключевые службы поддержки проекта. Важно четко понимать, что главная ответственность за финансирование проектов, поставки и управление кадрами возлагается на руководителя проекта. Это верно, даже если руководитель проекта не несет прямой ответственности за управление финансами, поставками и персоналом. Работа руководителя проекта заключается в том, чтобы обеспечить, чтобы финансы проекта хорошо управлялись, товары, услуги и материалы управлялись эффективно, и чтобы сотрудники проекта имели все навыки, необходимые для достижения успеха. 3.3.2. Управление финансами проекта. Организации сектора развития обычно полагаются на лицо или организации доноров, финансирующих программы, и ожидается, что грантовые средства будут правильно администрироваться. Организации развития несут обязательства перед сообществами и партнерами, которых они обслуживают, будучи ответственными за то, чтобы средства, полученные от их имени, использовались оптимальным образом в целях обеспечения максимальной отдачи. Чтобы осуществлять разумное финансовое управление проектом, руководителю проекта необходимо развивать навыки в трех областях: • Разработка бюджетов. • Определение стоимости затрат. • Контроль бюджетов и расходов. Практическая реальность большинства проектов заключается в том, что руководитель не будет иметь полного контроля над всеми финансовыми процессами. Чтобы быть успешным, руководитель проекта должен сотрудничать и координировать свою работу с финансовым директором плюс множеством других людей на всех этапах процесса управления финансами. Несмотря на то, что всегда есть элементы финансового менеджмента, где руководитель проекта не имеет полной власти и контроля, руководитель проекта все же является ответственным лицом. Эти шесть областей координации и сотрудничества в области финансов особенно важны: • Оценка исторических данных финансовых отчетов. Guide to the PMD Pro стр. 78 из 12 • • • • • Объяснение отклонений в бюджете. Выдача чеков. Разрешение расходов. Управление балансами денежных средств. Реализация политики закупок. Как обсуждалось ранее, мандат руководителя проекта – принимать на себя ответственность за обеспечение общего успеха проекта. В случае финансовых элементов руководитель проекта должен обеспечить, чтобы роли и ответственности всех лиц, вовлеченных в финансовые процессы, были ясны, и чтобы все лица отвечали по своим обязательствам. 3.3.3. Разработка бюджета. Бюджет представляет собой описание финансового плана проекта, который включает в себя перечень оценок стоимости (смет) проекта. Как и для всех компонентов плана проекта, для точности бюджетов важно обеспечить, чтобы они были всеобъемлющими и подробными. Всеобъемлющее бюджеты – это все статьи бюджета, необходимые для предоставления продуктов и услуг. В качестве первого шага команде проекта необходимо определить расходы, необходимые для доставки продуктов и услуг проекта. Это расходы, связанные с непосредственной работой проекта, включая заработную плату, транспортные средства, сырье, материалы, оборудование и т.д. Однако важно не останавливаться на достигнутом, но помнить, что всеобъемлющий бюджет должен предусмотреть расходы, связанные с косвенным работами проекта. Руководитель проекта должен иметь ответ на важный вопрос: какие ресурсы потребуются для поддержки процессов, которые являются жизненно важными для успеха проекта? К ним относятся ресурсы, необходимые для связи, управления рисками, мониторинга, оценки, управления проектами, управления человеческими ресурсами, для закупок, интеграции проекта, а также общими накладными расходами проекта. Подробные бюджеты: так же, как и содержание и объемы проекта должны определить конкретные мероприятия, необходимые для успешной реализации проекта, бюджет проекта должен пройти этот процесс. В то время как квалифицированный бюджет помогает определить общие параметры проекта для различных заинтересованных сторон, команда проекта должна более точно и конкретно определить затраты проекта, чтобы успешно осуществлять деятельность. Некоторые примеры уровня детализации, который должен иметь проект: Ø Затраты на операции: например, при определении затрат на приобретение, команда, работающая над бюджетом, должна не только определить стоимость услуг или продукта, но и стоимость управления процессом закупок. Уровень детальности бюджета может включать расходы, необходимые для запуска проекта (создание системы внутреннего контроля, системы учета, процесса приема на работу, и т. д.), а также стоимость завершения проекта (закрытие договоров, увольнение персонала и т.д.) Ø Общие услуги: другой уровень детализации, который зачастую отсутствует в бюджете проекта, это стоимость услуг или работ, назначенных для проекта самой организацией развития. Например, надо ли включать в бюджет расходы на время, затрачиваемое на проект финансовым менеджером, водителем, сотрудниками информационных технологий или другими? Если проект не включает достаточный уровень детализации бюджета, он рискует быть неспособным оценить весь спектр услуг и надзора, необходимых для успешной реализации проекта. Дизайн и структура бюджетного документа часто зависят от источника финансирования проектов. Например, в ситуации, когда проекты развития получают деньги от внешних доноров, параметры бюджета наиболее часто следуют указанию доноров. В результате проектные бюджеты существенно различаются по плану счетов и срокам. Guide to the PMD Pro стр. 79 из 12 План счетов – статьи бюджета проекта сгруппированы по категориям расходов, которые помогают проектным командам охватывать и анализировать операции по программным областям, по источникам финансирования, по местонахождению, по отделам, и т.д. В свою очередь, эти категории расходов сгруппированы в суб-элементы, которые имеют постатейные коды. Обычная практика бюджетирования - использовать план счетов, который идентифицирует все счета проекта, но категории расходов и статьи бюджета не стандартизированы и отличаются между донорами, организациямиисполнителями, и /или партнерами по проекту. Сроки: все бюджеты должны определять период времени, к которому они относятся. Есть несколько подходов к управлению календарным планом бюджета: Ø Бюджет на срок действия проекта (или многолетний бюджет) – это общий бюджет на весь срок реализации проекта, который служит в качестве официального финансового документа, который сопровождает план проекта. Ø Ежегодный бюджет проекта – для некоторых проектов нормой считается пересмотр бюджета на регулярной основе и требование от сотрудников проекта представлять ежегодный бюджет после завершения каждого года проекта. В то время как многолетние бюджеты, как правило, являются стандартными для отрасли развития, требование годовых бюджетов снижает риски, что бюджетная смета на основе многолетней перспективы будет неточной, будет страдать от изменчивости цен, или не будет достаточно гибкой, чтобы приспособиться к изменениям в области операционной окружающей среды. 3.3.4. Бюджетирование на основе видов деятельности. Бюджетирование по видам деятельности ориентируется на определение расходов по мероприятиям, которые имеют место в каждой области проекта, и на определение, как эти мероприятия связаны друг с другом, включая прямые и косвенные работы. Сторонники такого бюджетирования считают его более реалистичным, чем другие подходы к составлению бюджета, поскольку оно включает понимание того, сколько фактически мероприятие будет стоить. Если руководитель проекта может составить полный (всеобъемлющий и разложенный по видам работ) перечень видов деятельности, а также смету расходов на деятельность, бюджет окажется точным. Такой бюджет, ориентированный на виды деятельности, предлагает больше возможностей для подключения линейного персонала16, что делает более вероятным, что бюджет будет точным. Хотя существует целый ряд возможных форматов бюджета, который включает детали, такие как коды счетов, коды доноров, издержки [затраты] на единицу продукции, они все имеют два одинаковых требования: 1. наличие полного перечня видов деятельности во время планирования сферы деятельности; 2. определение, что именно необходимо для достижения каждого вида деятельности, и оценка, сколько это будет стоить. Выполнив эти два требования, бюджет будет представлять подробную информацию по каждому виду деятельности, и показывать связанные расходы, которые, в свою очередь, будут контролироваться. Если мониторинг показывает, что фактические расходы превысили стоимость оценки, то менеджер проекта будет знать, что проект вряд ли полностью выполнит свои объемы. Потребуется перепланировка работ, чтобы найти более эффективные способы реализации оставшейся деятельности. 16 Линейный персонал – это сотрудники организации, участвующие в реализации основных целей организации; обычно имеются в виду работники, которые выполняют функции, непосредственно связанные с производством и реализацией товаров/услуг (в отличие от штабного персонала, лишь косвенно связанного с производством и реализацией). Прим. переводчика Guide to the PMD Pro стр. 80 из 12 Как вариант, руководитель может запросить правление проекта или другую структуру руководства проекта скорректировать содержание и объемы деятельности. Иллюстрация 46. Пример бюджета, составленного по видам деятельности. Мероприятия 1.1. Создание планового отдела. Оборудование 1. Компьютеры 2. Факс модемы 3. Мебель для офиса Наем персонала 1. Партнеры 2. Офисные сотрудники 1.2. Установление связей с правительством Совещания 1. Подготовка материалов для презентаций 2. Подготовка видео фильмов 3. Канцтовары 4. Закуски Затраты поквартальные 1-й кв 2-й кв 3-й кв 2000 500 3000 2000 800 200 800 300 Итого 4-й кв Всего мероприятий 4000 500 3000 800 300 800 300 3200 1100 11800 5000 1000 1000 5000 4000 200 100 6000 200 100 400 200 3.3.5. Определение смет. Независимо от проекта или формата бюджета проекта, финансовый план только тогда полезен, если он основан на хороших оценках. В какой-то мере всегда будет риск, связанный с проектными расчетами. Оценка никогда не будет точной наукой, которая производит 100% точный результат. Руководители проектов не могут предсказывать будущее. Всегда будут отклонения и переменные, которые будут находиться вне контроля проектной команды. И, тем не менее, хотя есть множество причин, почему точные оценки являются сложной задачей, расчеты могут быть достаточно точными, чтобы поддерживать хорошие проектные решения. Кроме того, есть хороший опыт, который помогает руководителям проектов повысить точность бюджетных расчетов: 1. Выбирайте правильный подход для расчетов – расчеты, как правило, делаются на основе комбинации трех следующих методов. Бюджетирование сверху вниз17 - такое бюджетирование начинается с глобальной оценки стоимости проекта, а затем указания процента общей оценки в отношении к различным фазам или пакетам работ проекта. Проценты, указанные для компонентов, обычно определяются лицами, имеющими предыдущий опыт по аналогичным проектам. Такой подход к расчетам, как правило, является более эксклюзивным и включает в себя сравнительно небольшую группу людей, которые считаются «экспертами» на основе их прошлого опыта. 17 Это метод бюджетирования, при котором руководители высшего и среднего звена, основываясь на стратегических целях организации, составляют общий бюджет организации, а затем разбивают его по подразделениям и проектам, после чего руководители нижнего звена разбивают полученные сметы на конкретные работы в рамках подразделения или проекта; далее руководители нижнего звена могут передавать сметы для дальнейшей детализации управляющим отдельных производственных линий, цехов и т. д. Л.Ф. Guide to the PMD Pro стр. 81 из 12 Бюджетирование снизу вверх18 не начинается с глобальной оценки стоимости проекта. Вместо этого, оцениваются задачи. В этой модели расчеты делаются с помощью тех, кто хорошо знает реальность места исполнения проекта, и кто часто является теми людьми, которые будут отвечать за осуществление деятельности по проекту (включая партнеров, поставщиков, членов сообщества, и т.п.). Оценка снизу вверх стремится привлечь большее количество участников и требует больше усилий в управлении. Такая оценка снизу вверх более вероятно будет точной, т.к. персонал на местах, вероятно, лучше знает ограничения в ресурсах, которые влияют на смету расходов. Например, они могут точно знать, сколько ресурсов различные сообщества могут обеспечить в помощь строительству уборной, в частности, чтобы выкопать яму, т.е. они могут дать точные расчеты, а не предположение, что все сообщества могут предоставить такой ресурс. Параметрические расчеты в меньшей степени полагаются на людей, а вместо этого используют статистическую взаимосвязь между историческими данными и другими переменными (например, квадратные метры в строительстве, метры дороги, и т.д.). Параметрические оценки, как правило, используются для проектов и компонентов, которые производят конкретные результаты (например, создание инфраструктуры, строительство дорог, переводческие услуги, и т.п.) Здесь оценка производится путем выявления исторических данных из проектов, которые произвели аналогичные результаты (например, километры дорог, квадратные метры в строительстве, строки текста) и использования их для расчетов масштабов работ и качества, цен и ресурсов, и/или времени и календарных дат. Этот метод может дать более высокий уровень точности, но зависит от качества исходных данных, встроенных в модель. 2. Разработка оценки этапов (когда это возможно): в начале реализации проекта доноры часто требуют жесткого соответствия бюджету проекта. Хотя эта практика часто рассматривается как хорошая стратегия управления неконтролируемым или быстро растущим бюджетом, стратегия работает только в той степени, в какой бюджет проекта реалистичен. Часто бывает трудно составить точный бюджет на ранних стадиях жизни проекта. Реальность места осуществления проекта часто меняется в процессе реализации. Возникают непредвиденные расходы. Цены и инфляция меняется. По этой причине, проектные команды часто предпочитают работать через процесс поэтапного составления сметы, который дает возможность разработки ряда бюджетов в различных периодах реализации проекта (это может быть, например, целый ряд годовых бюджетов). Эта стратегия помогает гарантировать, что бюджет проекта точен на момент перехода на следующий этап проекта. Он также обеспечивает логическое обоснование для управляющих органов проекта в целях подтверждения, что он по-прежнему "имеет смысл", прежде чем выделять и тратить дополнительные средства. 3.3.6. Мониторинг финансового исполнения проекта. При мониторинге финансовых показателей проекта первый вопрос, который возникает: проект превышает бюджет или отстает от бюджета? Чтобы ответить на этот вопрос, большинство проектных команд достают самые последние данные бюджета и сравнивают совокупные планируемые затраты с фактическими затратами проекта на определенную дату. К сожалению, такие расчеты не слишком полезны. С одной стороны они могут дать представление о том, что проект потратил больше или меньше денег, чем было рассчитано на определенный период времени, но они не дают никаких данных, чтобы объяснить, почему происходят любые отклонения. Возьмем, к примеру, данные в Иллюстрации 47. Предварительный анализ данных третьего месяца проекта показывает, что проект вышел за рамки бюджета: планируемые совокупные затраты на конец третьего месяца (1100) меньше, чем фактические совокупные затраты (1300). 18 Это метод бюджетирования, при котором бригадиры, руководители цехов или отделов производят на своем участке детальную оценку будущих затрат в трудо-часах, машино-часах, тоннах и других натуральных единицах, сообщают результаты руководителям более высокого уровня, которые переводят полученные данные в стоимостную форму, объединяют в укрупненные группы и отправляют руководителям верхнего уровня на одобрение и утверждение. Л.Ф. Guide to the PMD Pro стр. 82 из 12 Иллюстрация 47. Пример бюджета шестимесячного проекта, включая фактические затраты до третьего месяца. Задача A B C D E F J H I J Запланированная общая стоимость за месяц Запланированная совокупная стоимость Фактическая общая стоимость за месяц Фактическая совокупная стоимость Запланированная стоимость 100 200 100 400 100 200 200 100 300 100 Месяц 1 Месяц 2 Месяц 3 Месяц 4 Месяц 5 Месяц 6 100 200 100 400 100 200 200 100 300 100 300 700 300 300 100 100 100 400 1100 1400 1700 1800 150 350 800 150 500 1300 К сожалению, этот быстрый расчет не дает полной картины финансового состояния проекта. Да, проект потратил на 200 (11%) больше, чем запланированный бюджет на первые три месяца реализации проекта. Однако, хотя есть соблазн предположить, что стоимостное отклонение в конце третьего месяца говорит о том, что есть превышение бюджета, надо быть осторожными с такими предположениями. Превышение расходов может быть отнесено к одной из двух причин: Вариант А: с одной стороны, проект может быть дороже, чем первоначально оценивалось. В этом случае мероприятия проекта запланированы, но они стоят дороже, чем предполагалось в бюджете. Анализ: вариант А безусловно проблематичен. Он указывает на тенденцию, которая, если будет продолжаться, приведет к выходу проекта за рамки бюджета. В этой ситуации необходимо предпринять корректирующие действия, чтобы гарантировать, что проект избежит бюджетного дефицита. Вариант Б: проект потратил больше, чем ожидалось, потому что проект идет с опережением графика. В результате проект тратит больше, чем ожидалось в первые три месяца реализации проекта. Анализ: вариант Б не обязательно является проблемой. Да, проект по сценарию Б тратит больше денег в месяц, чем первоначально планировалось, но он также выполняет больше работ, чем это было запланировано. В этом случае проект должен собрать больше информации, чтобы решить, затрачивает ли проект больше денег, чем планировалось на такие виды работ. Примечание: в обоих случаях следует убедиться, что проект имеет достаточно наличности (денежных потоков) для продолжения своей деятельности, потому что он тратит больше денег в месяц, чем изначально предполагалось. Сценарий Б представляет собой интересную задачу для команды проекта. Этот сценарий подчеркивает, что не достаточно только рассматривать, потратил ли проект больше или меньше денег, чем это было рассчитано для определенного периода времени. Важно проводить мониторинг финансовых показателей, отслеживая два отдельных, но взаимосвязанных показателя: денежные потоки и анализ заработанной (выполненной) стоимости. Guide to the PMD Pro стр. 83 из 12 3.3.6.1.Контроль затрат проекта через анализ освоенного объема. Самый лучший способ отслеживания затрат проекта – это контроль стоимости выполненных работ в течение периода времени. Анализ освоенного объема (или заработанной (выполненной) стоимости) является инструментом, который сравнивает плановые и фактические затраты по каждой задаче, которая выполнена, а также сравнивает темпы прогресса по каждой задаче, которая была запланирована в плане проекта. Это означает, что для того, чтобы провести анализ освоенного объема, руководителю проекта понадобится более полный набор данных, который сочетает в себе элементы бюджета проекта и календаря проекта. Иллюстрация 48 представляет собой пример обновленного взгляда на шестимесячный проект, представленный ранее, но теперь он включает две новых колонки, которые дают фактическую стоимость каждой задачи и процент выполненных работ по каждой задаче. Иллюстрация 48. Пример бюджета шестимесячного проекта, включая анализ освоенного объема Задача A B C D E F J H I J Запланиро ванная общая стоимость за месяц Запланиро ванная совокупная стоимость Фактическ ая общая стоимость за месяц Фактическ ая совокупная стоимость Запланиро ванная стоимость 100 200 100 400 100 200 200 100 300 100 Фактическая стоимость 150 200 100 400 100 200 50 100 % выполнено 100% 100% 100% 100% 0% 50% 100% 50% 50% 0% Месяц 1 Месяц 2 Месяц 3 Месяц 4 Месяц 5 Месяц 6 100 200 100 400 100 200 200 100 300 100 300 700 300 300 100 100 100 400 1100 1400 1700 1800 150 350 800 150 500 1300 При анализе информации в Иллюстрации 48 можно сделать два важных вывода: • Через три месяца проект полностью или частично завершил восемь задач. Сравнение плановых затрат на каждую из этих задач с фактической стоимостью выполнения работ показывает, что проект точно соответствует бюджету (проект потратил 1300 на работу, которая стоит 1300). • Проектный план предусматривает выполнение работ стоимостью 1100 за три месяца. Вместо этого было выполнено работ на 1300. Это означает, что проект идет на 18% с опережением графика. Так какие выводы можно извлечь из этого анализа? • Если проект будет продолжаться с текущей скоростью работ, он завершится досрочно. • Если тенденция проекта сохранится без изменений, проект завершится в рамках бюджета. Guide to the PMD Pro стр. 84 из 12 Обратите внимание, что выводы анализа освоенного объема отличаются от выводов анализа отклонений в совокупной стоимости в предыдущем параграфе. Это происходит потому, что анализ освоенного объема предоставляет больше информации, которая объединяет данные об объеме работ, бюджете и календарных периодах мероприятий проекта. В результате анализ освоенного объема позволяет понять, что не все сценарии, в которых совокупные расходы превышают бюджет проекта, плохие. С другой стороны, не все сценарии, в которых суммарные затраты проекта ниже бюджетных, хорошие. Руководителю проекта следует более подробно изучить информацию, чтобы получить ясное понимание бюджетной ситуации по сравнению с запланированным бюджетом на осуществление проекта. Иллюстрация 49 дает представление о комбинации результатов, которые могут возникнуть при проведении анализа заработанной стоимости, и показывает последствия различных сценариев. Обратите внимание, что таблица дает некоторые комбинации бюджета и графика, которые являются "хорошими", "плохими" и такими, которые требуют больше информации, чтобы понять состояние проекта. Иллюстрация 49. Результаты комбинаций анализа заработанной стоимости Отставание от бюджета В соответствии с бюджетом Превышение бюджета Отставание от планаграфика Нужно больше данных Плохо По плану-графику Хорошо Хорошо Опережение планаграфика Хорошо Хорошо Плохо Плохо Нужно больше данных Такая классификация статуса проекта, как показано в таблице в Иллюстрации 49, является очень полезной, однако руководители проектов должны использовать ее для более глубокого исследования: о чем говорит анализ текущего освоенного объема. Является ли нынешнее состояние результатом решений по управлению качеством, управлению рисками, управлению заинтересованными сторонами, или результатом одной из многих других причин, которые влияют на бюджет и календарь? И, наконец, есть одно последнее важное наблюдение. В то время как анализ освоенного объема может дать хорошие данные, которые помогают лучше контролировать финансовое состояние проекта, но он также требует точной учетной системы проекта, которая интегрирует стоимость на основе видов деятельности и данных плана-графика. Вместе эти данные могут быть использованы для расчета заработанной стоимости в отношении общей стоимости проекта и сроков исполнения. Система учета должна быть основана на практической структуре разбивки работ по видам деятельности и должна включать своевременную информацию о затратах. Любая задержка в отчете о затратах - это задержка в способности оценить текущую стоимость и статус плана-графика проекта. Эти условия часто отсутствуют в системах организаций развития, что делает затруднительным применение этого инструмента управления в контексте проектов развития. 3.3.7. Управление поставками. Представьте, что вы строите дом. Как бы вы решали сложные проблемы, связанные с управлением доставкой товаров и услуг от места происхождения до конечного использования в строительстве дома? Как вы планируете покупку материалов, сроки поставки, покупку оборудования, определяете помещение для хранения материалов, получение разрешений, отслеживаете состояние всех материалов, и так далее и тому подобное? Список можно продолжать. А теперь представьте строительство дома в отдаленном, бедном ресурсами сообществе. Как руководитель проекта вы должны управлять всем комплексом проблем с поставками, перечисленными выше, но вам также необходимо управлять множеством рисков, которые являются специфическими в контексте развития. Есть надежные поставщики? Существует ли коррупция в системе закупок? Существуют ли механизмы для транспортировки материалов? Есть ли проблемы с безопасностью? Вызывает ли беспокойство безопасность персонала? Какова ограниченность ресурсов? Даже этот краткий перечень дает представление о рисках в управлении поставками в проектах развития. Guide to the PMD Pro стр. 85 из 12 Задержки, вызванные неправильным управлением линией поставок, приводят не просто к потере управления проектом, но и к потере репутации и разочарованию бенефициара. Это бесценное достояние, которое почти невозможно восстановить, если оно потеряно. Более того, в связи с критическим характером услуг развития, которые предоставляют организации, недостатки и упущения могут привести к серьезным последствиям для бенефициаров, которые могут быть буквально на грани между жизнью и смертью. Кроме того, управление цепочкой поставок может составлять существенный процент от бюджета проекта. Вот почему важно, чтобы поставки проекта управлялись эффективно и действенно. Скорее всего, руководитель проекта не будет напрямую отвечать за функцию управления цепочками поставок. Скорее всего, в проекте будет группа лиц, которые обеспечивают снабжение и материальнотехническую поддержку ряду проектов. Несмотря на это, руководитель проекта несет ответственность за то, чтобы у проекта имелись правильные товары и услуги в нужное время и, как следствие, нуждается в тесном сотрудничестве и координации действий с лицами, отвечающими за функцию поддержки поставок для достижения успеха. «PMD Pro» определяет три следующих компонента управления цепочками поставок. Управление закупками, в том числе определение того, какие материалы и услуги необходимы, когда они необходимы, как они будут приобретаться, и кем. План закупок должен быть интегрирован со всеми другими элементами в план проекта, чтобы все решения о закупках были приведены в соответствие с бюджетом, календарными датами, качеством и параметрами рисков проекта. Материально-техническое обеспечение, в том числе планирование, осуществление и контроль за эффективным и экономически рентабельным поступлением и хранением сырья, материальных запасов, готовой продукции и информации от точки происхождения до пункта потребления с целью соответствия требованиям заказчика. Управление активами, в том числе систем, с помощью которых вещи, которые имеют значение для проекта, отслеживались, обслуживались и использовались. Руководитель проекта отвечает за то, чтобы эти компоненты находились под контролем. 3.3.7.1.Управление закупками. Закупка включает в себя полный процесс получения товаров и услуг от подготовки и обработка реквизитов до получения и утверждения счета на оплату. Руководитель проекта может нести ответственность за фактическое приобретение услуг или товаров, необходимых для разработки и реализации проекта, или может направлять, руководить этой деятельностью через руководителя группы контрактов или закупок. Независимо от роли и ответственности руководителя проекта, закупочная деятельность может оказать существенное влияние на бюджет проекта и план-график, поэтому они должны быть интегрированы в общий план проекта, бюджет и план-график. Примеры типичных закупок, связанных с проектом: • Материалы: они могут варьироваться от типичных продуктов, таких как мебель и персональные компьютеры, до узкоспециализированных продуктов для проектов, таких как медицинское оборудование, машины для бурения скважин, или дорожно-строительные материалы. Руководитель проекта может нести ответственность за фактические приобретение услуг или товаров, необходимых для разработки и реализации проекта, или может направлять эту деятельность через специалиста по закупкам. • Консультанты: часто даже при наличии внутренних ресурсов для выполнения значительного количества работ по проекту необходимы дополнительные ресурсы для завершения проекта в срок или предоставления необходимого опыта. Одной из стратегий является получение внешних ресурсов, как правило, консультантов, для усиления сотрудников проекта. • Поставщики: поставщик берет на себя ответственность за выполнение всех аспектов выбранных услуг, как правило, по конкретным стандартам и за фиксированную стоимость. Guide to the PMD Pro стр. 86 из 12 Например, это могут быть услуги по сносу сооружений, транспортные, охранные или строительные услуги. Существует три этапа в управлении закупками: • Планирование закупок. • Определение поставщиков. • Выбор, переговоры и заключение контракта. 3.3.7.1.1. Планирование закупок. Желательно создать план закупок, когда проект требует, чтобы предметы были закуплены у поставщиков. План материально-технического обеспечения определяет товары и услуги, которые проект будет получать от внешних поставщиков. Хороший план закупок включает еще один шаг, описывая процесс, который надо пройти, чтобы определить поставщиков на договорной основе. Этапы планирования закупок включают в себя: • Определение предметов, которые надо закупить. • Определение процесса приобретения этих предметов. • Планирование сроков доставки. 3.3.7.1.2. Определение поставщиков. Различные документы по закупкам могут быть использованы для получения информации от потенциальных поставщиков услуг и материалов. Расчеты: независимые расчеты времени и затрат, которые потребуются для предоставления услуг или материалов делаются, когда критерии выбора поставщика являются относительно простыми и основаны в первую очередь или исключительно на цене. В то время как цена является особенно важным фактором для расчетов затрат, следует внимательно отнестись к оценке предлагаемой стоимости, чтобы убедиться, что она реалистичная и не слишком оптимистичная цена, которая принимает во внимание технологии и навыки, вовлеченные в проект. Если имеются существенные различия между затратами и расчетами по плану-графику в представленных предложениях, самая низкая ставка не всегда может быть лучшей ценой. Если низкая цена предложения значительно ниже других предлагаемых цен, следует внимательно изучить предложение. Если контракт окажется не выгодным, это может создать много проблем и для подрядчиков и для агентства. Предложение: когда критерии отбора потенциальных поставщиков являются сложными, документы для расчетов не обязательно будут включать всю информацию, необходимую для принятия обоснованного решения. Такие типы закупок могут собрать дополнительную информацию с помощью приглашения на участие в конкурсе или через запрос на предложение19. RFP должен содержать полное, но краткое изложение работ, которое четко определяет требуемую продукцию или услуги, включая функциональные, эксплуатационные и рабочие характеристики, и необходимые интерфейсы с системами других агентств и процессов20. 3.3.7.1.3. Выбор, переговоры и заключение контрактов. Процесс закупок должен быть разработан для того, чтобы организация могла получать и оценивать сметы и предложения различных поставщиков, используя различные надлежащие критерии для принятия решения. Критерии отбора могут быть ограничены ценой и датами поставки, если материалы или услуги доступны и относительно просты по своей конфигурации. В целом, однако, выбор поставщика основывается на сочетании финансовых и технических соображений. Какие бы критерии отбора не применялись, группа, ответственная за принятие решения, должна иметь четкое 19 IFB от английского “Invitation for Bids” – это приглашение принять участие в торгах или переговорах о выдаче подряда. RFP (Request for Proposals) – это запрос предложений на заключение контракта. Л.Ф. 20 Объем и содержание работ – это один из пунктов контракта, описывающий обязательства подрядчика по выполнению работ. В английской аббревиатуре - SOW от “Statement of Work”. Л.Ф. Guide to the PMD Pro стр. 87 из 12 представление о критериях, применяемых для принятия решений, и их относительный вес. понимание будет лежать в основе окончательного выбора. Это 3.3.7.2.Управление логистикой (материально-техническим обеспечением). Поскольку многие проекты зависят от своевременной поставки материалов, надлежащая логистическая поддержка необходима. Логистика означает наличие нужных вещей в нужном месте в нужное время. В узком смысле, логистика включает в себя транспортировку товаров. В широком смысле, логистика включает в себя все мероприятия, необходимые для доставки товаров аккуратно, эффективно, своевременно в то место и тем людям, для которых они предназначены. Такое широкое определение материально-технического обеспечения включает в себя: • Управление запасами и складами. • Транспортировку материалов. 3.3.7.2.1. Управление запасами и складами. В зависимости от проекта товарно-материальные запасы могут представлять большую стоимость от общей стоимости проекта. Такая стоимость состоит из стоимости самих товарно-материальных запасов, а также затрат на транспортировку товаров, расходов на управление товарами (труд, упаковка, и т.п.) и хранения товаров на складах. Проектная группа должна создать управление инвентарными запасами, которое обеспечивает, чтобы материалы были в наличии для удовлетворения потребностей проекта, когда необходимо. Для этого руководитель проекта должен координировать свои действия с членами команды, которые непосредственно отвечают за управление запасами, постоянно отслеживают потребности в материалах относительно изменяющихся потребностей и приоритетов проекта. В рамках этой задачи проект должен установить баланс между спросом и предложением путем создания и поддержания минимального ассортимента для покрытия потребностей в течение времени, которое необходимо для подготовки размещения заказа, или «времени на выполнение покупки»21. Когда сотрудники проекта создают такой баланс, руководитель проекта должен обеспечить наличие соответствующих политик для установления стандартов и контроля для управления всеми элементами управления запасами и складами. 3.3.7.2.2. Транспортировка материалов. Цель транспортировки - физическое перемещение поставок надежным и безопасным образом, своевременно и экономически эффективно к месту назначения. Транспортная стратегия зависит не только от потребностей проекта, но может варьироваться от ситуации к ситуации. 3.3.7.3.Управление активами. Все оборудование, материалы и другое имущество, финансируемое или предоставляемое в рамках проекта, должно считаться активами проекта. Таким образом, проект должен определить политику управления активами, с помощью которой материалы, представляющие ценность для проекта, контролируются, содержатся и утилизируются в соответствии с требованиями организации и/или доноров. Такая политика должна включать в себя рекомендации по следующим темам. Определение активов: каждая организация должна устанавливать собственное определение цены и срока полезного использования имущества, что и определяет, что является активом организации. Это определение будет зависеть от организации, донора и/или проекта. ПРООН, например, определяет порог для основных средств в размере 1000 USD или больше, а срок службы не менее трех лет. В приведенной ниже таблице представлен обзор некоторых основных категорий активов ПРООН и продолжительность срока службы для каждой из этих категорий активов. 21 Время на покупку - промежуток времени между принятием решения о необходимости размещения заказа и поступлением заказанных товаров на склад, или иными словами, время между принятием решения о необходимости приобретения того или иного сырья или материала и его получением, которое складывается из времени, необходимого для подготовки размещения заказа, и времени на выполнение и доставку заказа. Прим. переводчика. Guide to the PMD Pro стр. 88 из 12 Иллюстрация 50. Категории активов ПРООН Категория Типичные офисные предметы, работающие на электричестве Крупное оборудование (генераторы, кондиционеры) Мебель Автомашины Срок службы 3 года Другие факторы 20 лет 10 лет 5 лет Или 100000 км (62000 миль) Документы активов: проекты должны вести полный и точный учет всех приобретений основных средств. Все активы, приобретенные для проекта (через приобретение, передачу или дарение), должны быть документированы. Маркировка активов - активы проекта должны быть маркированы (обозначены) для облегчения надзора и контроля над ними. Любая подходящая условная маркировка может применяться, если она применяется последовательно и служит для отслеживания активов. Документы мониторинга (отслеживания) активов: информация по активам должна обновляться на регулярной основе для учета приобретений, корректировки, передачи и удаления информации, включая физический подсчет. Всякое расхождение должно быть исследовано, понято и описано в журнале учета проблем проекта. Надежное содержание активов: создание адекватного контроля в месте хранения активов, чтобы основные средства должным образом содержались и были защищены. Такой контроль будет меняться в зависимости от активов и рисков. Например, организация может потребовать, чтобы компьютеры (ноутбуки) были обеспечены соответствующим блокирующим кабелем и надежно закрывались в шкаф, когда они не используются. Другим примером может быть требование, чтобы офисное оборудование, выданное для пользования сотрудникам, всегда было зарегистрировано в журнале учета выданного оборудования. Распоряжение активами – должны иметься четкие процессы распоряжения активами, включая требования, связанные с одобрениями, гласностью, требованиями доноров и требованиями по отчетности. При необходимости, политика должна включать в себя любые специальные требования, относящиеся к стоимости актива или типа актива в управлении (транспортные средства, компьютеры, иное). Плохое распоряжение активами может оказать существенное влияние на финансирование проекта, поскольку доноры могут отказать в расходах на активы, которые были неправильно утилизированы, и могут потребовать возврата средств или уменьшить денежные средства по окончательным договорным расчетам. 3.3.8. Управление кадрами. Управление людскими ресурсами (кадрами) является искусством и наукой. Искусство управления кадрами зависит от межличностного общения и лидерских качеств руководителя проекта. Может ли руководитель проекта мотивировать заинтересованных сторон? Внушать доверие? Управлять конфликтами? Формировать мораль команды? Наука управления людскими ресурсами зависит от эффективного планирования. Планирование кадровых ресурсов является неотъемлемым элементом комплексного плана реализации проекта. План управления кадрами проекта определяет деятельность и ресурсы, необходимые для управления сотрудниками проекта. Компоненты управления кадровыми ресурсами включают в себя: Приобретение персонала для проекта: в рамках функции управления командой руководитель проекта должен иметь четкие системы для определения кандидатов, проведения собеседований с кандидатами, определения критериев отбора, и окончательного выбора сотрудников проекта. Определение назначений сотрудников проекта: назначение сотрудников – это перечень проектных обязанностей, ролей и ответственности сотрудников. Назначение сотрудников и Guide to the PMD Pro стр. 89 из 12 распределение заданий часто происходит в процессе мониторинга и контроля для оценки отдельных членов команды. Документирование организационной схемы проекта: схема проекта представляет отношения отчетности между сотрудниками проекта. Развитие сотрудников проекта: какие навыки необходимы, каковы потребности в обучении, есть ли требования по сертификации (аттестации), какие имеются вопросы по соответствию нормативам? Проведение оценки эффективности: оценка работы является документированной официальной или неофициальной оценкой деятельности членов проектной группы. После анализа информации руководитель проекта может выявлять и решать проблемы, снижать конфликты, а также улучшать общую работу команды. Содействие высокопроизводительной атмосфере работы команды: как лидер проекта, руководитель проекта должен активно проводить работу по выявлению проблем и конфликтов и работать творчески, чтобы решать эти проблемы. Многие виды деятельности, связанные с управлением сотрудниками проекта (реализация плана набора сотрудников, приобретение персонала, определение назначений сотрудников, документирование организационной структуры) являются техническими по своей природе, и часто описываются как «наука» в управлении проектной командой. Навыки, отношение и поведение, необходимые для стимулирования высокопроизводительного коллектива, зависят от способности руководителя проекта действовать за пределами «науки» управления проектами и применять «искусство» управления. Для содействия высокопродуктивному коллективу руководитель проекта должен обладать умением передать видение деятельности, вдохновить на общую ответственность, перемещать планы внутри и вне организации, и управлять ситуациями, когда нет прямой иерархической власти. 3.4.Дисциплина 4. Управление рисками. При исследовании "основных" элементов сильного управления проектами большинство дискуссий быстро сводятся к теме риска. Но что такое риск? Этот термин часто используется свободно, без последовательности, а иногда и неправильно. В контексте «PMD Pro» риск – это потенциальное воздействие неопределенности на цели проекта. При рассмотрении определения риска существуют две следующих ключевые идеи, которые должны быть дополнительно изучены. Вероятность: риск можно рассматривать как вероятность неопределенных будущих событий (по сравнению с вопросами, которые касаются текущих событий, которые должны быть немедленно рассмотрены). Помните, о чем говорилось в ходе обсуждения во втором разделе о фазе реализации проекта: проблемы проекта – это риски, которые стали реальностью. Воздействие: риск обладает потенциалом влияния на проект. Большинство команд проекта сосредоточены на негативных рисках, у которых есть потенциал навредить проекту (время/календарные даты, стоимость/ресурсы, качество, объем и т.д.). В целом отрицательных рисков следует избегать. Положительные риски, с другой стороны, менее признаваемы и менее понимаемы. Коллектив проекта может допустить положительные риски, если они видят потенциал возможностей наряду с потенциалом для провала. Это называется интеллектуальное принятие риска. Управление рисками, однако, является одной из основных дисциплин управления проектами, и целью этой главы является краткое руководство по управлению рисками в секторе развития. Рисковым событием является то, что может случиться, и может повлиять на проект. Обратите внимание, что формулировка «может случиться» указывает на вероятность меньше, чем 100%. Если событие имеет вероятность 100%, другими словами, оно обязательно произойдет, событие становится проблемой (см. обсуждение вопросов управления во втором разделе). На самых ранних стадиях определения и разработки проекта коллектив начнет получать начальное понимание потенциальных рисков, которые могут повлиять на проект. Например, в проекте по сельскому хозяйству начальное интервью с фермерскими семьями может выявить проблемы в области маркетинга и каналов сбыта продукции. По мере развития проекта некоторые риски будут устранены или уменьшены, а другие могут возникнуть. Важно, однако, постоянно возвращаться к вопросам риска с самых ранних стадий проекта на протяжении всей реализации. Guide to the PMD Pro стр. 90 из 12 Рисками управляют посредством четырехэтапного процесса: • Идентификация риска - определение и документирование всех рисков, которые могут повлиять на проект. • Оценка риска - определение вероятности того, что риск будет иметь место, оценки его потенциального воздействия, а также оценки рисков по приоритетности. • Планирование мер реагирования на риск - решение, какие меры необходимы для снижения или устранения угроз, особенно в странах с высокой вероятностью возникновения рисков и их большого воздействия. • Мониторинг и контроль над рисками – реагирование на риск по мере возникновения и обеспечение исполнения адекватных процедур управления рисками. 3.4.1. Идентификация риска. Есть два этапа в процессе идентификации риска: 1. Определение категорий рисков проекта. 2. Определение конкретных рисков, которые подпадают под каждую категорию. Управление проектами является всесторонним! Отрицательные и положительные риски Полноценное управление рисками обращает внимание на негативные и на положительные риски. Негативные риски представлены потенциальными событиями, которые могут нанести вред проекту. В общем, этих рисков следует избегать. Положительные риски, с другой стороны, относятся к рискам, которые мы инициируем сами, потому что мы видим потенциальные возможности наряду с потенциалом для неудачи. Возьмем, к примеру, проект в сельском хозяйстве, который по оценкам займет шесть месяцев. Проектная группа понимает, что если добавить ряд новых партнеров, проект может быть завершен за половину этого времени. Конечно, новые партнеры означают новые риски. Что делать, если их способности окажутся низкими? Что если будут задержки в принятии новых систем? И т.п. Существует дилемма: рискнуть и внедрить риск для получения положительных результатов или остаться с традиционными партнерами и согласиться на шестимесячный срок исполнения проекта? 3.4.1.1.Определение категории риска. Классификацию рисков можно сравнить с эффективным медицинским обследованием. Если врач спрашивает: "Как вы себя чувствуете?" Пациент может сказать: "Хорошо". Но обследование покажет намного больше, если врач спросит: "Как ваши колени? Как ваши легкие? Есть ли боли в спине?" С такими вопросами пациент начнет думать конкретно о конкретных участках тела. Категории, однако, не должны быть слишком широкими или слишком конкретными. Если в приведенном выше примере врач спросит только о верхней или нижней части тела, это не слишком поможет. Точно также, если врач начнет расспрашивать о каждой кости, суставе или органе, пациент быстро разочаруется в связи с тратой времени. Вместо этого, врач должен определить необходимое количество значимых категорий, которые помогают выявлять проблемы пациента. При разработке категорий риска проектов развития важно признать, что каждый проект является уникальным, и невозможно разработать единый набор категорий риска, которые подходят для всех организаций и проектов. Проектные команды должны обследовать контекст конкретного проекта для разработки комплекса категорий риска, который соответствует их уникальным потребностям. Ниже представлены некоторые потенциальные категории рисков проектов: Стратегические/коммерческие • Отказ поставщиков от исполнения договорных обязательств. • Мошенничество / кражи. • Исполняющие партнеры не в состоянии обеспечить желаемый результат. Guide to the PMD Pro стр. 91 из 12 Экономические/финансовые/ рыночные • Колебания обменного курса • Нестабильные процентные ставки • Инфляция • Отрицательное влияние ситуации на рынке на планы проекта. Правовые и нормативные • Новое или измененное законодательство делает предположения. • Невозможность получения соответствующего разрешения. • Неудовлетворительные контрактные договоренности. недействительными проектные Организационные / управленческие / человеческий фактор • Плохое руководство. • Недостаточные полномочия основного персонала для исполнения своих ролей. • Плохие процедуры отбора персонала. • Отсутствие ясности по поводу ролей и обязанностей. • Столкновения личностей. • Отсутствие оперативной поддержки. Политические • Изменение государственной или правительственной политики. • Война и беспорядки. • Неблагоприятное общественное мнение / вмешательство СМИ. • Вмешательство политиков в принятие решений. Окружающая среда • Стихийные бедствия. • Резкое изменение погодных условий. Технические / оперативные / инфраструктурные • Недостаточная разработка проекта • Расползание объемов работ. • Неясные ожидания Риск управления проектами • Отсутствие планирования, анализа рисков, непредвиденных обстоятельств. • Недостаточное отслеживание и отсутствие своевременного контроля. • Нереалистичные графики. • Плохо организованная логистика. • Задержка в утверждении проектной документации. 3.4.1.2.Определение конкретных рисков. После того, как определена общая категория риска, команда проекта должна в сотрудничестве с ключевыми заинтересованными сторонами определить конкретные риски из каждой категории. Как минимум, команда и ключевые заинтересованные стороны должны начинать с изучения конкретных проектов и программных документов. Существуют многочисленные методы определения риска. Среди них коллективные обсуждения (мозговой штурм), неформальные дискуссии с участниками (фокус группы), планирование сценариев и собеседование с экспертами. При выявлении рисков следует описывать риски таким образом, чтобы три фактора были очевидными для читателя: Guide to the PMD Pro стр. 92 из 12 • Причины или происхождение риска; • Рисковое событие или ситуация; • Влияние рисков на проект. Например: «В связи с тем, что транспортировка материалов в этой области может быть задержана наводнением, есть риск, что поставки цемента не будут сделаны своевременно, что означает, что строительство туалета не будет завершено по графику". Такое описание рисков позволяет разрабатывать ответные меры по проблемам, включая причины, риск и его воздействие. Многие первоначальные риски определяются на стадии идентификации и разработки проекта. Как только проектная группа обследует контекст проекта посредством оценки и анализа сферы деятельности проекта, результаты этих действий дадут картину возможных рисков проекта. Процесс идентификации рисков необходимо продолжать в течение всего срока реализации проекта потому, что риски проекта будет развиваться с течением времени. Например, на самых ранних этапах проекта риски могут быть сконцентрированы в сфере приобретения фондов или управления заинтересованными сторонами. Когда начнется фаза реализации проекта, риски могут приобрести операционный характер и могут быть сконцентрированы в вопросах планирования, оценки и составления бюджета/контроля. Все это указывает на то, что выявление рисков не является одноразовым мероприятием, совершаемым один раз в начале проекта. Риски должны контролироваться на протяжении всего жизненного цикла проекта для того, чтобы проектная команда осознавала потенциальную угрозу для успеха проекта, которая неизбежно возникнет. 3.4.2. Оценка риска. Оценка риска представляет собой процесс определения количественного состава рисков, задокументированных на стадии идентификации рисков. Оценка рисков включает две особенно трудные задачи управления рисками проекта: • Определение приоритетов рисков: на основании критериев, согласованных между сотрудниками проекта и ключевыми заинтересованными сторонами, риски ранжируются в зависимости от их вероятности и последствий. • Выявление допустимости рисков: проектная группа должна работать с ключевыми участниками для определения приемлемого уровня допустимости риска и неприемлемого уровня, которые должны находиться под контролем. Полезным инструментом для оценки риска является матрица (таблица) оценки рисков. В таблице ниже приведен пример, как матрица может быть использована для оценки риска в проектах развития. Иллюстрация 51. Матрица оценки рисков. Вероятность возникновения риска Высокая Средняя Низкая Риск В Риск С Низкая Средняя Риск А Высокая Потенциальное влияние на проект В приведенном выше примере матрица разработана на основе двух выполненных действий: Ранжирование рисков по приоритетности: команда проекта и заинтересованные стороны определили три приоритетных риска путем ранжирования их вероятности и потенциального воздействия на сферу деятельности проекта по типу: низкий, средний или высокий. Guide to the PMD Pro стр. 93 из 12 Определение приемлемости риска: риски классифицированы по цвету (красный, оранжевый, желтый). В данном примере риск B явно представляет тревогу и должен находиться под активным контролем. Риск, обозначенный желтым цветом, вызывает более низкий уровень озабоченности, но тоже должен находиться под контролем. Не закрашенный риск не превышает допустимого уровня. В некотором смысле матрица оценки риска является обманчиво простым инструментом. Матрица может быть относительно простой, но чтобы использовать ее продуктивно, команды проекта и ключевые заинтересованные стороны должны иметь общее понимание критериев, которые используются для распределения рисков по приоритетам и выявления уровня толерантности к риску. Чтобы прийти к общему пониманию, руководитель проекта должен работать с ключевыми участниками проекта, чтобы получить ответы на следующие вопросы, что бывает иногда трудным процессом: • Какие критерии будут использоваться для определения приоритетности рисков? Время? Область? Стоимость? Другие факторы, имеющие значение для бенефициаров проекта? Соответствие правилам доноров? Безопасность сотрудников? • Какой процесс будет использован для выявления допустимости риска? 3.4.3. Ответные меры на риски. Выявление и оценка риска образуют основу для надежных вариантов реакции на риски. После того, как риск определен, как превышающий уровень допустимости по проекту, проектная группа должна определить стратегию наилучшего реагирования на риски. Помните! Целью управления рисками является не устранить все риски проекта. Скорее, цель состоит в определении, когда реагировать, если риск превышает уровень допустимости. Например, проекты, которые «не допускают риски», будут активно контролировать риски, независимо от того, в каком месте матрицы они обозначены. С другой стороны, проекты «допускающие» риски, могут быть готовыми принять большое количество рисков, не занимаясь активным управлением ситуацией. Если проект решает активно управлять рисками, стратегия реагирования включает следующие варианты (или сочетание вариантов): • Избежание рисков: не делать (или делать по-другому) некоторую часть деятельности, которая несет или содержит высокую вероятность риска. Например, проект может отказаться от работы в географическом районе, потому что он небезопасный. • Перенос риска: сместить (или разделить) риск некоторых аспектов проекта к другой стороне. Наиболее распространенным примером переноса риска является страхование. Например, страховой полис передает риск повреждения транспортного средства и потерь в страховую компанию. • Снижение риска/смягчение последствий: действовать так, чтобы уменьшить вероятность и/или воздействие потенциального риска. Возьмем, например, проект, который имеет озабоченность по поводу риска кражи товаров: Вероятность потенциальной кражи может быть уменьшена за счет увеличения систем безопасности строительства (охранники, новые двери, решетки на окнах). Воздействие потенциальной кражи может быть уменьшено за счет введения политики, по которой только товары, необходимые в течение следующих семи дней, хранятся в хранилище. • Принятие риска: если вероятность и последствия риска воспринимаются и оцениваются как разумные, организация может решить не принимать меры. Например, проект может признать, что он сталкивается с возможностью позднего наступления дождливого сезона, что прервет сельскохозяйственный цикл, но команда решает принять риск и ничего не предпринимать в целях передачи или смягчения риска. Guide to the PMD Pro стр. 94 из 12 Заметим, что "игнорирование" не является приемлемой стратегией реагирования на риск. Риск не должен оставаться непризнанным, неуправляемым, и не должен игнорироваться. Даже в ситуациях, когда риск принят, он не игнорируется. В этих случаях решение о принятии риска принимается на основе рационального процесса идентификации рисков, оценки и ответных мер, результатом чего становится решение о принятии риска. В такой момент команде проекта необходимо разработать план действий по ответным мерам, которые она выбрала. Руководители управления рисками должны выполнить следующие задачи: • Разработать организованный и комплексный план управления рисками; • Определить методы, которые будут использоваться для реализации ответных мер по риску; • Составить план выделения адекватных ресурсов для реагирования на риск. Каждый план по рискам должен быть задокументирован, но уровень детализации будет варьироваться в зависимости от проекта. Большие проекты или проекты с высоким уровнем неопределенности выигрывают от подробных и формальных планов по управлению рисками, которые отражают все аспекты идентификации рисков, оценки рисков и реагирования на риск. Маленькие проекты, или проекты, которые содержат минимальную неопределенность, могут потребовать перечня признаков опасности, который должен обновляться на критических этапах всего развития проекта. Такой список создается на самых ранних этапах разработки проекта и поддерживается в качестве контрольного перечня в течение всего срока реализации проекта. Перечисляя моменты, которые могут потенциально повлиять на стоимость проекта, график, объем и качество (или другие факторы, которые заинтересованные стороны определили, как приоритетные), а также имея текущий перечень рисков, проектная команда имеет лучшую перспективу для определения непредвиденных обстоятельств и надлежащего управления рисками. Для более сложных проектов и проектов с большим количеством неопределенностей ведется документ под названием «Реестр рисков», который обеспечивает более формальное и более детальное описание рисков и план по их устранению. Как и перечень тревожных признаков, реестр дает руководителям проектов список существенных рисков. Однако реестр рисков также содержит информацию об уровне вероятности возникновения и последствий риска. Он может также включать предлагаемые ответные меры для смягчения, ответственных лиц, а также текущий статус риска. Реестр рисков может также включать информацию о последствиях этих рисков для стоимости и графика проекта. Формат реестра рисков может варьироваться в зависимости от организации или проекта. Пример такого формата приведен ниже в Иллюстрации 52. Иллюстрация 52. Реестр рисков. Категория риска Стратегия Название риска Партнер не имеет способносте й Природная Дожди задерживаю т мероприяти я Ситуация с безопасност ью угрожает результатам Политическ ая Guide to the PMD Pro Статус Действующ ий – риск находится под активным контролем Устранен – проблема с риском решена Риск устранен Вероятн ость 3/5 Влияние 4/5 Балл риска 7 2/5 3/5 5 2/5 5/5 7 Ответная мера Смягчить: заложить деньги в бюджет на обучение бухучету Избежать: отсрочить мероприяти я до сухого сезона Передать: нанять транспортн иков для поглощения Ответственн ое лицо Марианн Когда Руководитель проекта 1 кв Транспортная компания 2 кв 1 кв стр. 95 из 12 риска утери Др. 3.4.4. Мониторинг и контроль риска. Последний шаг в процессе управления рисками - непрерывный контроль рисков для выявления любых изменений в статусе или их превращения в проблемы. Лучше всего проводить регулярные обзоры риска для определения текущих действий, вероятности риска и последствий, удаления рисков, которые больше не существуют, и идентификации новых рисков. Рекомендуется создать реестр рисков как можно раньше, в самом начале жизненного цикла проекта. Если он не создан на этапе начала проекта, тогда его нужно создать в тот же момент, когда создается система внутреннего контроля. Затем реестр рисков следует поддерживать в течение оставшейся части проекта, потому что риски являются динамичными. Перечень рисков и связанные с ними стратегии управления, скорее всего, изменятся, так как проект развивается, и новые риски появляются, или ожидаемые риски исчезают. Регулярные обзоры рисков проекта могут быть предметом обсуждения на всех заседаниях управления проектами. Если возникают непредвиденные риски, или влияние рисков является большим, чем ожидалось, запланированные меры реагирования могут оказаться неадекватными. В такой момент команда проекта должна запланировать дополнительные меры контроля над риском. 3.5.Дисциплина 5. Управление обоснованием проекта. Проекты осуществляются по целому ряду причин, но, в конце концов, инвестиции делаются по причине потенциальной ценности, которую проект имеет для заинтересованных сторон. Например: − донорская организация должна быть уверена, что инвестиции в этот вид деятельности будут стоящими инвестициями; − сообщество, где проект будет работать, должно понимать, что его участие может привести к конкретной общественно-экономической пользе; − руководство организации развития должно быть уверено, что успех проекта внесет вклад в цели крупной программы. Умелое управление обоснованием проекта помогает продемонстрировать, почему проект имеет значительный смысл для организации, доноров и получателей помощи. Успешные менеджеры проектов должны иметь опыт и навыки, чтобы: − сформулировать обоснование своих проектов; − суметь передать обоснование для более широкой аудитории; − отслеживать ход проекта в достижении того значения, которое оправдывает его существование. 3.5.1. Определение потребностей по проблемам или активам. В других секторах, которые полагаются на культуру проектов (информационные технологии, телекоммуникации, и т.д.), обоснование проекта чаще всего связано с окупаемостью инвестиций и бизнес преимуществами. Наиболее часто задаваемые спонсорами вопросы вращаются вокруг финансового обоснования проекта: сколько времени займет у компании, чтобы окупить инвестиции в проект? И все же, в то время как рентабельность предлагает огромные рычаги и преимущества в формулировании обоснования проекта, это лишь один из нескольких инструментов, которые могут быть использованы для поддержки решений инвестиционного проекта. В контексте отрасли развития обоснование проекта обычно начинается с анализа потребностей. Кроме того, когда проектная команда начинает собирать данные для предварительной разработки проекта, она должна решить, на чем будет основано определение потребности в проекте: на основании проблем или на основании активов. Если потребности определяются по проблемам, первым вопросом к сообществу будет, какие у них имеются проблемы. Этот вопрос предназначен для выявления пробелов/недостатков, которые могут быть решены. Проблема с таким традиционным подходом в том, что если вы ищите проблемы, вы, Guide to the PMD Pro стр. 96 из 12 несомненно, найдете их, и порой это могут быть проблемы, которые иначе не были бы названы, если бы вы не задали такой вопрос. Определение потребностей на основании активов является более позитивным и подчеркивает возможности, а не проблемы. Здесь первые вопросы ищут возможности и имеющиеся ресурсы. Например: что работает хорошо, какими сферами деятельности и успеха сообщество хочет поделиться с другими. Определяя активы и ресурсы, существующие в обществе, центром внимания определения потребностей становится не то, что нужно исправлять, а то, что хорошо работает, и может быть повторено или растиражировано. Иллюстрация 53. Сравнение подходов в определении потребностей. Подход на основе проблем Определение проблемы. Отладить то, что не работает. Сконцентрировать внимание на отрицательных сторонах. Подход на основе активов Искать решения и активы, которые уже существуют. Подкрепить то, что работает. Сконцентрировать внимание на положительных сторонах. 3.5.2. Переход от проблем к стратегии внедрения. Большая часть работы в управлении обоснованием происходит во время первой фазы проекта – на стадии определения и разработки проекта. Если в этот момент команда проекта хочет применить подход определения потребностей, ориентированный на проблемы, следующим шагом в процессе обоснования будет разработка дерева проблем. Дерево проблем, или древовидная схема, представляет собой упрощенную, но надежную версию реальности, определяя не только основные проблемы, но и последствия основных проблем, и их причины, которые определяют текущее состояние. При разработке дерева проблем важно начать процесс с определения «стартовой» проблемы, которая может быть определена либо через открытое коллективное обсуждение с заинтересованными сторонами, либо на основе предварительного анализа имеющейся информации. Когда стартовая проблема определена, осуществляется процесс разработки дерева последующих проблем (предпочтительно через процесс совместного участия): Ø проблемы, которые непосредственно вызывают стартовую проблему, помещаются ниже (причины); Ø проблемы, которые являются прямыми последствиями стартовой проблемы, ставятся выше (последствия). Главный вопрос логики дерева проблем: что является причиной этого? Если есть две или более причин, которые в сочетании вызывают последствия, они находятся на том же уровне в диаграмме. Причинно-следственные стрелки используются для соединения уровней дерева проблем. На рисунке ниже показано древовидная схема, которая была создана для проекта «Дельта реки», рассматривая причины и последствия ухудшения качества воды в реке в этой области. Обратите внимание, что эта диаграмма есть упрощенное представление о ситуации, и это не редкость для древовидной схемы, когда имеется несколько уровней причин и следствий вокруг ключевой проблемы. В результате древовидная схема часто становится чрезвычайно сложной. Guide to the PMD Pro стр. 97 из 12 Ловля и доходы рыбачьих семей снижаются Частые случаи заболеваний от плохой воды, особенно среди бедных семей и детей до 5 лет Речная экосистема под серьезной угрозой, включая снижение кол-ва рыбы Качество речной Иллюстрация 54. воды Древовидная схема проекта «Дельта реки» ухудшается Уровень фекальных отходов в реке высокий Большинство семей выбрасывают фекальные отходы в реку 70% семей не имеют туалетов или подключения к канализации Уровень бытовых и промышленных отходов в реке высокий Население не знает об опасности свалки отходов Население не знает об опасности сброса фекалий в реку Нет общественной информации и образовательных программ Сточные вода, обрабатываемые на заводе, не отвечают экологическим стандартам Высокий % промышленных отходов сваливается прямо в реку Экологический контроль не эффективный и тесно связан с интересами бизнеса Неадекватный уровень капитальных инвестиций и плохое планирование в местном правительстве Когда создано дерево проблем, следующий шаг – создать дерево (древовидную схему) целей, которое определяет потенциальные области внедрения для возможного решения определенных проблем. В самой простой форме дерево целей – это зеркальное отражение дерева проблем, где каждая формулировка проблемы трансформирована в положительную формулировку цели. Дерево проблем отражает причинно-следственную связь, а дерево целей отражает средства для достижения цели. Если взять пример с ухудшением качества воды, дерево проблем должно преобразоваться в дерево целей, которое будет выглядеть так: Guide to the PMD Pro стр. 98 из 12 Ловля и доходы рыбачьих семей стабильные и растущие Угроза экосистеме реки снижена, и кол-во рыбы растет Иллюстрация Число заболеваний от плохой воды, особенно среди бедных семей и детей до 5 лет снижено 55. Дерево целей для проекта «Дельта реки» Качество речной воды улучшено Кол-во твердых отходов, сбрасываемых в реку, снижено Загрязняющие вещества под контролем Агентство по защите окружающей среды более ответственно и эффективно защищает интересы широкого круга заинтересованных лиц Население знает об опасности сброса фекалий в реку Есть общественная информация и образовательные программы Кол-во домов и фабрик, сбрасывающих отработанную воду в реку, уменьшено Введено новое постановление, которое запрещает прямой сброс сточных вод в реку Контроль над загрязнениями имеет политический приоритет Сточные воды, обрабатываемые на заводе, отвечают экологическим стандартам Увеличение % семей и бизнесов, подключенных к канализации Возросшие капитальные инвестиции Улучшено бизнес планирование в правительстве, включая механизмы возвратности затрат Когда определены потребности (через анализ проблем или через анализ активов), следует проанализировать потребности и первоначально определить, есть ли адекватное обоснование для проектного внедрения. В это время организация развития должна рассмотреть два важных стратегических вопроса: • Какие элементы дерева целей будут включены в проектное внедрение? • Какие элементы не будут включены в содержание проекта? Согласие по этим вопросам может быть труднодостижимым, а принятие решения может быть сложным и спорным. Но надо помнить об опыте из Раздела 2 «Руководства». На этапе определения и разработки проекта определяется ряд критериев (Иллюстрация 16), которые можно использовать для принятия решения в отношении объема и содержания проекта. Эти критерии помогут сотрудникам проекта и иным участникам принять конкретные решения: где проект будет внедряться, какие услуги будет предоставлять, кого обслуживать, как услуги будут предоставляться. Возвращаясь к проекту «Дельта реки», критерии по выбору сферы деятельности включали наличие ресурсов, потенциал исполняющей организации, приоритеты местного правительства, и потребности домашних хозяйств. На основе этих критериев сотрудники проекта разработали альтернативное дерево, которое отражает последствия, задачи и цели (розовые квадраты на рисунке ниже), которые организация собирается выполнить. Важно заметить, что альтернативное дерево показывает, какие элементы не буду входить в содержание проекта (голубые квадраты). Guide to the PMD Pro стр. 99 из 12 Ловля и доходы рыбачьих семей стабильные и растущие Снижено число заболеваний от плохой воды, особенно среди бедных семей и детей до 5 лет Угроза экосистеме снижена и увеличено кол-во рыбы Иллюстрация 56. Альтернативное дерево проекта «Дельта реки». Качество речной воды улучшено Уровень фекальных отходов в реке снижен Увеличено число семей с доступом к средствам и устройствам гигиены Внедрена программа строительства туалетов Уровень сброса бытовых и промышленных отходов в реку снижен Население знает об опасности свалки отходов Есть общественная информация и образователь ные программы Есть общественная информации и образовательные программы Сточные вода, обрабатываемые на заводе, отвечают экологическим стандартам Снижен % промышленных отходов, сваливаемых в реку Агентство Экологического контроля эффективно и отвечает интересам широкого круга заинтересованны х сторон Улучшено бизнес и увеличены капитальные инвестиции со стороны местного правительства 3.6.Дисциплина 6. Управление заинтересованными сторонами. Проекты развития – сложные проекты, которые влияют на целый ряд заинтересованных сторон: отдельные лица, группы, организации, которые вовлечены в проект, или чьи интересы будут положительно или отрицательно затронуты в результате исполнения и завершения проекта. Опыт показывает, что когда заинтересованных сторон не учитывают или неправильно понимают при разработке проекта, или они мало вовлечены, или вовсе исключены из планирования и реализации, это может привести к неожиданным и нежелательным последствиям. Те же проекты, которые затратят время на определение заинтересованных сторон, и на то, чтобы понять их, в результате получают преимущество: − От четкого понимания отдельных лиц, групп и учреждений, на которых рассчитана проектная деятельность; − От лучшего понимания потенциала заинтересованных лиц; − От лучшего понимания того, кто может повлиять и внести вклад в планирование и выполнение проекта; Guide to the PMD Pro стр. 100 из 12 − От лучшего понимания перспективы с альтернативными разработками внедрения проекта и решения проектных конфликтов. Чтобы быть успешным, проект должен иметь дисциплину по управлению отношениями с заинтересованными сторонами. Сотрудники должны понимать реальность и сложность интересов и взаимоотношений, разрабатывать и предсказывать воздействие проекта (положительного и отрицательного) на все группы заинтересованных лиц, и разрабатывать и осуществлять планы, которые поощряют совместное участие и хороший обмен информацией. Компоненты хорошей системы управления заинтересованными сторонами: • Идентификация заинтересованных сторон. • Анализ заинтересованных сторон. • Вовлечение заинтересованных сторон. • Обмен информацией с заинтересованными сторонами. 3.6.1. Идентификация заинтересованных сторон. На стадии определения и разработки проекта обычно уже понятно, что у проекта будет много заинтересованных сторон. Поэтому на этом этапе нужно определиться с заинтересованными лицами. «PMD Pro» признает 6 категорий заинтересованных лиц, которые могут быть отправной точкой для их определения. Пользователи – это люди, которые получают непосредственную общественно-экономическую пользу от продуктов и услуг проекта. Например, в проекте по управлению водоразделом, пользователями, несомненно, являются жители сообщества, которые получают пользу от улучшения состояния почвы, и улучшения доступа жителей к качественной воде. Управляющие лица – люди или группы людей, которые имеют интерес к тому, как деятельность проекта управляется. Например, эта категория может включать: − правление проекта, наблюдательные группы или спонсоров, которые руководят сферой деятельности проекта; − аудиторов и регуляторов, которые устанавливают требования по соответствию и регулятивному контексту проекта; − финансирующих лиц (физических или юридических), которые предоставляют финансирование проекту, и которые могут быть как внешними (доноры), так и внутренними (когда проект финансируется внутренними средствами). Поставщики услуг (провайдеры) - это лица, которые активно участвуют в работе проекта. В эту категорию входят менеджеры, сотрудники, исполняющие организации, контрактники и поставщики. Влиятельные лица – это люди, которые имеют возможность изменить направление (положительно или отрицательно) проекта. Это средства массовой информации, государственные чиновники, бизнес интересы и главы сообществ. Зависимые стороны – это те, кто хочет от проекта иных, дополнительных продуктов или услуг. Обычно, зависимыми сторонами называют другие проекты или функциональные единицы организации, которым нужен один из результатов проекта. В примере с проектом по водоразделу небольшой проект по жилищному строительству может ждать завершения зонирования водораздела, чтобы начать строительную деятельность. Лица, поддерживающие жизнеспособность - это группы лиц, ответственные за поддержание продукта после завершения проекта. В примере с водоразделом министерство общественных работ и Guide to the PMD Pro стр. 101 из 12 министерство сельского хозяйства буду лицами, которые возьмут на себя ответственность за управление водоразделом после завершения проекта. Некоторые соображения, которые нужно учитывать при классификации заинтересованных сторон по категориям: - Категории пользователей могут смешиваться или совпадать: есть много случаев, когда отдельные лица или группы смогут попасть в несколько категорий. Например, сообщества могут быть пользователями и лицами, поддерживающими жизнеспособность. - Разбивка категорий: категории могут подразделяться на подкатегории, если нужно. Например, категория управляющих лиц уже разбита на три подкатегории. Точно также категории пользователей можно подразделить на подгруппы. - Заинтересованные лица проекта могут со временем поменяться: новые лица могут появиться, а прежние могут потерять свое влияние или интерес. Поэтому процесс идентификации заинтересованных лиц постоянный и должен пересматриваться в определенные промежутки времени в течение всего срока действия проекта. 3.6.2. Анализ заинтересованных сторон. После того, как заинтересованные лица определены, наступает время анализа, который состоит из следующих действий: • Исследование интересов заинтересованных сторон: что они могут приобрести или потерять в результате проекта; каковы их ожидания - положительные и негативные; какие ресурсы они могут предоставить; каковы их роли и обязанности; какой у них есть потенциал; будут они поддерживать проект или блокировать его. • Определение влияния заинтересованных сторон: влияние относится к власти, которую заинтересованные стороны имеют над проектом, например, в принятии решений, влиянии на проектную деятельность в положительном или негативном смысле, какова степень конфликтности или сотрудничества между ними, кто имеет власть вносить изменения в случае проблем и их причин. Существует множество инструментов для проведения такого анализа. обсуждает два конкретных инструмента: • Диаграмму Венна; и • Матрицу анализа заинтересованных сторон. Данный документ Диаграмма Венна создается для анализа и иллюстрации характера отношений между ключевыми сторонами. Она разрабатывается через перспективу одной заинтересованной стороны проекта или группы заинтересованных сторон. Каждый круг в диаграмме определяет такую сторону или группу, вовлеченную в проект. Размер круга может помочь определить относительную власть и влияние каждой такой стороны, а пространственное разделение используется для определения относительной силы или слабости рабочих отношений или взаимодействия между разными группами или организациями. Диаграмма Венна обычно применяется для совместного планирования с целевыми группами для обозначения концепции их взаимоотношений. Изображение ниже – это пример диаграммы Венна для определения полномочий и влияния множественных заинтересованных лиц, вовлеченных в управление рыбным промыслом в сообществе, проживающем у реки. Обратите внимание, что диаграмма отображает перспективу через одну группу заинтересованных лиц, в данном случае - рыбоводческие хозяйства. Размер и местоположение круга, обозначающего «Промысел Х», показывает, что он важен, но очень отдален. По той же логике «Агентство по защите окружающей среды» является отдаленным и явно связано с интересами отрасли. «Рыболовецкие кооперативы» представляют интересы рыбаков и имеют тесные отношения с розничными торговцами. Маленький размер круга, представляющий «Департамент рыболовства», указывает, что он имеет мало влияния. Иллюстрация 57. Диаграмма Венна по заинтересованным сторонам проекта «Дельта реки» Guide to the PMD Pro стр. 102 из 12 Матрица анализа заинтересованных лиц использует информацию диаграммы Венна (или иные инструменты анализа влияния заинтересованных сторон) для дальнейшей идентификации, развития и обобщения интересов, потенциала и возможных действий заинтересованных сторон. В отличие от диаграммы Венна матрица позволяет дать описание, которое является дополнительной информацией о заинтересованных сторонах, их интересах, влиянии и потенциальных действиях в ответ на интересы таких участников. Таблица ниже – матрица управления рыболовецким проектом, который отражен в диаграмме Венна выше. Матрица помогает определить пути вовлечения заинтересованных сторон, чтобы их внедрение имело смысл на всех стадиях деятельности проекта. Например, таблица показывает потенциальные риски для успеха проекта, которые исходят от плохо управляемой текстильной промышленности. Признавая эту потенциальную угрозу, сотрудники проекта могут предпринять шаги для обеспечения успеха, например, организовать встречи с руководителями текстильной промышленности для переговоров о решениях проблемы, или определить иные пути вовлечения их в проект. Иллюстрация 58. Матрица анализа заинтересованных сторон. Заинтересованная сторона и базовые характеристики Интересы и влияние проблем на них Потенциал и мотивация изменить существующее положение Рыболовецкие семьи: 20000 семей, низкие доходы, малый бизнес, организованы в неформальный кооператив. Женщины активно вовлечены в переработку рыбы. Текстильная отрасль: Сохранить и улучшить средства к существованию. Загрязнение влияет на объемы и качество ловли. Здоровье семей страдает, особенно женщин и детей. Острый интерес к контролю над загрязнениями. Ограниченное политическое влияние изза слабой организационной структуры. Сохранить и увеличить Имеются финансовые и Guide to the PMD Pro Возможные действия в отношении интересов заинтересованных сторон Подержать потенциал для организации и лоббирования. Определить и разработать альтернативные источники доходов. Повысить стр. 103 из 12 Средний бизнес, плохо регулируемый, нет никаких объединений. Хорошо связан с руководящей партией. Плохие данные о влиянии на окружающую среду. прибыли. Некоторая обеспокоенность об общественном мнении. Проблемы со стоимостью исполнения нормативов по окружающей среде. технические ресурсы для применения новых более чистых технологий. Ограниченная текущая мотивация для осуществления изменений. Домашние хозяйства: 45000 домашних хозяйств сбрасывают отходы и сточные воды в реку, которая используется как источник питьевой воды и рыболовства. Осведомленность о загрязнении среды от текстильной промышленности и влиянии на качество воды. Желание утилизировать отходы отдельно от домашних хозяйств. Желание получить доступ к чистой воде. Недостаточное понимание влияния отходов и сточных вод на здоровье. Появление желания платить за услуги по управлению отходами. осведомленность о социальном воздействии и последствиях для окружающей среды. Мобилизовать политическое давление для влияния на поведение отрасли. Усилить и исполнить законодательство по экологии. Повысить просвещенность жителей о последствиях их практики распоряжения отходами. Работать с сообществами и правительством по вопросам водоснабжения и санитарии. Агентство по защите окружающей среды, и т.п. 3.6.3. Вовлечение заинтересованных сторон. Руководитель проекта редко работает один. Даже самые мелкие проекты зависят от целого ряда заинтересованных сторон. По мере роста сложности проектов сеть отношений расширяется и может потенциально включать группы сообществ, государственные министерства, поставщиков, местные НПО, университеты, религиозные организации и др. Одной из задач в управлении различными сторонами является обеспечение ясного понимания ролей, обязанностей, полномочий и отношений между различными участниками. Одним из инструментов, с помощью которого это можно делать, является схема из четырех компонентов - в английской аббревиатуре – RACI22 Ответственный означает любого, кто делает работу для выполнения поставленных целей. Для каждой цели и задачи обычно имеется одно ответственное лицо, а другим лицам может быть делегировано задание по оказанию помощи. Подотчетный - принимает (подписывает) или одобряет работу, которую выполняет ответственное лицо. Должно быть только одно подотчетное лицо по каждому заданию или результату. Консультирующий – тот, у кого спрашивают мнения или заключения, и с которым поддерживают двухстороннюю связь. Информированный – тот, кому сообщают о прогрессе, часто только по завершению работ или по результату, и с кем поддерживают одностороннюю связь. Следующая схема дает пример упрощенной матрицы RACI для проекта «Дельта реки». 22 От английских слов Responsible – Ответственный; Accountable – Подотчетный; Consulted – Консультирующий; Informed - Информированный. Прим. переводчика Guide to the PMD Pro стр. 104 из 12 Иллюстрация 59. Матрица RACI «Дельта реки» Тип участия Проектное задание Написание концепции Разработка Оценка Анализ Логическая основа План мониторинга и анализа Написание предложения и подача Ответственные лица Кто следит за тем, чтобы работа была сделана? Выполнение работы связано с задачей? Возглавляет руководитель проекта. Помогает исполняющая организация. Возглавляет руководитель проекта. Помогает исполняющая НПО. Подотчетные лица Консультанты Кто подписывается под результатом, связанным с задачей? У кого нужно спросить мнения: Руководитель проекта Консультант по санитарии Официальные лица Министерства Здравоохранения Исполняющая НПО. Консультант Руководитель проекта. Местные работники. Участники проекта. Официальные лица Министерства Здравоохранения. Донор. Официальные лица Министерства Здравоохранения (правительственного уровня). Возглавляет руководитель проекта. Помогает исполняющая НПО. Исполняющая НПО. Консультант по СПИДу. Руководитель проекта. Группа ГО. Исполняющая НПО. Руководитель проекта. Местные работники Официальные лица Министерства Здравоохранения. Донор. Участники проекта Участники проекта Местные официальные лица Министерства Здравоохранения. Консультант по санитарии. Донор Официальные лица Министерства Здравоохранения (правительственного уровня). Исполняющая НПО. Участники проекта. Руководитель проекта. Ответственное за программу лицо. Донор. Участники проекта. Ответственное за программу лицо. Региональный технический консультант. Официальные лица Министерства Здравоохранения (правительственного уровня). Детальное планирование программы Возглавляет руководитель проекта. Помогает исполняющая НПО. Исполнение Возглавляет руководитель проекта. Помогает исполняющая НПО. Возглавляет руководитель проекта. Донор Мониторинг и оценка Кого следует информировать Кого нужно держать в курсе через копии отчетов, эл. почту и т.п. Матрица RACI должна быть распространена всем сотрудникам проекта и заинтересованным сторонам, чтобы у всех было одинаковое понимание ожиданий, ролей и обязанностей, связанных с проектом. 3.6.4. Обмен информацией с заинтересованными сторонами. Когда распределены роли и обязанности, наступает время управления сообщениями и обменом информацией между группами, участвующими в проекте. Это тоже наука и искусство. С одной стороны искусство успешного общения зависит от межличностных навыков руководителя проекта. А наука Guide to the PMD Pro стр. 105 из 12 общения связана с умением планировать и исполнять. Частью этой науки является тщательное определение стратегии общения относительно масштаба и сложности проекта. Например, в контексте маленького проекта слишком официальные отношения становятся административным бременем, которые мешают прочей деятельности проекта. В контексте большого проекта неформальные или случайные сообщения могут быстро превратить успех в катастрофу, если будут упущены важные вопросы и возможности из-за плохого планирования и осуществления обмена информации. В результате, нужна ясность в передаче сообщений и обмене информацией: что, зачем, кто, как, когда. Такая информация может быть организована в следующем формате. Иллюстрация 60. План передачи сообщений и обмена информацией. Сообщение Цель Кому Автор Назначено кому Средство передачи сообщения Частота сообщений При определении средств передачи сообщений надо ориентироваться на соответствие сообщениям проекта и на заинтересованные лица. Для определения механизма ниже даны некоторые вопросы, которые могут помочь определиться: • Какой механизм или инструмент повышает вероятность, что сообщение будет фактически получено, понято и будет исполняться? • Сколько информации следует включить в сообщение, и с какой степенью детализации? • Какой механизм лучше всего для данного типа сообщения? • Какой механизм предпочитает заинтересованная сторона? • Какой уровень взаимосвязи требуется (односторонний, двусторонний)? Далее, важно делать различие между регулярными сообщениями и постоянным обменом информацией с сотрудниками проекта, спонсорами и иными сторонами. Выбранный метод включает статус отчетов, запланированные собрания, расписание учебных сессий, иные графики. Guide to the PMD Pro стр. 106 из 12 Раздел 4. Адаптация “PMD Pro” Как заставить «PMD Pro» работать на вас? Инструменты, методы и методологии ничего не достигают, если сотрудникам проекта не удается применить их в среде своего проекта. Данный раздел описывает, как адаптировать различные инструменты и методы, чтобы сделать их полезными для руководителя и сотрудников проекта. 4.1.Основы адаптации Как уже говорилось, в управлении проектами нет единой дороги. Каждый проект уникален и имеет собственные цели. Простое применение инструментов и методов без учета контекста, ресурсов, отношений и проблем в лучшем случае будет способствовать «роботизированному» или «шаблонному» проекту. В дополнение к созданию массы ненужной работы, применение инструментов и методов без обоснования, скорее всего, запутает и деморализует проект и исполняющих партнеров. Пример: два руководителя прошли обучение «PMD Pro», получили знания и понимание методологии. Их организации, к сожалению, не оценили и ничего не поняли об управлении проектами. Когда они вернулись на рабочие места, одному из них сказали: «Инструменты «PMD Pro» хорошие, но мы здесь не так работаем». Другому руководителю было сказано: «Решайте, какие инструменты и методы вам нужны, и применяйте их, как вам нужно». Оба примера описывают варианты, которых следует избегать. Внедрение «PMD Pro» должно включать оценку имеющихся инструментов и методов, решение, что является наиболее полезным в конкретной ситуации, обдумывание, как эти инструменты могут быть интегрированы в организационные процессы и системы. Например, фотография внизу показывает результат простого картографирования того, как сотрудники проекта обсуждали вопросы после прохождения курса «PMD Pro», пытаясь адаптировать новые механизмы управления проектами к существующим инструментам. Везде, где возможно, руководитель проекта должен обсуждать со своей организацией следующие вопросы: − Новый инструмент заменяет существующий инструмент или будет дополнять его? − Как информация нового инструмента подходит к существующим процессам? − Надо нам вносить изменения в существующие процессы в результате внедрения нового инструмента или метода? С практической точки зрения руководитель должен рассмотреть инструменты и методы и задать вопрос: можно применить эти средства сейчас или требуется большая поддержка организации? Иллюстрация 59 показывает пример плана адаптации инструментов. Он заполнен примерными данными, которые определяют статус и указывают, потребуются ли изменения для успешного внедрения новых инструментов. Guide to the PMD Pro стр. 107 из 12 Иллюстрация 61. Пример применения инструментов управления проектами. Инструмент Могу я выполнять работу сейчас? Да Нужна мне поддержка? Какие организационные изменения надо внести прежде, чем мы сможем надлежащим образом применить и использовать данный инструмент? Нет Сетевые диаграммы Схема проекта Да Нет Да Диаграмма RACI Да Нет Контроль изменений Да Да Надо, чтобы сотрудники и партнеры внесли конкретный опыт и детали. Надо, чтобы сотрудники понимали цель и процессы. Стимулировать организацию на согласие на утвержденный формат. Следует использовать для отражения вклада и обмена информацией с заинтересованными сторонами. Должен быть интегрирован и связан с системой руководства проектом. Разбивка работ 4.2.Факторы для рассмотрения при применении «PMD PRO». Проекты не существуют в вакууме. Проекты живут в программах и портфелях. Проекты управляются в контексте организационных систем и донорских структур. То есть существует более широкая операционная среда проектов. В результате, поскольку все эти факторы влияют на исполнение проектов, их надо учитывать при применении «PMD Pro» к проектам. Программные соображения: программы состоят из групп связанных проектов, которые управляются координированным образом для получения общественно-экономической пользы и контроля, которые невозможно осуществить по раздельности. Временные рамки программы гораздо продолжительнее, а последствия обычно гораздо сложнее с учетом каждого отдельного проекта, разработанного для внесения вклада в цели. В хорошо управляемой программе существует взаимодействие инструментов, методов и подходов. Некоторые НПО имеют Отдел или Офис Управления Программой, роль которого заключается в обеспечении последовательности подходов, стандартов, в формировании потенциала, в предоставлении наборов инструментов и операционных инструкций. В таких ситуациях руководители проектов и их коллективы должны действовать в соответствии с инструкциями, инструментами и подходами программного отдела. Что касается связи между программами и проектами, НПО в международном секторе развития имеют тенденции разрабатывать крупные комплексные проекты, тогда как, возможно, лучше разработать программу с несколькими маленькими и простыми проектами. Системные соображения: руководитель проекта редко имеет возможность влиять на выбор организационных систем. Несмотря на это, руководитель должен обеспечить, чтобы потоки информации из организации и в организацию отвечали потребностям сотрудников проекта. Два примера ниже показывают, как руководитель проекта должен изучать и понимать системы организации, чтобы они работали на пользу проекта. Отчеты по бюджету и финансированию: бюджеты в предложениях донору обычно представлены по видам деятельности. В реальности многие НПО не имеют финансовых систем, которые могут производить финансовые отчеты по видам деятельности, а производят только отчеты по статьям бюджета и по кодам счетов. Поэтому в таких случаях руководитель проекта должен обеспечить, чтобы была запланирована и своевременно выполнена работа по преобразованию одного формата финансовой информации в другой формат. Валюта бюджета и обменные курсы: часто бывает, что руководителю проекта сообщают, что проект несет убытки в размере $20000 по обменным операциям, поэтому ему придется сократить мероприятия для компенсации убытков. Для снижения такого воздействия может применяться стратегия хеджирования, но колебания обменного курса невозможно устранить. Поэтому руководитель проекта может применить соответствующий подход для снижения недостачи. В связи с тем, что задача по выбору валюты проекта часто лежит на персонале финансового отдела, сотрудники часто выбирают валюту контракта. Если расходы в иной валюте, это немедленно Guide to the PMD Pro стр. 108 из 12 усложняет жизнь сотрудников проекта, т.к. бюджет проекта в одной валюте, а расходы в другой. Хотя это и не всегда возможно, но руководитель проекта должен настаивать, чтобы бюджет и расходы были в одной валюте. Даже если выбор валюты не подлежит переговорам, руководитель проекта может настоять на применении фактического обменного курса в течение срока действия проекта вместо того, чтобы применять легко рассчитываемый балансовый курс. Такая стратегия не смягчает валютные колебания, но помогает сократить разницу валютных курсов. Соображения о размере, сложности и рисках: здравый смысл диктует, что маленький, понятный проект не требует тех же соображений, что и проект в миллион долларов, исполняемый в различных местоположениях, с множественным коллективом в трудной, небезопасной среде с разнообразными заинтересованными сторонами. Факторы, связанные с размером, сложностью и рисками, часто упускаются из соображений руководителей проектов и их организаций в секторе международного развития. Два важных фактора рассматриваются ниже в качестве примера. Планирование и управление рисками: журнал учета рисков (реестр) всегда полезен. В небольших, недорогих проектах простой реестр качества рисков может быть достаточен. В проектах с высоким профилем риска может понадобиться реестр количественного риска. Проектные нормы по использованию и модифицированию реестра рисков могут быть различными. Кто может их менять? Кто может предлагать изменения? Когда изучают реестр рисков? Руководителю проекта надо думать, как лучше использовать инструменты и обеспечить, чтобы они были в помощь сотрудникам проекта. Руководство проектом: ключевая область, требующая внимания в более сложных проектах – руководство. Более мелкие проекты разделяют структуру руководства с целым рядом подобных малых проектов под управлением правления, или регионального совета, или подобной структуры. Многомиллионный проект с большим составом работников и обширным местоположением требует собственного правления, включая старшего потребителя (пользователя), старшего поставщика и исполнителей проекта, представляющих голоса заинтересованных сторон и их взгляды. Совет или правление проекта должен иметь четко описанный круг полномочий и операционные нормы. Члены совета должны понимать свои роли и обязанности. Также, может понадобиться изменить профиль такого правления для более длительного проекта в целях правильного отражения взглядов, которые в нем представлены. Рассмотрение знаний и компетенций: предполагается, что руководитель проекта отвечает за то, чтобы сотрудники и исполняющие партнеры обладали нужным опытом, включая знания, отношения и навыки, однако руководитель не должен ожидать, что он сформирует потенциал, позволяющий немедленно устранить все слабые места. При применении «PMD Pro» главным является оценка текущего уровня опыта сотрудников и исполняющих партнеров, а затем продвижение обучения с целью роста потенциала и способностей там, где обнаружены пробелы. Инструмент под названием «паукообразная» диаграмма показывает пробелы между текущими (базовыми) и желаемыми компетентностями (целевыми) за определенный период времени. Иллюстрация 62 показывает, как такая диаграмма может быть использована, хотя есть множество иных вариантов использования такой диаграммы. Guide to the PMD Pro стр. 109 из 12 Иллюстрация 62. Диаграмма, показывающая основные и целевые компетенции по «PMD Pro» Базовые Управление сферой деятельности 12 месяцев Управление кадрами/самоуправление Управление временем Управление ресурсами Лидерство, межличностные отношения Управление заинтересованными сторонами Управление обоснованием Управление рисками Если, например, руководитель проекта пытается осуществить разбивку работ (сделать декомпозицию) не удостоверившись, что каждый отдельный сотрудник и исполняющий партнер понимает, зачем это нужно, в чем ценность такой структуры и фактически умеет применять структуру разбивки работ в реальной ситуации, реализация проекта может оказаться под угрозой срыва. В организациях, исполняющих «PMD Pro», многие потребности в знаниях и компетентности, скорее всего, уже рассмотрены и учтены. Однако руководителю проекта все же нужно убедиться, все сотрудники и партнеры правильно используют каждый избранный инструмент на практике. Обнаруженные в работе пробелы надо устранять обучением и иными управленческими действиями. Соображения по исполнению: Руководитель проекта не только отвечает за то, чтобы сотрудники проекта все время наращивали компетентность, но что важнее, чтобы ежедневная работа вносила вклад в целевое влияние. Надо помнить, что изменения, над которыми работают организации международного развития, обычно нацелены на изменение качества жизни, благосостояния, устойчивости, снижение бедности, возрастание гражданского сознания и улучшения окружающей среды. Руководство «PMD Pro» не должно рассматриваться как разовое явление, а как начало динамического процесса, который преобразует познание в улучшенную работу, но что главнее, вносит вклад в постоянное улучшение. Guide to the PMD Pro стр. 110 из 12 Связывая «PMD Pro» с результатами проекта и требуя, чтобы сотрудники несли ответственность за превращение знаний в практику, менеджеры проектов увеличивают шансы увидеть изменения, которые действительно важны, и лежат в самой основе целей проекта. Один офис НПО после апробирования нескольких «PMD Pro» курсов, решил, что все участники обучения по «PMD Pro» должны разработать индивидуальный (в том числе с участием всего коллектива проекта, где возможно) план постоянного изучения и внедрения «PMD Pro». Шаблон их плана требовал деталей по предполагаемому применению знаний и инструментов управления проектами на рабочем месте в течение 12 месяцев. Назначенный человек из Отдела управления проектом должен общаться с каждым обучающимся и его/ее непосредственным начальником каждые 3 месяца для отслеживания соответствия, измерения вклада в результаты, а также для сбора/обмена передовым опытом. Этот офис НПО также предлагает учащимся виртуальный доступ (по телефону, электронной почте, социальным сетям, и т.п.) к экспертам управления проектами, которые могут консультировать их по вопросам использования «PMD Pro», применению инструментов, и по иным вопросам, которые могут возникнуть. Они также решили начать с малого поэтапного внедрения инструментов управления проектами таким образом, что позволяет практическое экспериментирование, адаптацию и контекстное изучение. Они решили, что их начальный "инструментарий" будет включать в себя 4 инструмента, которые признаны наиболее важными для первоначального улучшения. Они выбрали RACI, Реестр рисков, структуру разбивки работ, и журнал учета проблем. Заключение: применение «PMD Pro», как описано выше, действительно необходимо. Тем не менее, одно предупреждение должно быть учтено: работа менеджера проекта не должна сводиться к набору жестких правил, которые применяются бездумно в каждом проекте, программе или портфеле. Помните, как было сказано ранее в этом «Руководстве», что управление проектами в такой же степени искусство, как и наука. Будут обстоятельства, когда инструменты управления проектами или методы могут быть использованы, но по многим или веским причинам это может оказаться не лучшим выбором. Другими словами, слишком увлеченное требование обязательного и повсеместного применения инструментов и методов управления проектами во всех проектах, программах и портфелях может быть большой ошибкой. Каждый руководитель проекта должен научиться быть дисциплинированным и вдумчивым – должен стать специалистом в анализе каждого отдельного проекта, прежде чем осторожно и совместно выбрать и принять все самое лучшее из «PMD Pro». Guide to the PMD Pro стр. 111 из 12 Раздел 5. Приложения 5.1.Приложение 1. Термины и определения. Деятельность - Метод оценки на основе активов Обзор последействий Предположения - Базовая линия, линия отсчета Таксономическая классификация по Блуму Оценка снизу вверх Потенциал - Сертификат Компетентность Концепция Интенсификация Мандат (иногда рекомендательные письма) Критический путь Логическая схема выбора решения Декомпозиция работ DM & E (РМиО) Организации развития - Действия, через которые вклады ресурсов (финансовых, кадровых, технических, материальных и временных) мобилизованы для получения результатов проекта (обучения, строительства и т.п.), за которые сотрудники могут нести ответственность, и которые в совокупности производят результаты. Методология, которая стремится раскрыть и подчеркнуть сильные стороны внутри сообществ, как средство устойчивого развития. Простой, быстрый и универсальный способ познания, который может быть использован для идентификации и документирования полученного опыта и знаний, вытекающих из проекта. Гипотезы о необходимых условиях, как внутренних, так и внешних, определенных при разработке проекта, чтобы предполагаемые причинноследственные связи функционировали, как ожидается, и чтобы запланированные мероприятия дали ожидаемые результаты. Фактическая точка отсчета по условиям исполнения или работы до начала внедрения, которая необходима в качестве основы для мониторинга, оценки и контроля проекта. Классификация уровней знаний / навыков, которая обеспечивает структуру для разработки изучения23. Метод оценки, который начинается с консультации людей, которые отвечают за задачи проекта, и объединяет оценки в комплексный глобальный бюджет. Способности, навыки, понимание, отношения, ценности, связи, поведение, мотивация, ресурсы и условия, которые позволяют отдельным лицам, организациям, сетям / секторам и более широким социальным системам выполнять функции и достигать цели с течением времени. Документ, выданный лицу после успешного завершения курса обучения. Набор навыков, знаний, отношение и поведение, необходимые для эффективного выполнения конкретной работы, роли или действий в конкретной ситуации. Профессиональный обзор проекта, написанный для получения обратной связи перед тем, как выделять ресурсы для разработки обширного предложения. Добавление дополнительных ресурсов в проект в целях ускорения прогресса в плане-графике. Доказательство квалификации, компетентности или разрешений, относящихся к человеку. Последовательность действий, которая представляет самый длинный путь между началом проекта и концом проекта. Основные контрольные точки, используемые для заключения и принятия решений на конкретном этапе проекта, и переход к следующему этапу. Метод разделения или разбивки работ по проекту на более мелкие элементы, компоненты или их части. Разработка, мониторинг и оценка проекта. Организации, которые подпадают под широкую совокупность тесно 23 Древовидная структура, т.е. способ организации данных в виде иерархической структуры с одним корнем и несколькими ветвями, подобно генеалогическому дереву. Прим. переводчика Guide to the PMD Pro стр. 112 из 12 Ускорение работ Запас времени Диаграмма Ганта Цель - Инициирование Влияние Вклады Проблема Журнал учета проблем Итерация Логистика - Сетевая диаграмма Последствия - Результаты - Параметрические расчеты Портфель Guide to the PMD Pro связанных между собой действий по оказанию чрезвычайной помощи и развития через свои проекты и практику деятельности: с одной стороны такая совокупность способствует долгосрочным программам развития с совместным участием в таких областях, как окружающая среда, здравоохранение, образование и сельское хозяйство, а с другой стороны включает в себя более непосредственное осуществление проектов быстрой и временной помощи людям, которым угрожает голод, бездомность и нищета из-за внезапных стихийных бедствий или конфликтов. Ускорение сроков реализации проекта путем параллельного проведения мероприятий, которые обычно выполняются последовательно. Количество времени, на которое задача в сетевой диаграмме проекта может быть отложена, не вызывая задержки в дате завершения проекта. Гистограмма, которая графически представляет график деятельности по проекту. Желаемый конечный результат или воздействие самого высокого уровня (преобразование, устойчивость, средства к существованию, благополучие и т.п.), которому способствует проект – конечная цель многих логических структур. Процесс описания и решения начать проект и разрешения руководителю проекта расходовать ресурсы, усилия и деньги. Значительное влияние или долгосрочный результат (отождествляется с последствиями и уровнями целей во многих логических структурах). Ресурсы, которые проект должен мобилизовать и применить в деятельности по проекту (кадры, финансовые ресурсы, оборудование и т.д.) Возникший риск. Проблема может принимать форму нерешенных вопросов или ситуаций, которые значительно влияют на проект. Документ или база данных, которая обобщает проблемы, их текущий статус, и лиц, ответственных за решение в настоящее время. Акт повторения процесса во второй, третий или более раз для достижения желаемой цели, задачи или результата. Процесс планирования, реализации и контроля за эффективным, экономичным потоком и хранением сырья, процессом инвентаризации, готовой продукцией и информацией из пункта отправления до пункта потребления в целях соответствия требованиям заказчика. Изобразительное резюме решений и потоков, которые составляют процедуры или процессы от начала до конца. Что проект ожидает достичь на уровне получателя (например, использование знаний и навыков на практике в течение долгого времени; перевозка грузов по построенным дорогам с течением времени), и чему будет способствовать на уровне изменений для населения (улучшение питания; улучшение доходов; повышение урожайности; и т.д.), что в совокупности помогает добиться выполнения целей, и оказывать воздействие с течением времени. Ощутимые результаты деятельности проекта, в том числе продукты, товары, услуги и изменения (например, люди, прошедшие подготовку и повысившие уровень знаний и мастерства; качество построенных дорог), что в совокупности способствует получению желаемых последствий. Использование исторических данных аналогичных проектов для оценки деятельности по проекту. Этот метод оценки меньше полагается на людей и больше на статистические данные. Сочетание действующих программ и проектов, а также штатное стр. 113 из 12 Управление портфелем Закупки - Содержание и объем продуктов Программа Проект Устав проекта Управление проектом План реализации проекта Управление проектом Руководитель проекта - Проектное предложение Масштаб проекта (объем и содержание) Риск Волнообразное планирование Метод нисходящей оценки (сверху вниз) Структура декомпозиции работ (пооперационный перечень работ) - Guide to the PMD Pro расписание и бюджет, выделенный для каждого проекта или программы. Разработка и управление общим портфелем программ / проектов. Планирование и реализации всех аспектов приобретения ресурсов, в том числе разработка спецификаций, исследование рынка поставщиков, ведение переговоров, мероприятия по покупке, администрирование контрактов и контроль над запасами. Все необходимые результаты проекта, отвечающие согласованным спецификациям (что будет поставляться). Группа взаимосвязанных проектов, управляемых согласованно с целью получения общественно-полезных результатов и управления, которые не достижимы при управлении по отдельности. Комплекс мероприятий, отвечающих согласованным целям, и выполняющий согласованные цели за определенный период времени с помощью согласованного набора ресурсов. Документ, описывающий проект с высоким уровнем детализации, который используется для разрешения руководителю проекта начинать работу. Процесс измерения и отчетности о проделанной работе и принятие корректирующих мер для обеспечения выполнения целей проекта. Всеобъемлющее и логическое представление подробной модели проекта для обеспечения исполнения проекта в установленные сроки, в соответствии с содержанием и объемом в рамках бюджета. Организация и управление ресурсами с целью добиться успешного завершения конкретного проекта, целей, результатов и последствий. Профессионал в области управления проектами, который несет ответственность за планирование, осуществление и закрытие проекта после обеспечения успешного завершения и достижения конкретных целей проекта, результатов и последствий. Четкое и краткое предложение, которое стремится получить одобрение потенциального спонсора на доставку продуктов и/или услуг в ответ на запрос донора или предполагаемые потребности. Все работы, необходимые для доставки содержания продукта (как результаты будут создаваться и поставляться). Потенциальное влияние неопределенности на цели проекта. Итерационный (повторяющийся) процесс обеспечения повышения уровня детализации проекта. Подготовка к реализации с течением времени. Метод оценки, опирающийся на сравнительно небольшую группу экспертов, которые работают над созданием глобальных расчетов проекта, которые затем разбиваются на меньшие пакеты работ. Иерархический список заданий, создаваемых путем разложения на составляющие компоненты проекта, и разбивка проектного процесса на более подробные задачи. стр. 114 из 12 5.2.Приложение 2. Результаты изучения «PMD PRO» Цель Приложения 2 – определить результаты изучения «Руководства PMD Pro». Эти результаты дадут кандидатам на сертификацию по «PMD Pro» и обучающим организациям детальную информацию о том, что именно оценивают экзамены «PMD Pro1» и «PMD Pro2». Модель оценки результатов изучения «PMD Pro» определяет 4 уровня результатов изучения. Экзамен «PMD Pro1» измеряет результаты Уровня 1 и 2, а экзамен «PMD Pro2» оценивает результаты Уровня 3 и 4. Иллюстрация 63. Модель оценки результатов изучения «PMD Pro» Модель оценки результатов изучения «PMD Pro» 1. Знание 2. Понимание 3. Применение Знание ключевых Понимание Способность фактов, условий, основных применять концепций концепций основные руководства и руководства и концепции, инструкций. инструкций. относящиеся к программной области конкретного сценария. Общие определения по модели оценки результатов изучения руководства по управлению проектами 4. Анализ Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением «PMD Pro». Иллюстрация 64. Результаты изучения Руководства PMD Pro. Код Программная область: проекты в секторе развития программной области PR Уровень Тема Знание ключевых фактов, условий, концепций руководства и инструкций 01 01 Дать определение терминов управления проектом в контексте международного развития, включая управление проектами, программами, портфелями. 01 02 Определение 3-х сторон треугольника ограничений, как указано в PMD Pro 01 03 Вспомнить компетенции руководителей проектов в секторе развития 01 04 Вспомнить ответственность руководителя проекта в секторе развития Понимание основных концепций руководства и инструкций 02 01 Объяснить, как культура проектов в секторе развития отличается от проектов в иных секторах. 02 02 Описать опыт и ответственность руководителей проектов в секторе развития 02 03 Объяснить взаимосвязь между сторонами треугольника ограничений и их влияние на управление проектами Умение применять и адаптировать проекты в секторе развития к сценарию 03 01 Управлять работой персонала, который имеет разный уровень компетентности в управлении проектами 03 02 Определить преимущества управления группой проектов в контексте программы 03 03 Определить навыки в развитии, требуемые для прогресса роста сотрудника проекта от начинающего до руководителя проекта 03 04 В сценарии, где проектные ограничения находятся в Guide to the PMD Pro PMD Pro 1 PMD Pro 2 Ссылка на первичное руководство □ 1.3, 1.4 □ 1.3 □ 1.6 □ 1.3 □ □ 1.2 □ 1.6 □ 1.3 □ 1.6 □ 1.4 □ 1.6 □ 1.3 стр. 115 из 12 постоянном движении, определить альтернативы для управления треугольником тройных ограничений. Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением проектов в программе сектора развития в конкретном сценарии 04 01 Определить различия в требуемых компетенциях управления проектами по мере роста размера, сложности и рисков проекта 04 02 Сравнить содержание, цель и процессы проектов, программ и портфелей в секторе международного развития 04 03 Определить последствия изменений в проектных ограничениях на управление треугольником тройных ограничений проекта. Код Программная область: Модель фаз проекта по PMD Pro программной области PM Уровень Тема Знание фактов, условий, концепций, относящихся к Модели фаз проекта по PMD 01 01 Определить 6 фаз Модели фаз проекта PMD 01 02 Вспомнить термины, факты, концепции, относящиеся к 6 фазам общего цикла жизнедеятельности проекта в секторе международного развития Понимание модели фаз проекта по PMD Pro 02 01 Объяснить, каким образом фазы проекта в Модели PMD Pro взаимодействуют друг с другом. 02 02 Объяснить разницу между разработкой, мониторингом и оценкой проекта и управлением проектом в контексте сектора международного развития 02 03 Понимать цель и преимущества логической схемы выбора решения на протяжении цикла жизнедеятельности проекта по PMD Pro 02 04 Объяснить важность включения принципов управления проектами на протяжении всего срока проекта. Умение применять и адаптировать Модель фаз проекта по PMD Pro к конкретному сценарию 03 01 Умение применить 6 фаз с учетом рекомендованных мероприятий и действий, где следует, к конкретному сценарию Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением Модели фаз проекта PMD Pro в конкретном сценарии 04 01 Умение оценить применение 6 фаз в конкретном проекте путем оценки, были ли соответствующие мероприятия процесса правильно применены PMD Pro 1 Код Программная область: идентификация и разработка программной проекта области ID Уровень Тема Знание фактов, условий, концепций, относящихся к сфере идентификации и разработки проектов 01 01 Вспомнить три всесторонние категории работ Фазы идентификация и разработки проекта 01 02 Определить цель сбора данных и анализа данных 01 03 Определить методологию, подходы и инструменты для сбора данных PMD Pro 1 Guide to the PMD Pro □ 1.6 □ 1.4 □ 1.3 PMD Pro 2 Ссылка на первичное руководство □ □ □ 2.2 2.2 □ 2.2 □ 2.2 □ 2.2 2.2 □ 2.2 □ 2.2 PMD Pro 2 Ссылка на первичное руководство □ □ 2.2.1 □ □ 2.2.1.1, 2.2.2.2 2.2.1.2 стр. 116 из 12 01 04 Определить методологию, подходы и инструменты для анализа данных 01 05 Определить цели логической основы 01 06 Определить 5 характеристик показателя СМАРТ 01 07 Вспомнить основные параметры проекта, описанные в логической структуре 01 08 Вспомнить примеры логической схемы принятия решений в жизнедеятельности проекта Понимание фазы идентификации и разработки проекта 02 01 Объяснить концепцию уменьшения возможностей для эффективного управления изменениями на протяжении жизни проекта 02 02 Определить разницу между 4 категориями социальных потребностей 02 03 Объяснить важность триангуляции на этапе определения и разработки проекта 02 04 Определить различия между первичными данными (качественными и количественными) и вторичными данными 02 05 Объяснить категории критериев, которые определяют, что включается в проектное внедрение 02 06 Понимать вертикальную и горизонтальную логику логической структуры проекта 02 07 Объяснить преимущества управленческой логической схемы принятия решений в контексте управления проектами Умение применять и адаптировать фазу идентификации и разработки проекта к конкретному сценарию 03 01 Выбрать наиболее подходящий инструмент для поставленных целей по сбору и анализу данных 03 02 Определить элементы, которые надо включить в проектное внедрение на основе ясно определенных категорий критериев решений 03 03 По конкретному сценарию применить критерий принятия решения «Делать» или «Не делать» для определения, следует ли одобрять проект Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по фазе идентификации и разработки проекта в конкретном сценарии 04 01 Определить преимущества каждого типа сбора данных 04 02 Сравнить результаты и индикаторы логической структуры PMD Pro на каждом из четырех уровней 04 03 Объяснить разновидность возможностей эффективного управления изменениями в течение срока действия проекта 04 04 На основе сценария проекта провести различия между 4 категориями проектных потребностей 04 05 Интерпретировать вертикальную и горизонтальную логику логической основы 04 06 Оценить качество проектных показателей на основе критериев СМАРТ □ Код Программная область: начало проекта программной области SU Уровень Тема Знание фактов, условий, концепций, относящихся к сфере начала проекта 01 01 Знать цели фазы начала проекта 01 02 Определить три перспективы, которые должны быть представлены на совете и правлении проекта PMD Pro 1 Guide to the PMD Pro 2.2.1.2 □ □ □ 2.2.1.3 2.2.1.3 2.2.1.3 □ 2.2.1.4 □ 2.2.1 □ 2.2.1.1 □ 2.2.1.1 □ 2.2.1.1 □ 2.2.1.2 □ 2.2.1.3 2.2.1.4 □ □ □ □ 2.2.1.1, 2.2.1.2 □ 2.2.1.2 □ 2.2.1.4 □ □ 2.2.1.1 2.2.1.3 □ 2.2.1 □ 2.2.1.1 □ 2.2.1.3 □ 2.2.1.3 PMD Pro 2 Ссылка на первичное руководство 2.2.2.1 2.2.2.2 стр. 117 из 12 01 03 Определить цели сообщений о запуске проекта Понимание Фазы начала проекта 02 01 Понимать цель устава проекта 02 02 Объяснить важность создания структуры управления проекта 02 03 Объяснить связь между проектными допусками и руководством проекта 02 04 Объяснить ответственность спонсора проекта и правления проекта Умение применять и адаптировать фазу начала проекта к конкретному сценарию 03 01 На основе проектного сценария создать или обновить устав проекта 03 02 На основе проектного сценария определить стратегии для улучшения работы проекта через улучшенные процессы руководства проектом Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по фазе начала проекта в конкретном сценарии 04 01 Определить преимущества каждого типа сбора данных □ 2.2.2.4 □ □ □ 2.2.2.3 2.2.2.2 2.2.2.1 □ 2.2.2.2 Код Программная область: планирование проекта программной области РР Уровень Тема Знание фактов, условий, концепций, относящихся к сфере планирования проекта 01 01 Вспомнить факты, термины и концепции, относящиеся к плану реализации проекта 01 02 Определить 8 компонентов всестороннего плана проекта 01 03 Определить преимущества разработки планов проекта через процесс совместного участия Понимание Фазы планирования проекта 02 01 Объяснить важность включения каждого принципа управления проектами PMD Pro в процесс планирования проекта 02 02 Понимать преимущества волнообразного планирования 02 03 Сравнить логические структуры, предложения и планы реализации проекта Умение применять и адаптировать фазу планирования проекта к конкретному сценарию 03 01 Определить сценарии, где следует применять волнообразный подход к планированию проекта 03 02 На основе проектного сценария определить сильные и слабые аспекты плана проекта с точки зрения сбалансированности, всесторонности, интегрированности, участия и итерации Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по фазе планирования проекта в конкретном сценарии 04 01 Сравнить логическую структуру, проектное предложение и план реализации проекта по целям, содержанию, аудитории и процессу 04 02 Объяснить взаимосвязь между различными дисциплинами проекта и всесторонним планом проекта 04 03 PMD Pro 1 Guide to the PMD Pro □ 2.2.2.3 □ 2.2.2.2 □ 2.2.2 PMD Pro 2 Ссылка на первичное руководство □ □ 2.2.3 □ □ 2.2.3.3 2.2.3.5 □ 2.2.3.2–2.2.3.6 □ 2.2.3.6 2.2.3 □ □ 2.2.3.6 □ 2.2.3.2-2.2.3.6 □ 2.2.3.3 □ 2.2.3.3 □ 2.2.3.4 стр. 118 из 12 Код Программная область: реализация проекта программной области реализации Уровень Тема Знание фактов, условий, концепций, относящихся к сфере реализации проекта 01 01 Дать определения терминов, относящихся к реализации проекта, включая проблемы, журнал учета проблем, внутренний контроль 01 02 Определить 4 основных процесса в процессе управления проблемами 01 03 Определить мероприятия, проводимые для управления людьми в процессе реализации проекта Понимание Фазы реализации проекта 02 01 Понимать важность управления проблемами при реализации проектов развития 02 02 Объяснить последовательность и отношения между 4 базовыми процессами управления проблемами 02 03 Определить преимущества хорошо управляемых систем внутреннего контроля Умение применять и адаптировать фазу реализации проекта к конкретному сценарию 03 01 Разработать журнал учета проблем на основе проектного сценария 03 02 Применить 4-х этапный процесс к управлению проблемами в проектном сценарии Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по фазе реализации проекта в конкретном сценарии 04 01 Определить альтернативы для систем внутреннего контроля на основе категорий административных, финансовых и логистических систем PMD Pro 1 Код Программная область: мониторинг, оценка и контроль программной проекта области МЕ Уровень Тема Знание фактов, условий, концепций, относящихся к сфере мониторинга, оценки и контроля проекта 01 01 Вспомнить факты, термины и концепции, относящиеся ко всем уровням мониторинга, оценки и их связи с логической основой проекта 01 02 Вспомнить факты, термины и концепции, относящиеся к другим подходам в оценке 01 03 Вспомнить факты, термины и концепции, относящиеся к плану мониторинга и оценки проекта 01 04 Вспомнить факты, условия и концепции, относящиеся к управлению сменой контроля Понимание Фазы мониторинга, оценки и контроля проекта 02 01 Определить 6 элементов системы мониторинга проекта 02 02 Определить 6 сфер допусков проекта 02 03 Объяснить компромисс между стоимостью и сложностью при сборе данных мониторинга Умение применять и адаптировать фазу мониторинга, оценки и контроля к конкретному сценарию 03 01 Объяснить важность плана мониторинга проекта, и как его PMD Pro 1 Guide to the PMD Pro PMD Pro 2 Ссылка на первичное руководство □ □ 2.2.4.1-2.2.4.3 □ 2.2.4.1 □ 2.2.4.2 □ 2.2.4.1 □ 2.2.4.1 □ 2.2.4.3 □ 2.2.4.1 □ 2.2.4.1 □ 2.2.4.3 PMD Pro 2 Ссылка на первичное руководство □ □ 2.2.5.1-2.2.5.3 □ 2.2.5.2 □ 2.2.5.2 □ □ □ 2.2.5.2 2.2.5.5 2.2.5.2 □ 2.2.5.2 стр. 119 из 12 содержание отличается от плана, содержащегося в логической структуре проекта и плане проекта 03 02 Понимать элементы, которые дают информацию для плана мониторинга и оценки проекта 03 03 Объяснить причины оценки проектов Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по мониторингу, оценки и контролю проекта в конкретном сценарии 04 01 Сравнить содержание, процесс, цели качественных и количественных показателей 04 02 Сравнить и противопоставить стоимость и сложность различных подходов в мониторинге 04 03 Сравнить разницу между мониторингом, оценкой и контролем проекта 04 04 Объяснить отношения между мониторингом и оценкой и процессом итеративного планирования 04 05 Объяснить различия между показателями мониторинга и оценки на различных уровнях логической структуры проекта Код Программная область: переходный период проекта при программной завершении области ЕР Уровень Тема Знание фактов, условий, концепций, относящихся к сфере переходного периода проекта 01 01 Вспомнить 4 варианта перехода проекта 01 02 Вспомнить мероприятия, относящиеся к административному, контрактному и финансовому закрытию проекта 01 03 Определить 2-х этапный процесс по проверке результатов проекта Понимание Фазы переходного периода проекта 02 01 Определить разницу между обзором последействия и оценкой по завершению проекта 02 02 Объяснить цель и содержание матрицы планирования переходного периода проекта Умение применять и адаптировать фазу переходного периода проекта к конкретному сценарию 03 01 Разработать стратегию переходного периода проекта при завершении 03 02 Выбрать наилучшие инструменты для сбора данных по переходному периоду проекта с учетом ограничений проекта и целей познания Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по переходному периоду проекта в конкретном сценарии 04 01 Различать между надлежащим и ненадлежащим применением административного, контрактного и финансового закрытия проекта 04 02 Сравнить и противопоставить различные варианты изучения завершения проекта 04 03 Различать между надлежащим и ненадлежащим применением административного, контрактного и финансового закрытия проекта Guide to the PMD Pro PMD Pro 1 □ 2.2.5.2 □ 2.2.5.3 □ 2.2.5.2 □ 2.2.5.2 □ 2.2.5.1 □ 2.2.5.1 □ 2.2.5.1 PMD Pro 2 Ссылка на первичное руководство □ □ □ 2.2.6.1 2.2.6.3 □ 2.2.6.2 □ 2.2.6.4 □ 2.2.6.1 □ 2.2.6.1 □ 2.2.6.4 □ 2.2.6.4 □ 2.2.6.5 □ 3.3.6.4 стр. 120 из 12 Код Программная область: обзор дисциплин управления программной проектами области DO Уровень Тема Знание фактов, условий, концепций, относящихся к данной учебной сфере 01 01 Знать 6 дисциплин управления проектами Понимание темы обзора дисциплин управления проектами 02 01 Понимать, как проектный цикл PMD Pro поддерживается шестью дисциплинами управления проектами 02 02 Объяснить, как 6 дисциплин могут применяться к проектному циклу PMD Pro Умение применять тему обзора дисциплин управления проектами к конкретному сценарию 03 01 Умение применить 6 дисциплин к конкретному сценарию проекта Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по обзору дисциплин управления проектам в конкретном сценарии 04 01 Умение оценить применение 6 дисциплин в конкретном сценарии PMD Pro 1 Код Программная область: управление содержанием и программной объемами (масштабом) проекта области SM Уровень Тема Знание фактов, условий, концепций, относящихся к сфере контроля объемов работ 01 01 Вспомнить факты, термины и концепции, относящиеся к контролю объемов работ, включая объемы продуктов, проекта и структуру декомпозиции работ 01 02 Определить преимущества структуры декомпозиции работ Понимание контроля объемов работ 02 01 Понимание разницы между объемами продукта и объемами проекта 02 02 Понимание, что объемы проекта должны быть подтверждены и должны быть всеобъемлющими и детальными 02 03 Понимание 3-х общих проблем, которые возникают из-за отсутствия четко определенного содержания (объема) работ 02 04 Понимание состава структуры декомпозиции работ 02 05 Объяснить преимущества двух форматов структуры декомпозиции работ Умение применять и адаптировать контроль объемов работ к конкретному сценарию 03 01 Разработать простую структуру разбивки работ для конкретного сценария в формате графической диаграммы 03 02 Умение создать простую структуру разбивки работ для конкретного сценария в формате графической диаграммы Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по контролю объемов работ в конкретном сценарии 04 01 Объяснить всесторонний и детальный объем продукта и проекта через конкретный сценарий проекта 04 02 Оценить структуру декомпозиции работ с точки зрения всесторонности и деталей данного сценария проекта PMD Pro 1 Guide to the PMD Pro PMD Pro 2 Ссылка на первичное руководство □ □ 3.0 □ 3.0 □ 3.0 □ 3.0 □ 3.0 PMD Pro 2 Ссылка на первичное руководство □ □ 3.1.1-3.1.2 □ 3.1.2 □ 3.1.1 □ 3.1.1 3.1.1 3.1.2 3.1.2 □ 3.1.2 □ 3.1.2 □ 3.1.1 □ 3.1.2 стр. 121 из 12 Код Программная область: управление временем программной области управления временем Уровень Тема Знание фактов, условий, концепций, относящихся к управлению временем 01 01 Знать 5 шагов в планировании плана-графика 01 02 Определить термины, относящиеся к управлению временем, включая сетевые диаграммы, критический путь, диаграмму Ганта, время задержки проекта, ускоренное продвижение, интенсификация Понимание управления временем 02 01 Понимание 5 этапов в процессе планирования графиков 02 02 Объяснить отношения между оценкой ресурсов и разработкой календаря проекта 02 03 Понимание взаимосвязи между треугольником ограничений проекта и разработкой плана-графика 02 04 Понимание цели, структуры и содержания диаграммы Ганта 02 05 Понимание цели, структуры и содержания сетевой диаграммы 02 05 Объяснить цель и процесс ускорения движения и интенсификации Умение применять и адаптировать управление временем к конкретному сценарию 03 01 Умение создать простую сетевую диаграмму для конкретного сценария 03 02 Умение создать простую диаграмму Ганта для конкретного сценария 03 03 Умение определить факторы потенциальной длительности проекта в конкретном сценарии 03 04 Умение определить критический путь проекта в данной сетевой диаграмме для данного сценария проекта Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по управлению временем в конкретном сценарии 04 01 Отличать, какие задачи из сетевой диаграммы являются частью критического пути, а какие частью ускорения или замедления (резерв времени) проекта 04 02 Умение объяснить суммарную диаграмму Ганта против стандартной диаграммы Ганта 04 03 Определить возможности управлять запаздывающими проектами через интенсификацию и ускорение PMD Pro 1 Код Программная область: финансовое управление программной области FM Уровень Тема Знание фактов, условий, концепций, относящихся к управлению финансами 01 01 Определить термины, относящиеся к управлению финансами, включая прямые затраты, косвенные затраты, переходной стоимости, совместным услугам, плану счетов, анализу отклонений, и анализу заработанной (выполненной) стоимости 01 02 Определить 3 подхода к проектным расчетам Понимание финансового управления 02 01 Объяснить преимущества разработки оценки (расчетов) бюджетов каждой фазы PMD Pro 1 Guide to the PMD Pro PMD Pro 2 Ссылка на первичное руководство □ □ □ 3.2.0 3.2.1-3.25 □ □ 3.2.0 3.2.2-3.2.3 3.2.0 3.2.4 3.2.1 3.2.5 □ 3.2.1-3.2.4 □ 3.2.4 3.2.3 3.2.3 □ 3.2.3 □ 3.2.4 3.2.5 PMD Pro 2 Ссылка на первичное руководство □ □ 3.3.1-3.3.3 □ 3.3.2 □ 3.3.2 стр. 122 из 12 02 02 Понимать преимущества и недостатки 3 методов сметных предположений (бюджетных оценок) 02 03 Объяснить важность мониторинга движения денежных средств 02 04 Понимание значения анализа заработанной стоимости Умение применять и адаптировать финансовое управление к конкретному сценарию 03 01 Умение создать простой бюджет 03 02 Объяснить процесс измерения заработанной стоимости 03 03 Объяснить цель и создать план счетов 03 04 На конкретном примере выбрать сметные предположения на основе оценки сверху вниз, снизу вверх и параметрических данных Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по финансовому управлению в конкретном сценарии 04 01 Умение оценить применение разработки бюджета для данного сценария 04 02 Определить преимущества анализа заработанной стоимости 04 03 На основании данных бюджета проанализировать отклонения в кумулятивной стоимости проекта 04 03 На основании данных бюджета и дат проанализировать статус заработанной стоимости проекта □ Код Программная область: управление рисками программной области RM Уровень Тема Знание фактов, условий, концепций, относящихся к управлению рисками 01 01 Определить 4 этапа процесса управления рисками 01 02 Определить термины, относящиеся к управлению рисками, включая позитивные риски, негативные риски, реестр рисков, матрица оценки рисков и допустимость риска 01 03 Определить 4 стратегии реагирования на риски Понимание управления рисками 02 01 Объяснить важность вероятности и влияния в контексте управления рисками 02 02 Объяснить повторяющийся характер управления рисками и его важность в течение срока действия проекта 02 03 Понимать содержание и структуру реестра рисков 02 04 Объяснить цель, структуру и содержание матрицы оценки рисков Умение применять и адаптировать управление рисками к конкретному сценарию 03 01 Применить матрицу оценки рисков в конкретном сценарии 03 02 Организовать проектные риски по категориям рисков 03 03 Умение применить 4 стратегии управления рисками в конкретных сценариях Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по управлению рисками в конкретном сценарии 04 01 Интерпретировать матрицу оценки рисков для дифференцирования рисков, которые могут быть допустимыми, и которые могут быть исключены в данном не сложном проекте 04 02 Распределить стратегии мер реагирования на риски по категориям PMD Pro 1 Guide to the PMD Pro 3.2.2 3.3.3 3.3.3 □ □ 3.3.1 3.3.3 3.3.1 3.3.2 □ 3.3.1 □ 3.3.3 3.3.3 3.3.3 PMD Pro 2 □ □ □ Ссылка на первичное руководство 3.4.0 3.4.1-3.4.4. 3.4.3 □ 3.4.2 □ 3.4.4 3.4.1 3.4.2 □ □ 3.4.2 3.4.1 3.4.1-3.4.4 □ 3.4.2 □ 3.4.3 стр. 123 из 12 04 03 Интерпретировать содержание реестра рисков 3.4.1 Код Программная область: управление обоснованием программной области JM Уровень Тема Знание фактов, условий, концепций, относящихся к программной сфере 01 01 Определить термины, относящиеся к управлению обоснованием проекта, включая определение потребностей на основании проблем, определение потребностей на основании активов, дерево проблем, дерево целей Понимание управления обоснованием 02 01 Понимать важность обоснования проекта для сотрудников и заинтересованных сторон проекта 02 02 Объяснить разницу между подходами: определение потребностей на основании проблем, определение потребностей на основании активов 02 03 Понимать связь между деревом проблем и деревом целей 02 04 Определить и объяснить уровни иерархии в дереве проблем Умение применять и адаптировать управление обоснованием к конкретному сценарию 03 01 Создать базовое дерево проблем для конкретного сценария 03 02 Создать базовое дерево целей для конкретного сценария 03 03 Определить, как предлагаемые цели внедрения проекта отвечают критериям обоснования проекта в конкретном сценарии Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по управлению обоснованием проекта в конкретном сценарии 04 01 Умение оценить, имеется ли адекватное обоснование проектного внедрения на основе подхода анализа потребностей по проблемам 04 02 Интерпретировать причины и взаимосвязи в дереве проблем Сравнить и противопоставить подходы в анализе потребностей: определение потребностей на основании проблем, определение потребностей на основании активов PMD Pro 1 Код Программная область: управление заинтересованными программной сторонами области SM Уровень Тема Знание фактов, условий, концепций, относящихся к управлению заинтересованными сторонами 01 01 Перечислить 6 категорий заинтересованных сторон 01 02 Знать компоненты диаграммы RACI 01 03 Знать, что обмен информацией с заинтересованными сторонами важен и требует планирования и исполнения 01 04 Вспомнить инструменты определения заинтересованных сторон с точки зрения проектной зависимости, риска и власти Понимание управления заинтересованными сторонами 02 01 Понимать 4 главные роли, определенные в диаграмме RACI 02 02 Понимать компоненты плана обмена информацией 02 03 Объяснить цель и структуру инструментов анализа заинтересованных сторон, включая схемы RACI, диаграмму Венна, матрицу анализа участников и план сообщений Умение применять и адаптировать управление заинтересованными сторонами к конкретному сценарию PMD Pro 1 Guide to the PMD Pro PMD Pro 2 Ссылка на первичное руководство □ □ 3.5.1-3.5.2 □ 3.5.0 □ 3.5.1 3.5.2 3.5.2 □ □ 3.5.2 3.5.2 3.5.2 □ 3.5.2 □ 3.5.2 3.5.1 PMD Pro 2 Ссылка на первичное руководство □ □ □ 3.6.1 3.6.3 3.6.4 3.6.2 □ 3.6.3 3.6.4 3.6.1-3.6.4 стр. 124 из 12 03 01 Распределить заинтересованные стороны по категориям для конкретного сценария проекта 03 02 Создать диаграмму Венна для конкретного сценария 03 03 Создать матрицу RACI для конкретного сценария 03 04 Создать матрицу анализа участников для конкретного сценария 03 05 Применить рекомендуемые компоненты к плану обмена информацией в конкретном сценарии Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по управлению заинтересованными сторонами в конкретном сценарии 04 01 Интерпретировать содержание инструментов управления проекта, включая схему RACI, диаграмму Венна, матрицу анализа участников, план обмена сообщениями 3.6.1 □ □ □ 3.6.2 3.6.3 3.6.2 2.6.2 Код Программная область: управление поставками программной области SC Уровень Тема Знание фактов, условий, концепций, относящихся к управлению цепочками поставок 01 01 Перечислить 4 компонента, которые составляют управление сетью поставок 01 02 Перечислить 4 этапа в управлении закупками Понимание управления поставками 02 01 Объяснить 4 элемента управления логистикой 02 02 Определить альтернативы для определения провайдеров в процессах закупки Умение применять и адаптировать управление поставками к конкретному сценарию 03 01 Умение применить принципы управления поставками в конкретном сценарии проекта Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала по управлению поставками в конкретном сценарии 04 01 Умение оценить, используя рекомендуемое содержание, применение следующих процессов цепочки поставок в конкретном сценарии проекта: управление закупками, управление логистикой, управление активами, управление информацией PMD Pro 1 Код Программная область: применение PMD Pro программной области AD Уровень Тема Знание фактов, терминов, концепций, относящихся к применению PMD Pro 01 01 Вспомнить принципы применения Понимание применения PMD Pro 02 01 Понимать факторы соображений при применении PMD Pro к проектам 02 02 Понимать роль систем в применении инструментов и методов PMD Pro 02 03 Понимать связь между профилем риска проекта и выбором методов и инструментов PMD Pro 02 04 Оценить соображения, необходимые для реализации проектов с применением PMD Pro через исполняющих партнеров Умение применять и адаптировать PMD Pro к конкретному сценарию PMD Pro 1 Guide to the PMD Pro □ □ 3.6.1-3.6.4 PMD Pro 2 Ссылка на первичное руководство □ □ 3.7.0 □ 3.7.1 □ 3.7.2 3.7.1 □ □ □ 3.7.1-3.7.4 □ 3.7.1-3.7.4 PMD Pro 2 Ссылка на первичное руководство 4.1 □ 4.4 4.4 4.4 4.4 стр. 125 из 12 03 01 Применение дисциплин PMD Pro в отдельных проектах конкретного сценария проекта 03 02 Дать рекомендации по применению принципов PMD Pro в программах и во всей организации Уметь определить, анализировать и различать между надлежащим и ненадлежащим применением учебного материала в конкретном сценарии 04 01 Интерпретировать применение методов и инструментов PMD Pro в конкретном проекте 04 02 Связать методы и инструменты PMD Pro с бизнес процессами Guide to the PMD Pro □ 4.1-4.4 □ 4.1-4.4 □ 4.1-4.4 4.4 стр. 126 из 12 5.3.Приложение 3. Список использованной литературы. Blackman, Rachel, 2003, Project cycle management, Teddington: Tearfund. Boston University Corporate Education Center, Project Management Competency Development Process. Britton, Bruce, Heaney, Deborah, Sterne, Rod, 2001, The Partnership Toolbox, London: WWF. Council of Europe and European Commission, 2000, Project Management T-Kit, Strasbourg: Council of Europe publishing. Dearden, Philip N., 2001, Program and Project Cycle management (PPCM): Lessons from DFID and other organizations, Tokyo: CIDT. Deming, W. Edwards, 1986. Out of the Crisis, Boston: MIT Center for Advanced Engineering Study. Department for International Development (DFID), 2002, Tools for Development – version 15 DFID, Impact Assessment & Project Management Cycle (PMC). Emergency Capacity Building Project (ECB), 2007, Impact Measurement and Accountability in Emergencies The Good Enough Guide. London: Oxfam Publishing. Erwin, James, Smith, Michael L., Role & Responsibility Charting (RACI). European Commission, 2004, Aid Delivery Methods volume 1 Project Cycle Management Guidelines, Brussels: European Commission. Foundation Terre des Hommes, 2001, Project Cycle Handbook, Le Mont-sur-Lausanne: Foundation Terre des Hommes. Gardner, Alison, Greenblott, Kara, Joubert, Erika, 2005, What We Know About Exit Strategies Practical Guidance For Developing Exit Strategies in the Field, C-SAFE Regional Learning Spaces Initiative. GB Equal Support Unit, A Project Cycle Management and Logical Framework Toolkit – A practical guide for Equal Development Partnerships, Herefordshire: Local Livelihoods Ltd. Geyer, Yvette, 2005, Project Management, Pretoria: IDASA. GTZ, Manual of Project Management for Development Practitioners. International Fund for Agricultural Development (IFAD), Participatory Approaches for an ImpactOriented Project Cycle International Fund for Agricultural Development, 2002, A Guide for Project M&E, Rome: IFAD. Levine, Carlisle J., 2007, Catholic Relief Services’ (CRS) Guidance for Developing Logical and Results Frameworks, Baltimore: CRS. Lipczinsky, Malte, 1996, Getting to Know PEMT, Berne: SDC, Evaluation Section. McMillan, Della E., Willard Alice, 2006, Preparing for the Evaluation Guidelines and Tools for Pre-Evaluation Planning, Baltimore: CRS. Mercy Corps, 2005, Design, Monitoring and Evaluation – Guidebook, Portland: Mercy Corps. Novartis Foundation for Sustainable Development, Project Management Handbook, A Working Tool for Project Managers. Pataki, George E., Dillon, James T., 2003, McCormack Michael, Project Management, Guidebook Release 2, New York: New York State Office for Technology. Picard, Mary, 2001, Course Materials for the Design, Monitoring and Evaluation (DME) Course, Kosovo: CARE. Plan International, 2002, Project Management Methodology. Project Management Institute. 2004. A Guide to the Project Management Body of Knowledge: PMBOK® Guide – Third Edition. Rugh, J. 2002, Comparisons between Terminologies of Different Donor Agencies for Results/ Logical Frameworks, Atlanta: CARE International and InterAction’s Evaluation Interest Group. Guide to the PMD Pro стр. 127 из 12 Saldanha, Cedric D., Whittle, John F., 1998, Using the Logical Framework for Sector Analysis and Project Design: A User’s Guide, Manila: Asian Development Bank. Siles R. 2004, Guidelines for Planning, Implementing and Managing a DME Project Information System. Atlanta: CARE. Standish Group. 1995. The Chaos Report. Boston: The Standish Group. Stetson, G. Sharrock, and S. Hahn, 2004, Propack The CRS Project Package: Project Design and Proposal Guidance for CRS Project and Program Managers. Baltimore: CRS. Stetson, S. Hahn, D. Leege, D. Reynolds and G. Sharrock, 2007, Propack II The CRS Project Package: Project Management and Implementation Guidance for CRS Project and Program Managers. Baltimore: CRS. The Centre for Development and Population Activities, 1994, Project Design for Program Managers, Washington, D.C.: The Centre for Development and Population Activities. United Nations Environment Program, 2005, UNEP project manual: formulation, approval, monitoring and evaluation. VCP, 2003, Facts for Projects (draft version). Verzuh, Eric, 2008, The Fast Forward Project Management-Third Edition, New Jersey: John Wiley & Sons, Inc. Wheelwright, S.C., Clark, K.B. 1995, LEADING Product Development: A Senior Manager's Guide to Creating and Shaping the Enterprise, New York: Free Press. Wideman, Max, 2001, Project Management Simply Explained A Logical Framework to Help Your Understanding, Vancouver: AEW Services World Bank, 2006, Managing the Implementation of Development Projects – New Edition. World Vision Development Resource Team, 2007, Learning through Evaluation with Accountability and Planning: World Vision’s Approach to Design, Monitoring and Evaluation (LEAP) – Second Edition, Washington, DC: World Vision International. World Vision Development Resource Team, 2009, LEAP Lexicon – Second Edition, Washington, DC: World Vision International. Youker, Robert, 1989, Managing the project cycle for time, cost and quality: lessons from World Bank experience, Butterworth & C. (Publishers) Ltd. Guide to the PMD Pro стр. 128 из 12
