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

Управление проектами Н.В. Павлов 1. Общие замечания 3 1.1. Литература 3 1.2. Актуальность курса 3 2. Определения, место и роль проектного управления 7 2.1. Подходы к осуществлению экономической деятельности 9 2.2. Цели и стратегия проекта 24 2.3. Окружающая среда и участники проекта 26 2.4. Жизненный цикл проекта 29 2.5. Деятельность по управлению проектом 35 2.6. Объекты управления в проекте 35 3. История и перспективы проектного управления 41 4. Классификации проектов 45 5. Методоллогии управления проектами 48 5.1. Методология PERT 48 5.2. Гибкие методологии разработки 50 5.3. Критические цепочки 59 5.4. Классическая методология PMBOK 62 5.5. Работа с высокими рисками. Инновационные проекты (стартапы) 63 5.6. Сбалансированная методология 65 5.7. Процессно-ориентированное управление 67 6. Предынвестиционная фаза 67 6.1. Стандартизированное управление проектами 67 6.2. Предварительная проработка целей и задач проекта 69 6.3. Оценка, ранжирование и отбор проектов 71 6.4. Планирование границ проекта 75 6.5. Планирование содержания 80 6.6. Бизнес-план проекта 91 7. Организационная структура проекта 102 7.1. Типы оргструктур управления проектами 103 7.2. Зависимость оргструктуры от ориентации на функции или на процессы 105 7.3. Офис проекта 109 8. Финансирование проекта 115 8.1. Инвестиционные ресурсы 115 8.2. Источники финансирования 116 8.3. Организация финансирования проекта 118 9. Планирование проекта 121 9.1. Основные понятия и определения 121 9.2. Основные принципы планирования 122 9.3. Структурная декомпозиция работ 123 9.4. Графики работ 134 9.5. Организационная структура и матрица ответственности 135 9.6. Структура статей затрат проекта 136 9.7. Диаграмма контрольных событий 137 9.8. Диаграмма Гантта????? 138 9.9. Диаграмма по методу критического пути 142 9.10. Сетевые представления 142 9.11. Диаграмма «операции на стрелках» во временном масштабе 152 9.12. Расписание по методу критической цепочки 159 9.13. Иерархическое расписание 165 9.14. Линия баланса 170 9.15. Сетевое планирование 176 10. Планирование стоимости проекта 183 10.1. Ресурсное планирование 183 10.2. Связь сметного и календарного планирования 184 10.3. Основные принципы управления стоимостью проекта 186 10.4. Оценка стоимости проекта (что-то было) 191 10.5. Карта планирования стоимости 194 10.6. Оценка по аналогии 200 10.7. Параметрическая оценка 202 10.8. Оценка «снизу вверх» 207 10.9. Базовый план стоимости 211 10.10. Свод 218 11. Планирование качества проекта 219 11.1. Программа обеспечения качества проекта 219 11.2. Схема [типового] процесса 223 11.3. Аффинная диаграмма 229 11.4. Свод 232 12. Планирование риска 233 12.1. План реагирования на риски (тема практики) 233 12.2. Анализ Монте-Карло 240 12.3. Дерево решений 248 12.4. Свод 252 13. Построение команды 252 13.1. Четырехстадийная модель создания проектной команды 253 13.2. Матрица заинтересованных сторон 257 13.3. Реестр навыков 262 13.4. Карта балльной оценки приверженности 271 14. Документирование плана проекта 276 1. Общие замечания 1.1. Литература 1.1.1. Основная Милошевич Д. З. Набор инструментов для управления проектами — М.: Компания АйТи; ДМК Пресс, 2008. — 729 с. 1.1.2. Дополнительная И. И. Мазур, В. Д. Шапиро, Н. Г. Ольдерогге, А. В. Полковников. Управление проектами. Есть 2004, есть более новый, 2009 (2010). Управление проектом. Основы проектного управления : учебник / кол. авт. под ред. проф. М.Л. Разу. — М.КНОРУС, 2006. — 768 с. Статьи Глоссарий http://www.pmpractice.ru/knowledgebase/gloss/ 1.2. Актуальность курса Ни у кого не вызывает сомнений, что Россия должна экономически развиваться. Есть много разных предложений: догонять более развитые страны, искать свой путь. Но в любом случае нужны перемены, инновации. Зачем нужны инновации в экономике? Во-первых, человеку всё время хочется нового: новых товаров, услуг, впечатлений. Во-вторых, меняется внешняя среда организаций (в основном технологическая), что требует перестройки их деятельности. Под инновацией различные авторы понимают результат; изменение; это процесс. Наиболее правильным представляется считать инновации результатом. Это не только изобретение, но и внедрение нового. В 2009 Минобрнауки сделал доклад об инновационной ситуации в России. [Национальная инновационная система и государственная инновационная политика российской федерации. Базовый доклад к обзору ОЭСР национальной инновационной системы], сделанный по методологии ОЭСР. До 2006 года Россия дошла до 7 места по размеру ВВП, до 4 места по его росту. Но рост был без накопления капитала. То есть живем за счет старого оборудования. Резерв загрузки исчерпан. Оборудование изношено. И большой импорт высокотехнологичной продукции. Но всё-таки, ряд высокотехнологичных отраслей рос и мало снизился в кризис. Ситуация показана на рис. Рис. 1. На исследования и разработки в России тратится мало, но по росту этого показателя Россия на втором место после Китая. Финансирование исследований и разработок в основном государственное. Выполняет исследования в основном предпринимательский сектор. Довольно много работ и в госсекторе, но мало заняты образовательные учреждения. Раньше было наоборот. Во всем мире тоже велика роль образовательных учреждений. Число исследователей в России примерно такое же, как в развитых странах, но в других странах их число растет, у нас – падает. Результативность же во всем, кроме темпов роста числа патентов, ничтожно мала. Растет тенденция перехвата технологий, Россия больше покупает технологий, чем продает. Это может быть временным этапом, так было и в Японии после 2 мировой войны. Доля инновационной продукции в выручке в 3 раза меньше, чем даже в отстающих странах организации экономического сотрудничества и развития, а доля в продажах – в 10 раз меньше. Рис. 1. Ситуация в области инноватики в России (многоугольник) по сравнению со странами ОСЭР (100% по всем параметрам). (ВВЗ – валовые внутренние затраты. Триада – ЕС, США и Япония) Принятая в ноябре 2008 г. Концепция долгосрочного социально-экономического развития Российской Федерации на период до 2020 года (далее - Концепция 2020) определила основные направления перехода к инновационному социально-ориентированному типу экономического развития страны. Высокотехнологичные отрасли, определенные в Концепции 2020 в качестве локомотивов инновационного развития российской экономики, которые реально способны в настоящее время стать стартовыми направлениями в решении задачи создания современной научно-технологической базы и на основе которых можно осуществить модернизацию отечественной экономики, включают: • авиационную промышленность и двигателестроение; • ракетно-космическую промышленность; • судостроительную промышленность; • радиоэлектронную промышленность; • атомный энергопромышленный комплекс; • информационно-коммуникационные технологии. • Заслуживает внимания и свот-анализ инновационной системы России (табл. Таблица 1). Таблица 1 Свот-анализ инновационной системы России Сильные стороны Слабые стороны 1. Богатые природные ископаемые, обширная территория, которые могут быть эффективно освоены с помощью инновационных компаний. 2. Высокие темпы экономического роста в 2000 – 2007 гг. 3. Техническая модернизация ряда экономически успешных отраслей промышленности в докризисный период. 4. Исторически сильная научная и техническая культура, традиции и накопленный опыт в области организации и проведения научных исследований и разработок. 5. Квалифицированная (выше, чем в Китае), дешевая (дешевле, чем в Европе) рабочая сила и научно-технические кадры. 6. Бурный рост числа и разнообразие объектов инфраструктуры инновационной деятельности. 7. Относительно высокая оснащенность современными информационно-технологическими средствами управленческого звена компаний. 8. Продвижение промышленности по пути рыночных реформ, улучшение качества менеджмента, завершение в большинстве секторов процесса корпоративного строительства. 1. Высокий уровень монополизации национального и региональных рынков, доминирование крупных компаний сырьевого сектора в группе лидеров отечественного бизнеса. 2. Недостаточная координация между государственным и частным сектором в разработке приоритетов научно-технического и инновационного развития и мер их реализации. 3. Преобладание бюджетного финансирования всех форм научной и инновационной деятельности и инновационной инфраструктуры 4. Отсутствие скоординированной политики трансфера знаний и технологий. 5. Небольшая степень поддержки малых инновационных предприятий. 6. Низкий уровень инновационной активности бизнеса. Преобладание в большинстве компаний неинновационных способов создания конкурентных преимуществ. 7. Устаревшая технологическая структура основного капитала в большинстве отраслей, снижение возможностей модернизации в условиях современного кризиса. 8. Кризисное состояние отраслевой и фирменной науки, крайняя неоднородность сектора исследований, разрыв между потребностями промышленности и науки. 9. Недостаточный уровень внутреннего спроса на инновационную продукцию. 10. Низкий уровень инновационной культуры и отсутствие опыта инновационного предпринимательства. Возможности Угрозы 1. Возможности «перескакивания» на более высокие уровни технологического развития в ряде секторов вследствие эффекта запаздывающего развития. 2. Бурное развитие глобального рынка инжиниринговых услуг, в котором российские компании и научные организации позиционированы довольно высоко. Отрасли специализации в этом направлении – разработки в области авиационной и космической технологий, программного обеспечения, некоторых направлений ИКТ. 3. Встраивание в глобальные технологические цепочки в традиционных и высокотехнологичных секторах промышленности. 4. Усиление конкуренции на внутренних рынках как стимул инновационной активности. 5. Вступление в ВТО и снижение барьеров выхода на мировые рынки. 1. Сохранение технологического отставания в некоторых важных монополизированных секторах экономики. 2. Исчерпание преимуществ по качеству человеческого капитала и иным компонентам инновационного потенциала. 3. Резкое снижение расходов на исследования и разработки в условиях финансово-экономического кризиса и углубление технологического отставания России. 4. Усиление тенденций протекционизма в условиях финансово-экономического кризиса. 5. Огосударствление экономики и снижение стимулов для предпринимательской деятельности. Для России. [Медведев,2010]: есть венчурные компании, их капитал составляет 2 млрд. долл. Мал спрос на высокотехнологичную продукцию в России. Хочет сделать бизнес соответствующим сложным инновациям. Хочет создать инфраструктуру. Усилить фонд содействия развитию малых форм предприятий. Какие-то налоговые льготы. Надо подумать, как защитить от ошибок: 1) ошибки бывают, не надо за них наказывать, 2) но и не было бы жуликов. Задание правительству – подумать. Есть малые инвестиционные предприятия. Создаются изобретателями. Или в сфере услуг, например, в маркетинговых исследованиях. Они – основа. 1) гибкие, 2) подобраны кадры (свои люди). Наряду с малыми формами организации инновационной деятельности широкое распространение получают: ассоциации и консорциумы; технологические парки (научные, инновационные, экологические, конверсионные, технологические деревни и бизнес — парки); инкубаторы, объединяющие научные, инженерные и экономические коллективы творческих молодых специалистов. В крупных регионах получают развитие научно-производственные комплексы. Вывод: инновации актуальны. Но надо уметь их проводить. И надо проводить. 2. Определения, место и роль проектного управления Начать изложение материала целесообразно с общих определений. Деятельность [Википедия]: процесс (процессы) активного взаимодействия субъекта с миром, во время которого субъект удовлетворяет какие-либо свои потребности. Другие определения [Психологический словарь] Деятельность можно определить как специфический вид активности человека, направленный на познание и творческое преобразование окружающего мира, включая самого себя и условия своего существования. Деятельностью можно назвать любую активность человека, которой он сам придает некоторый смысл (в других источниках – если есть план). Признаки деятельности. [Психологиеский словарь: http://azps.ru/articles/cmmn/indexde.html]: 1. Выполняется субъектом. 2. Будучи связана с потребностью, детерминируется внешним миром, порождается встречей потребности с сопротивлением, препятствием. 3. Имеет мотив. Мотив бывает скрытый. Осознанный мотив это цель. 4. Содержание: изменение мира, производство или порождение определенного объективированного продукта материальной или духовной культуры. 5. Сопротивление, оказываемое средой, предметно. Следовательно, деятельность предметна. 6. Деятельность психологична, сознательна. Предметом психологического изучения является личность в деятельности. Например, анализируя деятельность школьника, учитель делает вывод о его способностях, об особенностях мышления и памяти. 7. Деятельность социальна. Существует социальное сопротивление удовлетворению потребностей в виде норм, правил, запретов и т. д. 8. Виды деятельности: игра, учение, труд. Деятельность экономическая [Экономический словарь] - совокупность действий на разных уровнях хозяйствования, в результате которых люди удовлетворяют свои потребности посредством производства и обмена материальными благами и услугами. Деятельность становится экономической тогда, когда ее цель либо следствие – производство и обмен товарами или услугами, признаваемыми в качестве и полезных или редких. Проект – представление о результате, вместе с представлением о способах его достижения и порядке их расположения во времени. Типовой проект или технология - обобщенное содержание набора проектов [из статьи]. Метод - по степени «очищенности» от конкретики аналогичен математическим объектам и является некоторым алгоритмом, оперирующим понятиями высокой степени общности. Методика - промежуточное звено между методом и технологией. Подход – некоторое основание, полагаемое в начале проектирования деятельности, из которого исходит проектировщик и которое рассчитывает сохранять в ходе осуществления проекта. Например, экономический подход акцентирует внимание на процессах обмена и распределения ресурсов, постулируя при этом рациональность выбора. Принцип задаёт процесс проектирования в направлении от абстрактного к конкретному, «сверху вниз». Таким образом, принцип предъявляет определенные требования к процессу превращения метода в проект. Пример принципа, соблюдение которого часто требует заказчик: «вы все у нас в компании наладьте, как по науке полагается, только вот самую верхушку, пожалуйста, не трогайте». Цель – предписывающее представление о результате некоторой деятельности. Взаимосвязь понятий видна на рис. Рис. 2. Цель – точка, на которую указывают стрелки. Рис. 2. Взаимосвязь основных понятий 2.1. Подходы к осуществлению экономической деятельности 2.1.1. Традиционное (функциональное) управление В управлении выделяют функции, например, планирование и реализация плана. Каждой такой функцией управляют отдельно, при этом главный упор делается на повышение стабильности выполнения каждой отдельной операции. Получается, что связь между функциями лишь механическая, технологическая, а органической, глубокой связи между функциями нет. Управление по традиции показано на рис. Рис. 3. Рис. 3. Традиционный принцип управления 3 говорит: «надо делать». 4 отвечает: «делаем», но не делают. 2 устраивает разнос. Если разнос не дал результата, вмешивается 1. Поэтому в конечном итоге главное для «4» - удовлетворить потребности «2» и «1». Квинтэссенция такого подхода: Проблема возникает лишь тогда, когда о ней узнает начальство. В качестве элемента 4 может быть и работа исполнителей над проектом. Особенности. 1. Традиционное управление по сути стационарное (от лат. stationarius – неподвижный), или статическое, так как существуют задаваемые извне, обычно – с верхних уровней практически постоянные цели, технологии, планы, и задача состоит в минимизации отклонений от них. Это по сути управ регулирование (от лат. regula – норма, правило). 2. Управление получается дискретным (проблема—решение) и линейным (причина—следствие). 3. Управление субъективно, так как главное место занимает личность руководителя. Это и хорошо, и плохо. В ряде случаев личностный фактор позволяет справиться со сложной проблемой, недаром управление войсками строго иерархично. Но чаще случаются, что группа выдающихся людей достигает весьма посредственных результатов. Тем не менее такое управление существует, вполне пригодно для текущего оперативного управления. Конечно, оно требует дополнения другими управленческими подходами. 2.1.2. Процессное управление Процессно-ориентированное управление подчеркивает горизонтальную связь между отдельными работами и операциями. Основной акцент делается на повышение стабильности выполнения процесса в целом. В этом отличие от предыдущего случая, в котором акцент делается на функции. Тут также стараются минимизировать отклонение процесса от ранее заданных показателей. Деятельность по инициации и целеполаганию, планированию и проектированию деятельности остается в стороне. Управление вписывается в бесконечную последовательность замкнутых циклов «команда(указание)— выполнение—контроль». Сущность данного подхода представлена на рис. Рис. 4. Исполнители А и В должны довести процессы до конечного состояния, то есть обеспечить достижение их целей. Рис. 4. Процессное управление 2.1.3. Подход, основанный на сценариях Какова конечная цель развития организаций? Майкрософт? Газпрома? Часто четко определенной конечной цели, которая должны быть достигнута, нет. В этом случае применяют сценарии. Предлагается некоторый вариант действий. Определяется, что получится, если его принять. Для этого делается прогноз нового состояния, которое возникнет после выполнения предложенных действий. Далее определяется, какие действия можно предпринять в спрогнозированной ситуации. Различные варианты действий сравниваются не только по тому, к каким результатам они приводят, но и, главным образом, по тому, какие возможности они открывают. И уже после этого обычно появляется какая-то конкретная цель: освоить производство нового продукта, выйти на новый рынок и т.д. 2.1.4. Проектное управление [Разу] (project – бросать вперед, бросаться, ссылать. Лат.). Существует путаница, внесенная переводчиками в трудные 90-е годы. Project в своём европейском значении означает мероприятия для достижения цели. Проект в русском языке обозначает план, замысел (например, проект бани, рис. Рис. 5). Это слово переводится на европейские языки как дизайн (design). Рис. 5 Проект бани [http://www.vashdomic.ru/catalog/bani/207]. В данном курсе, естественно, употребляется европейское значение слова project. В дальнейшем оно будет обозначаться как проект. Именно та и происходит практически во всех учебниках по управлению проектами Под проектированием будет пониматься разработка планов. Словосочетание управление проектами, вынесенное в название курса, не очень четко отражает объект исследования. Правильнее говорить проектное управление, подчеркивая этим не то, что происходит управление проектами (ими можно управлять, используя и традиционный, и по процессный подходы), а то, что используются специальные методы, разработанные для управления проектами. Многие стремятся планировать и упорядочивать свою деятельность [Архангельский Г. Непрожективный подход к организации деятельности]. Пример метода такого упорядочения – тайм-менеджмент. Это очень сложно, особенно в современных изменяющихся условиях, хотя и может быть эффективно. О системах тайм-менеджмента см. www.improvement.ru. Советский ученый Александр Александрович Любищев (1890 - 1972) создал жесткую систему тайм-менеджмента. Он вел дневник с 1916 по 1972 год, где фиксировал свои занятия с точностью до 10 минут, тратил дни на подсчет затрат времени. За свою жизнь он успел сделать удивительно много. Есть тренинги, где предлагается вести учет времени. Практически никто не приносит результаты анализа затрат своего времени – стыдно. Впрочем, есть люди, вообще не склонные к упорядочению своей деятельности. Военную стратегию и стратегию организации сложно планировать, так как они разрабатываются в ситуации неопределенности и имеют предметом своего интереса объекты, стремящиеся повышать эту неопределенность. Истоки проектного подхода к управлению можно найти в философии Платона. Привычная для европейца последовательность действий: • выстраивать идеальную форму (eidos); • ставить ее перед собой как конкретную цель (telos); • действовать, стараясь осуществить эту цель. Отправной точкой проектного управления является осознание цели проекта [Разу]. Цель проекта, как правило, характеризуется теми или иными элементами новизны. Цель содержит в себе основную идею проекта. Далее цель декомпозируется на осознаваемые и управляемые элементы деятельности, логически и организационно связанные в комплексы работ. Схема проектного управления имеет вид рис. Рис. 6 (рисунки взяты из Яндекс.Карт) Рис. 6. Сущность проектного управления Как видно из рисунка, управление проектом имеет три уровня: уровень целеполагания, уровень проектирования и уровень реализации. На уровне целеполагания находится основная идея — цель проекта. Цель проекта раскрывается, проецируется на поверхность модели — детального плана действий (уровень проектирования). Модель может быть • деревом целей, • структурой работ, • структурой затрат, • структурой продукции (результата) проекта, • информационно-технологической моделью • сочетанием разных типов модели. Проектируются: • основные средства; • ресурсы; • организационная структура проекта; • система коммуникаций между элементами проекта, • взаимодействие с внешней средой и пр. Всестороннюю модель деятельности можно назвать бизнес-проектом. Таким образом, модель проекта это его идеальное воплощение. Затем план проецируется на поверхность предметной области (уровень реализации). Реальность не соответствует идеалу, значит, 1) не точно реализуем, 2) иногда изменяем проект. Для успешной реализации строится реальная модель (модель фактического состояния). Это фактическое состояние документируется, затем сравниваем с идеалом. По результатам сравнения принимается решение. Проектное управление это целенаправленная деятельность, обеспечивающая последовательное представление цели в виде модели, а затем перенос модели на фактическую предметную область. Видно, что работа идет с системами и структурами. Это шаг вперед по сравнению с традиционным и процессным управлением. Но и этот подход имеет свои ограничения. Наиболее ярко ограниченность проектного подхода проявилась в попытке фон Клаузевица создать стройную теорию военного искусства. Войну, как наиболее непредсказуемую деятельность, не удалось осмыслить в терминах целей и проектов. Чтобы объяснить неминуемое расхождение между планом боевых действий и их реальным течением, Клаузевицу пришлось ввести концепцию «трения» (сопротивления обстоятельств при исполнении плана), что потребовало ссылок на искусство стратега, наработанные опытом практические навыки, и т.п., фактически обесценивших все попытки дать рецепты успешного стратегического действия. Фон Клаузевиц был с 1812 – на русской службе, участвовал в Отечественной войне, потом вернулся в Пруссию. Написал книгу о войне. Война – продолжение политики другими средствами. В [http://www.it2b.ru/it2b8.view3.page6.html], отмечается, что идеи фон Клаузевица полезны для маркетинга. Говорится, что лучше читать работы фон Клаузевица, чем неудачное развитие его идей в книге Р. Траута «Маркетинговые войны». Итак, проблема в том, что окружающая реальность «живет и реагирует» по выражению фон Клаузевица. Аристотель для снятия противоречия между теорией и практикой вводит способность наилучшего практического действия, названную им «рассудительностью» (phronesis), но точно определить ее сущность и методы ему не удалось. Точно так же, как не удалось греческой мысли ответить на вопрос о природе «хитрости» (metis), как искусства действия в непредсказуемых обстоятельствах, а также искусства побеждать значительно превосходящие силы противника. Хитрость воспевалась в гомеровской «Одиссее» и других произведениях древних греков, но они не смогли построить теорию хитрости, дать ее рецепты и алгоритмы. Отличия проектного менеджмента от традиционного, функционального по [Шапиро] даны в табл. Таблица 2. Таблица 2 Сравнение функций традиционного (функционального) и проектного менеджмента Функциональный менеджмент Проектный менеджмент Основной упор делается на поддержание status quo; решается устойчивый круг задач в стабильных условиях и ситуациях; полномочия и ответственность определены стабильной структурой управления, строго заданными функциями каждого субъекта управления; успех деятельности в целом определяется достижением промежуточных функциональных результатов. Происходит управление изменениями, деятельность в основном нестандартная (инновационная); круг задач постоянно изменяется, условия работы неопределенны; полномочия субъектов определены нечетко, они несут ответственность за изменения; структуры управления действуют в рамках проектного цикла; успех определяется достижением установленных конечных целей; В [Шапиро] отмечается, что увеличение доли нестандартной (инновационной) деятельности функциональных менеджеров превращает их в менеджеров проектов (проект-менеджеров в книге). С другой стороны, функции менеджмента проектов стали включать такие элементы общего менеджмента, как: • финансовый менеджмент: обеспечение бюджетных и других ограничений; • управление персоналом: определение профессионально-квалификационного состава, определение аппарата управления, мотивация и системы оплаты; • операционный (производственный) менеджмент; • закупки и поставки: определение потребностей, выбор поставщиков, логистика; • технико-технологические аспекты управления: создание нового продукта, инжиниринг, управление качеством; • маркетинг от предынвестиционной фазы до завершения проекта. 2.1.5. Стратегическое управление Подход, противоположный проектному, использовался еще в древнем Китае. «Вместо того, чтобы выстраивать модель как образец для действия, китайский мудрец, скорее, сосредоточивает свое внимание на привычном ходе вещей, стараясь постичь их соразмерность и извлечь пользу из их саморазвития» [Жюльен. Трактат об эффективности]. Подход называется также стратегическим. Стратегема (древнегреч. στρατήγημα — военная хитрость) — хитроумный план, оригинальный путь к достижению военных, гражданских, политических, экономических или личных целей. Ниже приводятся особенности стратегического подхода. Интересно отметить, что аналогичные особенности имеет и теория решения изобретательских задач (ТРИЗ) [о ТРИЗ]. 1. Внимание стратега сосредоточено не столько на том, как изменить ситуацию, сколько на том, как найти свое место в ней. «Рельеф местности обуславливает течение воды, а противник обуславливает победу» [Сунь-цзы, гл. 6, цит. по Жюльену]. В ТРИЗ задача тщательно очищается от всего, что может навязать представления о решении. В частности, убираются все технические термины. Например, вместо «нужно создать якорь, отличающийся тем, что…», говорится: «нужно создать штуковину, которая позволяла бы …». Мышление, не скованное предвзятыми, навязанными представлениями о результате, может легче увидеть новое, оригинальное решение (в случае с якорем таковым может оказаться оказывается металлическая плита-холодильник, прикрепляющаяся к неровностям дна с помощью замораживания воды). 2. Цель стратега находится на высоком уровне абстракции, что позволяет свободно использовать любые неожиданные изменения ситуации для ее достижения. Пример. Конкретная цель «уничтожить войско повстанцев». Более абстрактная цель: «умиротворить южные провинции». Очевидно, эта цель может быть достигнута не только уничтожением войска повстанцев, но и разложением этого войска изнутри, столкновением его с какой-либо третьей силой, и т.п. В ТРИЗ рекомендуется от цели, которую ставит заказчик, переходить к «надцели», и решать изобретательскую задачу, исходя уже из нее. Для этого полезно применять цепочку вопросов «зачем?» до того момента, когда прояснится конечная цель. Например, если поставлена задача «открыть запертую дверь дома», обычное инженерное мышление начинает перебирать ключи и отмычки, а тризовское формулирует надцель «проникнуть в дом» и находит ресурс в виде чердачного окна, или формулирует над-надцель «завладеть вещами, находящимися в доме», и отыскивает решение «обитатели сами выносят вещи, для чего необходимо имитировать пожар» []. 3. «Экономность» стратегического действия. В европейском военном искусстве, в частности у Клаузевица, в качестве одного из самых желанных результатов борьбы мы находим уничтожение врага. Однако Сунь-цзы неоднократно подчеркивает прямо противоположный подход: «тот, кто преуспел в военном деле, подчиняет чужие армии, не вступая в битву, захватывает чужие города, не осаждая их, и разрушает чужие государства без продолжительного сражения… На войне лучше сохранить страну противника без разрушений, разгромить ее – это наихудший поворот событий». Поэтому знаменитый полководец Чжугэ Лян, усмиряя мятеж юго-западных варварских племен под предводительством Мэнхо, несколько раз отпускал его, когда он попадал в плен, несмотря на недовольство своих менее дальновидных сподвижников. Он исходил из надцели «установить мир на южных рубежах царства», а не из цели «уничтожить восставших», и поэтому ему не нужен был уничтоженный Мэнхо, ему нужен был Мэнхо «перевоспитанный», решивший прекратить восстание и заключить мир, что Чжугэ Лян в конечном итоге и получил. Такой же принцип используется и в айкидо: инерция движения противника используется для того, чтобы заставить его потерять равновесие. Противник рассматривается как ресурс для решения стратегической задачи (достижения надцели). В ТРИЗ есть понятие идеальное конечное решение. Если под степенью идеальностью системы понимать отношение всех полезных результатов ее деятельности ко всем факторам «затрат» (система занимает место, загрязняет среду…), то идеальной будет являться та система, для которой знаменатель этой дроби равен нулю, т.е. системы нет, а ее функция выполняется. Если задача об устранении камней с решетки, через которую просеивается песок, решается в разрезе того, какое устройство нужно создать, чтобы убирать камни, то применяющий ТРИЗ решает задачу как сделать, чтобы решетка сама убирала с себя камни и предлагает просто наклонить решетку. Бывает, что для решения используется то, что до сих пор считалось вредным фактором. Пример такого подхода в маркетинге – решение задачи о том, как предотвратить воровство постояльцами красивых пепельниц из гостиниц. Оно заключалось в том, что на пепельницы нанесли символику гостиницы, ее адреса и телефоны, и таким образом уносимые постояльцами пепельницы давали рекламный эффект, гораздо больший их стоимости (рис. Рис. 7.). Рис. 7. Пепельница и коробок спичек с эмблемой гостиницы Здесь виден и переход от цели к надцели, и возникшую благодаря этому возможность получения дополнительной выгоды. 4. Внимание к закономерностям развития ситуации. Китайский стратег исходит из очевидного предположения, что любая река начинается с тонкого ручейка, а любой овраг – с едва заметной трещины. Поэтому искусство стратега – это в первую очередь искусство видеть, чувствовать, улавливать «зародыши», «ростки» будущих событий, правильно предугадывать их далеко идущие последствия, присоединяться к начинающемуся едва заметному движению и использовать его в своих целях. Европейская мысль не прошла мимо концепции случая, наиболее подходящего момента для совершения действия, уловить который должен стратег. У греков «хроносу» как линейному, однородному времени, противопоставлен «кайрос» как благоприятное время, наиболее подходящий момент. Но если греки на этом останавливаются, то китайцы с помощью обращения внимания на ростки, истоки, делают этот «кайрос» не случайным, но обусловленным и ожидаемым, заранее известным стратегу. Отсюда становится понятной настойчиво повторяемая мысль: хороший военачальник выигрывает сражения задолго до их начала, его победа обусловлена заранее. В маркетинге есть концепция управления по слабым сигналам [Мамонтов Р. И. Стратегический менеджмент как элемент системного маркетинга организации. Режим доступа http://www.dltens.ru/impuls2.html; Токарев В. Управление по слабым сигналам. Режим доступа http://www.e-xecutive.ru/community/articles/1268146/], которая, по сути, реализует описываемый принцип. 5. Ищутся не средства для достижения поставленной цели, а условия, которые необходимо создать для появления желаемых следствий (и даже не мешать своей активностью, основанной на незнании). Излюбленный пример китайских авторов: рост растения, для которого были созданы условия (взрыхлена почва и т.п.) и по отношению к которому наилучшим действием является недеяние, ожидание. Другим примером создания условий для достижения цели может служить стратагема «поместить солдат в местность смерти», т.е. поставить их в такие условия, в которых они не могут не проявлять максимально возможный героизм (например, сжечь корабли, на которых они высадились на территорию противника). В проектном управлении ресурсы рассматриваются сквозь призму плана, а при стратегическом – обстоятельства сквозь призму ресурсов. 6. Стратегическое решение «проявляется» сразу и в полном объеме. Поиск стратегического решения можно сравнить с разглядыванием ккартинок на рис. Рис. 8. В каждой из них зашифровано по два изображения. Одно из них можно или не видеть вообще, или увидеть сразу и целиком, но нельзя усматривать постепенно. Так и решение проблемы: «как можно было не заметить его раньше?!» Рис. 8. Примеры картинок с двойным изображением «Никто не возводит памятника хорошему стратегу», поскольку он настолько хорошо использовал ситуацию, что победа кажется легкой. Прямо противоположное мы видим в проектном подходе: попытка подходить к деятельности с позиций «взгляда, устремленного к образцу», сталкиваясь с «трением», сопротивлением обстоятельств, порождает превознесение воли, целеустремленности, героизма. Для достижения цели приходится прилагать значительные усилия, совершать поражающие воображение действия. Итог таков: если проектно мыслящий управленец, сталкиваясь с задачей, задает себе вопрос «как это сделать?», то стратегически мыслящий управленец в той же ситуации спрашивают себя «как сделать так, чтобы можно было этого не делать?». Следовательно, Лень – двигатель прогресса. 2.1.6. Различие проектного и стратегического подходов Задачная ситуация, согласно [Анисимов] – это конкретная ситуация (нижний уровень на рис. Рис. 9), в которой есть некий пробел, требующий заполнения. Например, известно, что в одном автомобиле едет 3 человека, а в другом – четыре. Требуется узнать, сколько всего людей едет в двух автомобилях. Для решения задачи переходят на определенный уровень абстракции (второй уровень рисунка). На этом уровне определяется цель решения задачи. В данном случае это неизвестная величина, которую необходимо определить. Например, для предыдущей задачи требуется решить уравнение Х=3+4. Теперь задача может быть решена, неизвестная величина найдена. а) б) Рис. 9. Уровни решения задачи В другой задачной ситуации необходимо создать отдел маркетинга в некоторой организации. Для этого случая ситуация имеет вид рис. Рис. 9, б. Абстрактный уровень (второй уровень ни рисунке) представляет собой организацию, имеющую отдел маркетинга. Очевидно, что в данном случае не существует четко определенной неизвестной величины или величин. Причина кроется в сложности ситуации, невозможности четко, формально определить, чего именно не хватает организации; что она получит, если будет создан отдел маркетинга. Это – проблемная ситуация [Анисимов]. Проблемная ситуация – это ситуация, в которой имеющиеся абстракции неадекватны конкретике: не существует очевидного «неизвестного», не определено, какое именно состояние является желаемым. Если возможно корректное абстрактное описание ситуации на более высоком уровне абстракции (самом верхнем на рисунке), на котором возможно абстрактное описание ситуации второго уровня, то проблемная ситуация является задачной, но сдвинутой на один уровень абстрактности выше. Если задачной ситуации соответствовала цель, то проблемной ситуации можно поставить в соответствие надцель – описание желаемого состояния, сформулированное на следующем уровне. Например, проблема «тяжелое положение на южных границах» дает надцель «умиротворить южные провинции», которая может воплощаться в очень различные цели уровня А («разбить войско повстанцев», «склонить вождей повстанцев к миру», и т.п.) и, соответственно, давать различные задачи. Следует отметить, что термин «надцель» был заимствован [Анисимов] из теории развития творческой личности, которая рекомендует творческому человеку ставить себе достойную цель жизни, но кроме упорной работы на ее достижение, рассматривать также надцели и переходить к ним по мере появления учеников, включающихся в работу над исходной целью. Итак, решение проблемы распадается на два этапа: превращение проблемы в задачу и далее в решение задачи. Есть попытки создать для решения проблем метатеорию. О.С. Анисимов считает такой метатеорией общую теорию деятельности (системомыследеятельностную методологию), которая позволяет преодолеть ограничения «предметных» дисциплин, создающие проблемы при их применении. В качестве другого примера метатеории можно привести ТРИЗ, благодаря использованию закономерностей второго уровня абстракции (философских: противоречие как двигатель развития; близких к математическим: понятие идеального конечного результата) позволяющей направленно действовать в ситуациях, являющихся для инженерной науки (дисциплины первого уровня абстракции) проблемными. Неадекватность модели первого уровня абстракции модели второго уровня здесь заключается в исчерпании обычных инженерных методов оптимизации системы на каком-то этапе ее развития, в невозможности дальнейшего развития системы с помощью поиска компромиссов между противоречивыми требованиями к ней. Существует и другой способ добиться результата: изменить второй уровень абстракции, например, путем внесения элемента случайности. В качестве примера решения проблем таким способом можно привести пример с мухами и осами, посаженными в открытую бутылку, обращенную дном к свету. «Умные» осы, имеющие на первом уровне абстракции вполне ясную модель решения подобных задач, гласящую: «выход находится там, где свет», но не обладающие способностью выйти на следующий уровень и увидеть очевидную неадекватность этой модели в данной конкретной ситуации, вскоре погибают. «Глупые» мухи, не связанные моделями первого уровня абстракции, совершают хаотические движения в пространстве бутылки и вскоре находят выход. Итак, на втором уровне мы считаем находящейся ту систему, изменение которой должно стать результатом нашей деятельности. Это ситуация в целом, включающая управленца, управляемую им систему, конкурирующие системы, внешние обстоятельства, и т.д. Нижний уровень – это уровень моделей конкретных систем и их состояний. Например, это может быть желаемое состояние организации к концу осуществления проекта: «оборот составляет…, прибыль превышает…», и т.д. Первый уровень абстракции – это уровень моделей более общего характера. Например, нацель этого уровня может выглядеть так: «сделать организацию лидирующей в отрасли». Это не совокупность описаний реальных или желаемых состояний конкретной организации, а совокупность общих представлений о том, какие признаки отличают лидирующую организацию. При достаточно четком описании надцель может порождать цели нижнего уровня. Важно отметить, что надцели и цели находятся не в отношении целое-часть, а в отношении абстрактное-конкретное, т.е. надцель содержит некоторый набор общих требований к конечному состоянию системы, которым могут удовлетворять совершенно различные конечные состояния, и соответственно, различные цели. Более того, цели и надцели не связаны соотношением более точное – менее точное. Формулировка цели в нечетких терминах (довести оборот фирмы до 1-2 млн. долл. в год) не переводит ее в разряд надцелей, поскольку уровень абстрактности сохраняется неизменным. Основываясь на изложенном, можно выявить различие проектного и стратегического подходов. Реализация проектного подхода заключается в следующем. 1. Этап проектирования. 1.1. Анализ исходной системы (ситуации) и построение ее модели первого уровня абстракции. 1.2. Фиксация несоответствия текущего состояния надцели этого уровня. 1.3. Построение на низшем уровне образа желаемого будущего состояния интересующей нас системы (постановка цели). 1.4. Подбор средств (действий и ресурсов), позволяющих перестроить систему на втором уровне абстракции до этого состояния. 1.5. Создание проекта использования этих средств. 2. Этап осуществления. 2.1. Оценка отклонения ожидаемого результата проекта от намеченной цели и действий по устранению этого отклонения. 2.2. Внесение корректив в цель и средства ее достижения при поступлении новой информации. В отличие от этого, реализация стратегического подхода состоит из следующих этапов. 3. Начальный этап. 3.1. Фиксация несоответствия текущего состояния надцели первого уровня абстракции. 3.2. Постановка надцели первого уровня абстракции: общих требований к будущему состоянию системы. 3.3. Поддержание процессов: рассмотрение тенденций развития ситуации на втором уровне абстракции, поиск тех из них, которые должны привести к достижению надцели. 3.4. Создание условий (в реальной действительности, на нижнем уровне!), при которых эти тенденции и возможности, заложенные в системе, могли бы проявиться в полной мере при минимуме нашего активного вмешательства. 4. Этап деятельности. 4.1. Оценка отклонения ожидаемого будущего состояния ситуации от соответствия надцели высшего уровня (!) и устранение факторов, мешающих ситуации самостоятельно приближаться к требованиям надцели. 4.2. Использование изменений ситуации в качестве ресурсов, усиливающих закономерное самостоятельное развитие ситуации в сторону соответствия требованиям надцели. 2.1.7. Взаимосвязь и области применимости подходов Проектный подход наиболее уместен при проектировании деятельности в следующих условиях. • Ситуация начала деятельности является задачной, то есть хорошо описывается моделями уровня А. • Объект деятельности является достаточно стабильным, его изменения в процессе реализации проекта невелики. • Мала вероятность появления непредвиденных обстоятельств любого характера; • Ожидаемый результат аддитивен: может быть достаточно подробно описан; допускает разложение на ряд частных результатов, достижимых по отдельности; допускает постепенное достижение. Стратегический подход наиболее уместен в следующих условиях: • Ситуация начала деятельности является проблемной: затруднений фиксируется только на уровне АА. • Объект деятельности «живет и реагирует», имеет место конкуренция, управленческая борьба, маркетинговая война. • Велика вероятность появления различных непредвиденных обстоятельств; • Ожидаемый результат не аддитивен: не допускает разложения на ряд результатов; не может быть описан на уровне А; достигается качественным скачком (изобретение, научное открытие, победа в войне). Стратегический подход перспективен в следующих областях. • Научное творчество. Открытие нового допускает только работу на уровне АА. Однако в официальной науке планируют круг решаемых исследовательских задач, заранее обозначают тематику исследования, то есть управление наукой далеко от стратегического подхода. • Развитие организации. Обычно определяют структуру организации «как есть», предлагают, как должно быть. Очень желательно появление чего-то принципиально нового. • Стратегия. Развития организации, маркетинговая и т.д. 2.2. Цели и стратегия проекта Выше отмечалось, что деятельность должна быть целенаправленной. Цель жизни для себя [Азимов, семинар]. Цель настоящая, если она остается при трех условиях: 1) если мало осталось жить, 2) если стало вдруг много денег, 3) если есть возможность по щучьему велению удовлетворить все желания. Это есть у единиц процентов. Цель образования – научить работать мозги. В Германии человек, который хочет стать механиком, в течение трех лет четыре дня в неделю работает на производстве, один день учится в спецшколе. Получает 300 евро в месяц. Получив аттестат, он получает 1000 евро. Причем получить работу шанс 1:5. Зачем он недополучил (потратил) 26 тыс евро? Что делать, если ты еще не знаешь, что тебе нравится делать. А идти учится уже надо. В таком случае предлагаются два универсальных образования, которые в любом случае пригодятся при организации своего любимого дела. Первое – экономическое. Ты всегда (почти) сможешь быть в курсе, на сколько кидает тебя твой бухгалтер. Второе – юридическое. Резюме: образование жизненно необходимо для развития мозгов, навыков общения, кругозора, лексикона, связей и т.д. Но одновременно должно являться подспорьем в ТВОЕМ ДЕЛЕ. Пример жизненной цели. Любищев (по Д. Гранину) - Я - кто? Я - дилетант, универсальный дилетант. Слово-то это происходит от итальянского "дилетто", что значит - удовольствие. То есть человек, которому процесс всякой работы доставляет удовольствие. В 1918 году Александр Любищев ушел из армии и занялся чисто научной работой. К этому времени он сформулировал цель своей жизни: создать естественную систему организмов. «Я задался целью со временем написать математическую биологию, в которой были бы соединены все попытки приложения математики к биологии». Любищев в двадцать с лишним лет, начиная свою научную работу, тоже точно знал, чего он хочет. Счастливая и необычная судьба! Он сам сформулировал программу своей работы и предопределил тем самым весь характер своей деятельности фактически до конца дней. А если цель, поставленная Любищевым, недостижима, в принципе недостижима? Если где-то лет через двадцать окажется, что создать такую естественную систему организмов невозможно? Или что современный математический аппарат для этого не годится? Тогда, выходит, все эти годы ушли зазря, цель была ложной, вместо цели - бесцельность. Ну что же, риск? Нет, тут пострашнее, чем риск, тут на карту ставилась будущность, талант, надежды - лучшее, что есть в человеческой жизни. Кто знает, сколько таких мечтателей сгинуло, не одолев несбыточных целей! Цель требует сил, несоизмеримых с нормальными, и времени больше, чем располагает человек в этой жизни, этак лет двести. То есть он, конечно, был уверен, что одолеет, но для этого надо было откуда-то взять добавочные силы и добавочное время. Все его планы, даже самый последний, пятилетний план, составлялись им из предположения, что надо прожить по крайней мере до ста лет. Углубление работы приводило к ее расширению. Надо было всерьез браться за математику. Затем пришла очередь философии. Поздно, но он начинает понимать, что ему не обойтись без истории, без литературы, что зачем-то ему необходима музыка... Увы, он не выполнил намеченного. Под конец жизни он понял, что цели своей не достиг и не достигнет. Пользуясь своей Системой, он мог точно установить, насколько он не дойдет до когда-то поставленной цели. Ему исполнилось семьдесят два года, когда он решил сосредоточить силы на книге "Линии Демокрита и Платона". Он рассчитал, что она займет лет семь-восемь и будет последним его трудом. Как всякий последний труд, он станет главным трудом, в котором предстоит разобрать общебиологические представления. В нем жила уверенность, что то, что он делает, – пригодится. Миссия проекта [Шапиро] – это генеральная цель проекта, четко выраженная причина его существования. Она детализирует статус проекта, обеспечивает ориентиры для определения целей следующих уровней, а также стратегий на различных организационных уровнях. Стратегия проекта – способы действий по получению обозначенных миссией результатов проекта. При разработке стратегии следует учитывать миссию с одной стороны и ситуацию в окружающей среде и возможные сценарии ее развития ее прогноз с другой. Подготовку стратегии проекта можно условно разделить на три последовательных процедуры: 1. Стратегический анализ начинается с анализа внешней и внутренней среды (т. н. SWOT-анализ). 2. Разработка и выбор стратегии осуществляются на трех различных организационных уровнях. 2.1. Корпоративная стратегия (общее направление развития организации: рост, сохранение или сокращение); 2.2. Деловая стратегия (стратегия конкуренции конкретного товара на конкретном рынке: лидерство в издержках; дифференциация; концентрация не определенной группе покупателей, номенклатуре продукта, географическом рынке). Стратегия проекта разрабатывается в рамках деловой стратегии, т. е. отвечает на вопрос, каким образом продукция проекта будет конкурировать на рынке. Очевидно, что выбор стратегии проекта должен существовать в рамках уже выбранного общего направления развития организации. 3. Функциональная стратегия для каждого функционального подразделения конкретизирует выбранную стратегию проекта. Стратегия позволяет определить направления действий и спланировать мероприятия. Реализация намеченных мероприятий приводит к определенному результату. Такова идеальная схема планирования и реализации проекта. 2.3. Окружающая среда и участники проекта Под окружающей средой (окружением) проекта следует понимать совокупность факторов и объектов, непосредственно не принимающих участия в проекте, но влияющих на проект и осуществляющих взаимодействие с проектом и отдельными его элементами. При этом обычно выделяют непосредственное окружение проекта, т.е. факторы и объекты, взаимодействующие с проектом напрямую, и дальнее окружение проекта, т.е. факторы и объекты, взаимодействующие с проектом посредством других факторов и объектов, обычно входящих в непосредственное окружение. Окружающая среда проекта рассматривается как источник рисков проекта; при этом риск может рассматриваться и как опасность, и как возможность опасности, но в любом случае как отклонение от ранее принятых решений. В структуре непосредственного окружения проекта следует выделить поставщиков различного рода продукции, работ и услуг, требующихся в рамках проекта, и потребителей прямых или побочных результатов проекта. Это могут быть подразделения предприятия, в рамках которого реализуется проект. Окружение проекта по [Шапиро] представлено на рис. Рис. 10. Рис. 10. Окружение проекта Участники проекта могут быть как во внешней, так и во внутренней среде (рис. Рис. 11). Рис. 11. Участники проекта (жирными линиями отмечены активные участники, тонкими – пассивные; сплошными – непосредственные, пунктиром – косвенные) Состав и структура участников часто непостоянны. Довольно стабильны лишь роли активных непосредственных участников проекта: • инициатор – носитель основной идеи проекта и инициативы по его реализации. В качестве инициатора может выступать практически любой из будущих участников проекта; • заказчик – участник, заинтересованный в достижении основной цели проекта. Заказчик определяет (точнее, утверждает) основные требования и рамки проекта, обеспечивает финансирование проекта, заключает контракты с другими непосредственными участниками проекта, несет ответственность за результаты проекта перед другими участниками проекта и обществом; • инвестор – участник проекта, осуществляющий финансирование проекта и заинтересованный в достижении финансовых результатов проекта. Инвестор вступает в контрактные отношения с заказчиком, осуществляет расчеты с другими участниками по мере выполнения проекта; • руководитель проекта (проект-менеджер) – участник проекта, которому делегированы полномочия по управлению деятельностью, направленной на достижение целей проекта. Руководитель проекта несет ответственность перед заказчиком за достижение всех целей проекта. В отдельных крупных и сложных проектах за выполнение обязанностей руководителя проекта отвечает специально приглашенная управляющая фирма, но в любом случае в качестве полноправного руководителя проекта выступает один человек. • команда проекта – совокупность действующих как единое целое участников проекта, которая обеспечивает под руководством проект-менеджера достижение целей проекта. Состав и обязанности команды проекта зависят от масштабов, сложности и других характеристик проекта, однако во всех случаях состав команды должен обеспечить высокий профессиональный уровень выполнения всех возложенных на команду обязанностей. Команда формируется в зависимости от потребностей проекта, опыта и квалификации персонала, а также от особенностей организации работы в проекте. Менее важные и не всегда имеющиеся участники: • контрактор – участник проекта, берущий на себя обязательства по выполнению отдельных работ по проекту. Контрактор может выступать как подрядчик (исполнитель работ), поставщик продукции, основных средств, ресурсов или консультант. Контрактор может также отвечать за выполнение всех работ по проекту. В этом случае он будет называться генеральным контрактором (или генеральным подрядчиком).; • субконтрактор – участник проекта, берущий на себя обязательства перед контрактором за выполнение отдельных работ по проекту. Субконтрактор (субподрядчик) выступает как косвенный участник проекта и с проектом взаимодействует не напрямую, а через контрактора, с которым у него заключены договорные обязательства.; • потребитель продукции проекта — юридическое или физическое лицо, являющееся покупателем или пользователем результатов проекта. Потребитель может быть конечным, который использует результаты проекта самостоятельно, или промежуточным., который, являясь покупателем результатов проекта, осуществляет их дальнейшую передачу другим потребителям, выступая при этом посредником.. Прочие участники: органы государственной и местной власти; общественные группы и население, чьи интересы затрагиваются в ходе реализации проекта; спонсоры; консалтинговые, инжиниринговые и юридические организации, вовлеченные в процесс реализации проекта. 2.4. Жизненный цикл проекта Жизненный цикл проекта делится на две основные стадии: разработка и реализация. Эти стадии могут идти до некоторой степени параллельно. Особенности стадий видны на рис. Рис. 12. Рис. 12. Особенности различных фаз проекта На основе общей двухстадийной структуры проектного цикла разрабатываются более детальные модели, соответствующие тем или иным типам проектов. В качестве примеров можно привести модели жизненного цикла инвестиционного проекта (рис.Рис. 13), проекта создания нового лекарственного препарата (рис. Рис. 14), проекта создания нового образца военной техники (рис. Рис. 15), проекта разработки и внедрения нового программного обеспечения (рис. Рис. 16). Рис. 13. Жизненный цикл инвестиционного проекта Рис. 14 Разработка лекарства Рис. 15. Жизненный цикл разработки военной техники Рис. 16. Жизненный цикл разработки программного обеспечения В книге [Шапиро] предлагается рассматривать типовой жизненный цикл проекта вида рис. Рис. 17. Рис. 17. Фазы жизненного цикла проекта по Шапиро Ещё один вариант выделения фаз жизненного цикла основан на модифицированной соответственно особенностям проектного управления последовательности стадий менеджмента: предпроектная стадия; планирование; моделирование; реализация; регулирование; корректировка; завершение. Свои особенности имеет разбиение на фазы жизненного цикла для строительных проектов (табл. Таблица 3). Таблица 3 Содержание фаз жизненного цикла строительных проектов Начальная (предынвестиционная) Инвестиционная (строительная) Эксплуатационная Предынвестиционные исследования Разработка проектно-сметной документации, планирование проекта и подготовка к строительству Проведение торгов и заключение контрактов; организация закупок и поставок, подготовительные работы Строительно-монтажные работы Завершение строительной фазы проекта 1. Изучение прогнозов и направлений развития страны (региона, города) 2. Формирование инвестиционного замысла 3. Подготовка ходатайства (Декларации) о намерениях 4. Предварительное согласование инвестиционного замысла 5. Составление и регистрация оферт 6. Разработка обоснования инвестиций, оценка жизнеспособности проекта 7. Выбор и предварительное согласование места размещения объекта 8. Экологическое обоснование 9. Экспертиза 10. Предварительное инвестиционное решение 11. Разработка предварительного плана проекта 1. Разработка плана проектно-изыскательских работ 2. Задание на разработку ТЭО (проекта) строительства и разработка 3. Согласование, экспертиза и утверждение ТЭО (проекта) строительства 4. Выдача задания на проектирование 5. Разработка, согласование и утверждение рабочей документации 6. Принятие окончательного решения об инвестировании 7. Отвод земли под строительство 8. Разрешение на строительство 9. Задание на разработку проекта производства работ 10. Разработка плана проекта 1. Тендеры на проектно-изыскательские работы и заключение контрактов 2. Тендеры на поставку оборудования и заключение контрактов 3. Тендеры на подрядные работы и заключение контрактов 4. Тендеры на услуги консультантов и заключение контрактов 5. Разработка планов (графиков) поставки ресурсов 6. Подготовительные работы к строительству 1. Разработка оперативного плана строительства 2. Разработка графиков работы машин 3. Выполнение строительно-монтажных работ 4. Мониторинг и контроль 5. Корректировка плана проекта и оперативного плана строительства (управление изменениями) 6. Оплата выполненных работ и поставок 1. Пуско-наладочные работы 2. Сдача-приёмка объекта 3. Закрытие контракта 4. Демобилизация ресурсов 5. Анализ результатов 1. Эксплуатация 2. Ремонт 3. Развитие производства 4. Закрытие проекта • вывод из эксплуатации • демонтаж оборудования • модернизация (начало нового проекта) 2.5. Деятельность по управлению проектом Деятельность по управлению проектом может быть управленческой и обеспечивающей. 1. Управленческая деятельность – деятельность руководителей высшего уровня организационной структуры; в свою очередь, включает пять видов деятельности, обладающих относительной самостоятельностью, но взаимосвязанных между собой: • планирование – определение оптимального результата при заданных ограничениях времени и ресурсов; • организация – определение путей, методов и средств достижения поставленной цели; • координация – установление слаженных, сбалансированных, гармоничных отношений между участниками в процессе совместного труда; • активизация – создание стимулирующих условий труда, при которых каждый работник трудится с полной отдачей; • контроль – своевременное устранение отклонений от заданного плана и их предупреждение в будущем. 2. Обеспечивающая деятельность – деятельность сотрудников среднего и нижнего уровня организационной структуры (как руководителей, так и исполнителей), которая включает: • согласование, визирование; • исполнение работы; • предоставление информации; • подготовку предложений. Особый вид деятельности, встречающейся при управлении проектами – принятие управленческих решений. Управленческое решение – это основанный на знании объективных законов и опыте, ведущий к практическим результатам творческий акт целенаправленного воздействия субъекта управления на объект. В рамках управления проектом принятие решений – не только выбор, но и создание альтернатив, и подготовка решения, и организация выполнения решения. 2.6. Объекты управления в проекте Можно выделить четыре базовых элемента управления практически любым проектом. 1. Работы – это трудовые процессы, направленные на достижение результатов и требующие необходимых затрат времени и ресурсов. К работам относится, в частности, деятельность • по созданию материальных объектов (производственные работы), • по созданию интеллектуально-информационной продукции (научно-исследовательские работы), • по выработке и передаче управляющих воздействий и обратной связи (решения и отчёты), • по перемещению материальных объектов, например ресурсов (поставки). 2. Ресурсы – это совокупность объектов, необходимых для выполнения работ. Существуют три основные группы ресурсов, используемых в управлении проектом: 2.1. Человеческие ресурсы – субъекты деятельности, объединённые в системы и взаимодействующие друг с другом и с другими ресурсами. Эти ресурсы включают руководителей и работников. По отношению друг к другу человеческие ресурсы могут являться и объектами деятельности. Человеческие ресурсы переносят свою стоимость на результаты труда постепенно, создавая при этом добавленную стоимость. 2.2. Материальные ресурсы – средства и предметы деятельности, используемые для выполнения работ. 2.2.1 Средства деятельности переносят свою стоимость на результаты в ходе выполнения работ постепенно. 2.2.1.1 Активные: машины и механизмы. 2.2.1.2 Пассивные: здания и сооружения. 2.2.2 Предметы деятельности: материалы и комплектующие изделия. Они полностью переносят свою стоимость на результаты работ, обычно изменяют свою натуральную форму и материально присутствуют в результатах работ. 2.3. Информационные ресурсы – данные, собираемые об объектах деятельности, о внешней среде, а также управляющие воздействия, направляемые от субъектов деятельности к объектам, определяющие цели и результаты работ. Информационные ресурсы выступают одновременно и как средства, и как предметы управленческой деятельности. К информационным ресурсам относятся проектные решения, модели, управляющие команды (приказы, распоряжения, задания), отчётную документацию и пр. 3. Результаты — это продукты деятельности (работ), воплощающие в себе ранее поставленные цели. Результаты могут быть: материальными (продукция) и нематериальными (документы; социальный эффект проекта); прямые и косвенные; промежуточные и окончательные. В качестве результата, в зависимости от типа и цели проекта, могут выступать: • новый продукт; • новый технологический процесс, • строительный объект, • программное средство, • научная разработка, • реализованная учебная программа, • реструктурированная компания, • сертифицированная система качества и т. д. Об успешности проекта (результата) судят по тому, насколько он (результат) соответствует по своим затратным/доходным, инновационным, качественным, временным, социальным, экологическим и другим характеристикам запланированному уровню. 4. Риски. Потенциальные последствия возмущений со стороны внешней среды. Необходимо изучить возможные варианты взаимодействия проекта и факторов (=причин) риска с целью минимизировать отклонения реального хода выполнения проекта от ранее принятых решений. Все четыре базовых элемента управления проектом находятся во взаимодействии друг с другом (каждый с каждым). Так, ресурсы используются при выполнении работ; в ходе выполнения работ создаются результаты; риски воздействуют на ресурсы, на работы, на результаты и т. д. Сам проект, в свою очередь, воздействует на окружающую среду и на риски. В проекте выделяются следующие объекты управления. 5. Цели проекта. Должна быть сформирована система целей и обеспечена их реализация. Основной метод – дерево целей. Затрагиваются все базовые элементы проекта. 6. Продолжительность проекта. Должны быть обеспечены заданные сроки достижения целей, для чего требуется выполнить набор взаимосвязанных работ. Основные методы на стадии разработки проекта: декомпозиция работ, сетевой график, расписание. На стадии реализации сроки контролируются, для чего строятся фактические графики выполнения работ. При необходимости вырабатываются корректирующие и предупреждающие мероприятия. Сетевой моделью комплекса работ называется ориентированный граф, используемый для описания зависимостей между работами и этапами проекта. Существует большое количество различных типов сетевых моделей, к наиболее распространённым из них можно отнести: • сетевые графики метода критического пути; • сетевые модели методов PERT, COST, PERT/COST; • сетевые матрицы. Хотя акцент делается на работах, затрагиваются и остальные базовые элементы: ресурсы, так как начало работ означает начало использование ресурсов; результаты, так как окончание работ означает создание результата; риски, так как воздействие факторов окружающей среды сказывается на продолжительности проекта. 7. Стоимость проекта. Требуется определить определённый финансовый результат и достичь его. Финансовый результат может заключаться: • в соблюдении установленного уровня расходов, отраженного в бюджете проекта; • достижении запланированных значений результирующих финансовых показателей проекта: ◦ чистого дисконтированного дохода; ◦ внутренней нормы рентабельности (индекса доходности). ◦ периода окупаемости. Для этого осуществляется планирование, учёт и контроль расходов и доходов с учётом требуемых результатов и рисков. Финансовый план включает три документа. План прибылей и убытков. Обычно его основу составляет обычный отчёт о прибылях и убытках. Этот план отражает операционную деятельность фирмы в намеченный период с точки зрения прибыльности. План-баланс демонстрирует финансовое состояние организации на конец рассчитываемого периода времени. Из его анализа можно сделать выводы о росте активов и об устойчивости финансового положения организации. Обычная форма представления – бухгалтерский баланс. План движения денежных средств характеризует формирование, отток и остатки денежных средств организации в динамике. Это наиболее важный финансовый прогноз для проекта. Обычная форма представления – отчёт о движении денежных средств. Важно! Итоговая цифра отчёта о потоке денежных средств отражает сальдо оборота денежных средств компании, а не её прибыль. В отчёт о денежных средствах не включается амортизация. Хотя это и расход, но она не представляет собой денежное обязательство. В то же время погашение основной суммы долга, хотя и не является расходом, включается в отчёт о денежных потоках, так как является денежным обязательством. Другие траты денег, направленные на приобретение оборудования или выплату дивидендов, не являются затратами, но влияют на денежные потоки. (Разобраться, что такое затраты, издержки, расходы и денежные обязательства, привести форму отчёта о движении денежных средств). В завершающей части финансового плана обычно присутствует анализ безубыточности, демонстрирующий, каким должен быть объем продаж для того, чтобы компания была в состоянии без посторонней помощи своевременно выполнять свои денежные обязательства и не имела убытков. На основе финансового плана проводится анализ финансовых ресурсов фирмы и выбирается схема финансирования инвестиционных проектов; акционирование, получение кредитов, лизинг. Бюджет проекта – структура, состав и значения статей расходов, необходимых для реализации проекта. Иногда включает и статьи доходов. Обычно разбивка расходов производится по этапам реализации проекта. Смета – документ, отражающий бюджет. Используется в строительных и некоторых других проектах Оценка стоимости проекта на протяжении его жизненного цикла имеет различную точность. Так, на начальных этапах стадии разработки стоимость оценивается с погрешностью порядка 50%. К концу стадии разработки погрешность в оценке стоимости снижается и составляет не более 5%. В ходе выполнения проекта плановая стоимость превращается в фактическую, отражающую реальное состояние дел. В качестве объектов — источников стоимости проекта выступают ресурсы. При этом некоторые ресурсы (такие, как материалы) создают (переносят) стоимость по мере их закупки и поставки, другие (такие, как основные средства и персонал) по мере участия в выполнении работ создают новую стоимость, зависящую от стоимости ресурсов и продолжительности работ. Стоимость результата проекта складывается из перенесенной и вновь созданной стоимости используемых ресурсов. В ходе приобретения ресурсов и выполнения работ происходит использование финансовых средств, при этом осуществляется контроль соблюдения бюджетных ограничений. Затем за счет реализации (продажи) результатов проекта потребителям появляются новые финансовые средства. 8. Качество проекта. Самое общее определение качества, согласно ГОСТ: соответствие результатов проекта выявленным потребностям и ожиданиям рынка. Потребности обычно сводятся к следующим группам: • требования к эксплуатационным характеристикам; • функциональные требования; • требования к надёжности (надёжность характеризуется множеством показателей, таких как готовность к использованию, безотказность, ремонтопригодность и т.д.); • требования безопасности; • экологические требования; • экономические требования; • эстетическим требования; • культурно-исторические требования. Качество проекта имеет следующие аспекты: • качество собственно результата, например, качество нового продукта; этот аспект рассматривается при изучении управления продуктом, важно лишь отметить, что важен контроль получаемого результата проекта; • качество разработки: проектная документация соответствует потребностям рынка и технологии производства; будет рассмотрен подробнее в данном курсе, так как это относится собственно к управлению проектом; • качество выполнения работ: соответствие работ плану и проектной документации; также будет рассмотрено подробнее; • качество ресурсного обеспечения: соответствие показателей качества ресурсов заданным проектным решениям; этот аспект обеспечивается поиском и отбором поставщиков, контролем поступающих ресурсов. 9. Персонал проекта. Необходимо обеспечить проект необходимыми человеческими ресурсами и эффективно их использовать. Человеческие ресурсы – это особый, пожалуй, наиболее важный и сложный в управлении вид ресурса. На стадии разработки проекта определяется потребность в персонале, проводится организационное проектирование: разрабатывается организационная структура, составляется штатное расписание. На стадии реализации осуществляется подбор кадров, адаптация и обучение персонала, распределение и контроль выполнения работ, мотивация и развитие работников. Команда проекта – это коллектив единомышленников, действующих как единое целое. Управление на ограничивается формальной выдачей заданий и контролем исполнения. В частности, практически всегда в команде возникают конфликты. Они играют не только отрицательную роль, но и представляют собой возможность развития. 10. Материально-техническое обеспечение проекта. Требуется обеспечить проект материальными ресурсами. Производится управление закупками, поставками, запасами, комплектацией. На стадии разработки определяется потребность в ресурсах, для чего строится дерево ресурсов; разрабатываются спецификации (перечень состава продукции); формулируются технические требования к материальным ресурсам; разрабатывается график поставок. На стадии реализации проводятся: поиск поставщиков; управление контрактами и договорами. Комплектация – обеспечение комплектности поставок. 11. Коммуникации проекта. Необходимо обеспечить сбор, обработку и своевременное предоставление информации участникам проекта. Таким образом, затрагиваются информационные ресурсы. На стадии разработки проекта определяются информационные потребности участников проекта, проектируется структура документации (дерево документации) и баз данных, а также создаётся проект информационной системы, включающей схемы аппаратной и программной составляющих. На стадиях разработки и реализации производится выработка решений, закрепляемых в документах, накопление учётных данных, подготовка и передача по назначению отчётов о промежуточных и окончательных результатах работ. 12. Риски проекта. Требуется минимизировать отклонения проекта от ранее поставленных целей. Риск – это возможность наступления события, воздействующего на проект и приводящего к отклонениям от ранее поставленных целей и принятых решений. Риски возникают на границе проекта с внешней средой. Факторы риска всегда располагаются за рамками проекта, даже если само негативное событие проявляется внутри проекта. На стадии разработки проводится выявление факторов риска, их анализ и количественная оценка, а затем построение моделей: дерева рисков и дерева решений. Затем планируются мероприятия по снижению рисков и их последствий. На стадии реализации имеется особенность: событие риска может не наступить. Поэтому реализация некоторых мероприятий может и не понадобиться. С другой стороны, ввиду изменений в ситуации, приходится продолжать работы стадии разработки. 3. История и перспективы проектного управления Элементы проектного управления уходят своими корнями в далёкое прошлое. 1. Древняя Месопотамия. Считается, что 4…5 тыс. лет назад произошла первая управленческая революция, результатом которой стало изобретение письменности для передачи информации. Деловые отношения развивались настолько бурно, что управленческому слою – жрецам – пришлось выработать способы эффективной реализации многих управленческих функций: ведения деловой документации, бухгалтерского учёта, снабжения, контроля, планирования и пр. Активно развивалась и наука, и практика управления. Многие древние записи были сделаны об имуществе. Интересный тезис: многие памятники прошлого отображают управление. Например, печать для документов. Отсюда мысль: культура есть продукт управленческой деятельности. Ещё один интересный, но спорный тезис. В Шумере как центре древнего управления главная роль принадлежала не науке и искусству, а магии. Во многих культурах есть связь магии и управления. Можно увидеть некоторые схожие черты между современным проектным управлением и магическим управлением древности. Принцип магии: подобное управляется подобным. Создаем модель и воздействуем на нее. Ожидаем, что воздействие сработает и в реальности. Впоследствии моделирование стало одной из основ науки. 2. Древний Египет. 2.1. Имелся большой опыт централизованного управления. 2.2. Были созданы первые университеты управления, в которых готовили менеджеров того времени – «дома учения писанию». 2.3. Есть образцы успешной реализации крупнейших и сложнейших проектов. 2.3.1 Монументально-строительного характера: великие египетские пирамиды. 2.3.2 Общехозяйственного характера: система ирригации. 2.3.3 Общественно-политического характера: религиозные реформы Эхнатона. 2.4. При реализации сложных комплексных мероприятий египтяне много внимания уделяли их тщательной предварительной проработке, созданию проектов и моделей предстоящей деятельности. 3. Древний Вавилон. Законы Хаммурапи принесли заметную пользу для управления работами. 4. Древняя Греция. Здесь наблюдаются проявления двойственности: тирания и демократия; геометрия Евклида и магические тайны чисел Пифагора. Развитию проектного управления способствовали войны. Это было временное объединение разнородных сил, например, для войны с персами. 5. Древний Рим. Происходило движение к централизации. Императора Диоклетиана (фото с сайта http://www.militaryphotos.net/forums/showthread.php?177957-On-this-day-in-Military-History/page26) называют великим управленцем за то, что он создал бюрократическую систему. Чиновники назначались на государственные должности на срок не более года. Главным в новой системе стала структура, мало зависящая от конкретных исполнителей. В Риме осуществлялись большие проекты, такие как термы Каракаллы (фото с сайта http://www.iskusstvu.ru/electronnoe_uchebnoe_posobie/3_2_2_Iskusstvo_Rimskoj_imperii.html). Септи́мий Бассиа́н Карака́лла (лат. Septimius Bassianus Caracalla; 4 апреля 188 — 8 апреля 217) – римский император из династии Северов. Правил с 211 по 217 гг. н. э. Официальное имя: Император Цезарь Марк Аврелий Север Антонин Август. Прозвище Каракалла, или Каракалл (Caracallus), взято от введённой им галльской одежды – длинного халата, ниспадавшего до щиколоток. Термы строились 5 лет, общая их площадь составила 11 га. Ещё один пример проекта. Недавно в Палестине нашли акведук длиной 170 км. Туннели 1, 11 и 94 км (!). Акведук подавал от 300 до 700 л воды в секунду. Но этого было мало для Римлян. Они тратили 500 л на человека (в Европе сейчас – 125). Строительство началось в 90-м году до н.э., велось легионерами и длилось 120 лет. Было вынуто 600 тыс. куб. м камней (четверть пирамиды Хеопса). Высота туннеля 2,5 м, ширина 1,5. Работать могли 4 человека, которые продвигались в день на 10 см. Чтобы ускорить работы, разметили и сделали 300 шахт на расстоянии от 20 до 200 м друг от друга. Они шли под углом 50%. Удивительно, что шахты точно выходят на абсолютно прямую литию туннеля, хотя туннель проложен по гористой местности! На протяжении 60 км туннель снижается ровно (!) на 30 см за 1 км. Инструменты, о которых мы знаем, в том числе самые современные, не могут обеспечить такой точности работ. 6. Средние века, Европа. Осуществлялись большие строительные проекты под управлением Церкви. 7. Возрождение. Произошла децентрализация управления проектами. 8. Новое время. Наряду с укреплением абсолютизма, происходило и развитие промышленных предприятий. Развивалась механизация. 9. Новейшее время. 9.1. Начало этого периода ознаменовалось централизацией управления организациями. Организации практически полностью зависели от руководителя. Теоретиками этого периода были Тейлор, Вебер. Системный подход в начале 20-го века развивали Богданов, Кендалл. 9.2. В 1930-е годы произошла революция в менеджменте. Организацией стали руководить не собственники, а менеджеры. Повысилась роль держателей акций в управлении организациями. 9.3. В 1950-е годы наметился менеджмент-бум. В это же время стала распространяться мысль, что надо не только произвести продукт, но и продать его. Деятельность организаций обратилась вовне. Начинается период развития маркетинга, стратегического управления, управления сбытом и ослабления вертикали управления. Появляются первые горизонтально-ориентированные формы организации деятельности. Во многих отраслях экономики в разных странах начинают применять матричные и проектные организационные структуры. И именно в это время зарождается теория и практика управления, которые в дальнейшем приведут к формированию методологии управления проектом. Таким образом, проектное управление зародилось потому, что возникла потребность в горизонтальной организации труда, позволяющей учитывать сложную динамику внешней среды и обеспечивать полноценную мотивацию работников, занятых не в прежнем материальном производстве, а в современной сфере услуг и экономике знаний. В области продвижения товаров на первый план выходит не материальная основа товара, а его имидж, образ, символ, остающийся в сознании потребителя. Базовые инструменты проектного управления, такие как метод критического пути, были изобретены в конце 1950-х годов. В 1970-м году стали учить сетевому планированию. Создаются системы управления предприятием на базе системного подхода к управлению проектами и программами. Применяются методы теории игр, методы дерева решений и другие средства анализа решений в условиях неопределённости и риска. Реализуются крупномасштабные проекты, например, создание атомных электростанций. Активизировались защитники окружающей среды, в связи с чем возникла необходимость изучать окружение проектов и учитывать внешние факторы: экономические, экологические, общественные и др. Развиваются методы управления конфликтами, разрабатываются оргструктуры управления проектами. Начиная с 1980-х, управление проектами стало сферой профессиональной деятельности, а с 1990-х для управления проектами разного масштаба стали широко применять компьютеры. 10. Конец 20 – начало 21 века. Происходит уход от серийного производства. Так, современное самолётостроение – это, скорее, процессное производство. Вот характерные черты современной экономики, обусловившие развитие проектного управления. Товары. Каждый товар должен быть в чем-то уникален и должен формировать имидж организации. Разработка происходит в условиях жёстких ограничений во времени, обусловленных конкуренцией. Развивается моделирование, без него немыслимы новые модели компьютера, телефона, автомобиля. Это приводит к тому, что товар всё более становится товаром-проектом. Надо управлять его жизненным циклом. Горизонтальная интеграция. Метод Just in Time это, по сути, единство поставщика и заказчика в едином планировании [Разу]. Политика. В эпоху борьбы идеологий считалось, что при социализме развитие идёт не так, как при капитализме. Но последние исследования типа «Почему Россия не Америка?» показали, что значимость явной идеологической составляющей в государственном управлении низка. Низка и материальная, природная обусловленность развития региона. Оказалось, что «экономические чудеса» различного характера, как российско-негативного, так и японско-позитивного, обусловлены применением современного менеджмента, в том числе и проектного, в управлении государством. Стало понятно, что современное государственное управление должно представлять собой управление совокупностью программ и проектов. Наука. С одной стороны, научно обосновывается необходимость применения проектного подхода. С другой – развиваются научные основы проектного управления. Искусство тоже становится проектным. Для демонстрации этого достаточно посмотреть список участников производства фильма. Итак, сегодня в мире развивается проектно-ориентированное мышление и проектно-ориентированное общество. В России масштабное управление проектами началось с индустриализации, в 1930-х годах. Днепрогэс, Московское метро – примеры больших проектов того времени. Получила развитие теория и практика поточного производства, например, во многих городах в 1930-годы проводилось поточное строительство домов. Были и другие проекты: космические; строительство БАМ; развитие индустриально-аграрной зоны Курской Магнитной Аномалии. В настоящее время богатый отечественный опыт теряется, хотя в нем есть много полезного. Перспективы. Проектно-ориентированное управление ожидают большие перспективы. Во многих странах созданы и развиваются научно-практические структуры, развивающие это направление. Например, в Финляндии в г. Турку создан институт PBI (Project-Based Industries). 4. Классификации проектов [Разу] Есть классификация животных, найденная X. Борхесом в китайском манускрипте и цитируемая М. Фуко в «Словах и вещах». В этой классификации животные «подразделяются на: а) принадлежащих Императору, б) бальзамированных, в) прирученных, г) молочных поросят, д) сирен, е) сказочных, ж) бродячих собак, з) включенных в настоящую классификацию, и) буйствующих, как в безумии, к) неисчислимых, л) нарисованных очень тонкой кисточкой из верблюжьей шерсти, м) и прочих, н) только что разбивших кувшин, о) издалека кажущихся мухами». Существует целый рад классификаций проектов. Классификация, предложенная [Шапиро], дана в табл. Таблица 4. Она приводится для ознакомления с областью, где распространено проектное управление. Таблица 4 Классификация проектов по различным признакам Классификационные признаки Типы проектов По масштабу (размеру проекта) Малый Средний Мегапроект По сложности Простой Организационно сложный Технически сложный Ресурсно сложный Комплексно сложный По срокам реализации Краткосрочный Среднесрочный Мегапроект По требованиям к качеству и способам его обеспечения Бездефектный (АЭС) Модульный Стандартный По требованиям к ограниченности ресурсов совокупности проектов Монопроект Мультипроект По характеру проекта/ уровню участников Международный (совместный) Отечественный: государственный; территориальный; местный По характеру целевой задачи проекта Антикризисный Реформирование/ реструктуризация Маркетинговый Инновационный Образовательный Чрезвычайный По объекту инвестиционной деятельности Финансовый Реальный Инвестиционный Инвестиционный По главной причине возникновения Открывшиеся возможности Чрезвычайная ситуация Необходимость структурно- функциональных преобразований Реорганизация Реструктуризация Реинжиниринг Практическую пользу представляет также классификация проекта по отрасли, так как имеются заметные отраслевые особенности проектов. 1. Строительный проект или проект по созданию крупного оборудования (например, трансатлантического лайнера). 2. Инвестиционно-инновационный. Это внедрение изобретений, таких как сверхлёгкий самолёт весом 32 кг; автомобиль-самолёт, система контроля влажности цветочных горшков с мобильным оповещением и т.д. 3. Разработка информационных систем, например, базы данных. Такие проекты ориентированы «внутрь» организации. 4. Веб-проекты. В отличие от предыдущего типа, ориентированы «наружу». 5. Маркетинговый проект, например. проведение рекламной или пиар-кампании. 6. Проект организационных изменений, от нового отдела до объединения ряда организаций в одну; внедрение информационной системы в организации. 7. Научный проект. Проведение научно-исследовательских работ. Приводимую классификацию можно расширить. Ещё одна полезная классификация, предложенная в [Разу] - классификация по цели и содержанию (рис. Рис. 18). Рис. 18. Классификация проектов по Разу. Терминальный (конечный) проект – проект, имеющий конечную цель и чётко ограниченный жизненный цикл от момента, когда проекта ещё до момента, когда проекта уже нет. Это наиболее распространённый тип проектов, часто описываемый в литературе. Примеры проектов такого типа: внедрение новой модели «Жигулей», строительство дома подрядной организацией. Строго говоря, когда новый дом принят комиссией, и строители привели в порядок окружающую территорию и уехали, «жизнь» дома не заканчивается, так что «обрубание» проекта бывает довольно искусственным. Сейчас распространяется т.н. девелопмент – система управления инвестиционной деятельностью по повышению доходности недвижимости. В проект девелопмента включается разработка проектной документации на дом, строительство, реализация квартир и эксплуатация дома. Так что «чисто» терминальных проектов не так уж много. Развивающийся проект – проект, на момент инициации не имеющий конечных целей, достижение которых означало бы завершение проекта. Конечные (терминальные) цели в развивающихся проектах обязательно появляются, но момент их появления определяется многими факторами. Примером развивающегося проекта может служить разработка программного обеспечения. У такой разработки есть начало. Есть стадии проектирования и реализации проекта. Но все программы содержат большее или меньшее количество ошибок. Готовая программа проходит стадию сопровождения – выявления и устранения ошибок в начале эксплуатации. Появляются патчи, сервис-паки. Одновременно проводится сбор и анализ замечаний и рекламаций для создания новой версии. Новая версия программы служит продолжением проекта. Вряд ли можно определить, когда кончится проект создания операционной системы Windows, пакета Microsoft Office и других полезных программ. Одна из версий программы Download Master имеет номер 5.7.2.1217. Этот номер отражает иерархию изменений. Какова будет следующая модификация, неизвестно. Зачастую аналогично развивается и другая продукция: новые модели автомобилей, бытовой техники, мобильных телефонов. Интернет-портал организации – тоже проект данного типа, он развивается вместе с организацией. В проектах данного типа особое значение имеют управление содержанием и управление структурой продукции (управление конфигурацией). Для этого есть специальные методы, должности и программное обеспечение. Причем это не просто линейное развитие, и даже не ветвящееся, так как со временем могут появиться новые функциональные области. Для открытых проектов конечной цели не существует в принципе. Пример такого проекта: проект развития региона. Со временем меняются внешние условия, внутреннее состояние. Меняются и целевые показатели, как в силу саморазвития, так и внешних факторов. Поэтому эти целевые показатели не могут стать конечными целями даже в самом долгосрочном плане. Для подобных проектов постоянно ведутся работы по пересмотру целей. Это называется скользящим планированием. Обычно используют несколько временных горизонтов планирования, например, составляют годовой и месячный планы. Краткосрочные планы имеют четкие цели. Существует программа развития России до 2020 года. Больше половины организаций перед кризисом 2008 года имели трёхлетние планы, многие переходили на пятилетние. Но после кризиса пришлось вернуться к более краткосрочному планированию. Хорошая аналогия проектов данного типа – движение в темноте с прожектором (любопытно, что проектор и прожектор – сходные слова!). Прожектор освещает определённый участок пути. По мере движения высвечиваются новые участки. Мультипроекты представляют собой несколько проектов, выполняемых одновременно. Это делается для повышения эффективности использования ресурсов, получения синергетического эффекта и других целей. Типичный пример – работы, выполняемые строительной организацией. Одновременная работа над несколькими объектами позволяет устранить простои машин и оборудования, гибко перераспределять работников между объектами. Важно, что такие проекты – не просто интеграция сетевых графиков. У них есть общая цель, которая не изменяется или слабо изменяется по мере завершения частных проектов. Из примера видно, что такие проекты характерны для организаций, ведущих проектно-ориентированную деятельность. Исходя из изучения всего многообразия проектов в [Разу] проводится мысль, что изучать надо не управление отдельно взятыми проектами, а проектное управление как принцип. 5. Методоллогии управления проектами 5.1. Методология PERT Основана на предположении о неограниченности ресурсов, критичен только срок выполнения. PERT - Program (Project) Evaluation and Review Technique – техника оценки и анализа программ (проектов). Идея следует из названия. PERT предназначен для планирования очень масштабных, единовременных, сложных, нерутинных проектов. Особенности: • подразумевается наличие неопределённости; есть возможность разработать рабочий график проекта без точного знания деталей и необходимого времени для всех его составляющих; • разработан для работы на бумаге. Самой популярной частью PERT является метод критического пути, опирающийся на построение сетевого графика (сетевой диаграммы PERT). (реферат: полный состав PERT). Была разработана в 1958 году консалтинговой фирмой «Буз, Ален и Гамильтон» совместно с корпорацией «Локхид» по заказу Подразделения специальных проектов ВМС США в составе Министерства Обороны США для проекта создания ракетной системы «Поларис» (Polaris). Проект «Поларис» был ответом на кризис, наступивший после запуска Советским Союзом первого космического спутника. [Основная статья Википедии]: Сетевой график Рис. 19. Пример сетевой диаграммы PERT для проекта продолжительностью в семь месяцев с пятью промежуточными точками (от 10 до 50) и шестью деятельностями (от A до F). Варианты сетевого графика: • работы на узлах, события на стрелках; • работы на стрелках, события на узлах. Диаграмма PERT с работами на стрелках представляет собой множество точек-вершин (события) вместе с соединяющими их ориентированными дугами (работы). Всякой дуге, рассматриваемой в качестве какой-то работы из числа нужных для осуществления проекта, приписываются определенные количественные характеристики: объемы выделяемых на данную работу ресурсов ожидаемая продолжительность (длина дуги). Любая вершина интерпретируется как событие завершения работ, представленных дугами, которые входят в нее, и одновременно начала работ, отображаемых дугами, исходящими оттуда. Это показывает, что ни к одной из работ нельзя приступить прежде, чем будут выполнены все работы, предшествующие ей согласно технологии реализации проекта. Начало этого процесса – вершина без входящих, а окончание – вершина без исходящих дуг. Остальные вершины должны иметь и те, и другие дуги. Последовательность дуг, в которой конец каждой предшествующей совпадает с началом последующей, называется путем. Путь от начала до конца наибольшей длины называется критическим путем. Задачи лежащие на критическом пути (критические задачи) имеют нулевой резерв времени выполнения и в случае изменения их длительности изменяются сроки всего проекта. В связи с этим при выполнении проекта критические задачи требуют более тщательного контроля, в частности, своевременного выявления проблем и рисков, влияющих на сроки их выполнения и, следовательно, на сроки выполнения проекта в целом. В процессе выполнения проекта критический путь проекта может меняться, так как при изменении длительности задач некоторые из них могут оказаться на критическом пути. Если начальный момент выполнения проекта положить равным нулю, то сроки окончания у первых работ сетевого графика, то есть работ, выходящих из первого события, будет определяться их продолжительностью. Время наступления любого события следует положить равным самому позднему времени окончания непосредственно входящих в это событие работ: считается, что работа в сетевом графике не может начаться, пока не завершены все предшествующие для нее работы. Для определения критического пути используется метод эстафеты. Просматриваются все дуги сетевого графика. Пусть очередная просматриваемая дуга связывает вершины i и j. Если для вершины i определено предположительное время его свершения и это время плюс продолжительность работы больше предположительного времени наступления события j, тогда для вершины j устанавливается новое предположительное время наступления, равное предположительному времени наступления события i плюс продолжительность работы рассматриваемой дуги. Решение заканчивается, когда очередной просмотр дуг не вызывает ни одного исправления предположительного значения времени начала/окончания работ/событий. В результате может быть определено событие с самым поздним временем наступления, и путь от начальной вершины в эту конечную будет считаться критическим и определять продолжительность выполнения проекта. Наряду с общей продолжительностью выполнения проекта, критический путь определяет другие характеристики сетевого графика, играющие важную роль при планировании реализации нововведения, минимизации сроков и расходов на разработку. Суть решения задачи сокращения сетевого графика сводится к привлечению дополнительных ресурсов к выполнению работ, лежащих на критическом пути, снятием работ, не лежащих на критическом пути, запараллеливанием работ. Философия, лежащая в основа данной методологии – выявление главного. «Принцип ведущего звена». 5.2. Гибкие методологии разработки Основана на предположении о критичности качества (полноте удовлетворения потребностей, как известных, так и неизвестных заранее, часто создаваемых выходом нового продукта). Используется в основном для программного обеспечения. На этом примере и будет рассмотрена. Пример. Новая система программирования: табличный процессор. Первым был не Excel, а Supercalc. Заранее известен только принцип. По мере создания возникают проблемы: необходимость ускорения работы (для этого используются цепочки зависимости ячеек), автоматическая коррекция ошибок (предложение добавить в конец недостающие закрывающие скобки), проблемы с перемещением блока ячеек (долгое время был сбой, если перемещали с частичным перекрытием областей исходного и результирующего положения). И многое, многое другое. Многие особенности моли быть определены только в процессе эксплуатации, причём НЕ разработчиками! Гибкий подход к разработке (англ. Agile software development, agile ['æʤaɪl] = проворный; быстрый, живой, подвижной, расторопный, шустрый) – это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько методологий. Риск несоответствия полученных характеристик требованиям заказчика снижается путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки. Agile-методологии делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen (1) загон (для быков) 2) арестантская камера, тюрьма, 3) (амер.) большое рабочее помещение (с большим количеством рабочих мест). Команда обычно включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент); тестировщиков, дизайнеров интерфейса, технических писателей (tech writer) и менеджеров. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации по сравнению с другими методами. Это привело к критике этих методов, как недисциплинирующих. 5.2.1. Принципы Agile определяет в основном ценности и принципы, которыми руководствуются успешные команды. Agile Manifesto, определяющий ценности и принципы, которыми должны руководствоваться успешные команды, разработан и принят 11-13 февраля 2001 года. Манифест подписали представители следующих методологий: Extreme programming, Scrum, Dynamic Systems Development Method, Adaptive Software Development, Crystal Clear, Feature-Driven Development, Pragmatic Programming. Agile Manifesto [http://www.agilemanifesto.org/iso/ru/] содержит 4 ценности, 12 принципов и не содержит практик. Ценности: личности и их взаимодействия важнее, чем процессы и инструменты работающее программное обеспечение полная документация сотрудничество с заказчиком контрактные обязательства реакция на изменения следование плану Принципы: • удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО; • приветствие изменения требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта); • частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще); • тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; • проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием; • рекомендуемый метод передачи информации – личный разговор (лицом к лицу); • работающее программное обеспечение – лучший измеритель прогресса; • спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок; • постоянное внимание на улучшение технического мастерства и удобный дизайн; • простота — искусство НЕ делать лишней работы; • лучшие архитектура, требования и дизайн получаются у самоорганизованной команды; • постоянная (частая) адаптация (улучшение эффективности работы) к изменяющимся обстоятельствам. Можно ли применять у нас? 5.2.2. Методология SCRUM Scrum [Scrum. Обзор методологии. А. Уразбаев] – одна из самых популярных методологий гибкой разработки. Одна из причин ее популярности – простота. Скрам – термин в Регби, когда толпа игроков выталкивает другую команду. Ход разработки показано на рис. Рис. 20 [??]. Рис. 20. Ход разработки в методологии Scrum 5.2.2.1. Роли Скрам Мастер (Scrum Master) – самая важная роль в методологии. Он отвечает за успех Scrum в проекте, связывает менеджмент и команду. Это может быть менеджер проекта или лидер группы. Он не раздаёт задачи членам команды, так как команда является самоорганизующейся и самоуправлямой. Основные обязанности Скрам Мастера (только в рамках методологии, это не формальные должностные инструкции!): • создавать атмосферу доверия, • участвовать в митингах в качестве посредника (фасилитатор, facilitator англ. – человек, занимающийся организацией и ведением групповых форм работы с целью повышения их эффективности). Его задача – следить за регламентом и способствовать сплочению группы и плодотворному обсуждению; • способствовать устранению препятствий в работе в меру своего влияния; • прояснять проблемы и открытые вопросы; • способствовать соблюдению принципов работы и бесперебойному ходу процесса. Руководитель (Product Owner) – это человек, отвечающий за разработку продукта. Если инициативно разрабатывается новый продукт, то это обычно менеджер по продукту. Если выполняется внутренний проект (например, разработка и внедрение информационной системы собственными силами, то это менеджер проекта. Наконец, если проект делается на заказ, то это обычно представитель заказчика. Важно, что он – единая точка принятия окончательных решений для команды в проекте. Именно поэтому это всегда один человек, а не группа или комитет. В рамках данной методологии руководитель: • отвечает за формирование общей концепции проекта (для проектов нового программного обеспечения концепция может меняться по мере разработки); • управляет денежными потоками проекта; • управляет ожиданиями заказчиков и всех заинтересованных лиц; • предоставляет команде понятные и тестируемые требования (важно отметить, что требования ставятся команде, но не конкретным ее членам!); • отвечает за приемку программного обеспечения в конце каждой итерации. Команда (Team). В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению работ. Работа команды оценивается как работа единой группы. Вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. Обязанности команды таковы: • отвечает за оценку элементов задания перед руководителем; • принимает решение по проектированию и внедрению; • разрабатывает софт и предоставляет его заказчику; • отслеживает ход работ вместе со Скрам-Мастером; • отвечает за результат перед руководителем. Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды – 7 ± 2 человека. В команду входят люди с различными навыками – разработчики, аналитики, тестировщики, причем роли не закрепляются жестко. Предполагается, что команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи. Для облегчения коммуникаций команда должна находиться в одном месте, предпочтительно размещать команду не в «кубиках», а в одной общей комнате, чтобы упростить свободное общение. Команде необходимо предоставить все необходимое для комфортной работы, обеспечить досками и флипчартами, предоставить все необходимые инструменты и среду для работы. Российская традиция работы не предусматривала разделение помещений стенками. Однако часто можно видеть, что напротив двери стоит шкаф, не позволяющий входящему сразу увидеть всю комнату. Столы располагаются таким образом, чтобы сидящему было комфортно, в соответствии с особенностями человеческой психологии: защищенная спина, но и возможность легко покинуть свое место. Так что было и есть стихийное приспособление к особенностям психики, часто даже неосознанное. При попытках организовать пространство осознанно оно часто оказывается неудобным, люди чувствуют себя некомфортно. В этом случае рекомендуется дать им переставить мебель по своему усмотрению. 5.2.2.2. Артефакты АРТЕФАКТ (от лат. ars — искусство и factum — сделанное) — художественный объект, символизирующий рукотворный мир техники, автономный по отношению к нерукотворному миру природы. Бэклог продукта (Product Backlog) – это список имеющихся на данный момент требований к разрабатываемому продукту и нерешенных задач с расставленными приоритетами. Может включать также описание особых ситуаций, имеющихся недоработок, возможных улучшений. Примеры задач, помимо выполнения текущих работ: провести тренинг, добавить оперативной памяти на все компьютеры. Бэклог продукта постоянно пересматривается и дополняется – в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За его содержание отвечает руководитель. Он должен учитывать мнения команды, чтобы более точно расставлять приоритеты и планировать длительность работ. Бэклог спринта (Sprint Backlog) содержит задачи и требования, выбранные руководителем, над которыми надо работать прямо сейчас. Пример дан в табл. Таблица 5. Таблица 5 Пример бэклога спринта. Трудоемкость работ, час Дата 22.07 24.07 31.07 До конца спринта осталось дней 15 13 8 Общая оценка трудоемкости, часов 128 100 52 Исполнитель Работа Разработка руководства пользователя 24 16 - В.И.Иванов Откорректировать главу 1 40 32 24 В.И.Иванов Написать черновик главы 2 24 24 24 Мелкие доделки А.П.Петров Убрать ненужную кнопку с формы 1 8 - - А.П.Петров Добавить столбец итогов в таблицу 3 4 4 - Работы по базе данных В.С.Сидоров Пропатчить версию 3.15 12 8 4 В.С.Сидоров Убрать лишнюю индексацию 16 16 - … … … … … По датам и оценкам оставшейся трудоемкости на эти даты можно построить график зависимости оценки оставшейся работы от даты. Этот график отражает ход работ. 5.2.2.3. Спринт (Sprint) В Scrum итерация называется спринт. Длительность спринта составляет обычно 1 месяц (30 дней). Результатом спринта является готовый продукт, который можно передавать или, по крайней мере, показывать заказчику. Такой продукт называется build, что можно перевести как «версия». Очевидно, слово пошло от стандартной процедуры создания программного обеспечения: написанные на языке программирования модули транслировались в машинные коды, а затем компилировались для построения целостного программного обеспечения. Например, 10.11.2011 можно было скачать версию браузера Opera Browser 12.00.1116. Такие новые версии появляются долгое время после того, как продукт выпущен на рынок. Видно, что версий было очень и очень много. Спринты обеспечивают быструю обратную связь проектной команде от заказчика (пользователя). Заказчик оценивает результат спринта и предлагает улучшения к созданной функциональности. Такие улучшения попадают в бэклог продукта и могут быть запланированы на следующий спринт. В течение спринта делаются все работы по сбору требований, проектированию, кодированию и тестированию продукта. Объем работ спринта должен быть фиксированным. Это принимаемые командой обязательства. Бэклог спринта не может быть изменен никем, кроме команды. 5.2.2.4. Жизненный цикл спринта Планирование спринта. В планировании спринта участвуют заказчики, пользователи, руководитель, скрам-мастер, и команда. Планирование спринта состоит из двух последовательных встреч. 1 встреча. Участники: команда, руководитель, скрам-мастер, пользователи. Цель: Определить цель спринта и бэклог спринта. Результат встречи: бэклог спринта. 2 встреча. Участники: скрам-мастер, команда. Цель: определить, как именно достичь цели спринта. Для каждого элемента бэклога спринта определяется список задач и оценивается их продолжительность. Результат: задачи в бэклоге спринта. Выполнение работ. Работы выполняются командой. В случае, если команда сообщает, что не успевает выполнить план спринта, скрам-мастер, руководитель и команда встречаются и выясняют, как можно сократить объем работ и при этом достичь цели спринта. Остановка спринта (Sprint Abnormal Termination). Производится до истечения запланированного срока (обычно 30 дней) в исключительных ситуациях. Это случается, если команда понимает, что не может достичь цели спринта в отведенное время. Остановку может произвести и руководитель, если необходимость в достижении цели спринта исчезла. После остановки спринта проводится встреча с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт. Ежедневная скрам-встреча. (Daily Scrum Meeting; теперь говорят митинг, не понимая, что значит это слово в России. Раньше было слово, обозначающее похожее явление: это называлось летучка). Проходит в начале дня. Длительность не превышает 15 минут. Цель – поделиться информацией и узнать, кто над чем работает. Не предназначена для решения проблем! Скрам-встречу проводит Скрам-мастер. Он задает каждому члену команды вопросы. • Что сделано вчера? • Что будет сделано сегодня? • С какими проблемами столкнулся? Скрам-мастер отмечает, какие вопросы надо обсудить, в формате что/кто/когда, например Обсудить проблему с переполнением в программе 3, Петя и Вася, сегодня утром. Демо и обзор спринта. Проводится в конце спринта. Рекомендованная длительность: 4 часа. Организуется скрам-мастером. Команда помогает составить повестку собрания (agenda) и последовательность выступлений. Команда демонстрирует очередную версию (т.н. инкремент) программного продукта, созданный за последний спринт. Остальные участники проекта его оценивают. Помимо этого, команда рассказывает о возникших задачах, их решении, препятствиях и проблемах, оставшихся нерешенными. Результаты обзора: • направления дальнейшего развитие системы; • рекомендации по улучшению процесса разработки. Подготовка к встрече не должна занимать более двух часов, поэтому обычно запрещается использовать презентации в Power Point. 5.2.3. Microsoft Solutions Framework (MSF) Это методология разработки программного обеспечения от Microsoft. MSF опирается на практический опыт корпорации Майкрософт, описывает управление людьми и рабочими процессами в процессе разработки решения и представляет собой согласованный набор концепций, моделей и правил. Имеется несколько методик, среди которых наиболее популярны • методика внедрения решений в области Управления проектами • методика управления IT-проектами на базе методологий MSF и Agile (гибридная методика). Состав MSF: 8. Модели. 8.1. Модель проектной группы. Проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга В проектную группу входят такие ролевые кластеры (роли): • управление программой (program manager): структура работ проекта; • разработка (developer): разработка приложений и инфраструктуры, технологические консультации; • тестирование (quality assurance engineer): планирование, разработка тестов и составление отчетности по тестам; • управление выпуском (release manager): инфраструктура, сопровождение, бизнес-процессы, выпуск готового продукта; • удовлетворение заказчика (user experience): обучение, эргономика, графический дизайн, техническая поддержка; • управление продуктом (product manager): бизнес-приоритеты, маркетинг, представительство интересов заказчика. Роли может совмещать один человек. Правда, нельзя объединять роль разработчиков ни с какой другой ролью. Характерно, что менеджера проекта нет, ответственность распределяется между лидерами кластеров. Такая структура приспосабливаема к проектам любого масштаба (масштабируема). 8.2. Модель процессов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением, что позволяет сфокусировать внимание на ценности разрабатываемого продукта для бизнеса. Предполагается, что разработка идет короткими циклами. 9. Дисциплины. 9.1. Управление проектами. Основан на треугольнике компромиссов: ресурсы, время, результат. На ранних этапах создается матрица компромиссов, согласовываемая с заказчиком. Пример. Для иллюстрации использования матрицы компромиссов Майкрософт предлагает использовать следующее предложение (вместо пропущенных слов могут быть вставлены «календарный график», «ресурсы» и «функциональность»): «Зафиксировав ___________, мы согласовываем ___________ и принимаем результирующий ___________». 9.2. Управление рисками. Это девиз: «мы не боремся с рисками – мы ими управляем». Акцент на превентивность. 9.3. Управление подготовкой (управление знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений). 5.3. Критические цепочки Их использование называют третьей революцией в управлении проектами [Бобровский С. Критические цепочки - третья революция в управлении проектами // PCWeek, 2000, № 45 (267), Режим доступа: http://www.pcweek.ru/about/authors/detail.php?ID=13710 ]. 3 даты признаются важнейшими в управлении проектами. 1917 г. – массовое распространение получили работы Гантта 1950-е – теория PERT-сетей (ВМС США) 1997 г - работа Илиахи Голдратта “Critical Chain” (метод критических цепочек, МКЦ). В среднем МКЦ дает ускорение работ на 90%. Данный метод сегодня используют 450 крупнейших предприятий мира, в частности, AT&T, Boeing, Ericsson, Ford Motor, General Motors, GTE, IBM, а также множество средних и мелких промышленных, государственных и военных организаций. Интересная мысль: программным проектом пытаются управлять так же, как например, постройкой моста. Результат: мосты строятся давно в срок и редко разваливаются. Крупные программные проекты завершаются полным провалом в 30% случаев, затягиваются на 100% в других 30% случаев. При этом сложность создания мостов выше, если судить только по бюджету и задействованным людским ресурсам. Причина 1. Трудно найти хороших руководителей проектов. Причина 2. Трудно измерить результат в программных проектах. Информационная система отражает бизнес и всё время меняется. Поэтому нельзя ставить жесткие сроки. Даже как в скраме: ежемесячные. Это чисто формально получается, бессмысленно. Основа МКЦ – теория ограничений, предлагающая сделать следующие шаги: • определить накладываемые на проект ограничения (например, по ресурсам); • учитывать их при построении плана и в процессе работ; • подчинить все второстепенные задачи этим ограничениям и не начинать их, пока не возникнет реальная необходимость; • определить способы смягчения этих ограничений. Каждый проект рассматривается как набор связанных между собой задач. Каждая задача определяется видом выполняемой работы (или исполнителем) и отпущенными на нее ресурсами (как правило, временем). Для нее существуют условия начала и завершения. Это схоже с сетевым планированием. Последовательные задачи, не требующие разных ресурсов и имеющие одинаковые критерии завершения, объединяются в одну. Например, проектирование программного модуля, его программирование и отладка рассматривается как одна задача при условии, что этим будут последовательно заниматься одни и те же исполнители. Определив задачи, можно переходить к определению сроков их выполнения. Это обычно делается на основе опроса самих разработчиков, которые, естественно, будут завышать трудоемкость работ. Хороший руководитель проекта примерно знает возможности исполнителей и может сам назначить сроки выполнения работ. Следующий шаг – определить критический путь проекта (в данном методе он называется критической цепочкой) и организовать единый буфер ресурсов для нее. Например, если ресурс – рабочее время, в конце критической цепочки вводится резерв времени. Общий буфер – ключевой элемент метода – фактически защищает каждую задачу своим большим запасом ресурсов, так как вероятность того, что сорвутся все задачи, очень мала. Для некритических задач вводятся отдельные буферы. По мере выполнения типовых задач в различных проектах можно уточнять оценки длительности их выполнения и осуществлять планирование более точно. Метод критических цепочек относительно нов, и не все проблемы. связанные с ним, полностью решены. В частности, имеется следующая проблема: по мере уточнения плана оставшихся работ с учетом уже выполненной части проекта критические задачи могут становиться некритическими и наоборот; могут появляться новые задачи. Буфер до некоторой степени страхует от влияния таких изменений на общую длительность проекта. Практический пример Рассмотрим построение одного проекта по методу критических цепочек (рис.. [Бобровский С. Критические цепочки - третья революция в управлении проектами. PC WEEK, 2000, № 45 (267). Режим доступа: http://www.pcweek.ru/idea/article/detail.php?ID=56323] Имеется пять видов задач, обозначенных разным цветом и выполняемых соответственно пятью группами людей (рис. Рис. 21, а). Для каждой задачи определена ее продолжительность в неделях. Рис. 21. Иллюстрация метода критических цепочек Шаг 1. Сдвиг каждой задачи вправо, то есть установка ее начала на возможно более поздний срок. Это позволяет собрать больше информации и устраняет простои (рис. Рис. 21, б). Шаг 2. Задачи «красной» и «желтой» групп требуют одинаковых ресурсов и не могут быть выполнены одновременно. Выполняется так называемое выравнивание ресурсов (рис. Рис. 21, в). Шаг 3. Определяется критическая цепочка. Общая продолжительность работ критической цепочки составляет 27 + 15 + 15 = 57 недель. Отличие от традиционного определения критического пути состоит в том, что в данном методе предварительно производится выравнивание ресурсов. Шаг 4. Формируются промежуточные буферы для цепочек некритических задач (серые прямоугольники на рис. Рис. 21, г). Для двух работ верхнего ряда буфер общий, так как это – цепочка. Размер буфера обычно определяется простыми способами – например, берется половина продолжительности цепочки, или задается исходя из корпоративного опыта. Возможен вариант, когда некоторые задачи стартуют раньше, чем критическая цепочка, как, например, первая работа во втором ряду. Шаг 5. Добавляется общий буфер для критической цепочки (рис. Рис. 21, д). Шаг 6. Первая задача критической цепочки синхронизируется с самой ранней некритической задачей (рис. Рис. 21, е). Это не противоречит шагу 1, так как тут речь идет только о критической цепочке, для которой это дополнительная «подстраховка». Общая продолжительность проекта при этом не увеличивается по сравнению с предыдущим шагом. Общий буфер для цепочки задач играет важную роль. Если задавать резерв времени выполнения каждой отдельной задачи, то, ввиду того, что не все эти резервы будут использоваться (возможность самого плохого варианта с задержками в каждой работе всё-таки низка), возникнут перебои в работе, а общая длительность работ будет завышена. В отличие от этого, резервы черпаются из общего буфера по мере необходимости. (????? о длине буфера исходя из вероятности завершения работ) Еще одной важной функцией общего буфера является мониторинг выполнения проекта. Если значительная часть резерва использована уже в начале проекта, это служит индикатором неблагоприятного развития события и говорит о необходимости корректировать план проекта. Хотя отмечается, что метод критических цепочек еще недостаточно проработан, он перспективен, так как не требует кардинальной перестройки организации, прост в понимании, быстр и дешев во внедрении, стимулирует каждого сотрудника повышать мастерство путем постоянного анализа своих трудозатрат, сокращает время выполнения проекта. 5.4. Классическая методология PMBOK PMBOK – Project Management Base of Knowledge – база знаний по управлению проектами. Это документ, который выходит 1 раза в 4 года, последний вышел в 2008. Распространяется он довольно долго. Есть сертификация по PMBOK, семинары. Использование этих методов основывается на предположении о неизменности требований и низких рисках. [PMBOK 4й редакции. Революция или Эволюция? В. Иванов] Что такое pmbok? В документе нет методик. Есть состав проекта: работы, участники… Вводная часть имеет довольно четкий акцент на управление программами проектов и портфелями проектов. Уже действует отдельная сертификация на программное и портфельное управление (PgMP, Program Management Professional). Помимо менеджера проекта появляется портфельный менеджер. Описывается основной принцип следования фаз проекта: водопад. Обычно следующая фаза не может начаться, если не закончена предыдущая. Но рассматривается и вариант перекрытия фаз проекта для его ускорения, и итеративные процессы. В итеративных методиках важнейший инструмент это создание прототипа, позволяющий быстро корректировать и верифицировать требования к результату проекта. Признается, что ошибки в «бумажных» спецификациях неизбежны и представляют собой серьезный источник рисков. PMBOK 4 разрешил проблемы совместимости методических разработок PMI и Microsoft. В PMBOK 4 четко прописаны обязательства подрядчиков, заблокированы многие риски. Это хорошо защищает интересы тех, кто заказывает решения по проектному управлению. 5.5. Работа с высокими рисками. Инновационные проекты (стартапы) Стартап (start-up, англ. запускать) или стартап-компания — недавно созданная компания, (возможно, даже ещё не зарегистрированная официально), строящая свой бизнес на основе инновации, не вышедшая на рынок или едва начавшая на него выходить и обладающая ограниченным набором ресурсов. Зачастую стартап-компании называют «гаражными». С гаража начинали Apple, Microsoft, Amazon, Google и многие другие. Интересно, что в Германии эти фирмы, скорее всего, не появились бы, так как законодательство этой страны запрещает заниматься бизнесом в гаражах. Стартапом также часто называют отдельный венчурный проект в рамках компании. Само понятие «стартап» очень тесно связано с Силиконовой долиной. В 1939 году небезызвестные Уильям Хьюллет и Дэвид Паккард, являвшиеся выпускниками Стэнфордского университета, основали первый в мире стартап, превратившийся впоследствии в корпорацию Hewlett-Packard.[1] В своем развитии стартапы проходят несколько стадий. Посевная стадия (seed stage): формируется идея и просчитываются прогнозы. Стадия запуска (startup stage): начинают тратиться ресурсы. До следующей стадии он будет убыточным. Стадия роста (growth stage): получение прибыли. до этой стадии доходят далеко не все стартапы. Стадия расширения (expansion stage): активная экспансия проекта. Обычно она начинается после некоторого снижение темпов развития и носит название второго писк популярности. Стадия выхода (exit stage): прорыв на «большой рынок». Зачастую происходит преобразование в открытое акционерное общество. Более детально стадии развития стартапа рассмотрены в [Вельф А. Стадии развития стартапа. //Портал фонда «Вечная молодость», Режим доступа http://www.vechnayamolodost.ru/pages/investiciiivenchur/stadii_razvitiya_startapa.html, IdeaBlog.ru] с ориентацией на программное обеспечение. 1. Пре-стартап стадия: название периода времени от момента возникновения идеи до запуска проекта в эксплуатацию или продукта в производство. 1.1. Предпосевной этап (Pre-seed): есть идея того, что нужно рынку и потребителям, но четкого представления о том, как ее следует воплотить и развивать, нет. То есть, ещё нет технического задания и бизнес-плана. 1.2. Посев (Seed): происходит изучение рынка, составляется техническое задание на первый (экспериментальный или опытный образец) продукта или его основных подсистем, составляется бизнес-план. Затем реализуется техническое задание, производится тестирование созданного продукта. Ведутся переговоры с первыми потенциальными клиентами. 1.3. Прототип: создание технического задания и проектирование интерфейсов на готовый продукт. 1.4. Работающий прототип: создание проекта или продукта с минимальными функциями. Для программного обеспечения это может быть просто набор окон с частично реализованными функциями кнопок. 1.5. Альфа-версия проекта или продукта: проект или продукт создан, но еще не оттестирован, в процессе тестирования и usability-тестирования в интерфейс еще добавляются некоторые мелочи, которые не были додуманы на стадии составления технического задания и проектирования интерфейса. 1.6. Закрытая бета-версия проекта или продукта: проект или продукт близок к тому, каким его видят основатели стартапа. Появляются первые немногочисленные пользователи, которые приглашаются основателями стартапа попробовать сервис и сообщать о том, чего им не хватает либо о тех багах (программных ошибках) , с которыми они столкнулись. 1.7. Публичная бета-версия проекта или продукта: начинается привлечение пользователей. Это либо самые любопытные, либо те, кто осознал у себя потребность в новом продукте услугах. Они сообщают об обнаруженных недостатках (количество ошибок в сложном программном обеспечении снижается экспоненциально, но практически никогда не доходит до нуля). Подписываются полноценные договора с первыми клиентами. 2. Запуск продукта в эксплуатацию или продукта в производство. 2.1. Ранний стартап: Запуск продукта, созданного в результате выполнения проекта, в производство или в эксплуатацию. 2.2. Поздний стартап: начальный период производства или эксплуатации. 3. Пост-стартап стадия. 3.1. Рост: положение стартапа на первичном целевом рынке (т.е. на том рынке, с которого он намеревался начать работу, и который описан в бизнес-плане) уже стабильно, и стартап уверенно идет к завоеванию на этом рынке той доли, которую он наметил себе в бизнес-плане. 3.2. Расширение: стартап выполнил либо очень близок к выполнению бизнес-плана на первичном целевом рынке, и выходит на другие рынки. 3.3. Выход: прежде всего имеется в виду выход из бизнеса венчурных инвесторов. Может произойти смена организационно-правовой формы: преобразование в открытое акционерное общество. 5.6. Сбалансированная методология Здесь делается акцент на взаимодействие сторон, заинтересованных в результатах проекта: исполнителей, заказчиков, пользователей. 5.6.1. Метод PRINCE2 Для примера рассматривается метод PRINCE2 [Что такое PRINCE2 http://blog-of-roman.blogspot.com/2008/06/blog-post_29.html ] PRINCE2 — английский стандарт на ведение проектов. Изначально создан для IT проектов, потом расширен для использования в любых проектах. Основан на четком процессе, разбитом на 8 стадий и 45 подстадий. У каждой стадии есть свой набор целей, активностей а также входных и выходных документов. Есть критерии, по которым можно судить о качестве документов. Они позволяют контролировать отклонения от качества в течение жизненного цикла проекта. Особенностью стандарта является его масштабируемость. В каждой стадии и подстадии описано, какую ее часть можно опустить, если проект небольшой. Метод не требует последовательного выполнения стадий. Например, процесс стратегического управления идет в течение всего жизненного цикла проекта. Зависимости между стадиями четко прописаны. Еще одна интересная особенность – рекурсивный подход к созданию проектов. Проекты могут состоять из частей, каждая из которых рассматривается как отдельный проект. В отдельный проект может быть выделен проект по пониманию, а нужно ли вообще наш проект делать. К числу недостатков относится большое количество PINO (Prince in name only) проектов, в которых опущено почти все, но они гордо зовутся сделанными по методологии PRINCE2. 5.6.2. Организационная структура 1. Менеджер проекта в традиционном понимании. 2. Совет проекта (Project Board). Состоит из трёх человек: представителя заказчика, главного пользователя и главного специалиста. Совет проекта ответственен за принятие стратегических решений. Менеджер проекта регулярно отчитывается перед Советом. Менеджер проекта обязан отслеживать возможные проблемы и предлагать совету альтернативные решения. Совет принимает решение о дальнейших действиях. 3. Служба-«гарант» (Project Assurance). Предоставляет независимое мнение о проекте с точки зрения тех же трех групп людей — заказчиков, пользователей и специалистов в предметной области. Служба готовит три отчета. • бизнес-отчет: о финансовом состоянии проекта и выгодности проекта в целом; • пользовательский отчет, содержащий описание того, насколько хорошо выполняются требования пользователей; • технический отчет: насколько хорош проект в технологическом плане. В небольших проектах роль гаранта выполняет совет проекта. В больших – это отдельная группа. 4. Служба административной поддержки, ответственная за проведение встреч, доведение нужной информации до всех ее адресатов, сохранение проектной информации и т п. В случае небольших проектов эти функции выполняет менеджер проекта. 5.6.3. Стадии Стартап (Start Up, SU). Требуется понять, нужно ли выполнять проект; описать его содержание. Инициация проекта (Initiating a Project, IP). Описывается цель проекта, формируется организационная структура, планируются сроки и стоимость. Планируется сроки и цена проекта. Составляется бизнес-предложение. Разрабатывается бизнес-кейс. Это – отличие данного метода от других. Бизнес-кейс – формальное описание бизнес-ситуации, граничных условий, в которых этот кейс сохраняет жизнеспособность. В процессе работы кейс периодически оценивается на предмет невыхода за эти граничные условия. Планирование (PL). Этот процесс продолжается в течение всего проекта. Стратегическое управление проектом (Directing a Project, DP). Производится Советом проекта на основе документов, предоставленных менеджером проекта, и Гарантом. Решения принимаются с учетом интересов сторон, представленных в Совете. Управление стадией (Controlling a Stage, CS): ежедневное управление ходом проекта при помощи контура управления. Осуществляются менеджером проекта. Управление поставками (Managing Product Delivery, MP). Обеспечение нужных ресурсов в нужном месте в нужные моменты времени. Осуществляется менеджером проекта. Управление границами стадии (Managing Stage Boundaries, SB): подготовка и предоставление информации Совету. Закрытие проекта (Closing a Project, CP). Оценивается, не нарушены ли граничные условия бизнес-кейса. Если это произошло, делаются попытки нормализовать ситуацию. При невозможности это сделать принимается решение прекратить работы. 5.7. Процессно-ориентированное управление Процесс – последовательность действий, направленная на определенный результат. Реальные операции, начиная от выполнения проекта и заканчивая оформлением командировочного удостоверения, походят через руки различных работников Даже самое четкое распределение обязанностей работников в организации не гарантирует задержек на стыке этих обязанностей. Поэтому при процессно-ориентированном управлении назначается работник, ответственный за конечный результат. Он обеспечивает отсутствие задержек выполнения работ. Таким образом, и весь проект, и составляющие его элементы представляются как процессы, а усилия исполнителей направлены на получение промежуточных и итоговых результатов. 6. Предынвестиционная фаза 6.1. Стандартизированное управление проектами Эта идея развивается в книге [Милошевич]. Подход показан на рис. Вопрос для обсуждения: зачем это надо? Рис. 22. Элементы управления проектами в организации Речь идёт в основном о проектах разработки нового продукта. Есть три типовых стратегии управления проектами. Они задают все элементы, которые находятся ниже. Если проекты типовые (обычно они имеют низкую стоимость), то стратегия заключается в акценте на снижение стоимости проекта. Если стоимость проекта низкая и проекты уникальные, то стратегия заключается в достижении наилучшего соотношения цена/качество. Если стоимость высокая и проекты уникальные, то конкурентная стратегия заключается в дифференциации, и акцент делается на расписание. Такая схема определяет типовые решения. Если возникнет уникальная ситуация – придётся изобретать новые решения. 6.2. Предварительная проработка целей и задач проекта 6.2.1.1. Определяется тип проекта Какие типы проектов являются проектами-кандидатами (например, проекты разработки продуктов, выхода на рынок, капитального строительства, непрерывного совершенствования и т. д.)? Процесс выбора: • формирование перечня проектов-кандидатов; • выработка критериев отбора; • выбор инструмента отбора • отбор проектов. 6.2.1.2. Формируются альтернативные идеи Основные источники идей проектов на уровне организации: • неудовлетворенный спрос; • избыточные ресурсы; • инициатива предпринимателей; • реакция на политическое давление; • интересы кредиторов. Методы формирования идей Мозговой штурм, исследования, изобретательство. 6.2.1.3. Предварительный отсев идей Это исключение непригодных идей. Важно, чтобы отсев проводился отдельно от формирования. Это - основной принцип креативной деятельности. Причины отсева имеют весьма общий характер. Например: • недостаточный спрос на продукцию проекта или отсутствие его реальных преимуществ перед аналогичными видами продукции; • чрезмерно высокая стоимость проекта (имеется в виду не только экономическая, но и социальная или экологическая); • отсутствие необходимых гарантий со стороны заказчика проекта или правительства; • чрезмерный риск; • высокая стоимость сырья. 6.2.1.4. Определение ограничений Должны быть заданы такие ограничения, как бюджет, обеспечение персоналом и т. д. Важно убедиться, что приняты во внимание соображения политики и стратегические планы, например, поддержка существующих продуктов или сооружение новой фабрики. Для маркетинга также важно ограничение по времени. В некоторых случаях отказываются от привлекательных проектов, если видно, что конкуренты выйдут на рынок с аналогичным продуктом раньше. 6.2.1.5. Выработка критериев сравнения проектов В процессе формирования инвестиционного замысла проекта должны быть получены ответы на следующие вопросы: • цель и объект инвестирования, место (район) размещения; • продукция проекта – характеристика и объем выпуска; • срок окупаемости; • доходность проекта; • назначение, мощность и основные характеристики объекта инвестирования; • предполагаемые источники и схема финансирования. Инвестиционный замысел существенно зависит от специфики результата проекта. Для строительных проектов действуют основные положения рекомендаций по формированию инвестиционного замысла (целей инвестирования), одобренные Министерством строительства РФ 13.03.97 г. Затем формируются основные характеристики проекта. Для сравнения характеристики должны быть одинаковыми для сравниваемых проектов: платной автодороги или склада, завода или порта. Если проекты разнородны, то признаки более общие. Если проекты сходны, то признаки более детальные. К характеристикам для предварительного сравнения можно отнести: • наличие альтернативных технических решений; • спрос на продукцию проекта; • оценка уровня базовых, текущих и прогнозных цен на продукцию (услуги) проекта; • перспективы экспорта продукции проекта; • продолжительность проекта, в том числе его инвестиционной фазы; • сложность проекта; • наличие разрешительной документации и требования к ней; • инвестиционный климат в районе реализации проекта; • соотношение затрат и результатов проекта. При отборе проектов в сфере НИОКР обычно рассматриваются приводимые ниже критерии: • затраты на реализацию проекта; • экономический (социальный) эффект от реализации; • возможность технического успеха; • возможность рыночного успеха • размер рынка результатов НИОКР; • доступность необходимого персонала; • степень приверженности организации проекту; • стратегическое позиционирование проекта; • конкурентоспособность результатов проекта; • степень благоприятствования окружения (в том числе законодательства); Тема для дальнейшего развития: показатели сравнения для маркетинговых проектов. 6.3. Оценка, ранжирование и отбор проектов 6.3.1. Аддитивная модель 5. Определяется набор факторов и показателей для их оценки (табл. Таблица 6). Таблица 6 Оценка проекта по аддитивной модели Фактор Параметр оценки Оценка Средний балл Стратегия Соответствие проекта стратегии организации 8 8,0 Стратегическая значимость 8 Конкурентное преимущество Уникальность 8 8,0 Выгоды для потребителя 9 Полезность для заказчика 7 Рыночная привлекательность Размер рынка 6 7,0 Доля рынка 8 Рост рынка 6 Сила конкуренции 8 Соответствие ключевым показателям компетентности Соответствие маркетинговой политике 5 6,0 Соответствие технологическим возможностям 6 Соответствие производственным возможностям 7 Технические достоинства Технический отрыв 9 9,0 Техническая сложность 9 Техническая вероятность успеха 9 Финансовые достоинства NPV в конце проекта 7 7,0 Индекс доходности 7 Срок окупаемости 7 Уровень финансовых рисков 7 Общая оценка проекта 45 из 60 (75%) 6. Даются балльные оценки каждого параметра по десятибалльной шкале. Для таких параметров, как срок окупаемости, можно задать шкалу балльных оценок с количественными границами. Например, срок окупаемости до года оценивается в 10 баллов, до 2-х лет – в 5 баллов, до трех лет – в три балла, свыше – в 1 балл. Для таких параметров, как стратегическая значимость, где критерии более субъективны, целесообразно ввести шкалу, проградуированную в ключевых фразах, например, 10 – полное соответствие, 9 – почти полное соответствие и т.д. 7. Определяется средний балл по каждому фактору (последний столбец таблицы). 8. Общая оценка определяется как сумма оценок факторов. 9. Определяется процент полученной оценки от максимально возможной. 6.3.2. Учет важности критериев Недостаток предыдущего метода заключается в том, что он не учитывает важность критериев. В более сложном случае используется взвешенная оценка. При этом экспертно определяется вес (значимость) каждого фактора или параметра и вычисляются средневзвешенные оценки. Важность параметров можно оценивать по такой же десятибалльной шкале. Формула расчета имеет вид где Oi – общая оценка i-го проекта; wj – балльная оценка важности j-го параметра, Pij – оценка j-го параметра для i-го проекта, n – количество параметров. Другой способ состоит в том, чтобы обеспечить сумму оценок важности, равной единице. Это более сложно для экспертов, но, по мнению специалистов по маркетинговым исследованиям, в частности, [Черчилль] оценки получаются более точными, так как эксперты вынуждены оценивать все факторы и параметры в комплексе. Такой способ можно порекомендовать при небольшом количестве оцениваемых параметров (до десяти). Формула при этом упрощается: у нее пропадает знаменатель, так как он становится равным единице. Иногда применяют следующий способ определения важности факторов: их сортируют от самого важного до самого неважного и назначают веса, равные где sj – ранг j-го критерия (место в упорядочении). Данная методика может применяться как для предварительного отбора наиболее перспективных вариантов осуществления проекта, так и для предварительного определения осуществимости проекта. В первом случае для дальнейшего рассмотрения остаются альтернативы, получившие наивысшие результаты, во втором — полученная интегральная экспертная оценка проекта сравнивается с определенным заранее ограничением снизу. Если полученное экспертным путем значение выше установленного предела, проект признается осуществимым. [Шапиро]. 6.3.3. Учет вероятности успеха, затрат и возможного эффекта Довольно часто учитываются лишь следующие критерии: • вероятность успеха; • эффект в случае успеха; • затраты на реализацию проекта. При этом можно принять проект с меньшей вероятностью успеха, если он сулит достаточно высокий экономический эффект. В этом случае также используются балльные оценки, а формула имеет вид , где Oi – итоговая оценка i-го проекта; O1i – оценка возможности успеха i-го проекта (низкая оценка – возможность низка); O2i – оценка экономического эффекта i-го проекта (низкая оценка – эффект мал); w1 и w2 – веса оценок возможности успеха и экономического эффекта соответственно, w1+w2=1, этими весами можно отразить соотношения важности достижения эффекта и возможности успеха; O3i – оценка затрат на реализацию i-го проекта (низкая оценка – затраты малы). 6.3.4. Модель с разными видами критериев , где Oi – итоговая оценка i-го проекта; большими буквами обозначены критерии балльных оценок i-го проекта, причем для всех оценок большие значения оценки соответствуют большим значениям оцениваемых параметров): Ai – доминирующие (настолько важные, что если они равны нулю, общая оценка также равна нулю; это, например, экономический эффект от реализации проекта); Bji, j=1…m – взаимозаменяемые критерии (уменьшение значения одного из них допустимо, если сопровождается увеличением другого; это могут быть надежность и ремонтопригодность оборудования); Ei – дополнительный критерий (применим не ко всем проектам из анализируемого множества. Так, критерий простоты использования применим к потребительским продуктам, но не применяется для продуктов производственно-технического назначения); Fi – критерий оценки расходов, (примерим к любым проектам); Gi - «необязательные» расходы (для некоторых проектов доступность таких ресурсов, как испытательные установки или квалифицированный программист, может быть ограничена; такие ресурсы следует рассматривать отдельно других затрат и только для проектов, требующих наличия данного ресурса); малыми буквами обозначаются весовые коэффициенты соответствующих критериев. Отношение bk/bl представляет собой показатель взаимозаменяемости между факторами Bk и Bl. Если Bk уменьшается на единицу, то Bl должен возрасти на величину bk/bl, чтобы сумма данных факторов осталась постоянной. Если существует взаимозависимость статей расходов, например, использование более дорогого сырья упрощает технологию и снижает затраты труда, то критерий F разделяется на составляющие аналогично критериям Bj. 6.3.5. Метод анализа иерархий Этот метод, предложеный Т. Саати [], довольно широко распространен. Последовательность выбора проекта такова. 1. Определяется набор сравниваемых альтернатив. 2. Определяется набор критериев сравнения. 3. Определяется относительная важность каждого критерия относительно каждого критериев по следующей шкале: • 9 – высшее (крайнее) превосходство первого сравниваемого критерия над вторым; • 7 – очень сильное превосходство; • 5 – сильное превосходство; • 3 – умеренное превосходство; • 1 – равноценность критериев; • 1/3 – умеренное превосходство второго из сравниваемых критериев над первым; • 1/5 – сильное превосходство; • 1/7 – очень сильное превосходство; • 1/9 – Высшая степень превосходства. • Значения 8, 6, 4, 2, 1/2, 1/4, 1/6, 1/8 – промежуточные. Определяется сравнительная оценка каждой альтернативы относительно каждой по аналогичной шкале. Производятся преобразования полученных оценок, представленных в матричном виде. Это можно сделать при помощи целого ряда программ, к числу которых относятся: «Мыслитель» [http://spirit-prog.ru/], «Выбор» [http://ciritas.ru/product.php?id=10] и многие другие. В результате получается строка оценок проектов согласно введенным исходным оценкам. На основе данных оценок проекты можно проранжировать по предпочтительности. При близких значениях оценок (разница менее 5%) ранги принимаются равными. *** Итог анализа – отобранные для реализации проекты (проект). 6.4. Планирование границ проекта Под границами в [Милошевич] понимаются требования к результатам проекта, сроки его реализации, используемые ресурсы, функции. Это требования заказчика. Работа с заказчиком Общение с заказчиком – важный элемент работы над проектом. Начинается она задолго до подписания договора на выполнение работ. Внимательное отношение к требованиям заказчика не только способствует успеху проекта. Это создает репутацию исполнителей. Известно много случаев, когда в российских предприятиях внедрялись информационные системы ведущих мировых производителей. Однако требования заказчиков выполнялись далеко не идеально. .Главные требования выдвигают работники, которые будут непосредственно использовать новую систему. Если аналогичные функции уже выполнялись, например, в Excel, то они могут довольно четко сформулировать свои пожелания. Однако если опыта работы в аналогичных системах нет, внедряемая система практическим всегда оказывается очень неудобной. Но даже есть требования сформулированы более или менее четко, выполнить их оказывается довольно трудным делом. Обычный ответ в таких случаях: – Мы – лишь небольшая фирма. Действуем по указаниям филиала в Вашем городе. Он подчиняется российскому представительству фирмы, которое находится в Москве. Мы, конечно, отправим Ваши пожелания по цепочке, но вряд ли они будут учтены. Для того, чтобы правильно учесть требования заказчика, следует определить цели, которые стремится достичь заказчик, уточнить круг лиц, с которыми следует общаться, их полномочия и квалификацию, значимую информацию, которую от них необходимо получить. Потом, в ряде встреч, можно подробно узнать все требования. Опыт автоматизации технологических процессов показывает, что ни одни работник в организации-заказчике не может правильно сформулировать требования в внедряемой системе. В этом случае можно рекомендовать изучить автоматизируемый процесс (изготовления продукции; экономических расчетов, планирования маркетинговых мероприятий и др.) на практике, лучше всего – выполнив его согласно существующим инструкциям. Результаты обсуждений и изучения объекта необходимо тщательно документировать. 6.4.1. Дом качества Требования заказчика специфичны тем, что отражают его нужды1. Они могут быть сформулированы как на количественном, так и не качественном уровне, например: «необходимо создать экономичный автомобиль», «необходимо, чтобы расход топлива был не более 5 л на 100 км», «чтобы можно было двигаться по бездорожью». Такие требования имеют некоторое сходство с концепцией продукта, так как фиксирует ожидаемые заказчиком (потребителем) выгоды. Количество требований, даже для таких проектов, как создание трансатлантического лайнера или полет на Марс, на должно превышать 10! Справа раскрывается уровень требований заказчика. Это может быть сравнение ожидаемого результата с аналогом, с лучшим мировым уровнем, с текущим состоянием в фирме-заказчике. Реализация сформулированных требований достигается комплексом работ, выполняемых исполнителем. Например, для обеспечения малого расхода топлива можно сделать автомобиль из легких сплавов или разработать новый, более мощный мотор. Количество работ также не должно превышать 10 даже для самых крупных проектов. Обычно каждое предлагаемое решение2 удовлетворяет целый ряд требований. Это и отражает «дом качества» (рис. Рис. 23). Дом качества для проекта разработки новой модификации продукта приведен на рис. Рис. 24. Это главы 2,3,4,5 курсового проекта по управлению продуктом [Методичка УП]. Из последнего рисунка видно, что заказчик (фирма-производитель продукции) хочет увеличить продажи, улучшить свой имидж и обеспечить повышение конкурентоспособности своей продукции. Это качественно различные требования. Для достижения целей заказчика предлагается разработать новую модификацию продукта, установить на него цену и разработать план мероприятий по продвижению новой продукции. Следует отметить, что работы, определенные как названия столбцов, должны подразумевать определенный результат. Не несут полезной информации такие названия, как «провести анализ», «изучить», «исследовать». Рис. 23. «Дом качества» проекта Рис. 24. Дом качества для разработки модификации продукта В нижней части («фундаменте») дома помещаются требования к результатам работ. Они должны быть проверяемыми, чтобы можно было оценить, выполнена работа или нет. Эти требования становятся параметрами технического задания на проект. Выполнение данных требований, подтвержденное исследованиями или испытаниями, и утвержденное актом сдачи-приемки, является основанием для оплаты работ по договору. Именно поэтому маркетологи, которые часто выступают заказчиками разработки новых продуктов, должны тщательно проверять эти требования. Если окажется, что требования выполнены, а желаемый результат не достигнут, работы по договору должны быть оплачены. В данном примере требуется обеспечить прибыльность выпуска новой модификации продукта, установить цену, которая обеспечивает максимальный объем продаж и обеспечить достижение этого объема за заданное время. В «крыше» отражается связь работ. Результаты одной работы могут дополнять результаты другой. Например, проведение маркетинговых исследований можно совместить с информированием потенциальных покупателей. Возможна и обратная ситуация: выполнение определенных работ затрудняет выполнение других. В этом случае в клетках «крыши ставятся обозначения. Например, можно обозначить положительную связь как «+», а отрицательную как «_». Контроль дома качества заключается главным образом в проверке матрицы отношений. Пустая строка означает, что требование заказчика не удовлетворяются, а пустой столбец показывает ненужную работу. Если проект длинный и сложный, то строится ряд домов: Строки дома Столбцы дома Требования заказчика  Результаты проекта; Результаты проекта  Характеристики результата Характеристики результата  Мероприятия проекта; Мероприятия проекта  Программа качества. Этот ряд отражает последовательность удовлетворения требований заказчика. Результаты проекта – качественные показатели, которые должны быть достигнуты. Для нового автомобиля это может быть расход топлива на 100 км. Чтобы обеспечить такой результат, потребуется: снизить вес на 100 кг, увеличить степень сжатия до 9,8, использовать бензин марки А98 и т.д. В свою очередь, для снижения веса требуется провести ряд работ. И наконец, чтобы работы выполнялись в срок и с надлежащим качеством, необходима реализовать программу качества управления проектами (об этом будет подробно рассказано ниже). 6.4.2. Использование дома качества Главное преимущество дома качества состоит в том, что вопреки распространенному мнению, что качество проекта можно оценить лишь по его завершении, здесь оно оценивается заранее. Это и хорошая отправная точка для всего проекта, и хорошая основа для повышений стабильности проекта (небольших изменений в процессе его выполнения). Преимущества: • концептуальная простота; • возможности визуализации. Недостатки: • громоздкость. Если у заказчика больше десяти требований, функции качества становятся тяжелыми для восприятия; • часто воспринимается участниками как излишняя бюрократическая работа для заказчика, в то время как на самом деле это помогает и заказчику, и исполнителю при определении содержания проекта. 6.5. Планирование содержания Это первый шаг фазы планирования. 6.5.1. Устав проекта Иногда Устав проекта называют также Ходатайством или Декларацией о намерениях. Для российских организаций это довольно новое понятие. Когда шла речь о начале нового проекта, довольно часто вначале составлялся протокол о намерениях. Хотя это был и не денежный документ, все же он имел определенную силу: его можно было предъявить партнерам, он служил основанием для начала процедуры получения разрешений и т.д. В настоящее время в литературе по управлению проектами Устав встречается довольно часто, но единства по поводу его роли нет. Одни считают, что это должен быть краткий формальный документ, другие включают в него все разделы бизнес-плана. Поэтому следует начать с определения назначения проекта. В современных российских условиях перед началом работ по проекту требуется • определить руководителя проекта и наделить его соответствующими полномочиями; • получить многочисленные согласования и разрешения (это особенно актуально для строительных проектов); • найти инвесторов, определить их вклад, ожидаемый ими результат, риски; • презентовать проект работникам организации-исполнителя; • привлечь ресурсы для выполнения проекта. Все эти задачи требуют некоторых полномочия для их решения. А переговоры с потенциальным инвестором требуют развернутого бизнес-плана. Итак, более целесообразно считать устав проекта документом, который определяет само существование проекта и определяет полномочия участников. Именно такой подход предлагается в [Милошевич]. Поэтому предлагается следующая форма Устава (рис. Рис. 25) для внутрифирменных проектов. Большим достоинством данного документа является его краткость. Все расчеты и обоснования приводятся в приложении. Для проектов, которые осуществляются при взаимодействии двух сторон (исполнитель и заказчик) или большего числа сторон форма устава приближается к форме договора: указываются реквизиты сторон и другие обязательные атрибуты. Рис. 25. Примерный вид Устава проекта Видно, что это краткое описание проекта. Инициирует дальнейшую работу, в том числе детализацию содержания, указывает исполнителей. Существует ряд особенностей заполнения данного документа. Бизнес-цель – движущая сила проекта. Прибыль от продаж – основной источник для развития коммерческой организации, а также источник дивидендов. Если это проект по установке нового оборудования, то бизнес-целью будет не сама эта установка, а ликвидация узкого места в производстве [Милошевич]. Цель проекта. Для больших проектов указывается стратегическая цель, может быть, даже миссия, для малых – тактическая цель (тактические цели обычно называются задачами). Указывается некоторый конкретный результат. Количественный результат легче поддается контролю. Можно указывать и качественный результат, например, разработку платформы для создания линейки новых продуктов. Если это проект, связанный с маркетинговыми исследованиями, то правильно указывать разработку рекомендаций по принятию решений. Следует избегать таких неопределенных слов как собрать данные, изучить, проанализировать и т.п. Показатели проекта. В данном разделе задаются временные и стоимостные показатели. Можно указать примерную оценку ресурсов на реализацию проекта, например, количество человеко-месяцев на его выполнение. Если же в проекте задействованы различные подразделения, то ресурсы указываются для каждого из них. Для повышения точности и детальности устав проекта полезно делать на основе бизнес-плана. Для строительных работ существует «Типовое положение по разработке и составу Ходатайства (декларации) о намерениях инвестирования в строительство предприятий, зданий и сооружений», рекомендованное Министерством строительства РФ 13.03.97. Документ, помимо инвестора (заказчика), может подготавливаться проектным институтом (по договору); заинтересованными юридическими и физическими лицами, которые определяются заказчиком; специалистами из консалтинговой фирмы. Примерный состав Ходатайства (Декларации) о намерениях: Реквизиты инвестора (заказчика). 1. Местоположение намечаемого к строительству предприятия, сооружения. 2. Наименование предприятия, его технические и технологические данные: • объем производства промышленной продукции (оказания услуг) в стоимостном выражении в целом и по основным видам в натуральном выражении; • срок строительства и ввода объекта в эксплуатацию. 3. Обоснование социально-экономической необходимости намечаемой деятельности. 4. Примерная численность рабочих и служащих, источники удовлетворения потребности в рабочей силе. 5. Потребность предприятия в сырье и материалах (в соответствующих единицах). 6. Потребность предприятия в водных ресурсах (объем, количество, источник водообеспечения). 7. Потребность предприятия в энергоресурсах (электроэнергия, тепло, пар, топливо), источник снабжения. 8. Транспортное обеспечение. 9. Обеспечение работников и их семей объектами жилищно-коммунального и социально-бытового назначения. 10. Потребность предприятия в земельных ресурсах. 11. Водоотведение стоков. Методы очистки, качество сточных вод, условия сброса, использование существующих или строительство новых очистных сооружений. 12. Возможное влияние предприятия, сооружения на окружающую среду: • виды воздействия на компоненты природной среды (типы нарушений, наименование и количество ингредиентов-загрязнителей); • возможность аварийных ситуаций (вероятность, масштаб, продолжительность воздействия); • отходы производства (виды, объемы, токсичность), способы утилизации. 13. Источники финансирования намечаемой деятельности, учредители, пайщики, финансовые институты, правительство, коммерческие банки, кредиты поставщиков. 14. Использование (распределение) готовой продукции. Видно, что состав этого документа определяется спецификой строительных проектов, влияющих на самые различные факторы окружающей среды и требующих многосторонних согласований и обеспечения материальными ресурсами. 6.5.2. SWOT анализ Это оценка ситуации. Цель данного шага – определить важные для успеха проекта действия. По свот-анализу существует обширная литература. Здесь целесообразно остановиться на интересном подходе, который предлагается применить к проектам в [Милошевич]. Суть подхода заключается в следующем. 1. Определяются требования заказчика к результатам проекта. 2. Определяется, что необходимо для реализации проекта как во внутренней, так и во внешней среде организации. Например, если критический фактор – скорость выполнения проекта, необходим опыт параллельной работы над частями проекта, четкое взаимодействие между подразделениями и работниками, программное обеспечение для планирования и контроля выполнения работ. Во внешней среде должно быть достаточное количество сырья, которое можно быстро заказать и получить. 3. Важные факторы определяются мозговым штурмом. Число действительно важных факторов обычно не превышает 10. 4. Оценивается реальное состояние по каждому фактору. Можно использовать шкалу Зеленый-желтый-красный, можно – пяти- или десятибалльную. 4.1. Если реальное состояние какого-либо фактора внутренней среды соответствует требованиям, то это сильная сторона. 4.2. Если реальное состояние какого-либо фактора внешней среды соответствует требованиям, то это возможность. 4.3. Если реальное состояние какого-либо фактора внутренней среды не соответствует требованиям (имеется так называемый разрыв), то это слабая сторона, и необходимо предпринимать действия по ликвидации или уменьшению этого разрыва. 4.4. Если реальное состояние какого-либо фактора внешней среды не соответствует требованиям (имеется так называемый разрыв), то это угроза, и необходимо предпринимать действия по ликвидации или уменьшению этого разрыва. Обычно как-то перестраиваются параметры внутренней среды. Если же, к примеру, есть угроза срыва поставок, возможно, следует включить в состав исполнителей проекта поставщика. 5. Планируются действия, необходимые для уменьшения разрывов до приемлемого уровня. Проведение SWOT-анализа занимает от 15 минут до нескольких часов. Главный плюс применения данного метода состоит в том, что заранее, еще до начала реализации проекта становится видно, что есть, а чего недостает. Минус, как отмечает [Милошевич] состоит в том, что если рассказать руководству о предстоящих сложностях, проект могут и не запустить. Нужно сперва ввязаться в бой, а там видно будет... (Наполеон Бонапарт). Рисунок с сайта [http://www.dejepis.com/index.php?page=000&kap=014&pod=4]. 6.5.3. Содержание проекта Окончательно проект, выполняемый сторонней организацией-исполнителем, оформляется договором. Часто это договор на передачу научно-технической продукции или договор о выполнении работ. Такие договоры состоит из нескольких документов: собственно договора, протокола соглашений о договорной цене и – одного из важнейших документов – технического задания. Не существует строгих стандартов на техническое задание, кроме договора на выполнение научно-исследовательских работ и разработку программного обеспечения. И стандарты, и сложившаяся практика подразумевают, что главная часть технического задания – технические требования к результатам: программе, новому продукту, рекламной кампании и т.д. Детальная проработка таких требований занимает довольно длительное время (один-два месяца работы нескольких человек со стороны исполнителя, многочисленные обсуждения и согласования с заказчиком). И такая работа становится этапом выполнения договора. Поэтому в ряде случаев при подписании договора вместо технического задания составляют его сокращенный вариант, называемый исходными требованиями. Именно о таком документе, называемым также содержанием проекта, и пойдет речь. Этот документ составляется практически для всех проектов самого различного назначения и масштаба. Его примерный вид, для случая выполнения проекта сторонней организацией, дан на рис. Рис. 26. Рис. 26. Образец Содержания проекта Видны некоторые отличия от Устава. Описание содержания работ. Дается сжато, до десяти пунктов даже для крупных проектов. Детализация производится уже на последующих этапах. Например, для проекта строительства фабрики: «Разработать проект фабрики по производству оптики; рассчитать бюджет проекта; построить фабрику; сдать фабрику в эксплуатацию». Для проекта в области программного обеспечения: «Определить технологические процессы обработки информации; разработать конфигурацию программного обеспечения; разработать план обучения; создать прототип; обучить персонал; внедрить программное обеспечение». Правильно составить описание работ довольно сложно. Вот некоторые рекомендации. Полезно применить следующий способ структурирования содержания: • задать действие (определить); • затем – объект, над которым это действие производится (технологические процессы) и т.д. 2. Ослабить привязку описания содержания работ к операциям и усилить привязку к результатам. Например, в каждом пункте содержания проекта разработки программного обеспечения подразумевается некоторый результат: описание технологических процессов, конфигурация программного обеспечения и т.д. Так что способ обеспечения второй рекомендации состоит в том, чтобы каждая работа подразумевала какой-то самоценный результат: документ, продукт, завершенную работу. Так следует планировать содержание ремонтных работ в квартире или на даче. При этом оплачивать можно только завершенный этап работ. Этот же принцип применяется и в проектах. В договоре должны быть прописаны действия в случаях, когда работы завершаются досрочно: выяснилась невозможность реализации проекта или закончилось финансирование или создались обстоятельства непреодолимой силы. В этом случае обычно оплачиваются фактически выполненные работы. Гораздо легче и согласовать проект договора, и урегулировать неплановую ситуацию, если каждая работа имеет конкретный результат. Ключевые результаты проекта. Иногда в содержание включают и этот пункт. Это важно, так как результат можно показать, проверить, измерить. Наличие результата – основание для оплаты выполненных работ. Итак, выполнение каждой из работ, изложенных в описании содержания, должно привести к получению определенных результатов. Самый простой способ определения ключевых результатов – переписать описание содержания работ, слегка переформулировав их. Например, Определить технологические процессы обработки информации преобразуется в Описание технологических процессов обработки информации или в технологические карты. Именно поэтому данный раздел был опущен в образце на рис. Рис. 26. Если окажется трудно сформировать результаты по описанию содержания работ, значит, названия работ надо переформулировать. Результаты могут быть как промежуточными (технологические карты), так и конечными (выпуск программного продукта). Результаты могут представлять собой материальный продукт (станки, производственные мощности), нематериальный продукт (отчет, исследование и т. д.), услугу (завершенное обучение). Следующий шаг после идентификации результатов – определение того, какими показателями оценивается, насколько полно и в каком состоянии должен быть получен каждый из них. Контрольные события. Это основные события и ключевые даты, отмечающие ход выполнения описания работ и получение результатов. Называются также вехами. Их легко сформировать, так как они должны соответствовать результатам. На рис. Рис. 26 видно, как формулируются контрольные события на основе содержания или результатов работ. Легкость формирования контрольных события служит критерием правильности созданного перечня работ и результатов. Событий не должно быть много, они должны быть ясно определены и хорошо понятны заинтересованными сторонами, иметь четкие предельные даты наступления и не противоречить списку результатов. Допущения. При разработке проекта ряд факторов принимается как данность. На самом деле они не известны точно либо являются неопределенными. Это допущения. О важности допущений говорят примеры. Если создается база данных уровня факультета, потом оказывается, что надо добавить функции для кафедры; применить во всем университете. Часто при планировании сроков делается допущение, что все участники работают только над одним проектом. А реально оказывается, что над несколькими. Ограничения могут быть физическими, техническими, ресурсными или иными. Например, для участия в тендере на выполнения консалтинговых услуг может оказаться, что заказчик требует наличия стопроцентной сертификации «профессионала по управлению проектами». Хотя ограничения находятся внизу документа, принцип должен быть таким: Сначала идентифицируйте основные ограничения и только потом разрабатывайте содержание и приступайте к выполнению проекта. Иначе проект может потерпеть неудачу. Управлять допущениями и ограничениями — значит четко идентифицировать их, измерять и основывать на них описание содержания. По мере развития проекта необходимо возвращаться к этому вопросу и проверять, существуют ли еще имевшиеся в начале работы допущения и ограничения и не возникли ли новые. Возможно, потребуется пересмотреть содержание проекта или вообще отказаться от его завершения. Предупреждения. Пример из [Милошевич]. Некий подрядчик, занимающийся внедрением компьютерных технологий в Африке, включил в содержание своих проектов поставку вычислительных центров в комплекте с офисной мебелью. Однако, оказалось, что покупать офисную мебель на месте гораздо дешевле. Для того, чтобы изменить порядок поставок, необходимо явно зафиксировать изменения. Иначе есть большой риск, что все участники проекта будут работать по привычным схемам. Итак, необходимо особым образом отмечать то, что обычно по умолчанию входит в состав работ, но в данном проекте не нужно. Главное требование к содержанию заключается в том, чтобы оно было устойчивым, то есть либо минимально менялось по мере реализации проекта. Вот некоторые рекомендации для этого. 6. Снизить сложность проекта, перейти от крупных проектов, которые включают в себя много сложно взаимосвязанных работ, к более мелким проектам. Тогда • переделки при уточнениях работ и их взаимосвязей значительно сократятся и упростятся; • проект быстрее завершится, то есть серьезные изменения произойти вряд ли успеют; • проект станет понятнее, поэтому при его планировании будет меньше ошибок. Деление крупного проекта на мелкие, для каждого из которых разрабатывается свое содержание, обычно не составляет труда. 7. Создавать как результат проекта устойчивые продукты. Это означает, что продукт следует разрабатывать таким образом, чтобы он мог функционировать в более широком диапазоне, чем это кажется необходимым при планировании проекта. Например, в холодную зиму 1987 года, когда было -40OC, оказалось, что «хрущевские» дома рассчитаны на температуру -25 OC. В результате некоторые дома разрушились. В сейсмоопасных зонах также лучше строить дома с запасом прочности, чтобы избежать их переделки и даже жертв. 8. Жестко зафиксировать содержание на ранних этапах. Это позволит не только избежать изменений. Это ускорит и реализацию проекта, что снизит вероятность изменений. Оценивание и тонкая подстройка описания содержания. Все проверяется. Качество исходной информации, полноту описания содержания. Описание содержания – первый шаг планирования. Потом приходится его подстраивать. [Милошевич] предлагает еще ряд полезных правил составления содержания. 9. Как надо поступать при разработке Содержания. 9.1. Если Содержание занимает несколько страниц, оно разделяется на части: • резюме объемом в одну страницу; • вспомогательную документацию. В частности, в проект нового продукта обычно включается описание продукта, которое содержит анализ целевого рынка; концепцию продукта и выгоды, которые получат потребители, изготовители и продавцы; стратегию позиционирования; обязательные и желаемые характеристики продукта. Иногда рассматривают и риски реализации проекта. Не повторяйте во второй части то, что уже изложено в первой. 9.2. Используйте повседневную лексику, а не сложную терминологию; расшифровывайте сокращения. 9.3. Включите в Содержание данные о функциональных группах, являющихся поставщиками ресурсов. 9.4. Добейтесь утверждения документа руководством (!). 10. Чего не надо делать при подготовке Содержания. 10.1. Приступать к составлению Содержания не зная, как его структурировать. 10.2. Превращать содержание в чисто техническое описание проекта. 10.3. Использовать неточные понятия: около, приблизительно и т.п. 10.4. Смешивать большие и малые цели, контрольные события и результаты. 10.5. Начинать выполнение проекта до тех пор, пока содержание не будет рассмотрено независимыми экспертами. 6.5.4. Изменения содержания В реальных ситуациях возникает необходимость изменять содержание проекта. Возможно, оказывается невозможным реализовать проект в полном объеме за указанные сроки или в рамках выделенных ресурсов. Возможно, открываются новые перспективы и старое содержание устаревает. Вначале предпринимаются действия по сохранению существующего содержания. Изыскиваются резервы для реализации проекта в срок; воплощение новых идей переносится в новый проект. Но всё же бывает, что изменения необходимы. Сложность их внесения заключается в том, что при выполнении проекта имеется некоторое противостояние между заказчиком и исполнителем. Причем оно проявляется и обостряется именно в процессе выполнения проекта. Состоит оно в том, что заказчик хочет получить результат побольше за те же или за меньшие деньги, а исполнитель – получить побольше денег, сделав поменьше. Поэтому всякая инициатива какой-либо стороны по изменению содержания проекта рассматривается другой прежде всего именно на предмет возможного ущемления своих интересов. Для простых проектов в договоре пишется: изменения возможны только по взаимному согласию сторон. Это взаимное согласие подтверждается двусторонним актом, в котором, например, говорится: Ограничение 2 «двигатель весом не более 10% от грузовика» читать: «двигатель весом не более 15% от грузовика»3. Еще один пример: при проектировании трансатлантического лайнера Куин Мери 2 его ширина была, согласно общепринятой практике, задана не более ширины Панамского канала. Однако для обеспечения комфорта пассажиров это требование пришлось впоследствии изменить. В общем случае требуется заранее определить следующие моменты. 1. Определяется, кто уполномочен утверждать изменения? Порядок оформления изменений практически совпадает с порядком подписания договора. Для крупных проектов зарубежные специалисты предлагают даже создавать комитет по рассмотрению изменений. 2. Изменения обычно разделяют на существенные и несущественные. Кроме того, они разделяются по типам: финансовые, маркетинговые, технические. В связи с этим решаются следующие вопросы. • Как определить существенность изменений? • Каков порядок работы с изменениями разных уровней существенности и разных типов? 3. Задается точная процедура работы с изменениями: формы всех документов, порядок их рассмотрения. 4. Создается определенный управленческий резерв. Для ослабления риска изменений следует выделить некоторую денежную сумму в качестве управленческого резерва и определить порядок его использования. 5. Определяется порядок реализации изменений. 6.6. Бизнес-план проекта 6.6.1. Состав бизнес-плана Перед тем, как вкладывать в проект большие средства, необходим его технико-экономический анализ. Этот этап особенно важен для проектов строительства предприятий. Эти проекты требуют больших затрат, занимают длительное время, и необходимо еще до начала реализации проекта убедиться, что затраты окупятся. Но технико-экономический анализ актуален и для других типов инвестиционных проектов. Для того, чтобы проект могли оценить заказчики, исполнители, инвесторы, эксперты, необходимо его подробное описание. В последние годы такие описания широко распространились в форме бизнес-планов. Бизнес-план – это подробный, четко структурированный и тщательно подготовленный документ, описывающий цели и задачи, которые необходимо решить организации, способы достижения поставленных целей и технико-экономические показатели организации и/или проекта в результате их достижения. В бизнес-плане содержится оценка текущего момента, сильных и слабых сторон проекта, анализ рынка и информация о потребителях продукции или услуг. Бизнес-план дает возможность понять общее состояние дел на начальный момент; ясно представить тот уровень, которого может достичь проект (организация) в результате реализации проекта; видеть процесс перехода от одного состояния в другое. Точная структура и название подобного документа определяется сложившейся для различных типов проектов практикой. Например, для различного вида строительных проектов составляется «Обоснование инвестиций», вид которого можно найти в Строительных нормах и правилах (СНиП). Примерный состав обоснования инвестиций для проекта строительства промышленного предприятия имеет следующий вид. 6. Резюме проекта. Эта вводная часть имеет особое значение. Как правило, она пишется уже после того, как составлен весь план. Занимая не более 2—3 страниц, она фактически трактуется как самостоятельный рекламный документ, т. к. в ней содержатся основные положения всего бизнес-плана. В этой части указываются: название и адрес предприятия; имена и адреса учредителей; основные положения предлагаемого проекта, его суть и цель; ожидаемый эффект; потребности в финансах. Вводная часть должна быть написана так, чтобы вызвать интерес у потенциального инвестора. По содержанию вводной части инвестор часто судит о том, стоит ли ему терять время дальше и читать план до конца. 1. Общая характеристика отрасли и предприятия. 2. Исходные данные и условия. 2.1. Цели и задачи проекта. 2.2. Характеристика объектов и сооружений. 2.2.1 Мощность предприятия, номенклатура продукции. 2.2.2 Основные технологические решения. 2.2.3 Основные строительные решения. 2.3. Место размещения предприятия. 2.4. Обеспечение предприятия ресурсами. 2.5. Окружение проекта. 2.6. Оценка воздействия на окружающую среду. 2.7. Текущее (исходное) состояние проекта. 2.8. Кадры и социальное развитие. 3. Анализ рынка. 3.1. Характеристика рынка продукции проекта. 3.2. Оценка конкурентоспособности продукции проекта. 3.3. Прогноз развития рынка продукции проекта. 3.4. Прогноз спроса на продукцию проекта. 4. Управление проектом. 4.1. Укрупненная структура работ. 4.2. План проекта. 4.3. Структура управления проектом. 4.4. Команда проекта. 5. Оценка эффективности проекта. 5.1. Исходные данные и результаты расчета. 5.2. Финансовый план. 5.3. Анализ рисков. 6. Приложения. Для недороги проектов, занимающих небольшое время, состав этого документа может быть упрощен. Видно, что составление бизнес-плана – довольно сложный процесс, связанный с исследованиями, оценками и расчетами. Сложность данного этапа состоит в том, что он проводится еще до инвестирования. Поэтому масштабные работы развернуть невозможно. Приходиться широко пользоваться экспертными, предварительными оценками, применять упрощенные методы расчета. Анализ проектов стал самостоятельной, динамично развивающейся областью знаний. Работы выполняет специально создаваемая заказчиком группа, состоящая из: • специалистов по маркетингу. Их задача — ответить на вопрос, сколько и по какой цене можно продать продукции проекта; • производственников, оценивающих вероятную стоимость продукции и требования к сырью; • финансистов, оценивающих затраты на проект и определяющих источники и размеры финансирования; • специалистов, собирающих информацию об окружении проекта, законодательных и нормативных актах и др., имеющую большое значение для конкретного проекта; • полезно привлекать для составления бизнес-плана сторонних консультантов. Они помогут увидеть проект «снаружи», дать информацию по специальным вопросам. Средние затраты на технико-экономическое обоснование составляют, по данным Всемирного банка, в процентах от стоимости проекта: • формирование инвестиционного замысла проекта (инвестиционные предложения, декларация о намерениях) – 0,2—1%; • исследование инвестиционных возможностей (обоснование инвестиций, краткое технико-экономическое обоснование) – 0,25—1,5%; • технико-экономическое обоснование строительства – 1,0—3,0% (для небольших проектов) и 0,2—1,0% (для крупных). Утвержденное обоснование может использоваться заказчиком: • для выбора наилучшего варианта из нескольких представленных проектов, для этого проводятся их экспертный анализ и сравнение; • для переговоров с потенциальными инвесторами, которые должны в деталях представлять сущность предлагаемого проекта; • для переговоров с органами исполнительной власти о предоставлении ему субсидий, налоговых и иных льгот; • для проведения дальнейших исследований, например – опросов общественного мнения; • для получения разрешений и актов экспертизы. 6.6.2. Исходные данные Типовой состав исходных данных для бизнес-плана. 1. Прогнозы экономического и социального развития целевых научно-технических и комплексных республиканских программ. 2. Копии решений государственных и местных органов по проекту. 3. Сведения о состоянии ресурсов, вовлекаемых в хозяйственную деятельность будущего объекта (предприятия), окружающей природной среды в предполагаемом районе строительства, об инфраструктуре, о рекреационных и особо охраняемых территориях. 4. Сведения о возможности применения на объекте (предприятии) импортного оборудования. 5. Примерная производственная программа в денежном и натуральном выражении, номенклатура основной и попутной продукции, требования к ее качеству и конкурентоспособности. 6. Общая характеристика объекта строительства (предприятия), сведения для определения его оптимальной мощности. 7. Заключение Антимонопольного комитета о невозможности или нецелесообразности увеличения производства на существующих предприятиях. 8. Результаты выполненных ранее научно-исследовательских и опытно-конструкторских работ по технологическим процессам, оборудованию, исследованиям существующего рынка и тенденций его развития и т. д. 9. Выкопировки из утверждений в установленном порядке проектно-планировочной документации с указанием предполагаемой площадки (площадок) строительства и возможных мест присоединения к сетям и коммуникациям. 10. Данные о подлежащих сносу при строительстве объекта зданиях и сооружениях, примерное число переселяемых граждан. 11. Результаты маркетингового анализа по выпускаемой продукции: объема рынка, цен, оценка маркетинговых затрат. 12. Другие данные, характеризующие особенности намечаемого к строительству объекта. 6.6.3. Сбор информации и прогнозы На первом этапе исследований на уровне Российской Федерации, региона, города, района, квартала изучают следующее: • генеральную схему расселения, природопользования и территориальной организации производительных сил регионов и РФ; • прогноз экономического и социального развития РФ; • прогнозы деловой активности иностранных и отечественных компаний в регионе; • территориальные комплексные схемы охраны природы и природопользования зон интенсивного хозяйственного освоения и уникального значения, включающие мероприятия по предотвращению и защите от опасных природных и техногенных процессов; • документы государственного регулирования инвестиционной деятельности в регионе осуществления проекта. • отраслевые прогнозы; • генеральные планы городов, других поселений и их систем, а также жилищных, промышленных, рекреационных и других функциональных зон; • градостроительные прогнозы и программы; • схемы и проекты районной планировки, административно-территориальных образований; • проекты детальной планировки общественных центров, жилых районов, магистралей городов; • проекты застройки кварталов и участков городов и других поселений. Из состава бизнес-плана видно, что требуется большой объем маркетинговых исследований. Порядок их проведения изучался в курсе «Маркетинговые исследования». Информацию о спросе, размере рынка и конкуренции можно получить, обратившись в соответствующие специализированные организации или проведя собственные исследования. Источником информации могут стать публикации отраслевых ассоциаций, правительственные отчеты и статьи в научных журналах. Требуется также много внутренней информации об организации, где будет выполняться проект. Она собирается и предоставляется самыми различным специалистами: экономистами, маркетологами, технологами. Большую часть информации о производственных потребностях можно получить у производителей аналогичной продукции. Многие показатели проекта на этом этапе приходится определять путем прогнозирования, экспертными методами или по аналогии. Для оценки финансовой части проекта используются обычные формы отчетов: • балансовый отчет; • отчет о прибылях и убытках; • отчет о движении денежных средств. • Необходимо использовать существующие к моменту проведения анализа документы, сделать на основе их данных прогнозы, которые удобно представить в таком же стандартном виде. Если проект строительный, проводится выбор и согласование места размещения объекта, экологическое обоснование проекта. Порядок проведения и состав документов повержены изменениям и сильно зависят от предполагаемого места размещения объекта (промзона, исторический центр). В этих работах участвуют: заказчик, местная администрация, органы государственной экспертизы, генпроектная организация. На основе результатов проделанной работы формируются: • план проектно-изыскательских работ; • предварительный план реализации проекта в целом для оценки длительности, структуры проекта, и состава необходимых исполнителей; • предварительная смета проекта. Этап выполняется инвестором (заказчиком) с привлечением необходимых экспертов, в том числе в области управления проектами. 6.6.4. Основные технико-экономические показатели проекта Проекты, которые рассматриваются в данном курсе, в большинстве своем инвестиционные, то есть требуют значительных единовременных затрат на планирование и реализацию4. К тому же многие проекты требуют затрат на закупку оборудования, приобретение или строительство зданий и сооружений. И лишь через определенное время произведенные затраты начинают окупаться. Для инвестиционных проектов требуется определить целесообразность реализации проекта, то есть своевременный возврат инвестиций и получение прибыли от реализации проекта. При этом возможны два основных варианта таких проектов. • Создаются или приобретаются основные средства (недвижимость, оборудование), которые затем работают длительное время. Это может быть приобретение или строительство завода или магазина, расширение производства и т.д. Для анализа выбирается определенный горизонт планирования. До кризиса 2008 года большинство организаций перешли на трехлетнее планирование, некоторые – даже на пятилетнее, однако кризис внес свои коррективы, поэтому по большей части реализуются проекты, окупающиеся за год. Тем не менее, если речь идет о строительстве крупного предприятия, то планировать приходится на 5…10 лет. • Осуществляется временный бизнес-план, после которого проект ликвидируется; это может быть проект магазина по продаже СD у метро (сразу было очевидно, что это временный бизнес, во-первых, из-за развития сети Интернет, позволившей скачивать фильмы и программы, во-вторых, из-за временного договора аренды площадей), проект добычи и продажи сапропеля со дна озера и т.п. В этом случае длительность проекта обычно определена заранее, а в конце приобретенные основные средства и прочие активы реализуются. Для оценки проекта его сравнивают с некоторым базовым вариантом, оценивая как дополнительные инвестиции, так и дополнительные текущие доходы и расходы. Обычно в качестве базы при оценке одного или нескольких вариантов проекта принимается ситуация, когда проект вообще не реализуется. Например при оценке проекта реконструкции предприятия следует сравнивать показатели результатов реализации проекта с показателями действующего предприятия, а при намерении построить новое предприятие – с ситуацией без строительства нового предприятия. Типовой расчет по технико-экономическому обоснованию можно нейти в [Гаранин. Методические указания по ТЭО], табл. Таблица 7. Обычно для оценки используются чистый дисконтированный доход, индекс доходности и срок окупаемости. Для общей оценки используются чистый дисконтированный доход и индекс доходности в конце проекта (выделено жирным шрифтом). Таблица 7 Расчет технико-экономических показателей инвестиционного проекта, тыс. руб. Номер периода n (число периодов конечно) 0 (старт проекта) 1 2 3 Длительность шага – квартал (варианты: год, месяц) Показатели Операционная деятельность 1. Денежные притоки (выручка от реализации) 435 435 435 2. Денежные оттоки (стр.2.1+стр.2.2) 412 412 412 2.1. Прирост переменных издержек 305 305 305 2.2. Прирост постоянных издержек 107 107 107 3. Сальдо денежного потока от операционной деятельности Dn (стр.1 – стр.2) 23 23 23 Инвестиционная деятельность 4. Денежные притоки Ln (ликвидационная стоимость) 5. Денежные оттоки Kn (инвестиции) 60 7. Сальдо денежных потоков Dn+Ln-Kn (стр.3 + стр.4 – стр.5) -60 23 23 23 9. Коэффициент дисконтирования 1,00 0,95 0,90 0,86 10. Чистые денежные поступления (стр.7 х стр.9) -60 23 23 22 11. Чистый дисконтированный доход -60 -37 -14 8 23 23 22 23 46 68 60 60 60 60 60 12. Индекс доходности 0,4 0,8 1,1 13. Срок окупаемости, периодов (количество периодов до того момента, когда PIn станет больше 1. 3 Финансовая реализуемость – показатель, принимающий два значения: «да» или «нет» и характеризующий наличие финансовых возможностей осуществления проекта. Проект финансово реализуем, если на каждом шаге расчета сумма денежных притоков и оттоков проекта для всех участников является неотрицательной. Если надо производить затраты, то вначале надо взять кредит. 6.6.5. Проектный анализ Проектный анализ – это расчет ожидаемых результатов проекта и их оценка с целью принятия решения о начале проекта, его продолжении, развитии, сужении его рамок или полном досрочном прекращении. Проектный анализ осуществляется не только на предынвестиционной фазе, но и во время выполнения проекта, практически до самого его завершения. При этом точность растет со временем, так как неопределенность снижается по мере движения к завершению проекта. Ввиду того, что наибольший объем подобных работ приходится проводить для строительных проектов, структура проектного анализа будет дана именно для них. Технический анализ В рамках технического анализа инвестиционных проектов изучают следующие аспекты. 1. Технико-технологические альтернативы принятых решений. 2. Варианты местоположения строящегося объекта. 3. Размер (масштаб, объем) проекта. 4. Сроки реализации проекта в целом и его фаз. 5. Доступность и достаточность источников сырья, рабочей силы и других потребных ресурсов. 6. Емкость рынка для продукции проекта. 7. Затраты на проект с учетом непредвиденных факторов. 8. График работ проекта. Коммерческий анализ Задача коммерческого анализа – оценить проект с точки зрения конечных потребителей продукции или услуг, предлагаемых проектом. В общем виде решаемые при этом задачи можно свести к трем типам. 1. Маркетинговые задачи. 2. Определение источников и условий получения ресурсов. 3. Определение условий производства и сбыта. Вот перечень типовых вопросов, на которые дает ответ коммерческий анализ. 4. Где будет продаваться продукция? 5. Имеет ли рынок достаточную емкость, чтобы поглотить всю выпускаемую продукцию без влияния на ее цену? 6. Если вероятно подобное влияние на цену, то каково оно? 7. Останется ли проект жизнеспособным, с финансовой точки зрения, при новой цене? 8. Какую долю общей емкости рынка может обеспечить предлагаемый проект? 9. Предназначена ли выпускаемая продукция для местного потребления или идет на экспорт? 10. Какие финансовые мероприятия потребуются для продвижения продукции на рынок и какие резервы надлежит предусмотреть в проекте для финансирования маркетинга? 11. Способны ли существующие методы поставок гарантировать своевременность поставок и устранить перебои? 12. Практикуются ли конкурсные торги для установления справедливых цен? 13. Кто разрабатывает спецификации на необходимые закупки? Экологический анализ Важность экологического анализа обусловлена тем, что взаимоотношения между деятельностью человека и окружающей средой недостаточно изучены. Но их надо оценить хотя бы качественно. Неверные экологические решения приводят к необратимым изменениям в окружающей среде. Например, так и нет единого мнения, влияет ли человек на климат. Извержение вулкана дает мощнейшие воздействия. Есть данные, что влияние человека составляет лишь порядка 1% от влияния природных эффектов. Сейчас много говорят о глобальном потеплении. Но что здесь правда, а что – самореклама ученых или выгодная кому-то шумиха? Недавно ученые исследовали парадокс молодого Солнца. Раньше оно было холоднее. Но на Земле было тепло. Парниковый эффект повышал температуру на 30О. Потом солнце нагревалось, а парниковый эффект снижался из-за того, что бактерии связывали азот, а растения – углекислый газ. Подвижки земной коры уносили эти элементы вглубь. Сейчас повышение температуры из-за парникового эффекта оценивается в 18 О. Принимаемые решения по охране окружающей среды на химкомбинате под Тулой оценивались количеством незасохших вновьпосаженных елок в Ясной Поляне, усадьбе Л.Н.Толстого. Экологические последствия огромного разлива нефти в Мексиканском заливе летом 2011 года еще требуется уточнить. Итак, требуется оценить, в чем будет вред созданного в результате реализации проекта предприятия, и что делать, чтобы его снизить до допустимого уровня. По данным Всемирного банка, расходы на необходимые меры по защите окружающей среды составляют не более 3% общих затрат на проект. Существенно больших — до 10% — затрат требуют те проекты, которые нуждаются во включении защитных мер после завершения их разработки (например, рекультивации отработанного карьера). Требования к оценке воздействия хозяйственной деятельности предприятия на отдельные компоненты окружающей среды изложены в [Указания к экологическому обоснованию хозяйственной и иной деятельности в предынвестиционной и проектной документации. Министерство охраны окружающей среды и природных ресурсов Российской Федерации; Главное управление государственной экологической экспертизы 15 июля 1994 года]. Организационный анализ Цель организационного анализа – оценить организационную, правовую, политическую и административную обстановку, в рамках которой проект должен реализовываться и эксплуатироваться, а также выработать необходимые рекомендации в части: • менеджмента; • организационной структуры; • планирования; • комплектования и обучения персонала; • финансовой деятельности; • координации деятельности; • общей политики. Основные задачи организационного анализа: • оценка возможного влияния законов, политики и инструкций на судьбу проекта — особенно в части защиты окружающей среды, заработной платы, цен, государственной поддержки, внешнеэкономических связей; • определение действий участников проекта, связанных с соблюдением действующего законодательства и подзаконных актов (инструкций, регламентов и пр.); • оценка сильных и слабых сторон участников проекта с точки зрения материально-технической базы, квалификации, структур, финансового положения; • разработки мер по устранению слабых сторон участников проекта, выявленных в процессе анализа, а также снижению отрицательного воздействия окружения проекта (законы, политика, инструкции); Социальный анализ Цель социального анализа – определение пригодности вариантов плана проекта для его пользователей. Результаты социального анализа должны обеспечить взаимодействие между проектом и его пользователями, их поддержку в достижении целей проекта. Социальный анализ сосредотачивает внимание на 4 основных областях: • социально-демографические и экономические характеристики населения, затрагиваемого проектом от половозрастного состава до распределения доходов; • социокультурные характеристики, особенно в части приемлемости проекта для местной культуры; В Корее с трудом пробивали дорогу заведения типа Мак-Дональдса, так как европейская пища невкусна для местного населения (прежде всего – недостаточно остра. Основные виды социальных результатов проекта, подлежащих отражению в расчетах эффективности: • изменение количества рабочих мест в регионе; • улучшение жилищных и культурно-бытовых условий работников; • изменение условий труда работников; • изменение структуры производственного персонала; • изменение надежности снабжения населения отдельными видами товаров; • изменение уровня здоровья работников и населения; • изменение свободного времени населения. Предусматриваемые проектом мероприятия по созданию работникам нормальных условий труда и отдыха, обеспечению их продуктами питания, жилой площадью и объектами социальной инфраструктуры – обязательные условия реализации проекта и какой-либо самостоятельной оценке в составе результатов проекта не подлежат. Результаты анализа, проведенного на предынвестиционной фазе, заносятся в бизнес-план. *** По бизнес-плану принимается решение об инвестировании проекта, а в случае нескольких альтернатив – выбирается наиболее предпочтительная. 7. Организационная структура проекта В данном разделе будет рассматриваться в основном организационная структура управления проектом, а не все организацией. Организационная структура управления проектом является управляющей моделью в рамках подсистемы управления персоналом проекта [Разу]. Она определяет состав человеческих ресурсов, необходимых для успешной реализации проекта, а также систему взаимодействия между ними. Она включает полномочия участников, ответственность, коммуникации. Проект не всегда подразумевает создание специальной команды. Бывает, что над проектом работают сотрудники различных организаций. Но в любом случае необходима координация действий участников проекта. Этим и объясняется сложность и многовариантность оргструктур проекта. Здесь, вслед за [Разу, Шапиро], рассматриваются схемы оргструктур, раскрывающие не конкретные детали существующих вариантов, а принципы их создания. 7.1. Типы оргструктур управления проектами Выделенная Специально создается для разовых внутрифирменных проектов (рис. Рис. 27. Созданной структуре передаются ресурсы (например, оборудование). Когда структура ликвидируется после завершения проекта, ресурсы возвращаются в подразделение организации, где они были исходно. Количество работников, включаемых в оргструктуру проекта, а также ее сложность, могут быть самыми разными. Различается и степень выделенности. Она варьируется от отдельного независимого предприятия, контролируемого только на высшем уровне, до структурного подразделения внутри организации, взаимодействующего с другими подразделениями материнской структуры. Рис. 27. Выделенная оргструктура Часть оргструктуры организации Если организация ориентирована на выполнение проектами, оргструктуры управления проектами становятся ее органичной постоянной частью (Рис. Рис. 28). Появляется уровень управления – руководители проектов (средний уровень на рис. Рис. 28). Они руководят работниками в рамках своих проектов. При этом некоторые работники могут быть задействованы в нескольких проектах. В различных проектах используются одни и те же ресурсы, принадлежащие организации (например, вычислительная техника). Чаще возникает некоторая промежуточная ситуация, когда часть оргструктуры основывается на традиционном функциональном принципе (бухгалтерия, кадровая служба, служба безопасности), а часть реализует вышеописанную схему управления проектами. По последнему принципу обычно строится и научно-исследовательская деятельность вузов. Существуют научно-исследовательские группы более или менее постоянного состава, возглавляемые научным руководителем. Они заключают договоры на выполнение различных работ по своему профилю. В эти группы могут входить и преподаватели, в своей основной деятельности подчиняющиеся заведующим кафедрами. Такие группы пользуются услугами экономических и других служб вуза. Рис. 28. Управление проектами в оргструктуре организации Двойственная оргструктура Если в проекте участвуют две организации, играющие примерно одинаковую роль, то используется двойственная оргструктура управления проектом. Например, для выполнения проекта может быть создано новое юридическое лицо, учредители которого – организации-участники – входят на равных правах в органы управления нового юридического лица (общее собрание акционеров, совет директоров, ревизионная комиссия, правление). Может создаваться и комитет, управляющий проектом, в который входят представители организаций-участников проекта. Сложные оргструктуры В более сложных случаях структура управления проектом и ее взаимосвязь с оргструктурами участвующих в проекте организаций могут быть самыми различными. На рис. Рис. 29 показан пример оргструктуры управления проектом, в которой задействованы заказчик, генеральный подрядчик (проектно-ориентированная организация), и подрядчики, выполняющие определенные виды работ. Оставляя в стороне юридическое оформление договорных отношений, рассмотрим только взаимосвязи, обеспечивающие управление проектом. От организации-заказчика, осуществляющей, например, внедрение новой информационной системы работы с клиентами, с проектом обычно работает представитель – менеджер среднего звена. Это может быть, например, начальник службы информационных технологий (1). Он работает с руководителем проекта – сотрудником организации, разрабатывающие и внедряющей подобные системы (2). В свою очередь, один из исполнителей проекта, например, отвечающий за оборудование (3), занимается с руководителем проекта по комплектации и поставкам оборудования, которую проводит субподрядная организация (4). Рис. 29. Пример сложной оргструктуры управления проектами. 7.2. Зависимость оргструктуры от ориентации на функции или на процессы В [Разу, Шапиро] предлагается рассматривать вертикальные структуры как структуры, обеспечивающие функции управления, а горизонтальные – как структуры, обеспечивающие выполнение процессов проекта. Вертикальная структура Традиционно для управления в организациях используется вертикальная, функциональная структура, ориентированная на жесткое управление. Именно она показана на предыдущих рисунках. В типовом случае такая структура имеет следующий вид. Генеральному директору подчиняются несколько директоров (технический, коммерческий, финансовый, директор по информационным технологиям, директор по маркетингу и т.д.), у каждого из которых в подчинении находится служба – крупное подразделение, состоящее из нескольких отделов. Кроме этого, у самого генерального директора имеются набор подчиняющихся ему непосредственно подразделений (например, юридический отдел) и работников (например, секретарь). В службах выделяются отделы (бухгалтерия, отдел кадров, отдел маркетинга и т.д.). В отделах могут формироваться группы (группа рекламы в отделе маркетинга). Производственную часть возглавляет главный инженер. Она состоит из цехов, разбивающихся в свою очередь на участки и бригады. Главному инженеру могут подчиняться отдел технического контроля, конструкторский отдел и другие отделы, тесно связанные с производством. В книгах по теории организации, наряду с достоинствами, приводят и множество недостатков такой структуры. Тем не менее, она остается основной для организаций различного размера и видов деятельности. Во-первых, успех деятельности организации, в том числе с функциональной структурой, зависит от организационной культуры. Если для того, чтобы услышать пожелания своего коллеги, требуется указание непосредственного начальника и официальный письменный запрос, то вряд ли проектная, да и другая деятельность будет успешна. Во-вторых, руководитель, наделенный формальными полномочиями, играет большую (чаще положительную) роль в достижении успеха, жестко организуя и контролируя работу. Наиболее естественный путь выполнения проектов в организациях с функциональной структурой состоит в том, что руководитель структурного подразделения становится руководителем проекта. Например, руководитель службы информационных технологий управляет внедрением новой информационной системы силами работников своей службы. Недостатки функциональной структуры проявляются в проектах, требующих усилий специалистов в различных областях. Для таких случаев используется механизм посредников. Посредники – это отдельные люди или группы людей, которые облегчают взаимодействие между подразделениями. Примером посредника может служить специалист по компьютерной технике. Он может значительно облегчить внедрение информационной системы, автоматизирующей функции отдела кадров, отдела труда и зарплаты, бухгалтерии. Он занимается и проектами автоматизации других подсистем управления предприятием, например, внедрением системы управления работой с клиентами (CRM). Следующий шаг усиления горизонтальных связей – команды. Они создаются как на временной, так и на постоянной основе. Продолжая рассмотренный пример, можно выделить команду, состоящую из программистов, специалистов по компьютерной технике, специалистов по компьютерным сетям, рабочих. Подобных команд может быть в организации несколько, причем работник может входить более, чем в одну команду. Команды действуют в рамках проекта, хотя формально подчиняются руководителям своих структурных подразделений. Проекты разработки и вывода на рынок новых продуктов требуют тесного взаимодействия отдела продаж, отдела маркетинга, отдела маркетинговых исследований, производства. Руководство разработало и утвердило план развития организации. Отдел продаж запланировал сроки вывода на рынок, отдел маркетинговых исследований определил пожелания потребителей. Технологический отдел разработал технологию производства, производственники внедрили этот процесс, снабженцы обеспечили сырье и комплектующие изделия. Отдел сбыта заключил договора на поставки готовой продукции. При этом необходимы согласования, поиск компромиссов. Общее руководство таким проектом может взять на себя главный конструктор или коммерческий директор. Подобные команды, состоящие из работников различных подразделений, могут заниматься и проектами для сторонних организаций, но главная проблема состоит в том, что управление проектом усложняется. Прежде всего это происходит из-за необходимости согласований планов работы с заказчиком, предоставлении ему результатов работы, фиксации факта выполнения работ и т.д. Для этого руководитель проекта должен быть освобожден от других обязанностей. Итак, использование команд целесообразно в небольших или средних нересурсоемких проектах в рамках одной организации, в средних нересурсоемких проектах. Это может быть создание и/или внедрение программного обеспечения или обучения работников. Во многих зарубежных фирмах (например, General Electric, General Motors, Volvo) существуют команды. Обычно это бригады, кружки качества, группы энтузиастов. Общей чертой таких образований можно назвать их инициативность: в такие команды входят по убеждениям. Устойчивую эффективно работающую команду трудно создать по приказу. Матричные структуры (Рис. Рис. 30) – следующий шаг на пути усиления роли процессов в противовес функциям управления. Рис. 30. Матричная оргструктура Видно, что помимо традиционных функциональных подразделений, в подчинении руководителя организации (верхний блок) находятся руководители проектов. Они подчиняются ему либо непосредственно, либо, как показано на рисунке, через руководителя программы (проектной части). Вертикальные блоки обычно соответствуют отделам или цехам. Горизонтально вытянутые блоки представляют собой проекты. Видно, что для их исполнения задействованы различные функциональные подразделения. Квадраты, образуемые пересечением горизонтальных и вертикальных блоков, обычно представляют собой функциональные подразделения более низкого уровня: это группы, участки, отдельные работники. Особенность данной структуры (и ее основной недостаток!) стоит в двойном подчинении таких подразделений. Работники, назначенные на проект на полную или частичную занятость, работают в своих функциональных подразделениях. Руководитель проекта определяет, когда и что должно быть сделано, а функциональный руководитель определяет, кто будет назначен на проект и какие технологии следует применять для выполнения задач по проекту. Функции руководителей проекта могут быть различными. В слабой матричной структуре они просто координаторы, диспетчеры, контролирующие ход работ по своему проекту, и информирующие об этом руководство. В сильной матричной структуре их функции гораздо шире. У каждого руководителя проекта даже может быть собственный штат. Матричные структуры используются в банковском деле и страховании, производстве вычислительной техники, в больницах, правительственных и учебных учреждениях. Применение матричных структур целесообразно в технологически сложных проектах, где необходимо применять большое количество различных технологий, традиционно находящихся в ведении разных функциональных областей. Матричные организационные структуры вызывают острые споры. Их преимущества не абсолютны, и применять их надо с большой осторожностью. Структура, в которой приоритет безусловно принадлежит процессам проекта, называется проектно-целевой (рис. Рис. 31). Здесь под началом руководителей проектов появляется собственная оргструктура, в которую могут входить собственные отделы: опытно-конструкторские, финансовый, маркетинга, а также производственные подразделения, например, опытные цеха и участки. Рис. 31. Проектно-целевая структура К проектно-целевым относятся дивизиональные структуры, создаваемые для выполнения определенных задач • в географических регионах; • в отдельных секторах рынка; • для определенного вида клиентов (потребителей); • связанных с созданием и (или) продвижением отдельных видов товаров. Выбор типа оргструктуры определяется конкретными условиями и традициями организации. Существует целый спектр смешанных оргструктур. В качестве примера можно привести частично матричную структуру, в которой матричная схема рис. Рис. 30 затрагивает только часть функциональных подразделений. Тип оргструктуры не является чем-то неизменным. Например, на момент инициации проекта в нем может быть задействована небольшая группа специалистов, объединенных в команду. По мере созревания проекта в его организационную структуру вводятся необходимые сотрудники и отделы, а по мере движения к завершению проекта освобождающиеся ресурсы выводятся из этой организационной структуры. Подводя итог, следует отметить, что вопрос разработки оргструктуры весьма сложен. В данной работе он был лишь затронут. Более подробно вопросы выбора принципа создания оргструктуры приводятся в [Разу, Шапиро], а для детальной разработки оргструктуры требуются высококвалифицированные специалисты. Рис. 5.5.2. Общая последовательность разработки и создания организационных структур управления проектами 7.3. Офис проекта 7.3.1. Понятие офиса проекта Это понятие [МазурШапиро] ново для Росси, в мире оно тоже появилось не очень давно. Как уже отмечалось, в крупном проекте имеется ряд участников, среди которых: - руководитель (менеджер) проекта; - менеджеры и специалисты по направлениям деятельности; - ряд функциональных работников (секретарь, системный администратор, курьер). Специфика их деятельности: • команда временная; • ее состав непостоянен; • работники заняты неполный рабочий день; • работники обычно занять еще и на другой, постоянной работе; • территориально они расположены в разных местах. Значит, нужна некоторая инфраструктура, обеспечивающая выполнение проекта. Это не просто место. Офис проекта – специфическая инфраструктура, обеспечивающая эффективную реализацию проекта или портфеля проектов на базе компьютерных, коммуникационных и информационных технологий, а также отработанных стандартов осуществления деятельности и коммуникаций. Основное назначение офиса проекта в данной трактовке – обеспечение эффективной коммуникации членов команды проекта. Состав офиса проекта. • определенный набор рабочих мест, привязанных к конкретным географическим координатам, в том числе ◦ головной офис, где размещается менеджер проекта, хранится основная документация, проводятся важные совещания, установлены средства связи, компьютерное оборудование, оргтехника и пр.; ◦ набор территориально распределенных офисов (оборудованных рабочих мест, в том числе домашних, мобильных) отдельных групп или членов команды проекта, где установлены средства коммуникаций, компьютеры, оргтехника; • виртуальный офис. Виртуальный офис представляет собой не привязанную к определенному месту программно-телекоммуникационную среду, обеспечивающую возможность работы и коммуникаций по единым стандартам. Основа виртуального офиса – распределенная компьютерная система на базе телекоммуникационных сетей, позволяющая пользоваться едиными программными средствами, едиными базами данных и знаний, вести единый учет, контроль, мониторинг работ по проекту, проводить видеоконференции, телекоммуникационные совещания в реальном режиме времени. В современных условиях это «Notebook + модем + мобильный телефон». В однопроектной системе офис ориентирован на управление конкретным проектом. В многопроектной системе офис проекта, как правило, представляет собой многоуровневую систему: • на первом уровне этой системы рассматриваются конкретные проекты и принципы их мониторинга. Здесь используются традиционные инструменты и информационные технологии мониторинга проектов; • на втором уровне рассматриваются вопросы формирования портфеля проектов организации, их взаимосвязи и рационального наполнения. Базовыми на этом уровне являются: инструменты тендеров (для пополнения портфеля заказов), стратегического менеджмента, управления общими ресурсами и управления качеством в проектах; • на третьем уровне решаются задачи корпоративной политики развития проектной организации. Экспертная оценка показывает: такой подход определяет 30—40% экономии затрат на проекты и времени их реализации. Основные требования к организации офиса проекта: • наличие реального управленческого офиса – помещения; • единые внутрифирменные стандарты подготовки и сопровождения проектов (проекта); • единая информационная технология управления проектами; • база данных и шаблонов типовых решений по проектам; • компьютерная сеть, сообщающаяся с Internet; • виртуальный офис на базе компьютерных сетей, обеспечивающий функционирование команды проекта в режиме реального времени, несмотря на территориальную распределенность членов команды. Для системы дистанционного образования также разработан ряд подобных систем. Одна из распространенных – Moodle. Поддерживаются различные способы контроля знаний: не только задания, присланные в текстовом виде, но и различные тесты. Вся активность участников и достигнутые результаты фиксируются. Для общения используются форумы. Основное программное обеспечение имеет интерфейс более чем на 50 языках. Имеются дополнительные разработки, увеличивающие функциональность, например, система «Деканат». Функционирование обеспечивают администраторы. А главные участники – студенты и преподаватели. С помощью подобных систем организуются курсы для студентов, находящихся в других городах, проводятся совместные занятия и программы для студентов из разных стран. Система Moodle может быть дополнена системой телекоммуникаций Adobe Connect, позволяющей вести сеансы онлайнового общения между отдельными участниками, а также в группах. 7.3.2. Состав виртуального офиса проекта В состав виртуального офиса проекта входят следующие элементы. 1. Центральный офис, где находится руководитель проекта, административные работники и оборудование, необходимое для его работы: компьютер, коммуникационное оборудование и оргтехника. 2. Удаленные рабочие места (по месту основной работы участников или на дому). 3. Мобильные рабочие места (ноутбуки или коммуникаторы). 4. Мобильные коммуникационные устройства (мобильные телефоны, устройства видеосвязи). 5. Сервер, на котором находится центральная база данных проекта. Расположение сервера может быть различным. Если он находится в центральном офисе, нужно организовать его обслуживание и защиту от вирусов. Можно арендовать вычислительные мощности у провайдера, связываясь с сервером через Интернет. 6. Каналы коммуникации: Интернет, Интранет. Первый канал – глобальная сеть, второй – закрытая от внешнего мира сеть организации. 7. Оборудование, обеспечивающее работу каналов связи: роутеры, модемы… Функциональные части офиса проекта: Работники • Оборудование • Программное обеспечение • Базы данных (могут находиться на сервере и на отдельных компьютерах). • Документы. 7.3.3. Принципы организации офиса проекта 1. Использование CALS-технологий (Continuous Acquisition and Life Cycle Support – непрерывная технология сбора данных и поддержки жизненного цикла). В основе этих технологий лежит набор интегрированных информационных моделей самого жизненного цикла; выполняемых в его ходе бизнес-процессов; продукта (изделия); производственной и эксплуатационной среды и пр. 2. Онлайновая и оффлайновая коммуникация. Это обеспечит максимальное удобство обмена информацией. 3. Надежность работы, высокий коэффициент готовности. Система должна находиться в работоспособном состоянии практически постоянно. Вероятность потери данных должна быть минимизирована. 4. Достоверность данных в системе. Здесь особенно опасно наличие различных версий одного и того же документа, в том числе и устаревших. Это достигается, с одной стороны, дисциплиной работы (некоторые работники создают огромное количество промежуточных версий любого документа), так и обеспечением единственности оригинала документа, хранящегося в базе данных. При этом следует различать единственность оригинала в документообороте и наличие копий файлов для обеспечения надежности хранения данных. 5. Своевременное обновление данных. Чтобы данные в базах были актуальны, следует заинтересовать работников в их обновлении. Это можно обеспечить, если работники увидят пользу в поддержании данных в актуальном состоянии. Например, после ввода новых данных можно будет автоматически сформировать сложный документ на их основе, сэкономив много усилий. 6. Обеспечение информационной безопасности: минимизация использования флеш-памяти, внедрение Интранет, защита от вирусов. Во всем мире признано, что самым опасным устройством, из-за которого происходит утечка конфиденциальной и секретной информации, является флеш-память. Много скандалов разразилось из-за того, что работники берут файлы на флеш-памяти домой и забывают флешки где попало. Что же касается Интранет, то министерство обороны США, которое, собственно, и начало развитие Интернет, отключилось от всемирной сети, воздав свою локальную сеть, обезопасив себя от постоянных хакерских атак. Книги здесь невнятны. Пример: Главная отличительная особенность Intranet кроется в информационном уровне коммуникаций, который в значительной степени определяется спецификой проекта и наиболее существенен для управления проектом. При этом аппаратный и программный уровни коммуникаций являются обеспечивающими. Информационное обеспечение может иметь разную базовую технологию передачи и хранения информации. И так десятки страниц! На английский не переводится. 7.3.4. Проектирование офиса проекта Сейчас создать офис проекта довольно просто, надо воспользоваться современным оборудованием и программным обеспечением. Но для правильного функционирования нужен администратор сервера и консультант по применению технических и программных средств Для работы системы Moodle требуются технические специалисты и «учитель учителей». Проектирование офиса проекта – это фактически проектирование автоматизированной информационной системы. Традиционно [Мазур] проектирование начиналось сверху вниз, от проектирования организационной структуры и бизнес-процессов команды проекта до проектирования и реализации программного обеспечения и других технических средств вплоть до средств передвижения. Однако такой подход на практике оказывается слишком идеализированным. Кроме того, в настоящее время уже имеется программное обеспечение практически для любого применения. Поэтому на практике развитие офиса проекта происходит следующим образом. 1. Создание на базе имеющегося программного обеспечения. 1.1. Производится выбор программного обеспечения управления проектами. 1.2. Закупается программное обеспечение, необходимое дополнительное оборудование, производится его установка. 1.3. Определяется оргструктура для обслуживания офиса проекта. 1.4. Детально изучаются возможности программного обеспечения. 1.5. Производится некоторая перестройка бизнес-процессов (порядка обмена информацией, составления документов, их архивации и т.д.), в соответствии с особенностями программного обеспечения. 1.6. Одновременно с этим проводится обучение работников новому порядку работы. 1.7. Проводится внедрение системы, вначале по возможности на небольшом проекте или для части функций. 1.8. К системе подключаются новые участники, новые стандарты работы распространяются на все проекты. Такой подход использовался за рубежом еще в самом конце 1990-х годов [Я], когда некоторые фирмы перестраивали свои бизнес-процессы под имеющиеся стандарты. Это вызывало поначалу огромные споры об уникальности, важных особенностях конкретного бизнеса, однако в конце концов участники согласились принять такой подход и результаты оказались положительными. Оказалось, что практически все уникальные особенности бизнеса различных фирм и их подразделений надуманы и более эффективно отказаться от них. 2. Эволюционный подход []. Он основывается на эмпирическом наблюдении: каждая работоспособная системы была раньше работоспособной более простой системой. 2.1. Работники выполняют свои функции при помощи широкораспространенных программных средств, чаще всего – офисных приложений. 2.2. На первом этапе проводится оптимизация частных задач: разрабатываются формы таблиц и документов, уточняется необходимая информация для их составления. При необходимости производится перевод задачи на другое программное обеспечение, например, от электронных таблиц переходят к базе данных. Следует отметить, что такая оптимизация не носит окончательного характера, это лишь устранение некоторых особенно бросающихся в глаза недочетов, приведение документооборота к виду, удобному для работы. Известен случай, когда работники IBM жаловались на недостаток информации, необходимой им для работы. В результате они стали регулярно получать огромные отчеты о состоянии техники и технологий в мире. Читать их было крайне затруднительно, поэтому этого никто не делал. В результате на три года «прозевали» создание персональных компьютеров. 2.3. Начинается процесс автоматизации передачи данных от одной задачи к другой. Это может быть организация пересылки, программ передачи данных из одного документа в другой. 2.4. Этот процесс продолжается, охватывая все большую часть работы. 2.5. При необходимости организуется центральное хранилище данных, разрабатывается порядок работы с ним по хранению и обмену документами. Этот процесс также возникает из существующих функций документооборота, включая архивацию документов. 2.6. В такой системе нетрудно совершенствовать отдельные документы, улучшая весь документооборот. 2.7. Возможна и радикальная перестройка деятельности. Она проводится по единому плану, но может делаться поэтапно, не требуя двойной параллельной работы в старой и новой системах автоматизации, как это бывает при внедрении нового программного обеспечения. Проектирование организационной структуры и бизнес-процессов с учетом требуемых ресурсов можно осуществлять с использованием специализированных программных средств, например продукта Visio2000. Проектирование помещений и площадей обычно производится в специализированном программном продукте, например в AutoCAD. Для совмещенного проектирования архитектуры, интерьера, организационной структуры и бизнес-процессов можно экспортировать чертежи из AutoCAD в Visio2000. Пример единого подхода к формированию пространственной, организационной среды и оптимизации бизнес-процессов приведен на рис. 6.2.2. 8. Финансирование проекта 8.1. Инвестиционные ресурсы Финансирование проекта – обеспечение проекта инвестиционными ресурсами. В их состав входят не только денежные средства, но и выражаемые в денежном эквиваленте прочие инвестиции, в том числе основные и оборотные средства, имущественные права и нематериальные активы, кредиты, займы и залоги, права землепользования и пр. Надо планировать не только размер, но и динамику инвестиций. Финансирование должно поступать в нужные моменты времени в нужном размере. Финансирование проекта включает следующие основные стадии: • технико-экономическое обоснование проекта; • разработку плана реализации проекта (в данном случае важны размер и срок поступления ресурсов, оценки возможных рисков (потерь); • организацию финансирования, в том числе: ◦ оценку и выбор возможных форм финансирования; ◦ определение финансирующих организаций; ◦ определение структуры источников финансирования; ◦ контроль выполнения плана и условий финансирования. В табл. Таблица 8 приведена структура инвестиционных ресурсов организации. Таблица 8 Структура инвестиционных ресурсов организации Группа ресурсов Типы ресурсов в группе Внутренние, входящие в состав собственного капитала ● Прибыль; ● Специальные фонды, формируемые за счет прибыли; ● Амортизационные отчисления (на определенных условиях); ● Страховые возмещения; ● Иные (неденежные) виды ресурсов: ○ земельные участки; ○ основные фонды; ○ промышленная собственность и др. Привлеченные, включаемые в состав собственного капитала ● Финансовые средства, привлекаемые за счет эмиссии и размещения акций, в т. ч. путем: ○ открытого (публичного) размещения; ○ закрытого (частного) размещения; ● Средства, выделяемые вышестоящими холдинговыми и акционерными компаниями; ● Гранты и благотворительные взносы; ● Государственные субсидии, в том числе: ○ прямые; ○ косвенные (в виде налоговых и иных льгот) Привлеченные, не включаемые в состав собственного капитала ● Банковские кредиты и займы; ● Кредиты, займы, ссуды в денежной форме, предоставляемые небанковскими учреждениями; ● Государственные кредиты и займы, в том числе: ○ прямые; ○ в форме налогового инвестиционного кредита; ● Коммерческие кредиты (предоставляемые поставщиками машин, оборудования и других инвестиционных товаров; подрядчиками); ● Финансовые средства, привлекаемые за счет эмиссии и размещения облигаций; ● Машины, оборудование, иные неденежные виды ресурсов, привлекаемые на основе лизинга, в т. ч.: ○ операционный лизинг; ○ финансовый лизинг 8.2. Источники финансирования Финансирование проектов может осуществляется следующими способами: самофинансирование – использование в качестве источника финансирования собственных средств инвестора (государство берет средства из бюджета и внебюджетных фондов; организации – из собственных средств); использование заемных и привлекаемых средств. Система финансирования инвестиционных проектов включает: • источники финансирования; • организационные формы финансирования. В табл. Таблица 9 представлена структура источников финансирования проектов. Таблица 9 Структура источников финансирования инвестиционных проектов Группа Тип Организационная структура источников в группе Государственные ресурсы Собственные Государственный (федеральный) бюджет Бюджеты субъектов федерации (республиканские, местные) Внебюджетные фонды (Пенсионный фонд РФ, Фонд социального страхования РФ, Государственный фонд занятости РФ, Федеральный фонд обязательного медицинского страхования РФ, прочие фонды) Привлекаемые Государственная кредитная система Государственная страховая система Заемные Государственные заимствования (государственные займы, внешние заимствования, международные кредиты и пр.) Ресурсы организаций Собственные Собственные инвестиционные ресурсы организаций Привлекаемые Взносы, пожертвования, продажа акций, дополнительная эмиссия акций Инвестиционные ресурсы инвестиционных компаний-резидентов, в том числе паевых инвестиционных фондов Инвестиционные ресурсы страховых компаний-резидентов Инвестиционные ресурсы негосударственных пенсионных фондов-резидентов Заемные Банковские, коммерческие кредиты, бюджетные и целевые кредиты Инвестиционные ресурсы иностранных инвесторов, включая коммерческие банки, международные финансовые институты, институциональных инвесторов, организации Организационные формы участников финансирования инвестиционных проектов приведены в табл. Таблица 10. Таблица 10 Классификация источников и участников финансирования проектов Группа Подгруппы Организационная форма участника инвестиционной деятельности Бюджет и внебюджетные фонды Федеральный бюджет ● Правительство РФ ● Министерство экономики РФ ● Министерство финансов РФ Бюджеты субъектов федерации ● Распорядительные органы субъектов федерации Внебюджетные фонды ● Пенсионный фонд РФ (только инвестиции в ценные бумаги) ● Государственный Фонд занятости населения РФ (только инвестиции в государственные ценные бумаги) ● Фонд инвестирования жилищного строительства Федеральный центр проектного финансирования ● Прочие Кредитная система ● Банки ● Кредитные учреждения ● Центральный банк РФ ● Федеральное казначейство ● Инвестиционные банки Система страхования Фонды и организации страхования ● Росгосстрах РФ ● Страховые компании Коллективные формы финансирования Инвестиционные организации ● Инвестиционные компании и фонды ● Негосударственные пенсионные фонды ● Инвестиционные банки ● Страховые организации ● Страховые компании ● Паевые инвестиционные фонды Иностранные инвесторы Правительства иностранных государств ● Международный Банк Реконструкции и Развития (МБРР) ● Европейский Банк Реконструкции и Развития (ЕБРР) ● Международные финансовые институты ● Коммерческие банки ● Институциональные инвесторы ● Инвестиционные банки ● Международный финансовый комитет ● Эксимбанк США ● Прочие Организации РФ Любые 8.3. Организация финансирования проекта При финансировании проектов обычно сам проект является способом обслуживания долговых обязательств. Финансирующие субъекты оценивают объект инвестиций с точки зрения того, принесет ли реализуемый проект такой уровень дохода, который обеспечит погашение предоставленной инвесторами ссуды, займов или других видов капитала. Кредитор несет повышенные риски, выдавая необеспеченный или не в полной мере обеспеченный кредит. Погашение этого кредита осуществляется обычно за счет денежных потоков, образующихся в ходе эксплуатации объекта инвестиционной деятельности. Финансирование различается по регрессу. Регресс - требование о возмещении предоставленной в заем суммы. С полным регрессом. Риски лежат на заемщике, но возврат кредита осуществляется быстро и цена его невысока. Используется для малоприбыльных и некоммерческих проектов. Без права регресса. Все риски лежат на кредиторе. Цена такого кредита высока. Таким способом финансируются проекты по развитию инновационных технологий, с хорошими рынками сбыта продукции, с надежными поставщиками и пр. Но таких проектов не так ужи много. С ограниченным регрессом. Промежуточный вариант. Риски распределяются между участниками. Цена финансирования умеренна. Все участники проекта заинтересованы в его эффективной реализации, поскольку от этого зависит их прибыль. В России развивается венчурный бизнес, который по сути относится к финансированию без права регресса. Однако часто происходит просто долгосрочное финансирование. 8.3.1. Жизненный цикл проекта с точки зрения заемщика и инвестора Важно, чтобы кредитор имел четкое представление о жизненном цикле проекта заемщика, а заемщик – о проектном цикле кредитора, чтобы не допускать сбоев в продвижении проекта и действовать максимально скоординированно. Особенности жизненного цикла проекта с точки зрения заемщика и кредитора даны в табл. Таблица 11. Для кредитора все начинается с отбора заявок на финансирование проекта, для заемщика – с идеи проекта. Деятельность инвестора по финансированию конкретного проекта начинается позже, чем у заемщика, – с принятия решения о реализации инвестиционного проекта. Инвестиционная фаза начинается с момента подписания договора (кредитного соглашения), а заканчивается, когда заемщик оформляет отчет о завершении инвестиционной деятельности. Для заемщика проектный цикл может продолжаться в эксплуатационной фазе. Таблица 11 Характеристика проектного цикла для различных участников проекта Заемщик Кредитор Проектный цикл имеет более широкие временные рамки. Именно у него, как правило, зарождается концепция проекта (начало проектного цикла). И именно он в основном доводит инвестиционный объект до ликвидации (демонтаж, продажа, коренная реконструкция -конец проектного цикла) Проектный цикл начинается с момента получения от будущего заемщика заявки на финансирование проекта, а заканчивается моментом, когда заемщик выполняет все свои платежные обязательства по кредиту, и кредитный договор прекращает действие. В том случае, когда банк финансирует проект не через кредит, а в виде инвестиций, проектный цикл для банка удлиняется, и его конечная точка для банка и для компании будет одной и той же (если, конечно, банк не проведет деинвестирование своих средств до момента ликвидации инвестиционного объекта) Проектный цикл проектной компании-заемщика: ● предынвестиционные исследования: ○ разработка концепции; ○ технико-экономическое обоснование инвестиционная фаза: ○ планирование и проектирование; ○ торги и закупки; ○ строительно-монтажные работы (для строительного проекта); ○завершение проекта Проектный цикл банка включает: ● отбор проектов; ● подготовка проектов; ● оценка проектов; ● ведение переговоров и утверждение проекта; ● реализация проекта и контроль за ее ходом; ● оценка результатов реализации проекта 8.3.2. Контроль реализации проекта и снижение проектных рисков Финансовые методы, обеспечивающие снижение проектных рисков, включают: • юридические гарантии; • банковские гарантии; • использование активов проекта как залог для покрытия кредитных рисков; • косвенные гарантии в форме долгосрочных контрактов на реализацию проектного продукта, поставку ресурсов и пр.; • создание фонда для покрытия возможных рисков; • поручительства (альтернатива банковской гарантии); • резервные кредиты; • использование вексельных инструментов (обязательства заемщика погасить задолженность); • различные виды страхования; • проведение мероприятий по управлению рисками проекта, в том числе: по снижению рисков, предотвращению и контролю, распределению рисков между участниками проекта и пр.; • проведение всестороннего анализа проектных рисков на предынвестиционной фазе проекта; • для банков-инвесторов – оптимизация структуры портфеля инвестиционных проектов. В обязанности заемщика входит предоставление регулярных отчетов о: • ходе работ, • подписываемых контрактах; • разнообразных возможных препятствиях для реализации проекта; • соблюдении строительных, технических, экологических и иных норм; • соответствии проводимых работ технической документации Контроль может проводиться как кредитором, так и сторонней организацией. В некоторых случаях затраты по контролю реализации проекта могут достигать 5 и более процентов от общего объема инвестиций в проект. Обязательства заемщика по соглашению о реализации проекта считаются частично выполненными после сдачи объекта инвестиционной деятельности в эксплуатацию. Порядок сдачи оговаривается в проектном соглашении. Обязательства считаются полностью выполненными после выполнения всех условий кредитного договора. 9. Планирование проекта 9.1. Основные понятия и определения Как отмечалось выше, планирование – одна из основных фаз проектного управления. Это построение модели реализации проекта. Важность планирования определяется еще и другой отличительной особенностью проектного управления уникальностью результата реализации проекта. Концептуальное планирование проводится в начальный период жизненного цикла проекта. Его результат – концептуальный план – представляет собой технические требования, оценки, укрупненные календарные планы, процедуры контроля и управления. Стратегическое планирование представляет собой процесс разработки стратегических, укрупненных, долгосрочных планов. Детальное (оперативное, тактическое) планирование связано с разработкой тактических, детальных планов-графиков для оперативного управления на уровне ответственных исполнителей. Обычно планирование производится сверху вниз. На уровне высшего руководства организации разрабатывается план с несколькими проектами. Он служит для управления на уровне организации в целом. Каждый отдельный проект сначала представляется в краткой форме, только с ключевыми событиями (вехами). Это отражается в содержании проекта. Затем краткий план детализируется. Зачем нужен детальный план, если всем всё ясно? Довольно часто происходит смена руководства или смена исполнителя. Если детальный план находится в голове одного человека, это может привести к печальным последствиям. Ели же часть работ отдана на аутсорсинг, то эта часть отмечается в общем плане одним пунктом, а детализируется в планах организации-исполнителя. В проекте используются разнообразные ресурсы: • трудовые ресурсы; • финансы; • оборудование; • техническая оснастка; • материалы и поставщики; • информация; • технологии. Каждая работа должна быть укомплектована всем необходимым. Для этого определяется: • необходимый объем ресурсов; • имеющиеся ресурсы; • пути получения недостающих ресурсов. Для этого необходима декомпозиция проекта с образованием различных структур. Искусство декомпозиции проекта состоит в умелом согласовании основных структур проекта, к которым относят: • организационную структуру; • структуру статей затрат; • структуру ресурсов; • функциональную структуру; • информационную структуру; • структуру временных интервалов: этапов, работ. Основой для построения и согласования всех остальных структур между собой служит так называемая структурная декомпозиция работ. 9.2. Основные принципы планирования Четкая постановка цели. Проект предназначен для решения какой-либо проблемы, удовлетворения определенной потребности и т. п. Исходя из этого и формируется цель. Если проблема недостаточно четко сформулирована, цель может оказаться неверной и проект потерпит неудачу. Учет всех имеющихся данных. В инжиниринговых проектах на результаты планирования определенных этапов проекта существенно влияют результаты поисковых работ смежных направлений, результаты промежуточных этапов, например, тестирование экспериментального образца. Но и в этом случаен необходимо учитывать всю имеющуюся информацию, чтобы как можно более точно спланировать проект. Например, можно предусмотреть различные варианты хода проекта. Привлечение к планированию специалистов различного профиля. На предприятиях часто имеется плановый отдел, которому и поручается планирование. Но учесть важные факторы можно, если привлечь ответственных исполнителей из финансового отдела, отдела снабжения, конструкторского. Учет предыдущего опыта. Очень важны практические аспекты планирования, о которых нельзя прочитать ни в одной книге. Учет доступности ресурсов. Чаще всего не учитывается доступность трудовых ресурсов, которые должны обладать определенной квалификацией и находиться в заданное время в заданном месте для выполнения работ. Учет координации. Большие проекты разбиваются на относительно независимые части, за реализацию которых отвечают самостоятельные подразделения. Но при этом обязательна координация этих частей, иначе подразделения будут преследовать свои локальные цели, что может привести к нарушению порядка работ и даже срыву реализации проекта в целом. Учет мотивации. Особенно это важно, если проект выполняется одновременно с выполнением обычных должностных обязанностей. Работников необходимо стимулировать, и у руководителя проекта должны быть для этого полномочия и средства. Корректный уровень детализации. Излишняя детализация сильно усложняет и планирование, и контроль проекта. Но и излишнее укрупнение тоже грозит потерей управляемости. Необходима золотая середина. Главная цель планирования – последующее отслеживание хода проекта. Одна из самых серьезных ошибок – планирование для того, чтобы был план. Создаваемый план дожжен стать реальным инструментом управления работами по проекту. 9.3. Структурная декомпозиция работ 9.3.1. Сущность Структурная декомпозиция работ (СДР, английский аналог WBS – Work Breakdown Structure) – это иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня, пакеты детальных работ. СДР позволяет решать проблемы организации работ, распределения ответственности, оценки стоимости, контроля результатов, сроков их достижения. Существуют две формы представления СДР [Милошевич]: 1) древовидная (рис. Рис. 32); 2) иерархический список (рис. Рис. 33). Рис. 32. Древовидная структура СДР Рис. 33. СДР как иерархический список Исходные данные для составления СДР: • описание содержания проекта; • технологическая карта выполнения операций (трудовые процессы); • пожелания заказчика (в круг рассматриваемых вопросов должны входить: желание клиента быстрее получить продукт или услугу, необходимость быстрого моделирования, потребность в аутсорсинге, то есть привлечении ресурсов извне); • пул доступных ресурсов (пул ресурсов – имеющиеся ресурсы определенного типа. Например, один пул может включать 5 программистов, другой- 3 экскаватора, третий – склад, вмещающий 10 вагонов товаров. Из пула ресурсы распределяются по работам проекта или по разным проектам. Последнее значительно повышает полезное использование ресурсов). • конкретная проектная ситуация. СДР структурируется по уровням. Структура должна быть строго иерархической. На любом из уровней группе «дочерних» (более детальных) элементов соответствует только один «родительский» элемент (более высокого уровня). Это правило обеспечивает корректность суммирования стоимостей, вывода объединенных календарных графиков и обобщения информации о работах при переходе с одного уровня на другой. Уровень 0 – весь проект. Уровень 1 структурировать можно по-разному. По стадиям жизненного цикла проекта. Например, проект разработки программного обеспечения может состоять из таких фаз, как определение требований, высокоуровневое проектирование, низкоуровневое проектирование, написание кода и тестирование. Если последовательные фазы неприменимы или не используются в организации, то проект разделяется в соответствии с составляющими результат физическими системами. Например, в проекте разработки самолета системы, находящиеся на уровне 1 СДР, могут включать в себя фюзеляж, крылья, двигатель. Этот подход широко распространен в ряде традиционных производственных отраслей, в которых СДР напоминает ведомость комплектующих изделий. Разбиение СДР по географическим зонам практикуется, в частности, в сфере строительства. Уровень 1 СДР проекта может состоять из здания A, здания B и т. д. Достаточно часто в СДР присутствуют и названия географических зон: например, северо-западная, юго-западная, юго-восточная и северо-восточная площадки. На уровне 2, можно применить тот же или другой принцип. Например, СДР, где уровень 1 структурирован по географическому принципу, может иметь географические зоны и на последующих, низших уровнях. Может оказаться и так, что СДР структурирована на уровне 1 по жизненному циклу проекта, а на уровне 2 – по системам. Допускается и смешанное разбиение (пример – на рис. ) Рис. 34. Пример смешанной СДР. Определяется это в большой степени традициями организации или отрасли. Более правильные, но непривычные способы будут вызывать сопротивлений исполнителей. Детализация производится до определенного, оптимального уровня: до уровня пакета работ. (рис. Рис. 35). Можно провести аналогию между пакетом работ и явлениям в театральной пьесе. Новое явление начинается, когда кто-то входит или выходит со сцены. Рис. 35. Место пакета работ в СДР. Пакет работ решает конкретную задачу, имеющую определимые конечные результаты, которыми «владеют» назначенные организационные единицы и которые эти организационные единицы должны производить [Методические основы управления ИТ-проектами / В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. Лекция 2: Планирование проекта URL http://www.intuit.ru/department/itmngt/metbitm/2/, Милошевич]. Для каждого пакета работ назначается ответственное лицо, составляется расписание, оценивается стоимость ресурсов, пишутся планы реагирования на риск и выполняются другие функции планирования, измеряется ход исполнения пакета и осуществляется его упреждающий контроль. С одной стороны, чем на более мелкие части разбита работа, тем она проще и тем легче ей управлять. Но при увеличении числа пакетов работ увеличиваются затраты на планирование и контроль проекта. Более того, мелкие работы часто нуждаются в изменении. Пример. Пакет работ: доставить дополнительную машину песку на стройку. Эта работа делится на поиск потенциальных поставщиков, их обзвон, выбор поставщика, заключение с ним договора (это тоже многоступенчатый процесс сбора подписей), предоплату, подготовку места для песка, ожидание машины, приемку песка, окончательный расчет в поставщиком. Если работы будут детализированы до такого уровня, может оказаться, что при обзвоне подходящий поставщик не найден. Это означает, что требуется снова осуществлять поиск, то есть изменять проект. Гораздо проще рассматривать доставку песка как один пакет работ, выполняемый менеджером. Итак, выяснение степени детализации СДР включает в себя определение количества уровней СДР, количества и среднего размера пакетов работ, подходящих к конкретной ситуации и принятых в вашей отрасли. Обычно для малых и средних проектов в области разработки программного обеспечения [Милошевич] бывает • от трех до четырех уровней в СДР; • от 15 до 40 пакетов работ; • от 40 до 80 часов на средний пакет работ; • длительность среднего пакета работ – от одной до двух недель или от 3 до 7% общего бюджета рабочего времени. В больших проектах: • пять и более уровней в СДР; • от 80 до 200 часов на средний пакет работ; • длительность среднего пакета работ – две-четыре недели или от 0,5 до 2,5% общего бюджета рабочего времени. Для начинающих менеджеров проекта можно порекомендовать простое практическое правило: пакет работ не должен занимать меньше недели. Конечно, это лишь общие рекомендации, и возможны некоторые отклонения от них. 9.3.2. Структурирование СДР сверху вниз В качестве исходных данных имеется документ Содержание работ. Уровень детализации обсуждался выше. Структурирование выполняется по следующим шагам. 1. Идентифицируются основные результаты проекта. В зависимости от типа выбранной СДР это могут быть фазы, системы, географические зоны или их комбинации. В данном случае они тесно связаны с содержанием проекта. 2. Основные результаты разделяются на меньшие, лучше поддающиеся управлению, уровень за уровнем до тех пор, пока не будет достигнута точка, в которой результаты являются вещественными, поддающимися верификации и определяемыми с тем уровнем детализации, который позволяет использовать их для интеграции операций планирования и контроля проекта. 3. Выбирается способ представления СДР. В случае малых проектов изображение СДР в виде дерева обеспечивает лучшую наглядность. Сложные СДР лучше представлять в виде оглавления. 4. Проверяется, ориентирована ли СДР ориентирована на результаты. Например, если в СДР речь идет о предметах поставки, в ней нет места операциям. Это важный принцип обратной связи: проверить то, что реально получается. Потом можно будет полностью полагаться на созданные и проверенные результаты и идти дальше. 5. Проверяется, включает ли СДР все работы проекта. То, что оставлено за пределами СДР, не будет учтено при распределении ресурсов и календарном планировании!. 6. Каждый элемент СДР по мере возможности делается независимым от других элементов того же уровня. Это трудноформализуемая задача. Рекомендации заключаются в выделении результатов и исполнителей. То есть принцип выделения пакета работ действует здесь на всех уровнях. 7. Деление работ продолжается вплоть до уровня планирования и управления, применяемого в организации. Отдельные результаты, например, достижение заданного уровня известности с помощью рекламной кампании, могут быть получены с помощью аутсорсинга. Для них не требуется высокая детализация. Таким образом, часто оказывается, что уровень детализации различен для различных работ. 8. Формируется итоговая СДР, объединяющая все элементы в единый проект. Результат общей СДР – завершение проекта. Разработка СДР не представляет собой жестко заданный алгоритм. Имеются лишь рекомендации. Поэтому могут существовать различные одинаково хорошие СДР. СДР лучше рассматривать сразу для портфеля проектов. Тогда будет больше уверенности в эффективном использовании ресурсов. Таких, например, как автокран, принтер, переплетная машина. Свою полезность для практики показали шаблоны СДР для семейств проектов, например сооружения автомагистралей, создания программного обеспечения, разработки технологических процессов. После того как шаблоны построены и приняты, разработка СДР для нового проекта сводится к адаптации шаблона. Это экономит время, позволяет получить качественную СДР и обеспечивает межпроектную совместимость. Вообще, типовые проекты широко распространены в первую очередь в строительстве (привести примеры). Типовой проект это в первую очередь план (design), адаптируемый под реальное местоположение. Но и большинство работ тоже типовые. Кроме того, есть ГОСТ по типовым проектным решениям в АСУ5 [ГОСТ 24.703-85. Типовые проектные решения в АСУ. Основные положения]. Типовое проектное решение (ТПР) в области АСУ представляет комплект технической документации, содержащий проектные решения по части объекта проектирования, включая программные средства и предназначенный для многократного применения в процессе разработки, внедрения и функционирования АСУ с целью уменьшения трудоемкости разработки, сроков и затрат на создание АСУ и ее частей. ТПР разрабатывают при наличии однородных объектов управления, для которых создание ТПР АСУ является экономически целесообразным. ТПР является результатом работы по типизации, заключающейся в приведении к единообразию по установленным признакам наиболее рациональных индивидуальных (нетиповых) проектных решений, объединяемых областью применяемости и общими требованиями к ним. ТПР разрабатывают на объекты проектирования, охватывающие элементы различных видов обеспечения АСУ, постановки задач (комплексов задач) и на отдельные функции (комплексы функций) АСУ. Таблица 12 Примеры объектов проектирования для простых ТПР приведе­ны в таблице. Вид ТПР Примеры объектов проектирования ТПР по информационному обеспечению Базы данных и их организация, классификаторы технико-экономической и нормативно справочной информации, формы представления и организации данных в системе (в том числе формы документов, видеограммы, массивы) данных и протоколы обмена данными ТПР но программному обеспечению Программы общего и специального программного обеспечения АСУ ТПР по техническому обеспечению Комплексы средств, обеспечивающих ввод, подготовку, преобразование, обработку, хранение, регистрацию, вывод, отображение, передачу информации и средства реа­лизации управляющих воздействий ТПР по организационному обеспечению Инструкции, определяющие функции подразделений управления, действия и взаимодействие персонала АСУ ТПР по лингвистическому обеспечению Тезаурусы и языки описания и манипулирования данными ТПР по математическому обеспечению Методы решения задач управления, модели и алгоритмы ТПР на постановку задачи Постановка задачи (комплекса задач) АСУ ТПР по функциям Подсистема АСУ, выделенная по функциональному признаку, функция АСУ, задача АСУ, комплексы функций и задач АСУ Разработку ТПР осуществляют на основе использования проектных решений, реализованных в конкретных АСУ. 9.3.3. Построение СДР «снизу вверх» Краеугольным камнем подхода «снизу вверх» является мозговой штурм (brainstorming) для определения всех работ проекта, которые должны быть выполнены. Процесс основан на построении аффинной (лат: affinis — родственный) диаграммы. Данные приведены на основе Википедии (в 2011 году имелось только в англоязычной версии) и [Using Affinity Diagrams to make sense from Brainstorming // Learnyourcompany.com: business improvement made easy. URL http://www.leanyourcompany.com/methods/Using-Affinity-Diagrams.asp]. Этапы следующие. Ряд предварительных шагов может быть как в методе «сверху вниз»: сбор необходимой информации для составления СДР, выбор типа СДР и определение степени ее детализации. Далее перечислены остальные шаги подхода «снизу вверх». 1. Формирование подробного списка результатов. Данный шаг требует проведения мозгового штурма для определения того, каковы должны быть результаты проекта. Следует подчеркнуть важность перечисления не работ, а результатов. Не «проанализировать», а «разработать прогноз» или «выявить важны факторы»! Каждый результат рекомендуется записать на бумажке с клейким слоем и развесить на доске. Для малого или среднего проекта обычно формируется 40—60 результатов. В ходе мозгового штурма недопустима какая-либо критика идей! 2. Группировка взаимосвязанных результатов. Карточки группируются, ориентировочно по 5. Затем создаются группы из групп и т.л. В малых и средних проектах получается 3…4 уровня группировки. Принцип группировки более или менее соответствует принципам выделения групп на высших уровнях СДР. Это наиболее сложный этап, так как, как отмечалось выше, создание СДР неформализуемо и у участников могут быть различные мнения по поводу группировки. Поэтому возможен следующий вариант действий. 3. Создание дубликатов результатов и их консолидация. Если члены команды имеют весьма различающиеся представления о том, как следует группировать результаты, то создаются дубликаты результатов, которые размещаются в различных группах согласно предложениям членов команды. Затем организуется обсуждение, в котором разбираются различные мнения и делается попытка достичь согласия. Если это не удается, руководитель использует право решающего голоса. 4. Еще один вспомогательный шаг: устранение избыточности. Похожие результаты объединяются в один. 5. Присвоение названий группам. Иерархическая структура требует, чтобы группы и результаты на различных уровнях имели названия, причем нужно в максимально возможной степени сохранять согласие между членами команды. Имеет смысл потратить время на разработку названий результатов/групп: это полезно для понимания желаемых итогов проектов, а также для обеспечения наибольшей сопричастности участников. На первый взгляд может показаться, что это неважно: «хоть груздем назови, только в кузов не сажай». Но с другой стороны – «назвался груздем – полезай в кузов». Важность правильного названия трудно переоценить. Это в полной мере понимали еще в прошлые века: «Жизнь, необыкновенные и удивительные приключения Робинзона Крузо, моряка из Йорка, прожившего 28 лет в полном одиночестве на необитаемом острове у берегов Америки близ устьев реки Ориноко, куда он был выброшен кораблекрушением, во время которого весь экипаж корабля кроме него погиб, с изложением его неожиданного освобождения пиратами; написанные им самим». Теперь столь подробное изложение пишут в реферате, но название как первое знакомство с книгой или частью проекта стало играть еще более важную роль. В итоге получается предварительная СДР. 6. Оценка правильности структурирования СДР. Подходу «снизу вверх», как и подходу «сверху вниз», недостает строгости и упорядоченности научного метода, что оставляет определенное место для ошибок. Следовательно, на этом этапе нужно оценить разработанную СДР в соответствии с вышеприведенными рекомендациями по структурированию. Часто СДР приходится менять, иногда довольно значительно, пока она не станет основой для интеграции планирования и контроля проекта. Этот подход, и особенно метод аффинных диаграмм, будет весьма полезен в следующих случаях: • если нет опыта разработки и реализации проектов; если СДР используется впервые. Он обеспечивает быстрый старт работы и сопричастность; • в проектах разработки или применения новых технологий, которые обычно характеризуются высокой степенью неопределенности и отсутствием прецедентов; • при разработке нового шаблона СДР, на основе нескольких вариантов, используемых различными менеджерами проектов. Недостатки этого метода общие для метода мозгового штурма; • если участников разработки мало, нет гарантии того, все ли работы учтены, не переупрощена ли задача; • если участников много – усложняется проведение 9.3.4. Использование СДР Преимущество СДР заключается в простой визуализация сложных, часто неясных взаимосвязей в четко структурированное дерево или оглавление; Однако чрезмерно большая СДР требует слишком много времени. СДР вначале применялась в крупномасштабных правительственных проектах. Однако в настоящее время она применяется практически повсеместно, даже в малых проектах практически во всех отраслях. СДР позволяет организовать работы проекта в виде получения малых управляемых относительно независимых результатов. По мере продвижения к верхним уровням СДР эти «первичные» результаты можно интегрировать, получая целостную картину итогового поддающегося измерению состояния проекта. Наконец, ход получения результатов поддается измерению. Иными словами, создается основа для интеграции функций планирования и контроля проекта. Именно поэтому СДР считается наиболее важным элементом управления проектами. Итак, СДР помогает: назначить лиц, ответственных за пакеты работ проекта. Распределение обязанностей ясно из рис. Рис. 35, который представляет собой так называемую матрицу ответственности; • осуществить календарное планирование работ. Начав с определения времени выполнения пакета работ, можно перейти к объединению календарных планов, так как есть иерархия работ; СДР – не сетевой график работ, на котором показана взаимосвязь отдельных работ. • оценить ресурсы, необходимые для выполнения работ. СДР – формальная структура для оценивания ресурсов. Определив потребности пакетов работ в ресурсах, можно определить общие ресурсные требования и получить график использования ресурсов во времени. В малых и средних проектах часто используют предпочитают оценки, основанные на ресурсах (человеко-днях, машино-часах, количестве затраченных материалов и т.д.), а не на стоимости. Стоимостная оценка может быть получена умножением количества необходимых ресурсов на стоимость единицы ресурса. • определить способы реагирования на риски проекта. Чаще всего причиной рисков является недостаток или неправильное использование ресурсов. С помощью СДР можно увидеть источники рисков и продумать реакцию на них; • осуществлять другие, вспомогательные функции проекта, например, планирование качества. Это удобно делать для пакетов работ, но легко получить и обобщенные результаты; • измерять ход исполнения работ. На уровне пакета работ сравнивается плановый и фактический ход. СДО помогает получить общую картину. Зная ход исполнения для каждого элемента работ и всего проекта в целом, можно оценить отклонение фактических показателей от плановых. Важно помнить, что окончательная цель измерения хода исполнения – упреждающий контроль проекта. • управлять работами, обеспечивая достижение целей проекта. Возможные ошибки структуризации проекта • пропуск стадии структуризации проекта и переход непосредственно к поиску и решению текущих, оперативных проблем проекта; • использование при структуризации только функций, фаз или организационных подразделений вместо конечных продуктов или используемых ресурсов; • непонимание того, что СРР должна охватывать весь проект (обычно — недостаточное внимание начальной и конечной фаз проекта, работ функциональных, обеспечивающих подразделений); • повторение элементов структуры; • отсутствие интеграции структуры проекта с системой ведения бухгалтерских счетов в компании и с системой подготовки проектно-сметной документации; • излишняя или недостаточная детализация; • невозможность компьютерной обработки результатов структуризации — планов проекта из-за ошибок формального характера (каждый уровень или элемент плана должен быть определенным образом закодирован); • неучет «неосязаемых» конечных продуктов, таких как услуги, информационное или программное обеспечение. 9.4. Графики работ Цель создания графиков работ (календарного планирования) заключается в обеспечении возможности оперативного управления ходом выполнения проекта по пакетам работ на уровне ответственных исполнителей. График работ используется для согласования сроков и других параметров проекта, для контроля хода работ, для сдачи-приемки работ. Наличие и сопровождение детального графика работ – одно из главных требований правильного управления проектом. Процесс разработки детального графика работ обычно состоит из следующих этапов. 1. Предварительный вариант графиков работ для отдельных элементов СДР разрабатывается на уровне структурных подразделений. 2. Проводится корректировка и согласование частей графика работ. 3. Участники команды создают общий график работ. 4. Проверяется его полнота и согласованность. 5. График работ представляется на утверждение и возможные корректировки заказчику. 6. Производится окончательное утверждение графика работ заказчиком и исполнителем. Это – обязательная часть работы над проектом! 7. Впоследствии возможно внесение изменений в этот график, для этого используется специальная процедура двустороннего согласования изменений. График работ, существующий на момент начала работ по проекту, называется базовым. Для простых проектов небольшой длительности возможно составление детализированного базового графика еще до начала работ. Для более сложных проектов возможна работа с т.н. иерархическим графиком. На высших уровнях такого графика рассматриваются крупные части проекта, подпроекты, а на более мелких они детализируются до уровня пакетов работ. При этом разработка детальных графиков для всего проекта не обязательно завершить к началу работ. Иногда это и невозможно ввиду неопределенности некоторых параметров проекта к моменту начала работ (например, если проект строительства включает выбор его места, то дальнейшие этапы могут зависеть от расположения стройки). В этом случае используется принцип «бегущей волны»: вначале график работ подготавливается на первые 60 дней, а затем его разработка продолжается по ходу выполнения работ. Возможно составление графика работ для случаев возникновения рисков. 9.5. Организационная структура и матрица ответственности Для организации скоординированной деятельности по выполнению проекта строится матрица ответственности. Матрица ответственности показывает, какое подразделение отвечает за каждый пакет работ. На одной оси – список пакета работ, на другой – список подразделений и исполнителей, принимающих участие в выполнении работ. Если никаких дополнительных оргструктур под проект не создается, то в матрице указываются существующие подразделения. Если же команда проекта создается специально, то оргструктура формируется под СДР. При этом учитываются: • специфика профессиональных навыков, необходимых для выполнения работ; • объем работ; • сроки выполнения проекта. Упрощенная матрица ответственности [Милошевич?] для разработки плана проекта представлена в табл. Таблица 13. Таблица 13 Матрица ответственности. Виды ответственности или роли: О — ответственный исполнитель, И — исполнитель, П — приемка работ, К — консультации. Задачи Согласование целей этапов проекта Разработка плана по вехам Определение бюджета проекта Подготовка плана проекта Утверждение плана Исполнители Менеджер проекта О О О П О Администратор проекта И И О Планово-финансовый отдел К К Отдел сбыта К К К Разработка оргструктуры часто вызывает определенные сложности, так как требуется точно определить обязанности каждого члена команды. Более подробное рассмотрение этого вопроса выходит за рамки данной работы. 9.6. Структура статей затрат проекта Здесь нецелесообразно углубляться в тонкости бухгалтерского учета. Поэтому стоит указать лишь возможную форму хранения данных по статьям затрат. На этапе планирования это лишь плановые числа. Цели создания перечня статей затрат и определения их размера: • определение общей суммы затрат; • контроль соответствия фактических затрат плановым; • корректировать отклонения фактических затрат от плановых. Данные по статьям затрат удобно хранить в базе данных следующей структуры. • Элемент СДР. • Элемент оргструктуры. • Содержание (подготовка документов, изготовление макета, реклама…). • Период (месяц). • Счет (основные средства). • Субсчет (оборудование). • Ответственный исполнитель. • Сумма. Из базы данных подобной структуры удобно извлекать нужную информацию с помощью различных фильтров. При планировании крупных проектов число отдельных статей затрат может достигать нескольких тысяч. В этом случае для них вводится иерархическая структура. 9.7. Диаграмма контрольных событий На этом этапе планирования появляется время. Вехи (контрольные события) – события нулевой длительности, например момент подписания контракта, протокола или акта сдачи-приемки. Вехи отмечают существенные события, определяющие дальнейший ход развития проекта, точки перехода. Они решают проблему контроля проекта, предоставляя набор естественных контрольных точек. При определении вех используется информация о ключевых точках, стадиях и состояниях, через которые проходит проект в течение своего жизненного цикла. За основу создания вех берутся результаты, отмеченные в содержании проекта, но здесь уровень детализации повышается. Обычно в проектах десятки вех. Графическое представление моментов наступления контрольных событий называется диаграммой контрольных событий. Сверху вниз указываются наименования вех, по горизонтали откладываются временные интервалы. Точки обозначают наступление той или иной вехи. Польза от такой диаграммы заключается в том, что руководство видит, наступили или нет определенное событие. Веха – точка, когда полезно задать вопрос о целесообразности продолжения проекта [Милошевич) ]Наполеон, знаток военного дела, во время своих походов никогда не составлял каких/либо планов, исключая разве что самые схематичные наброски [1]. Эти схемы, вероятно, напоминали диаграммы контрольных событий, обозначавшие ключевые моменты кампании. Когда Наполеон вторгся в Египет, он четко разъяснил генералам свои цели. Действия генералов в значительной степени опирались на это расписание высокого уровня, что и привело к победе. Напротив, когда в июне 1812 года Наполеон вторгся в Россию с более чем 400-тысячным войском, он решил не информировать генералитет о своих планах. В результате в декабре 1812 года разбитая армия Наполеона, насчитывавшая к тому времени всего 20 тысяч человек, была вынуждена отступить. Типовая ошибка составления диаграммы контрольных событий - скучивание их в начале и в конце проекта. Лучше распределить их равномерно по времени. 9.8. Диаграмма Гантта????? Разработана в 1917 году. Пример. Строится на содержании проекта, на диаграмме вех или диаграмме контрольных событий. Тут – в деталях. Детали лучше всего знают непосредственные исполнители. Но надо все единообразно, значит, нужна система разработки расписания. Исполнители знают, менеджеры составляют расписание, руководители контролируют и утверждают. Руководитель – дирижер оркестра. Цитата, Роль руководителей в календарном планировании не сводится к владению теорией, инструментами или программным обеспечением. Напротив, их основная функция состоит в том, чтобы задавать вопросы, читать отчеты, возглавлять задействованный в проектах персонал и обеспечивать общую поддержку. Как оркестр под управлением хорошего дирижера, сотрудники должны синхронизировать свои действия, чтобы расписание составлялось слаженно и имело перед собой ясную цель. 9.8.1. Составление диаграммы Гантта 1. Определение степени детализации и идентификация операций. Надо определить. Например, решено, что в проекте определенного типа будет содержаться порядка 25 операций и никакая операция не займет более трех недель и менее недели. Это позволяет указать направление для следующего шага и гарантирует, что диаграмма будет иметь правильный размер и не станет ни слишком неуклюжей и времяемкой, ни слишком маленькой и неинформативной. Нужна практика. (На примерах надо каждый раз смотреть). Если уж очень важна детализация (прозрачный процесс, до каждой копейки), то есть принцип вложенности задач. На верхнем уровне – 20 пакетов работ, каждая детализируется еще на 20. Было структурное програмирование. В каждой программе 7 блоков. В крайнем случае 10. Потом куаждый блок – свои 10 блоков и т.д. Было скучновато. Это ушло. Но это была одна из первых систем программирования, а птотом и проектирования. 2. Разбиение проекта на операции (мозговым штурмом). Можно использовать СДР. Тут еще можно детализировать до операции (работы). Неважен объем работ в операции, важно учесть всё. Потом уточняем состав операции по п.1. Мало – разбиваем, много – объединяем. 3. Упорядочивание операций подразумевает их выстраивание в логическом порядке выполнения, для чего требуются хорошие знания технологии и приоритетов проекта. Иначе говоря, в первую очередь проводятся операции, результаты которых необходимы для выполнения последующих операций. Алогичная последовательность операций неизбежно приведет к переделкам и замедлению хода исполнения проекта. (вот только тут появлестя временная взаимосвязь операций!). 4. Оценивание длительностей операций. Ресурсы, людские и материальные, определяют процесс оценивания длительностей операций. Надо определить названия ресурсов и длительность работы каждого из них, например 100 часов работы программиста. Далее, зная доступность ресурсов и рабочий календарь компании (допустим, воскресенье — выходной), произвести преобразование работы во время по календарю. В частности, если программист задействован в нескольких проектах, 100 часов его работы, быть может, придется распределить на 12 недель. И такая процедура должна быть проделана для каждой операции. 5. Составление чернового варианта диаграммы Гантта и ее уточнение. Рисование диаграммы Гантта требует листа бумаги или шаблона, у которого горизонтальная ось соответствует времени, а вертикальная — списку операций. Для ориентира в масштабе можно просуммировать длительности операций. Но реально будет меньше из-за параллельности. Но надо и резерв оставить. Далее следует: • отобразить каждую операцию с помощью полоски, длина которой пропорциональна длительности операции на временной шкале; • в случае множественных операций, составляющих фазу работ, над первой из них дополнительно изобразить суммарную полоску, называемую операцией типа гамак, или просто гамаком. Гамак начинается одновременно с началом первой операции и заканчивается с окончанием последней. Разумно объединять в гамак каждые 4—10 взаимосвязанных детальных операций. Так как руководство нуждается в получении полной картины проекта, способность операций типа гамак к отображению сводной информации делает их очень удобными для этой цели; • проверить правильность диаграммы. Все ли необходимые операции здесь перечислены? Упорядочены ли они логически? Верно ли выбрана временная шкала? Адекватно ли изображены длительности? Внесите на диаграмму все необходимые уточнения и приготовьтесь к ее использованию. 9.8.2. Использование диаграммы Гантта Когда использовать. Диаграмма Гантта — эффективный инструмент для малых и простых проектов, когда нет нужды показывать зависимости между операциями, поскольку они известны всем лицам, участвующим в планировании. По мере увеличения размера и сложности проекта диаграмма Гантта становится все менее приемлемой. Попросту говоря, диаграмма постепенно теряет способность справляться со все возрастающим количеством данных, операций и взаимозависимостей между ними. В больших и кросс-функциональных проектах использование диаграммы Гантта в качестве основного инструмента календарного планирования непрактично и неэффективно (см. врезку «Советы по использованию диаграммы Гантта»). Напротив, в больших и сложных проектах одновременное применение диаграмм Гантта и диаграмм по методу критического пути может быть очень мудрой стратегией. МКП-диаграмма способна эффективно справляться с большим количеством операций, данных и взаимозависимостей между ними, но не в состоянии просто и наглядно показать работающим в проекте людям операции, которые будут выполняться, например, в течение следующей недели или двух. Здесь в игру вступает диаграмма Гантта. Извлечение из обширной МКП-диаграммы тех операций, которые подлежат выполнению в ближайшие одну-две недели, представление их в формате диаграммы Гантта и вручение этих «частичных диаграмм Гантта» людям, ответственным за проведение соответствующих работ, дают возможность получить и использовать ясные и практичные краткосрочные расписания, отражающие ближайшую перспективу. Ответственность за координацию действий владельцев таких расписаний по-прежнему лежит на руководстве. Одно из основных достоинств современных реализаций диаграммы Гантта (например, в инструменте MS Project) состоит в том, что она, используя многоуровневость вложенных задач, позволяет охватить все тело сложного проекта, мультипроекта или программы проектов. — Прим. ред. Время использования. В зависимости от знаний и опыта команды диаграмма Гантта, содержащая 20 операций, может быть разработана за 10—40 минут. Некоторые опытные менеджеры проектов используют правило «операция в минуту», имея в виду, что на отображение каждой операции на диаграмме требуется минута. Учтите: чем больше людей задействовано в построении диаграммы, тем больше времени может понадобиться. Выгоды. Наличие диаграммы Гантта помогает убедиться, что каждый сотрудник понимает график выполнения операций проекта. Затем в календаре каждого участника выделяется необходимое время, после чего люди приступают к проведению операций. Преимущества и недостатки. Диаграмма Гантта характеризуется следующими преимуществами: • наглядность. Диаграмма создает графическую картину проекта, что делает ее непревзойденным инструментом коммуникации; • простота. Практически любой человек, не имеющий или имеющий минимальную специальную подготовку, — от члена команды проекта до спонсора — может читать или строить диаграмму Гантта; • способность отображать как запланированное, так и фактическое состояние проекта (см. раздел «Линия исполнения» главы 12); • возможность использования в планировании и распределении ресурсов. Указание возле каждой операции количества людских ресурсов и суммирование их для каждого периода времени позволяют получить общий объем конкретного ресурса для каждой операции и проекта в целом (см. раздел «Базовый план стоимости» главы 7). Диаграмма Гантта имеет ряд недостатков, способных ограничить ее применимость: • она не показывает взаимозависимости между операциями, не позволяя четко выстроить последовательность операций проекта и, как следствие, критический путь. При отсутствии такой информации диаграммы Гантта становятся малоэффективными в больших и кросс-функциональных проектах; • она не может эффективно справляться с проектами, содержащими большое количество (например, несколько сотен) операций. Этот недостаток компенсируется использованием иерархических диаграмм Гантта, где операция в диаграмме более высокого уровня разбивается на ряд операций в диаграмме более низкого уровня (см. раздел «Иерархическое расписание»). Адаптация диаграммы Гантта. Диаграмма Гантта, представленная в данном разделе, есть не что иное, как обобщенная форма. Она будет полезной только в том случае, если адаптировать ее формат и характеристики к вашим нуждам. Ниже приводятся некоторые примеры подобной подстройки. СОВЕТЫ ПО ИСПОЛЬЗОВАНИЮ ДИАГРАММЫ ГАНТТА • полагайтесь на диаграмму Гантта, пока она содержит не более 25 операций; • используйте диаграмму Гантта в качестве основного инструмента календарного планирования в малых, простых, функциональных проектах; • не используйте диаграмму Гантта в качестве основного инструмента календарного планирования в больших, сложных, кросс-функциональных проектах1; • организуйте командную разработку диаграммы Гантта: это повышает ее качество, обеспечивает большую вовлеченность участников и более высокую степень их приверженности делу. 9.9. Диаграмма по методу критического пути 9.10. Сетевые представления Сетевая диаграмма (сеть, граф сети, PERT-диаграмма) — графическое отображение работ проекта и зависимостей между ними. В планировании и управлении проектами под термином «сеть» понимается полный комплекс работ и вех проекта с установленными между ними зависимостями. Есть типы «вершина-работа» (диаграмма предшествования) и «вершина-событие». Рис. 13.9.1. Фрагмент сети «вершина—работа» Рис. 13.9.2. Фрагмент сети «вершина—событие» Существует еще блок-схема. Похоже, но тут нет циклов, и тут логические связи, а не вход-процесс-выход. 9.10.1. Диаграмма по методу критического пути? Диаграмма по методу критического пути (МКП диаграмма) предоставляет средства отображения операций проекта в виде узлов (рис. 6.4) или стрелок, определяет, какие из них являются критическими (в смысле влияния на время завершения проекта), и выполняет их календарное планирование так, чтобы достичь целевой даты завершения при минимальной стоимости [14]. Это общая постановка, обычно считается, что используестя только временной ресурс. 9.10.2. Построение диаграммы по методу критического пути 1. Сбор исходной информации. Качество МКП диаграммы определяется качеством исходной информации, к которой относятся: • содержание проекта; • области ответственности; • доступные ресурсы; • средства построения. Рис. 6.4. Пример МКП диаграммы 2. Определение степени детализации и идентификация операций. Проект сооружения крупной фабрики содержит около 2000 операций, каждая из которых длится от двух до четырех недель. Это позволяет понять, какая степень детализации приемлема, а какая — нет. Цель календарного планирования — учесть сложность и размер проекта таким образом, чтобы предоставить команде достаточную информацию — не слишком много, но и не слишком мало — с целью направлять повседневную работу, определять взаимодействия между рабочими группами и эффективно отслеживать исполнение. ЗАЧЕМ ПРИ РАЗРАБОТКЕ ДИАГРАММЫ ПО МЕТОДУ КРИТИЧЕСКОГО ПУТИ НУЖЕН КОМАНДНЫЙ ПОДХОД Использование проектной команды представляет собой, возможно, наиболее эффективный способ построения МКП-диаграммы. И вот почему: • члены команды обычно являются самыми достоверными источниками информации о своих фрагментах расписания; • каждый член команды видит, в какое время и в каком месте его участок становится критически важным для успеха проекта; • команда способна наилучшим образом упорядочить операции, сократить их длительности и длительность всего проекта; • команда как целое может сконцентрировать свою энергию и умственные усилия на операциях, критически важных для выполнения проекта; • вовлеченность членов команды в процесс усиливает их чувство сопричастности результатам проекта. Как только необходимая степень детализации определена, можно приступать к осуществлению следующих шагов. 3. Идентифицировать операции, выполнение которых нужно для реализации проекта. Метод – мозговой штурм. Это можно сделать с помощью иерархической структуры работ, позволяющей идентифицировать операции наиболее систематическим и комплексным способом. 4. Уточнение. Если операций получилось меньше, чем предполагалось изначально, следует продолжить разбиение больших операций. Если же количество операций больше задуманного, объединяйте сходные операции до достижения желаемого количества. 5. Упорядочивание операций. Это идентификация взаимозависимостей между операциями. Определяются операции-предшественники, выполнение которых является непосредственным условием для начала каждой операции. Часть операций упорядочивается в чисто технологическом порядке. Описанные взаимозависимости называются жесткими, или логическими, поскольку технология выполнения работ требует именно такого порядка выполнения. Например, код должен быть сначала написан и только потом протестирован, иначе никак нельзя. Игнорирование подобных зависимостей приведет к переделкам проекта и срыву сроков. Есть и мягкие, или предпочитаемые, зависимости. Они не обусловливаются логикой проекта, а устанавливаются произвольно, отражая опыт и предпочтения конкретного менеджера. Например, мы вправе написать часть кода, протестировать ее, написать следующую часть, снова провести тестирование и т. д. Зависимости могут также диктоваться доступностью ресурсов. Если две операции требуют одних и тех же ресурсов, их придется выполнять последовательно. Как только взаимосвязи установлены, они могут быть описаны. См. пример. 6. Выделение ресурсов и оценивание длительности операций. Длительность операции следует определять через перечень ресурсов, необходимых для ее проведения. Например, это программист. Операция требует 100 часов Трудно очень планировать работу проргаммиста. Очень трудно – офисного работника. Рабочих – легче, и теория более развита для них. Напдо учесть, что рабочая неделя 40 часов. Да еще он может быть занят в других проектах или своей повседневной работой. Итого может получиться и 8 недель календарного времени. А ход работы такой: - идентификация ресурсов, - вычисление времени их работы, - преобразование этого времени в календарное - запись результата. 7. Составление чернового варианта МКП диаграммы. Каждая операция отображается на диаграмме в виде условного значка — кружка или прямоугольника. Идентификатор операции и ее длительность проставляются внутри значка. Диаграмма в таком формате называется диаграммой «операции в узлах». Для получения диаграммы «операции в узлах» необходимо отразить зависимости с помощью стрелок, соединяющих каждый кружок (операцию) с его непосредственными последователями, причем острия стрелок должны быть направлены в сторону последних. Для удобства соедините все кружки, не имеющие предшественников, с кружком «старт», а все кружки, не имеющие последователей, — с кружком «финиш». 8. Определение критического пути. Обычно на диаграмме существует несколько различных путей от старта до финиша, определяемых как последовательности зависимых операций. Чтобы вычислить время прохождения по некоторому пути, следует просуммировать длительности всех лежащих на нем операций. Критический путь — это наиболее долгий путь от старта до финиша. Он показывает минимальное время, необходимое для выполнения проекта. По сути, критический путь — это маршрут, представляющий собой «узкое место» проекта и в первую очередь требующий неусыпного внимания. В то время как в малых проектах суммирование длительностей операций не вызывает сложностей, в крупных оно становится обременительным. Поэтому в последнем случае предпочтительнее использовать другой способ вычисления критического пути — процедуру прямого/обратного прохода [16]. Пусть, например, имеется дата старта проекта. Тогда для каждой операции существует наиболее ранняя дата старта (ES). Если время выполнения операции равно t, то наиболее ранняя дата финиша этой операции (EF) вычисляется как EF = ES + t. На рис. 6.5 показано, как осуществляется прямой проход для вычисления дат ES и EF для каждой операции. Процесс (в движении слева направо) выглядит следующим образом: • дата раннего старта операции — это наибольшая (наиболее поздняя) дата среди дат раннего финиша всех ее непосредствен ных предшественников; • дата раннего финиша — это сумма даты раннего старта и длительности выполнения операции. Предположим теперь, что вы хотите завершить проект ко времени раннего финиша проекта. В этом случае определите понятие позднего финиша (LF — наиболее позднее время, в которое может быть завершен проект), так чтобы дата его окончания не превысила дату раннего финиша. Следовательно, LF = EF. По аналогии допустимо определить дату позднего старта (LS) как LF — t, где t — длительность выполнения операции. Основываясь на приведенных положениях, вы можете выполнить обратный проход справа налево для расчета каждой операции (см. рис. 6.5). Рис. 6.5. Прямой и обратный проходы Итак: • дата позднего финиша операции — это наименьшая (наиболее ранняя) дата среди дат позднего старта всех ее непосредственных последователей; • дата позднего старта — это разность даты позднего финиша и длительности выполнения операции. Теперь, когда прямой и обратный проходы завершены, отметьте следующее. На рис. 6.5 показано, что даты раннего и позднего старта равны не для всех операций. Разность между датами позднего и раннего старта (или между датами позднего и раннего финиша) называется полным временным резервом операции. Полный временной резерв — это максимальный промежуток времени, на который вы можете задержать выполнение операции относительно даты ее раннего старта без срыва срока завершения проекта. Другая разновидность временного резерва — свободный временной резерв. Он равен промежутку времени, на который вы вправе задержать выполнение операции относительно даты ее раннего старта без смещения даты раннего старта любой операции, являющейся ее непосредственным последователем. Операция с положительным полным временным резервом может иметь свободный временной резерв или не иметь его. В любом случае свободный резерв не должен превышать полный. Итак, свободный временной резерв равен разности между датой раннего финиша операции и наименьшей (наиболее ранней) датой среди дат раннего старта всех ее непосредственных последователей. В нашем примере (см. рис. 6.5) операции B и D имеют свободный временной резерв, равный 5 и 15 дням соответственно, а все остальные операции обладают нулевым свободным резервом. Для чего же нужны два вида временного резерва? Операции, лежащие на критическом пути, имеют нулевой временной резерв и называются критическими операциями Однако при правильном планировании работы, находящиеся на КП, тоже должны иметь резерв. Суммарный резерв этих работ называется общим резервом проекта. В управлении проектами общий резерв не может быть равен нулю. А критический путь определяется тем, что суммарная длительность работ (без резервов), находящихся на нем, является самой большой среди параллельных цепочек работ, выстроенных по схеме гамак. — Прим. ред.. На рис. 6.5 единственный критический путь показан утолщенными стрелками. Однако критических путей может быть несколько, особенно в проектах, выполняющихся в режиме быстрого прохода. Операция с нулевым полным временным резервом имеет фиксированное запланированное (внесенное в расписание) время старта, то есть ES = LS. Как следствие, задержка старта операции означает задержку старта проекта. Именно поэтому такие операции называются критическими. Напротив, операции с положительным полным временным резервом предоставляют определенную гибкость. Например, допустимо ослабить пиковые нагрузки в проекте (растянуть их во времени) за счет смещения операций в сторону дат позднего старта — и это не повлияет на время завершения проекта. Однако эта гибкость может быстро исчезнуть. Рассмотрим околокритический путь — путь с очень малым полным временным резервом. Околокритические пути требуют почти столько же внимания и управления, сколько критические. Если допустить скольжение операции, находящейся на околокритическом пути, ее малый полный временной резерв будет быстро израсходован, и путь превратится в критический. В случае свободного временного резерва мы можем задержать старт операции на время, равное (или меньшее) свободному резерву без нарушения дат старта или резервов последующих операций. 9. Пересмотр и уточнение. Внимательно посмотрите на черновой вариант своей диаграммы и ответьте на следующие вопросы. • Не оказалась ли упущенной (по забывчивости или иной причине) какая либо важная операция? • Логично ли упорядочены операции? • Имеют ли длительности операций разумные значения? • Календарное планирование проекта выполнено в режиме ограничения по времени или по ресурсам? ОГРАНИЧЕНИЕ ПО ВРЕМЕНИ ИЛИ ПО РЕСУРСАМ Несмотря на тот факт, что фирма Intel весьма заинтересована в скорейшем выходе на рынок с новым продуктом, менеджеры проектов при разработке расписаний вынуждены учитывать проблему взаимоотношений между временем и ресурсами: как бы быстро они ни хотели выполнить проект, доступность ресурсов ограничена. Таким образом, выделяются два класса расписаний [4]: • расписания, ограниченные временем. Проект должен быть завершен к определенному сроку при минимальном использовании ресурсов. В данном случае критическим фактором является время, а не ресурсы. Как правило, это проекты, которые имеют высокий приоритет; • расписания, ограниченные ресурсами. Проект нужно завершить как можно быстрее, но затратив не более определенного количества ресурсов. В таком случае критическим фактором уже являются ресурсы, а не время. Как правило, это проекты, которые имеют низкий приоритет. Между двумя крайними случаями расположены проекты с выравниванием ресурсов, имеющие средние (промежуточные) приоритеты. В таких проектах после разработки расписания задачи перемещают в допустимых временных границах, чтобы добиться более равномерного использования ресурсов. Пока руководство четко определяет, к какой группе относится каждый проект, менеджеры не испытывают проблем, поскольку большая часть коммерчески доступного программного обеспечения управления проектами уже содержит алгоритмы, позволяющие разрабатывать расписания для любой из трех названных ситуаций. Проблемы возникают, когда руководитель обязывает менеджеров выполнить проект к конкретному сроку, но при этом выделяет недостаточное количество ресурсов. Столкнувшись с таким системным ограничением [8], менеджеры вынуждены самостоятельно изыскивать ресурсы. В результате они работают сутки напролет, убеждая членов команды проекта поступать так же, и лавируют, лавируют, лавируют... В большинстве случаев им сопутствует успех. В конце концов, корпоративные принципы Intel направлены прежде всего на обеспечение производительности. Если компания участвует в конкурентной гонке и критическим параметром является время, то надо проверить, нельзя ли сократить длительность проектов. Единственный способ сделать это — постараться сократить операции, лежащие на критическом пути, с помощью быстрого прохода либо сжатия длительности, а также посредством их комбинации [18]. Быстрый проход означает чередование жестких и мягких зависимостей, изменяя логику диаграммы посредством устранения изначально существовавших зависимостей и создания новых. В этом процессе длительности операций и объем ресурсов остаются прежними. Иными словами, быстрый проход связан с изъятием операций с критического пути и их перекрывающимся выполнением. Распараллеливание. Сжатие означает сокращение длительности операций, лежащих на критическом пути, без изменения взаимозависимостей между ними. Этого можно добиться, выделив для выполнения операции больше людей, организовав сверхурочные работы, используя другое оборудование и т. д. Однако сначала следует рассчитать, перевешивают ли получаемые выгоды стоимость подобного ускорения проекта. Для большинства проектов, где наиболее важным показателем является время выхода на рынок, ответ — да. СОВЕТЫ ПО МКП-ДИАГРАММЕ • Если вам необходимо ускорить расписание, делайте это посредством быстрого прохода или сжатия. • Будьте осторожны! Ускорение расписания может увеличить число критических операций. Если раньше критическими были около 10% от общего количества операций, то в сегодняшних быстрых расписаниях таковыми являются от 40 до 50%. • Распределите основные контрольные события по диаграмме. Это поможет увидеть как лес (контрольные события), так и деревья (операции). • Применяйте цветовую маркировку операций, выполняемых различными поставщиками ресурсов, чтобы показать взаимодействия между ними и обеспечить координирование. • Разрабатывайте шаблоны МКП-диаграмм, а затем используйте их логически непротиворечивым образом при составлении расписаний для новых проектов. 9.10.3. Использование мкп диаграммы Когда использовать. Инструмент критического пути изначально был разработан для больших, сложных и кроссфункциональных проектов [19]. Так как можно работать с большим количеством операций, но выделять критические. С распространением знаний и появлением прораммной поддержки метод стал использваться и в более малых проектах. Полезно взять МКП, и на ближайшие недели построить диаграмму Гантта. Трудоемкость. Опытной небольшой команде на по строение МКП диаграммы, содержащей 250 операций, может по требоваться один-два дня. Рост численности команды усложняет взаимодействие между ее членами и, как следствие, приводит к увеличению необходимого времени. Применение в качестве отправной точки шаблона расписания позволяет сократить время разработки. ТРИ «НЕ» ДЛЯ МКП-ДИАГРАММ • Не допускайте, чтобы МКП-диаграмма управляла вами. Это лишь расписание, и оно не примет решения за вас. • Не считайте МКП-диаграмму истиной в последней инстанции. Если существует лучший способ составления расписания — воспользуйтесь им! • Не отбрасывайте диаграмму сразу же, как только сроки выполнения операций начинают скользить. Пересмотрите ее, обновите, усовершенствуйте — и применяйте снова! Выгоды. Наличие МКП расписания помогает менеджеру получать информацию об общем времени выполнения, оценивать последовательность операций, обеспечивать необходимые ресурсы, отслеживать критические участки или измерять прогресс проекта (или его отсутствие). Преимущества и недостатки. МКП диаграмма обеспечивает следующие преимущества: • графическое представление. Значение диаграммы легко объяснить даже дилетантам на основе сетевого графика проекта, который в явном виде отображает технологический порядок работ. Вычисления не представляют сложности и могут быть быстро выполнены с помощью современных персональных компьютеров; • интуитивная логика. Диаграмма просто и недвусмысленно отображает зависимости в сложной совокупности операций, составляющих проект, показывая, какие операции должны быть завершены, прежде чем будут начаты другие; • акцент на высшем приоритете. МКП диаграмма привлекает внимание к небольшой группе операций, имеющих критическое значение для соблюдения времени завершения проекта, что значительно повышает точность расписания и надежность его контроля. Из недостатков МКП диаграммы могут быть названы следующие: • она слишком витиевата для тех, кто использует ее впервые. Множество операций, выглядящих как паутина взаимосвязанных путей, способно дезориентировать новичка, поскольку затрудняют понимание. Один из менеджеров сказал: «Когда я воспользовался методом МКП в первый раз, мне на ум пришло сравнение с усеянным птичьими следами полем, совершенно не поддающимся расшифровке»; • она не привязывает события к конкретным датам, так как не содержит временной шкалы. Диаграмма, разумеется, сопровождается таблицей, в которой указаны сроки, однако современные менеджеры проектов, которым никогда ни на что не хватает времени, но от которых постоянно требуются скорость и эффективность, считают, что невозможность быстро проверить даты и временные резервы снижает ее ценность; • она становится перенасыщенной, если применяется к очень динамичному проекту, где частые изменения — в порядке вещей. Как следствие, обновление и изменение расписания может оказаться очень времяемким. Вариации. МКП диаграмма, приведенная в данной главе, имеет формат AON («операции в узлах»). Существуют и другие форматы МКП: АОА («операции на стрелках»), PERT (методика оценивания и рассмотрения программ) и PDM (диаграмма предшествования). В методе АОА операции показываются в виде стрелок, соединенных между собой кружками (или точками), которые обозначают последовательностные зависимости. Таким образом, все непосредственные предшественники операции ведут к кружку, находящемуся в хвосте стрелки, а все непосредственные последователи ответвляются от кружка в острие стрелки. Таким образом, кружок становится событием, где завершаются все ведущие к нему операции. МКП очень похож на PERT [21], исключая тот факт, что для расчета ожидаемой длительности операции МКП использует детерминистские оценки, a PERT — средневзвешенные, вычисляемые по формуле: где а — оптимистическая оценка длительности; b — пессимистическая оценка длительности; m — наиболее вероятная оценка длительности. Метод PERT использовался главным образом в исследовательских проектах и проектах разработки, в то время как МКП, изначально предназначенный для строительной индустрии, распространился и в других предметных областях. PDM — это сеть «операции в узлах», позволяющая вводить между двумя операциями опережения и задержки. С ее помощью упрощают процедуру отображения разветвленных и сложных зависимостей, имеющих место в реальных проектах, что обеспечивает методу PDM широкую применимость в различных отраслях и дает ему преимущество перед методами МКП и PERT (эти методы позволяют вводить опережения и задержки только путем расщепления операций на подоперации, что ведет к значительному увеличению количества операций в сети и усложнению управления ей). Адаптация МКП диаграммы. В данном разделе мы описали обобщенный вид МКП диаграммы. Для того чтобы получить максимальную выгоду, вам следует адаптировать ее к конкретным проектным нуждам. Ниже приводятся некоторые примеры такой подстройки. Действия по адаптации Примеры действий по адаптации Определение границ использования – Использовать МКП/диаграмму для кросс-функциональных проектов, содержащих более 25 операций; – выбрать формат диаграммы — «операции на стрелках» или «операции в узлах»; – разработать шаблоны, которые будут использоваться в качестве стартовой позиции при составлении МКП/диаграмм для новых проектов Модификация конкретной характеристики — Изменить систему обозначений в соответствии с тем, что будет отображено на диаграмме, например название операции, длительность, ресурсные требования, владелец и т. д.; — принять решение о способе показа критического пути Добавление отличительной особенности Добавить на диаграмму основные контрольные события и связать их с операциями с целью отображения зависимостей 9.11. Диаграмма «операции на стрелках» во временном масштабе 9.11.1. Что такое диаграмма «операции на стрелках» во временном масштабе? Диаграмма «операции на стрелках» во временном масштабе (time-scaled arrow diagrams TAD) — это единственный из методов критического пути, который использует временную шкалу (рис. 6.6). Его назначение состоит в том, чтобы анализировать, планировать и выполнять календарную привязку проектов для достижения целевой даты при минимальной стоимости. В ходе этого процесса TAD определяет, какие операции проекта являются критическими в смысле оказываемого ими влияния на дату завершения проекта, позволяя команде сконцентрироваться на них. 9.11.2. Построение TAD Построение TAD — задача, требующая терпения и дисциплины. Она включает в себя несколько основных шагов. Как и для всех инструментов календарного планирования, здесь необходимо сначала определить степень детализации и идентифицировать операции. Хотя этот шаг обычно относится к процессу планирования содержания, мы рассмотрим его с целью представить полную картину разработки данного инструмента. 1. Сбор исходной информации. Качество TAD в значительной степени определяется качеством исходной информации, к которой относятся: • содержание проекта; • области ответственности; • доступные ресурсы; • система управления расписанием. Рис. 6.6. Пример TAD 2. Определение степени детализации и идентификация операций. Крупные проекты разработки и представления новых продуктов, как правило, включают от 300 до 500 операций длительностью три–пять недель. Следовательно, именно такая степень детализации может считаться приемлемой. Она обеспечивает то количество информации — ни больше ни меньше, — которое нужно для направления и мониторинга работ проекта конкретного размера и уровня сложности. Как только необходимая степень детализации определена, можно приступать к выполнению следующих шагов: 3. Идентифицировать операции, выполнение которых нужно для реализации проекта. Как и для любого инструмента календарного планирования, это можно сделать с помощью иерархической структуры работ, позволяющей идентифицировать операции наиболее систематическим и комплексным способом. Для составления TAD необходимы те же операции, что и для выполнения пакетов работ — элементов самого низ кого иерархического уровня СДР. 4. Уточнение. Если операций получилось меньше, чем предполагалось изначально, следует продолжить разбиение больших операций. Если же количество операций больше задуманного, объединяйте сходные операции до достижения желаемого количества. 5. Упорядочивание операций. Упорядочивание — это нахождение и установление взаимозависимостей между операциями, расположение операций в определенном порядке путем выявления для каждой из них тех операций предшественников, выполнение которых является непосредственным условием для данной операции, и устранением свободных концов. СВОБОДНЫЕ КОНЦЫ МОГУТ СБИТЬ С ТОЛКУ ПРОЕКТНУЮ КОМАНДУ Мы часто наблюдаем TAD, содержащие свободные концы, в том числе ХВОСТЫ И ОСТРИЯ СТРЕЛОК, не связанные с другими операциями. Ответ на вопрос: «Почему?» — звучит примерно так: «Я хочу показать только критический путь и зависимости на нем. Остальные части и относящиеся к ним зависимости для меня несущественны». Это порочная практика. Для того чтобы определить критический путь, команда должна оценить все пути, которые содержат операции, должным образом соединенные друг с другом. Если имеются свободные концы, команда просто не заметит действительно критического пути. В результате цель разработки TAD — привлечение внимания к критическим операциям — не достигается. Можно использовать и жесткие, и мягкие зависимости. Отношения между операциями Бывают следующих типов: финиш–старт (FS), старт–старт (SS), финиш–финиш (FF) и старт–финиш (SF) [22]. Для каждой из представленных таким образом зависимостей можно задать величину опережения/задержки, а затем более точно определить эти зависимости (рис. 6.7). Зависимость FS – наиболее типичная. Зависимость SS широко распространена в ослучаях, где требвется сокращении времени ЖЦ. Отражает допустимость параллельной работы. Зависимости типа FF и SF популярными так и не стали. 6. Выделение ресурсов и оценивание длительности операций. Аналогично МКП. Есть сложность. ВРЕМЯ ПЕРЕКЛЮЧЕНИЯ МЕЖДУ ЗАДАЧАМИ УВЕЛИЧИВАЕТ НЕТОЧНОСТЬ РАСПИСАНИЯ Почти 90% проектов выполняется в мультипроектной среде. Это значит, что наличие менеджеров, управляющих одновременно несколькими (от 2 до 10) проектами, является широко распространенной практикой [3]. И хотя подобный подход обеспечивает грандиозные преимущества в смысле повышения качества управления [7], он также порождает уникальную проблему, обусловленную чрезвычайно скрупулезным календарным планированием, — это время переключения между задачами. Когда менеджер переключается с одного проекта на другой, ему требуется определенное время для перестройки мышления и «вхождения» в другой проект — как физически, так и психологически [8]. Сотрудники также входят сразу в несколько проектных команд и испытывают те же трудности. С ростом размеров и сложности их проектов увеличивается и время переключения между задачами [10]. Некоторые эксперты утверждают, что размер потерянного времени может доходить до 20% от общего рабочего времени менеджера мультипроекта или сотрудника, участвующего в четырех проектах одновременно. Реальная проблема состоит в том, что при календарном планировании множественных проектов потери времени на переключение обычно не учитываются. Как следствие, расписания проектов печально известны своей оптимистичностью и неточностью. Справиться с этой проблемой помогают по крайней мере две стратегии. Одна состоит в том, что при проведении календарного планирования уменьшить ежемесячное количество часов работы занятого в нескольких проектах лица на то время, которое потребуется на переключение от одного проекта к другому. Другая стратегия — увеличить для конкретного проекта оценку рабочих часов занятого в мультипроекте лица на величину потерь. Эти стратегии не обладают особой привлекательностью, однако они необходимы для реалистичной разработки TAD или любого другого используемого инструмента. 7. Выбор формата представления. Сопоставление формата позвоночного столба и каскадного формата TAD. Каскадный формат: • одна зона — одна операция. Зона — это горизонтальный ряд или полоска, проходящая через изображение TAD. Каскадный формат позволяет отображать одну операцию в одной зоне; • пониженная сложность. Каскад напоминает диаграмму Гантта — простой по виду инструмент, который создает ощущение малой сложности и легкого применения; • менее практичный. Так как одна операция располагается в одной зоне, TAD большого размера может потребовать для своего отображения многих листов бумаги и большого пространства (например, на стене) для размещения. Формат позвоночного столба: • одна зона — много операций. Данный способ позволяет отображать в одной зоне несколько операций. Позвоночный столб, так как операции симметрично располагаются от центрального, обычно критического пути; • повышенная сложность. Внешний вид TAD в значительной степени напоминает любую другую сеть, что иногда выглядит сложным и отпугивает некоторых менеджеров проектов; • Более практичный. Поскольку в одной зоне могут располагаться несколько операций, допустимо напечатать TAD большого размера на одном листе бумаги, разместив его на малом пространстве. 8. Составление чернового варианта TAD. Каждая операция отображается на диаграмме в виде стрелки. Острие одной стрелки совмещается с хвостом другой, показывая последовательность операций. При таком изображении все непосредственные предшественники любой операции соединены с началом (то есть с хвостом) стрелки, отображающей эту операцию, а все не посредственные последователи ответвляются от острия. Таким образом, начальная точка стрелки (хвост) становится событием, когда все операции, ведущие в эту точку, завершены. Есть форматы позвоночного столба и каскадный. 9. Определение критического пути. Обычно на TAD существует несколько различных путей, определяемых как последовательности взаимозависимых операций. Здесь критический путь виден просто. Но можно и расчетами, как выше. 10. Пересмотр и уточнение. Далее следует пересмотреть то, что было разработано. TAD позволяет: • определить критический путь, резервы, даты начала и окончания операций и их длительности; • проверить жесткие и мягкие зависимости — опережения и задержки; • выявить благоприятные возможности для ускорения выполнения проекта, ввести опережения или задержки. Иными словами, при пересмотре и уточнении TAD мы можем модифицировать ее для того, чтобы получить более хорошее расписание, удовлетворяющее наши нужды. 11. Проверка TAD. Убедитесь, что TAD: • показывает все операции, необходимые для выполнения проекта; • отображает логическую последовательность операций; • не содержит свободных концов; • показывает длительности всех операций и выделенные для них ресурсы; • отражает длительность каждой операции в масштабе временной шкалы; • обозначает критические пути и полные временные резервы. 9.11.3. Использование TAD Когда использовать. Изначально предназначен для больших проектов. Но сейчас и в малых. В малых обычно каскад. Называется диаграмма Гантта со взаимозависимостями. Можно строить диаграмму Гантта для ткущих работ. Трудоемкость. Опытной небольшой команде проекта на построение TAD диаграммы, содержащей 250 операций, требуется один полтора дня. Рост численности команды приводит к увеличению необходимого времени. Использование в качестве отправной точки шаблона TAD является хорошим способом сократить время разработки. Выгоды. Как и у других сетевых графиков. Но есть и уникальная возможность, —непосредственное считывание с временной шкалы дат начала и завершения отдельных операций и всего проекта, равно как и значений полного временного резерва. Преимущества и недостатки. TAD обладает следующими пре имуществами: • • пониженная сложность. TAD сочетает в себе лучшие черты диаграммы Гантта (наглядность и временную шкалу) и сетевого графика (отражение взаимосвязей). Это делает применение TAD гораздо более привлекательным в сравнении с другими сетевыми графиками; • графическое отображение. Способность к четкому отображению последовательности работ в масштабе временной шкалы упрощает понимание значения диаграммы. Вычисления не представляют трудности и могут быть проведены быстро и просто с использованием персонального компьютера; • интуитивная логика. TAD просто и явно показывает взаимозависимости между входящими в проект операциями. Это помогает определиться с порядком следования операций. Недостатки: • бывает, что выглядит сложно. Множество взаимосвязанных операций, даже представленное в каскадном формате, может сбить с толку неопытного пользователя; • ошеломляющий объем работ и большие затраты времени в ситуациях, когда требуются частые и значительные обновления и изменения TAD. СОВЕТЫ ПО TAD • Если выполнять расписание нужно в режиме быстрого прохода, используйте зависимость «старт—старт» без задержки. Будьте готовы к тому, что 40–50% от общего числа операций окажутся критическими. • Основываясь на сходстве TAD в каскадном формате и диаграммы Гантта, распространите использование TAD во всех малых проектах. Это существенно повысит точность календарного планирования. • Введите в TAD контрольные события — пусть они служат маяками в море операций. • Добейтесь применения шаблонов TAD — это поможет поднять качество и производительность календарного планирования. Адаптация TAD. Материал, рассмотренный в данном разделе, относится к стандартному, обобщенному виду TAD диаграммы. Для того чтобы получить максимальную выгоду, вам следует адаптировать ее к конкретной проектной ситуации. Ниже приводятся некоторые примеры подобной подстройки. Действия по адаптации Примеры действий по адаптации Определение границ использования – Использовать TAD для функциональных и кросс-функциональных проектов, содержащих более 25 операций; – применять каскадный формат при количестве операций, не превышающем 100, и формат позвоночного столба в остальных случаях; — создать шаблоны, которые могут использоваться в качестве стартовой позиции при разработке TAD-диаграмм для новых проектов Модификация конкретной характеристики – Изменить систему обозначений в соответствии с тем, что будет отображено на диаграмме, например название операции, длительность, ресурсные требования, владелец и т. д.; — принять решение о способе показа критического пути Добавление отличительной особенности Добавить на диаграмму основные контрольные события и связать их с операциями с целью отображения зависимостей 9.12. Расписание по методу критической цепочки 9.12.1. Что такое расписание по методу критической цепочки? Расписание по методу критической цепочки (CCS) — это сетевой график, нацеленный на получение радикально коротких расписаний (рис. 6.8). Данный метод, разработанный в 1997 году, является относительно новым инструментом для менеджеров и использует ряд уникальных подходов. Во-первых, он делает акцент на критической цепочке, то есть наиболее длинном пути взаимозависимых операций, который препятствует выполнению проекта в срок. Критическая цепочка, в отличие от критического пути, никогда не изменяется. Во вторых, длительности операций критической цепочки представляют собой оценки, взятые с 50%-ной вероятностью, поэтому они существенно короче, чем в других инструментах календарного планирования, где, как правило, предполагается 95%-ная вероятность. В-третьих, в противоположность критическому пути критическая цепочка определяется ресурсными зависимостями. В-четвертых, в критическую цепочку встроены буферы, предназначенные для ее защиты в ходе выполнения проекта. И наконец, метод критической цепочки требует определенных действий со стороны членов проектной команды. 9.12.2. Построение CCS 1. Сбор исходной информации. В силу того что получение коротких расписаний сопровождается неизбежными трудностями, а также вследствие новизны данного метода, качество CCS зависит от детальности и определенности исходной информации даже в большей степени, чем при использовании других инструментов календарного планирования. К исходной информации относятся: • содержание проекта; • области ответственности; • выделенные ресурсы; • система управления расписанием. Рис. 6.8. Пример расписания по методу критической цепочки Ресурсы здесь наиболене важны. Особенно важно рассмотреть те, котоыре задействованы полностью и только в данном проекте. Согласно логике метода, те члены команды, которые работают в режиме полной занятости, обеспечивают более высокую производительность, чем те, время которых разделяется между несколькими проектами (нет переключекний). Но есть и другая сторона медали. На практике, когда конкретному члену команды, занятому в единственном проекте, дается дополнительное задание по второму проекту, производительность обычно немного возрастает, поскольку этому сотруднику больше не приходится ждать, пока другие члены команды его проекта выполнят свои операции, — он может просто переключаться между двумя проектами. Однако при добавлении третьего, четвертого, пятого и т. д. проекта производительность резко падает, и данный специалист тормозит выполнение всех проектов, в которых участвует. Именно поэтому метод CCS требует использования выделенных проектных команд. Рис. 6.9. Производительность члена команды1 1 Перепечатано с разрешения The Free Press, an imprint of Simon & Schuster Publishing Group, из REVOLUTIONIZING PRODUCT DEVELOPMENT: Quan tum Leaps in Speed, Efficiency, and Quality by Steven C. Wheelwright and Kim B. Clark. Copyright © 1992 by Steven C. Wheelwright and Kim B. Clark 2. Определение степени детализации и идентификация операций. Крупные проекты разработки новых продуктов, включающие в себя от 5 до 10 тысяч человекочасов трудозатрат, будут содержать порядка 500 операций длительностью от одной до четырех календарных недель. Это правило не только свидетельствует о недопустимости, например, расписания, состоящего из 180 операций, или операций, имеющих 15 недельную длительность. По идее, детальность отражает точку зрения компании на то, какой должна быть правильная степень детализации. 3. Мозговой штурм: идентификация операций, которые необходимы для реализации проекта. Пока не надо принимать во внимание размер операций, а надо сосредоточиться на том, чтобы идентифицировать их все. 4. Проверить получившуюся степень детализации. Если имеющееся количество операций меньше желаемого, то продолжить разбиение крупных операций, а если больше — объединить сходные операции. 5. Упорядочивание операций. Аналогично предыдущему случаю 6. Выделение ресурсов и оценивание длительности операций. . Не надо включать резерв на случай ЧП. Включают, явно не оговаривая, чтобы подстраховаться. Тут этого не надо бы, вбудет учтено! Есть рапределение времени выполнения операции. Есть точка длительности, при кторой вероятность выполнения равна 50%. (20 дней) Есть точка, при которой вероятность равна 95% (50 дней). Резерв получается в 30 дней! Надо брать не 95%, а 50%! Это будут делать тогда, когда реально надо сделать быстро! 7. Определение критической цепочки. Критическая цепочка (CC) — это наиболее длинный путь в сетевом графике с учетом взаимозависимостей между операциями и ресурсами либо последовательность взаимозависимых событий, которые препятствуют выполнению проекта в более короткий срок. 8. Указание ресурсных буферов. Служат для защиты критической цепочки от недоступности ресурса. Не имеют длительности. Вводятся для каждого вновь используемого ресурса. Означает момент, когда новый ресурс потребуется в готовй к выполнению операции критической цепочки. 9. Создание проектного буфера. Это новое. На случай чрезвычайных ситуаций, срывов предоставляется временной резерв без работ в конце критической цепочки. Длительность выибрается, например, как 50% длительности критической цепочки (см. пример расписаня по критической цепочке). 10. Создание питающих буферов критической цепочки. Там, где операции не из критической цепочки впадают в критическую цепочку. Размер чаще всего равен половине длительности предшествующих операций (пояснить, каких). 11. Пересмотр и уточнение. Заключительный этап при построении CCS — пересмотр того, что именно разработано. Цель пересмотра — внести изменения, которые могут привести к получению более эффективного расписания проекта. 11.1. Внимательно рассмотрите CCS, определите критическую цепочку, даты начала и завершения операций, их длительности и буферы. 11.2. Есть ли логика в таком построении? Имеются ли возможности по улучшению CCS? СОВЕТЫ ПО CCS • Применяйте CCS в важных проектах, которые могут позволить себе использование выделенных команд. • Задействуйте CCS в компаниях, участвующих в конкурентной гонке, где важно время выхода на рынок и, как следствие, сокращение длительности цикла проекта. • Сопровождайте применение CCS измерением производительности и поощряйте поведение, которое способствует досрочному получению результатов операций и использованию их в последующих операциях. • Работайте с CCS там, где существует устойчивая культура исполнения, готовая принять оценки с 50%/ной вероятностью. 9.12.3. Использование CCS Когда использовать. Не везде. Применение CCS наиболее обоснованно в том случае, когда над проектом работает отдельная команда, стремящаяся значительно сократить длительность жизненного цикла проекта. Единственная работа такой команды — ее проект. Команда, снабженная всеми необходимыми ресурсами, функционирует в компании, культура исполнения которой сконцентрирована на превышении ожиданий своих заказчиков, создании дополнительных ценностей для акционеров и обеспечении надежного карьерного роста для своих сотрудников. Трудоемкость. Опытной небольшой команде проекта на построение CCS, содержащего 250 операций, требуется один-полтора дня. Рост численности команды усложняет коммуникацию между ее членами и, как следствие, приводит к увеличению необходимого времени. Применение в качестве отправной точки шаблона расписания позволяет существенно сократить время разработки. Выгоды и расходы. То же, что и в других методах, но применение CCS в проекте способно значительно сократить финансовые и временные затраты, что объясняется следующими факторами: • CCS представляет собой превосходный способ посмотреть на ситуацию с другой стороны. Иначе говоря, CCS признает и принимает во внимание тот факт, что взаимозависимости операций, взаимосвязи между длительностями операций, ресурсными требованиями и доступностью ресурсов оказывают значительное влияние на общее время выполнения проекта [28]; • CCS обеспечивает защиту базового расписания, помогая бороться с неопределенностями посредством использования питающих, ресурсных и проектных буферов, что позволяет установить реалистичный предельный срок завершения проекта. Как следствие, CCS дает возможность радикально сократить сроки исполнения проекта. По опыту: на 25%; • CCS помогает правдиво оценить длительности операций [29]. В противоположность другим инструментам данный метод обладает встроенным механизмом, который предотвращает введение менеджером временного резерва; • CCS способствует как корпоративным, так и проектным достижениям. Критическая цепочка требует идеального исполнения, что очень трудно. Здесь - реаличтично; • CCS укрепляет дисциплину. Есть и минусы. Эксперты считают, что есть некоторые допущения и требования, которые могут снизить эффективность: • нужна дополнительная эмпирическая проверка; • часто ставят большой резерв на случая ЧП и размер буферов часто завышают, ставить 50% вероятность – требуется суперкоманда; • требуется отдельная команда проекта, это усложняет взаимодействие с внешними организациями; • не используются контрольные события, что затрудняет координирование расписания с внешними организациями; • CCS изматывает участников проекта. Стрессы и проч. Преимущества. Простая концепция 50% вероятность. Почти не требуют статистической подготовки. Адаптация CCS. Материал, рассмотренный выше, относится к стандартному, обобщенному виду CCS. Для того чтобы получить максимальную выгоду, вам следует адаптировать это метод к конкретным нуждам. Ниже приводятся некоторые примеры подобной подстройки. Действия по адаптации Примеры действий по адаптации Определение границ использования — Использовать CCS для кросс/ функциональных проектов стратегического характера; — применять каскадный формат, как и в случае TAD, поскольку он привычнее для менеджеров Модификация конкретной характеристики — Изменить систему обозначений в соответствии с тем, что будет отображено на расписании, например название операции, длительность и т. д.; — принять решение о способе показа критической цепочки и буферов ПРОВЕРКА РАСПИСАНИЯ ПО МЕТОДУ КРИТИЧЕСКОЙ ЦЕПОЧКИ Убедитесь, что расписание по методу критической цепочки: • показывает все операции, необходимые для выполнения проекта; • отображает логическую последовательность операций; • отражает длительности операций без временного резерва на случай возникновения чрезвычайной ситуации, то есть основывается на оценке с 50%-ной вероятностью; • показывает проектный буфер, предназначенный для защиты целевой даты завершения проекта; • выявляет питающие буферы, служащие для защиты критической цепочки; • представляет ресурсные буферы, определенные для защиты критической цепочки. 9.13. Иерархическое расписание 9.13.1. Что такое иерархическое расписание Иерархическое расписание — это многоуровневое расписание с переменной степенью детализации на каждом уровне (рис. 6.11). Каждая операция в расписании более высокого уровня разбивается на несколько операций, а иногда на целые расписания. Как правило, расписания различных уровней связываются в местах контрольных событий проекта. Хорошей основой для построения иерархических расписаний является структурная декомпозиция работ. 9.13.2. Построение иерархического расписания Разработка иерархических расписаний тесно связана с объемом проекта. Очень большой проект вполне может использовать три уровня расписаний, в то время как проект среднего размера — не более двух. Чтобы представить наиболее сложную ситуацию, мы рассмотрим здесь трехуровневое расписание. При составлении расписаний следует руководствоваться правилами для расписания соответствующего типа — будь то диаграмма Гантта, сетевой график или диаграмма контрольных событий. Качество иерархического расписания определяется качеством исходной информации, к которой относятся: • содержание проекта; • области ответственности; • доступные ресурсы; • система управления расписанием. Содержание проекта может обеспечить вас информацией, необходимой для понимания операций, которые подлежат календарному планированию. Сведения о содержании предоставляются менеджерам, ответственным за выполнение конкретных пакетов работ проекта, либо изыскиваются ими. При календарном планировании пакетов работ эти менеджеры будут опираться на информацию о доступности ресурсов и руководствоваться указаниями системы управления расписанием. Рис. 6.11. Пример иерархического расписания Разработка расписания уровня 1 — главного расписания проекта. Главное расписание проекта — это сводное расписание, выполняемое, как правило, в формате диаграммы Гантта или диаграммы контрольных событий. Создается на этапе планирования, это начальный план. Основывается на контрольных событиях. Цель: выявить фазы, которые требуют особого внимания, например, материальное обеспечение; определить важные испытания, важные даты получения результатов. Поэтому полезно связать с целями и задачами проекта. И еще цель – показывать руководству отчетность о ходе проекта. Расписание уровня 2 называется функциональным, так как обычно находится в вединии функциональных единиц. Разворачивает операции главного расписания проекта, осуществляя их календарное планирование с большей степенью детализации. Для этого расписания обычно выбирается формат диаграммы Гантта или сетевого графика с включенными контрольными событиями. Цель. Используется руководителями среднего звена для планирования и управления. Важная задача - распределение ответственности за выполнение пакетов работ (уровня 3 СДР). Требования. Надо включить всё важное: все контрольные события, людские ресурсы, логическую упорядоченность работ, возможные смещения времени выполнения операций. Соответственно расписание уровня 2 должно: • допускать идентификацию приоритетов проекта; • определять критические и околокритические пути; • обеспечивать быстрый старт проекта, как только от руководства будет получено разрешение на его выполнение. Пример. Крупное расписание уровня 2 имеет вид диаграммы операции на стрелках во временном масштабе, каскадный тип, 10 пакетов работ. Было функциональным расписанием для подразделения: отдела маркетинга, группы электротехники, группы оптоэлектроники, группы программно аппаратного обеспечения и т. д. Уровень 3 – расписние пакетов работ. Используется менеджерами низшего звена, например менеджерами пакетов работ, для корректировки ежедневных и еженедельных работ проекта. Более популярен формат диаграммы Гантта или диаграммы контрольных событий. Есть виды. • создание полностью интегрированного расписания для всего проекта; • построение законченного расписания для каждой операции расписания уровня 2; • создание отдельного детального расписания для каждой фазы по мере развертывания проекта и их связывание через расписание уровня 2; • разработка каждым участником проекта детальных расписаний для операций уровня 2, за которые он несет ответственность. Расписание уровня 3 должно отражать ежедневную и еженедельную работу, которую сотрудники организации обязаны выполнять и контролировать, и опираться на доступные ресурсы, установленные взаимозависимости и временные цели, одобренные руководством. Пример. Для пакетов ралот используется диаграмма Гантта, до 10 операций. Всего около 500 операций уровня 3. Возможны варианты. Надо, конечно, смотреть на проблему в целом. РАСПИСАНИЕ «КОНТРОЛЬНЫЕ СОБЫТИЯ — МЕТОД КРИТИЧЕСКОГО ПУТИ — КОНТРОЛЬНЫЕ СОБЫТИЯ» ПОЗВОЛЯЕТ ДОБИТЬСЯ ЖЕЛАЕМОГО РЕЗУЛЬТАТА Некая компания, работающая в сфере полупроводниковых технологий, определила в своем проекте длительностью шесть месяцев и стоимостью 70 миллионов долларов несколько основных контрольных событий, которые были представлены группе руководителей высшего звена (расписание уровня 1). Для еженедельного отслеживания и корректировки хода исполнения команда использовала МКП-диаграмму, в которую было внесено более 400 малых контрольных событий (расписание уровня 2). Малые контрольные события диаграммы были сгруппированы в отдельные диаграммы контрольных событий, врученные затем рабочим группам, которые отвечали за ту или иную техническую дисциплину (расписания уровня 3). Каждая диаграмма контрольных событий, включающая в себя от 40 до 50 элементов, являлась ключевым инструментом выполнения работ и предоставления отчетов о прогрессе команде управления проектом. Будучи свободной от сложных зависимостей, типичных для МКП-диаграмм, диаграмма малых контрольных событий определила четкие и простые цели, к достижению которых нужно было стремиться. 9.13.3. Использование иерархического расписания Когда использовать. Иерархические расписания применяются в следующих ситуациях, встречающихся при выполнении проектов: • при высокой неопределенности порядка выполнения календарное планирование методом бегущей волны. Бывает, что к началу проекта есть информация лишь о его начальной фазе; остальные детали проясняются по мере развертывания проекта. Делается грубое расписание всего проекта. А для фаз делаем по мере определения деталей; • для крупных проектов. У руководителей разных уровней различные обязанности в проекте. Каждому нужна информация с разной степенью детализации. Трудоемкость. Для разработки трехуровневого иерархического расписания с несколькими сотнями операций может потребоваться несколько дней, если в организации есть соответствующие процессы. Однако чем больше людей заняты в разработке расписания и чем менее они опытны, тем больше времени понадобится. Хорошо, что эти временные затраты распределены по всему периоду выполнения проекта. Выгоды. Интеграция всего календарного планирования по уровням и по времени (по фазам ЖЦ). Все имеют персональные задания, но при этом видят и общую картину (сравнение с бегуном. Он видит текущий участок дороги, но полезгно видеть, где будет подъем, сколько осталось, куды бечь). Преимущества и недостатки. Преимущества иерархических расписаний заключаются в следующем: • гибкость. Общее есть, далее на том, что надо делать сейчас. Не надо думать о том, о чем нет информации; • надлежащий объем информации. Все знают только то, что необходимо. Недостатки: • сложность. Нужен отработанный процесс, навыки, коориднация работы многих участников при разарботке. Не сразу получается; • трудоемкость. Недовольны часто. Но хорошо хоть, что затраты распределены. СОВЕТЫ ПО ИЕРАРХИЧЕСКИМ РАСПИСАНИЯМ • Используйте иерархическое расписание, если вы имеете дело с проектом, где информация появляется по мере развертывания. • Вовлекайте в процесс календарного планирования тех людей, кто несет ответственность за пакеты работ, поскольку именно им предстоит выполнять данные операции. • При недостатке опыта используйте в иерархическом календарном планировании сочетание диаграмм Гантта и диаграмм контрольных событий, чтобы достичь большей сопричастности. • Применяйте надежные связи (которые будут играть роль цементирующего раствора) для связывания расписаний различных уровней (отдельных кирпичей). Вариации. Для мультипроектов, когда выполняется параллельное управление несколькими проектами. Надо добавить еще уровень сверху для мультипроекта. Данная вариация особенно широко используется при разработке продуктов и управлении строительством. Рис. 6.12. Пример иерархического расписания для множественных проектов Адаптация иерархического расписания. Для того чтобы извлечь из расписания максимальную пользу, необходимо адаптировать его к конкретным проектным нуждам. Ниже приводятся некоторые примеры подобной подстройки. Действия по адаптации Примеры действий по адаптации Определение границ использования — Использовать трехуровневое иерархическое расписание типа «одна диаграмма Гантта — одна TAD — множество диаграмм Гантта» для больших и неопределенных проектов; — применять двухуровневое расписание типа «одна диаграмма контрольных событий — множество диаграмм Гантта» для малых и неопределенных проектов; — разработать шаблоны, которые могут использоваться в качестве начальной точки при построении иерархических расписаний для новых проектов Модификация конкретной характеристики Принять решение о том, какая информация будет отображена на диаграмме, например название операции, длительность, ресурсы, владелец и т. д. Добавление отличительной особенности Назначить ответственных лиц, для чего указать на диаграмме имя «владельца» каждой операции или контрольного события ПРОВЕРКА ИЕРАРХИЧЕСКОГО РАСПИСАНИЯ Убедитесь, что вы иерархическое расписание: • имеет более одного уровня; • демонстрирует, как операции более высокого уровня разворачива/ ются в несколько операций или в целые расписания более низкого уровня; • отображает расписания, связанные друг с другом в точках основных контрольных или значимых событий проекта; • характеризуется надлежащей степенью детализации на каждом уровне. 9.14. Линия баланса 9.14.1. Что такое линия баланса? Линия баланса (LOB) — это инструмент календарного планирования и отслеживания хода повторяющихся проектов (рис. 6.13). Иначе говоря, LOB отображает кумулятивное количество или долю компонентов, которые должны быть выполнены к конкретному моменту времени для того, чтобы расписание соблюдалось. Рис. 6.13. Пример LOB НЕКАЧЕСТВЕННО ВЫПОЛНЕННАЯ ВЕДОМОСТЬ МАТЕРИАЛОВ МОЖЕТ СОСЛУЖИТЬ ПЛОХУЮ СЛУЖБУ Некая компания получила запрос на поставку продукта XYZ по очень жесткому расписанию. Руководитель, который пообещал заказчику оформить предложение в тот же день, запросил информацию о LOB, чтобы идентифицировать узкие места и оценить вероятность соблюдения расписания. Первый шаг подготовки LOB заключался в получении ведомости материалов для юридического лица с целью понять процесс изготовления компонентов и определить программу. Представитель производственного отдела сразу увидел, что ведомость устарела и не включает всех необходимых частей. Обновление ведомости материалов и определение сроков поставки заняли несколько дней. В результате руководители не смогли выполнить свои обязательства и были вынуждены уступить заказ более оперативному конкуренту. 9.14.2. Построение LOB Сбор исходной информации. Разработка качественной LOB требует наличия следующей информации: • содержание проекта; • области ответственности; • доступные ресурсы; • ведомость материалов, сроки поставки и нормы производства; • система управления расписанием. Постановка цели. Чтобы приступить к разработке LOB, необходимо задать цель: в наших случаях — поставка 50 кабелей или сооружение 15 зданий согласно требуемому расписанию. Ресурсы, допустим, ограничены. Определение программы. Разработка программы сводится к составлению плана производства или строительства в формате сетевого графика, диаграммы Гантта или диаграммы контрольных событий (рис. 6.14). Сначала для одгого изделия. Рис. 6.14. Программа для одной единицы, входящей в проект, который характеризуется множеством единиц Контрольные точки – события в сетевом графике, конечные точки лент в диаграмме Гантта или контрольные события в одноименной диаграмме. Контрольные точки используются для измерения хода исполнения проекта. В случае проекта, результат которого характеризуется множеством конечных предметов поставки, необходима программа для всех единиц. Если можно сделать все сразу, нет проблем, делаем одну партию. Если производственные мощности ограничены, то надо разрабатывать программу производства. Разработка S диаграммы для программы. На следующем шаге необходимо отобразить программу для множества единиц на S диаграмме, показывающей кумулятивное количество предметов поставки относительно временной шкалы (рис. 6.15), а также совокупный график достижения контрольных точек. Допустим, темп производства имеет линейный характер. Тогда S-кривые в нашем примере на самом деле являются прямыми. По сути, это обозначает планируемое производство единиц и их промежуточных частей или фаз. Рис. 6.15. S диаграмма для программы множества единиц Построение и уточнение LOB. Проведите вертикальную линию через всю S диаграмму. Это и есть линия баланса — мгновенный снимок состояния проекта в определенный момент времени (например, на 30-й день), показывающий кумулятивное количество компонентов или единиц, которые согласно плану должны быть уже произведены. Чтобы отразить ход исполнения в соответствии с планом, нарисуйте еще одну линию, которая будет отображать кумулятивное количество фактически завершенных компонентов или единиц (пунктирная линия на рис. 6.13). Например, из рис. 6.13 видно, что к моменту наступления первых двух событий количество отстает от планового на пять единиц, к моменту наступления третьего отставание составляет две единицы, к моменту четвертого возникает опережение на две единицы. А к моменту пятого опережение составляет уже шесть единиц, при этом узкие места отсутствуют. Бывает, что нужны уточнения, так как это черновой вариант. 9.14.3. Использование LOB Трудоемкость. Если все перечисленные выше предварительные требования соблюдены и имеется соответствующая компьютерная программа, построение LOB с 20 или более единицами/ компонентами может быть выполнено за один два часа. Рост численности команды усложняет коммуникацию между ее членами и, как следствие, приводит к увеличению необходимого времени. Когда использовать. Разработана в 1950-е. Применяется при малых объемах производства новой продукции, которые требуют координации процессов проектирования, для мелкосерийного производства или строительства. Примеры: пилотная партия микропроцессоров; строительство коттеджного поселка; постройка (одного) судна. Выгоды. Сравнивается план и факт. АКЦЕНТИРОВАНИЕ НА КРИТИЧЕСКИХ КОМПОНЕНТАХ Традиционно считается, что не все компоненты одинаковы. Из практики известно, что одни компоненты способны оказаться узкими местами в графике поставки, а другие — нет. Чтобы адекватно реагировать на различные уровни риска, сопряженные с этими компонентами, компания может использовать LOB, например, только для мониторинга календарного планирования производства печатных плат, которое, как показывает опыт, наиболее подвержено задержкам. Преимущества и недостатки. Основные преимущества LOB следующие: • наглядность. Она обеспечивает визуальное представление планового и фактического прогресса повторяющихся операций; • лаконичность. Позволяет получить информацию о прогрессе с первого взгляда — это достоинство, к которому стремится любой инструмент ведения отчетности; • сфокусированность. LOB показывает то, что требует особого внимания. Использование LOB, однако, может быть сопряжено со следующими ограничениями: • инструмент одного дня. Линия баланса — это мгновенный снимок, сделанный в конкретный момент времени. В следующий момент понадобится построить другую LOB, снова затратив на это время и усилия, что в случае жестких расписаний, характерных для современного бизнеса, может служить доводом против использования данного инструмента; • непонятно, если много компонентов (не видно леса); • ненадежная шкала. Даже сейчас, с распространением компьютеров, вертикальная шкала, отображающая широкий диапазон значений, может быть неточной. СОВЕТЫ ПО LOB • Сфокусируйте внимание на критически важных компонентах или единицах. • Применяйте LOB для выявления узких мест. • Если у вас имеется система планирования материальных требований, используйте предоставляемые ею возможности для определения программы и разработки S-диаграммы и LOB. • Продемонстрируйте LOB руководству, если вам необходима поддержка в решении той или иной проблемы. 9.14.4. ПРОВЕРКА LOB Убедитесь, что LOB: • показывает количество единиц или компонентов; • отображает фазы операции; • отражает количество компонентов или единиц, производство которых запланировано на конкретную дату; • демонстрирует фактический ход изготовления компонентов или единиц на ту же дату графика поставок, если эта информация нужна для отслеживания прогресса. Адаптация LOB. Для того чтобы получить от использования LOB максимальную выгоду, следует адаптировать ее к конкретным проектным нуждам. Ниже приводятся некоторые примеры подобной подстройки. Действия по адаптации Примеры действий по адаптации Определение границ использования – Применять линию баланса в комбинации с системой планирования материальных требований; – разработать шаблоны, которые могут выступать в качестве начальной точки при создании LOB для новых проектов Модификация конкретной характеристики Использовать логарифмическую шкалу вместо линейной на оси ординат в случае необходимости разместить там широкий диапазон величин и увеличить точность 9.14.5. Свод методов 9.15. Сетевое планирование Сетевая диаграмма (сеть, граф сети, PERT-диаграмма) — графическое отображение работ проекта и зависимостей между ними. В планировании и управлении проектами под термином «сеть» понимается полный комплекс работ и вех проекта с установленными между ними зависимостями. Есть типы «вершина-работа» (диаграмма предшествования) и «вершина-событие». Рис. 13.9.1. Фрагмент сети «вершина—работа» Рис. 13.9.2. Фрагмент сети «вершина—событие» Существует еще блок-схема. Похоже, но тут нет циклов, и тут логические связи, а не вход-процесс-выход. Методы сетевого планирования — методы, основная цель которых заключается в том, чтобы сократить до минимума продолжительность проекта. Основываются на разработанных практически одновременно и независимо методе критического пути МКП (СРМ — Critical Path Method) и методе оценки и пересмотра планов ПЕРТ (PERT — Program Evaluation and Review Technique). Критический путь — максимальный по продолжительности полный путь в сети называется критическим; работы, лежащие на этом пути, также называются критическими. Именно длительность критического пути определяет наименьшую общую продолжительность работ по проекту в целом. Длительность выполнения всего проекта в целом может быть сокращена за счет сокращения длительности работ, лежащих на критическом пути. Соответственно любая задержка выполнения работ критического пути повлечет увеличение длительности проекта. Метод критического пути позволяет рассчитать возможные календарные графики выполнения комплекса работ на основе описанной логической структуры сети и оценок продолжительности выполнения каждой работы, определить критический путь для проекта в целом. Полный резерв времени, или запас времени, — это разность между датами позднего и раннего окончаний (начал) работы. Управленческий смысл резерва времени заключается в том, что при необходимости урегулировать технологические, ресурсные или финансовые ограничения проекта он позволяет руководителю проекта задержать работу на этот срок без влияния на срок завершения проекта в целом. Работы, лежащие на критическом пути, имеют временной резерв, равный нулю. Процесс сетевого планирования предполагает, что вся деятельность будет описана в виде комплекса работ или работ с определенными взаимосвязями между ними. Для расчета и анализа сетевого графика используется набор сетевых процедур, известных под названием «процедуры метода критического пути». Процесс разработки сетевой модели включает в себя: определение списка работ проекта; оценку параметров работ; определение зависимостей между работами. Определение комплекса работ проводится для описания деятельности по проекту в целом, с учетом всех возможных работ. Работа является основным элементом сетевой модели. Под работами понимается деятельность, которую необходимо выполнить для получения конкретных результатов. Пакеты работ определяют деятельность, которую необходимо осуществить для достижения результатов проекта, которые могут выделяться вехами. Прежде чем начать разработку сетевой модели, необходимо убедиться, что на нижнем уровне СРР определены все работы, обеспечивающие достижение всех частных целей проекта. Сетевая модель образуется в результате определения зависимостей между этими работами и добавления связующих работ и событий. В общем виде данный подход основан на предположении, что каждая работа направлена на достижение частного результата. Связующие работы, возможно, и не требуют получения какого-либо материального конечного результата, например работа «организация исполнения». Оценка параметров работ является ключевой задачей руководителя проекта, привлекающего для решения этой задачи членов команды, ответственных за реализацию отдельных частей проекта. Ценность календарных графиков, стоимостных и ресурсных планов, получаемых в результате анализа сетевой модели, полностью зависит от точности оценок продолжительности работ, а также оценок потребностей работ в ресурсах и финансовых средствах. Оценки должны производиться для каждой детальной работы, а затем могут быть агрегированы и обобщаться по каждому из уровней СРР в плане проекта. Рис. 13.9.4. Диаграмма Ганга Продолжительность (длительность) работы определяет время, которое предполагается затратить на ее выполнение. Оценки длительности каждой детальной работы выполняются на основе предыдущего опыта и количества планируемых на работу исполнителей. Облегчает эту процедуру то, что оценки необходимо делать цля детальных работ проекта, которые представляют собой, как правило, элементарные виды деятельности. Основными являются два типа работ: работа с фиксированной продолжительностью имеет определенную длительность, которая не зависит от количества назначенных ей ресурсов: нельзя ускорить выполнение работы, назначив, например, вдвое больше исполнителей, поскольку существуют факторы, влияющие на длительность работы, но не зависящие от количества исполнителей; работа с фиксированным объемом имеет длительность, зависящую от количества назначенных исполнителей (ресурсов). Таким образом, для работ, продолжительность которых зависит от количества доступных ресурсов, возможен вариант непосредственного расчета длительности исходя из информации о требуемых объемах работ (например, в человеко-днях) и количестве доступных ресурсов. В этом случае увеличение числа исполнителей приведет к сокращению времени выполнения работы. Определение зависимостей между работами необходимо для расчета календарного графика по МКП. Связь предшествования отображает в расписании логическую зависимость между работами. Наиболее частой причиной таких зависимостей являются технологические ограничения (начало одних работ зависит от результатов других), хотя возможны и ограничения, диктуемые другими соображениями. Эти связи образуют структуру сети. Совокупность взаимосвязей между работами определяет последовательность выполнения работ. В соответствии с установленными связями работы делятся на предшествующие и последующие. Предшествующая работа является обеспечивающей для последующей; таким образом, для начала выполнения последующей работы требуется выполнение всех предшествующих. Основными методами определения зависимостей между работами являются: 1. Метод предшествования (PDM), или «вершина—работа» (см. рис. 13.9.1). Оперирует четырьмя типами зависимостей предшествования—следования: «начало после окончания». Это стандартная последовательность, при которой предшествующая работа должна завершиться до начала последующей; «начало после начала». Это наиболее общая последовательность при моделировании работ, которые должны выполняться одновременно. В этом случае не требуется завершения предшествующей работы до начала последующей. Для ее начала необходимо, чтобы предшествующая работа только началась; «окончание после окончания». Этот тип зависимости также используется для моделирования параллельных работ. В этом случае окончание последующей работы контролируется окончанием работы предшественницы; «окончание после начала». Этот тип зависимости используется довольно редко и применяется прежде всего для работ, выполняемых вахтовым методом. 2.Метод построения стрелочных диаграмм (графиков) (ADM), или «вершина—событие». Этот метод оперирует только зависимостями «Начало после окончания» и в некоторых случаях требует применения фиктивных работ для корректного отражения технологии (см. рис. 13.9.2). Методы построения условных диаграмм (графиков). Сетевые шаблоны. На практике часто оказывается, что между работами должна быть установлена нежесткая связь, под которой понимается зависимость с временной задержкой. Процентная или количественная оценка фактора задержки показывает, на какое время начало или окончание одной работы отстоит от начала или окончания другой. Например, последующая работа не может начаться раньше, чем через два рабочих периода после окончания предшествующей работы. Завершающим этапом определения зависимостей является проверка взаимосвязей на петли и другие логические ошибки. После построения структуры сети и выполнения оценок продолжительностей работ команда проекта имеет все необходимое для расчета календарного графика по МКП. Календарное планирование по МКП требует определенных входных данных. После их ввода производится процедура прямого и обратного прохода по сети и вычисляется выходная информация. Для расчета календарного графика по МКП требуются следующие входные данные: набор работ; зависимости между работами; оценки продолжительности каждой работы; календарь рабочего времени проекта (в наиболее общем случае возможно задание собственного календаря для каждой работы); календари ресурсов; ограничения на сроки начала и окончания отдельных работ или этапов; календарная дата начала проекта. Любое изменение даты начала проекта повлечет пересчет сроков выполнения каждой работы. Для процессов детального планирования даты начала подпроектов или пакетов работ определяются на основании укрупненных планов. При наличии входных данных производится процедура расчета расписания вперед и назад и вычисляется выходная информация. Расчет расписания вперед начинается с работ, не имеющих предшественников. В его ходе определяются ранние даты работ, под которыми понимаются наиболее ранние возможные сроки начала и окончания работ при условии, что предыдущие работы завершены: Расчет расписания назад начинается с работ, не имеющих последователей. В его ходе определяются поздние даты работ, под которыми понимаются наиболее поздние возможные сроки начала и окончания работ при условии, что дата завершения проекта не будет задержана: На основании рассчитанных ранних и поздних дат начала работ определяются величины временных резервов для каждой работы. Полный резерв является наиболее значимым из всех резервов. Он представляет собой время, на которое может быть задержана дата завершения работы без задержки планового срока завершения проекта. Свободный резерв показывает время, на которое может быть задержано выполнение работы без ущерба для полного резерва последующих работ сети (без задержки их раннего начала). Результаты вычислений по МКП позволяют получить: общую продолжительность проекта и календарную дату его окончания. Для выявления командой приемлемых результатов с точки зрения целей возможно проведение дальнейших исследований по сценарию «что, если»; работы, лежащие на критическом пути. Любая задержка таких работ приведет к задержке даты завершения проекта. Все критические работы имеют резерв времени, в общем случае равный нулю, что означает, что их ранние и поздние сроки выполнения совпадают; ранние и поздние календарные даты начала и окончания каждой работы. Анализ по МКП не требует установки жестких дат начала для работ, не лежащих на критическом пути. В отличие от критических работ они могут быть запланированы на любое время между их ранними и поздними датами. Расчет по МКП и анализ календарного графика работ с использованием компьютерных средств (гл. 22) можно проводить по мере необходимости, всякий раз, когда проводится обновление информации или изменяются внешние условия по проекту. Информация, полученная в результате вычислений по МКП, может быть представлена либо в табличной форме (рис. 13.9.5), либо в виде календарно-сетевого графика. Такой формат отчета по планированию графика работ дает возможность быстрого просмотра основных результатов анализа по МКП. Большая часть средств автоматизированного планирования (гл. 22) имеет гибкие режимы отбора и сортировки, с помощью которых можно создать различные типы отчетов, из которых разработчик плана выбирает наиболее значимые и эффективные для представления различным потребителям. Для многих проектов уже на стадии временного анализа выясняется, что в поставленные директивные сроки проект выполнить будет очень сложно. Для получения приемлемых с точки зрения целей проекта сроков возможно проведение дальнейшей коррекции расписания по сценарию «что, если». Если расписание не укладывается в директивные сроки, то можно попытаться сократить сроки выполнения отдельных задач или изменить зависимости (ввести, например, где это возможно, зависимости с временными задержками). Работа Описание работы Продолжительность Раннее начало Раннее окончание Позднее начало Позднее окончание Полный резерв ВА710 Возведение каркаса 20 28 дек. 25 янв. 28 дек. 25 янв. AS107 Установка системы и компонент 30 21 янв. 04 мар. 21 янв. 04 мар. ВА712 Настилка полов 14 26 янв. 14 фев. 26 янв. 14 фев. ВА730 Бетонирование первого и второго этажей 15 15 фев. 08 мар. 15 фев. 08 мар. ВА810 Установка механического и электрооборудования 15 25 фев. 17 мар. 12 апр. 02 май 32 AS109 Тестирование и отладка линии А 24 07 мар. 07 апр. 07 мар. 07 апр. AS110 Тестирование отладка линии Б 24 07 мар. 07 апр. 07 мар. 07 апр. AS270 Налаживание роботизированного пути линии Б 24 07 мар. 07 апр. 07 мар. 07 апр. AS 108 Установка системного контроллера 16 07 мар. 28 мар. 21 мар. 11 апр. 10 BA720 Возведение стен эскалатора 10 09 мар. 22 мар. 09 мар. 22 мар. BA731 Бетонная плита основания 10 09 мар. 22 мар. 09 мар. 22 мар. AS250 Строительство железнодорожных сообщений 20 14 мар. 08 мар. 28 мар. 22 апр. 10 BA820 Установка HVAC дымоходов 10 18 мар. 31 мар. 03 май 16 май 32 AS260 Налаживание роботизированных путей линии А 15 22 мар. 07 апр. 22 мар. 07 апр. BA750 Возведение внешних стен 28 23 мар. 29 апр. 23 мар. 29 апр. Рис. 13.9.5. Представление расчета по МКП 10. Планирование стоимости проекта Рис. 7.1. Роль инструментов планирования стоимости в процессе управления проектами 10.1. Ресурсное планирование Для выполнения работ требуются ресурсы, которые могут выражаться как в труде рабочих, материалах, оборудовании, так и в виде позиций денежных затрат, когда нет необходимости или возможности знать, какие конкретно ресурсы их составляют. Невоспроизводимые, складируемые, накапливаемые ресурсы в процессе выполнения работ расходуются полностью, не допуская повторного использования. Не использованные в данный отрезок времени, они могут использоваться в дальнейшем. Иными словами, такие ресурсы можно накапливать с последующим расходованием запасов. Поэтому их часто называют ресурсами типа «энергия». Примерами таких ресурсов являются топливо, предметы труда, средства труда однократного применения, а также финансовые средства. Воспроизводимые, нескладируемые, ненакапливаемые ресурсы в ходе работы сохраняют свою натурально-вещественную форму и по мере высвобождения могут использоваться на других работах. Если эти ресурсы простаивают, то их неиспользованная способность к функционированию в данный отрезок времени не компенсируется в будущем, т. е. они не накапливаются. Поэтому ресурсы второго типа называют еще ресурсами типа «мощности». Примерами ресурсов типа «мощности» являются люди и средства труда многократного использования (машины, механизмы, станки и т. п.). Функции потребности ресурсов. Потребность работы в складируемом ресурсе описывается функцией интенсивности затрат, показывающей скорость потребления ресурса в зависимости от фазы работы; функцией затрат, показывающей суммарный, накопленный объем требуемого ресурса в зависимости от фазы; функция потребности показывающей количество единиц данного нескладируесого ресурса, необходимых для выполнения работ, в зависимости от фазы. Функции наличия (доступности) ресурсов. Функции наличия задаются аналогично функциям потребности. Отличие заключается в том, что функции наличия задаются на проект в целом, так что их аргументом выступает не фаза работы, а время (рабочее или календарное). Проверка ресурсной реализуемости календарного плана требует сопоставления функций наличия и потребности в ресурсах проекта в целом. Одним из преимуществ представления проекта в виде сетевой модели является возможность легко получать информацию о ресурсных потребностях на каждом промежутке времени. Алгоритм ресурсного планирования проекта включает в себя три основных этапа: определение ресурсов (описание ресурса и определение максимально доступного количества данного ресурса); назначение ресурсов задачам; анализ расписания и разрешение возникших противоречий между требуемым количеством ресурса и количеством, имеющимся в наличии. Ресурсное планирование при ограничении по времени предполагает фиксированную дату окончания проекта и назначение на проект дополнительных ресурсов на периоды перегрузок. Планирование при ограниченных ресурсах предполагает, что первоначально заданное количество доступных ресурсов не может быть изменено и является основным ограничением проекта. При данном подходе наличное количество ресурса остается неизменным, а разрешение конфликтных ситуаций производится за счет смещения даты окончания работ. 10.2. Связь сметного и календарного планирования Смета (оценка, предварительный расчет, estimate) — документ, содержащий обоснование и расчет стоимости проекта (контракта), обычно на основе объемов работ проекта, требуемых ресурсов и цен. После согласования с заказчиком, руководством и т. п. смета становится бюджетом (budget). На основе сметы определяется не только стоимость проекта, но и организуется контроль и анализ расхода денежных средств на проект. Взаимосвязь календарно-сетевого планирования и разработки сметной документации на разных уровнях управления представлена на рис. 13.10.1. Рис. 13.10.1. Взаимосвязь календарно-сетевого планирования и разработки сметной документации Одна из основных проблем интеграции двух систем — несоответствие уровней детализации сметы и календарно-сетевого графика. Надо учитывтаь план производства работ, то есть разделить, скажем, бетонные работы по фундаменту, стенам, а не объединять все бетонные работы в одно. Бывает и слишком детальная смета: слишком много расценок для одного вида работ. Хорошие сметчики очень нужны! 10.3. Основные принципы управления стоимостью проекта Стоимость проекта определяется совокупностью стоимостей ресурсов проекта, стоимостями и временем выполнения работ проекта. Управление стоимостью проекта включает в себя процессы, необходимые для обеспечения и гарантии того, что проект будет выполнен в рамках утвержденного бюджета. Стоимость = затраты (здесь). Процессы: • оценка стоимости проекта; • бюджетирование проекта, т. е. установление целевых показателей затрат на реализацию проекта; • контроль стоимости (затрат) проекта, постоянной оценки фактических затрат, сравнения с ранее запланированными в бюджете; • выработка мероприятий корректирующего и предупреждающего характера. Под бюджетированием понимается определение стоимостных значений выполняемых в рамках проекта работ и проекта в целом, процесс формирования бюджета проекта, содержащего установленное (утвержденное) распределение затрат по видам работ, статьям затрат, по времени выполнения работ, по центрам затрат или по иной структуре. Бюджетирование является планированием стоимости, т. е. определением плана затрат: когда, сколько и за что будут выплачиваться денежные средства. Бюджет может составляться в виде: календарных план-графиков затрат (рис. 14.3.1), матрицы распределения расходов, столбчатых диаграмм затрат, столбчатых диаграмм кумулятивных (нарастающим итогом) затрат (рис. 14.3.2), линейных диаграмм распределенных во времени кумулятивных затрат (рис. 14.3.3), круговых диаграмм структуры расходов (рис. 14.3.4) и пр. Таблица 14.3.1 Рис. 14.3.2. Столбчатая диаграмма кумулятивных затрат Рис. 14.3.3. Линейная диаграмма распределенных во времени кумулятивных затрат Рис. 14.3.4. Круговая диаграмма структуры расходов Виды бюджетов Стадия проекта Вид бюджета Назначение бюджета Погрешность, % Концепция проекта Бюджетные ожидания Предварительное планирование платежей и потребности в финансах 25-40 Обоснование инвестиций Предварительный бюджет Обоснование статей затрат, обоснование и планирование привлечения и использования финансовых средств 15-20 Технико-экономическое обоснование Тендеры, переговоры и контракты Уточненный бюджет Планирование расчетов с подрядчиками и поставщиками 8-10 Разработка рабочей документации Окончательный бюджет Директивное ограничение использования ресурсов 5-8 Реализация проекта Фактический бюджет Управление стоимостью (учет и контроль) 0-5 Сдача в эксплуатацию Эксплуатация Завершение проекта Форма представления бюджетов зависит от: потребителя документа; цели создания документа; сложившихся стандартов; интересующей информации. В зависимости от стадии жизненного цикла проекта бюджеты могут быть: предварительными (оценочными); утвержденными (официальными); текущими (корректируемыми); фактическими. После проведения технико-экономических исследований (гл. 4) составляются предварительные бюджеты, которые носят в большей степени оценочный, нежели директивный характер. Такие бюджеты подвергаются согласованию со всеми заинтересованными лицами и в конечном итоге утверждаются руководителем проекта Работа Январь Февраль Март Апрель Май Июнь Июль Август Сентябрь 1. Подготовка бизнес-плана 10 000 5000 2. Разработка проектной и исходно-разрешительной документации 20 000 3. Геологическая и геодезическая подготовка 3000 4. Устройство фундамента 20 000 5. Общестроительные работы 15 000 15 000 15 000 6, Кровельные работы 20 000 7. Отделочные работы 5000 10 000 8. Пусконаладочные работы 2000 10 000 2000 9. Сдача объекта в эксплуатацию 5000 Рис. 14.3.1. Календарный план-график затрат Основным документом, с помощью которого осуществляется управление стоимостью проекта, является бюджет. Бюджетом называется директивный документ, представляющий собой реестр планируемых расходов и доходов с распределением по статьям на соответствующий период времени. Бюджет определяет ресурсные ограничения проекта. На стадии формирования бюджета работы все ресурсы, привлекаемые для ее выполнения, списываются на различные статьи затрат. То есть используется структура счетов затрат. В качестве базовых вариантов могут использоваться российские бухгалтерские планы счетов, международные бухгалтерские планы счетов, планы счетов управленческого учета. По принципу декомпозиции: путем агрегирования информации со счетов нижних уровней структуры можно получить данные о затратах на требуемом уровне детализации, вплоть до верхнего, характеризующего бюджет проекта. При выполнении работ проекта фактическая информация о затратах также учитывается на соответствующих счетах затрат, что позволяет на соответствующих уровнях детализации проводить сравнение запланированных затрат (бюджетных) с фактическими. Управление стоимостью осуществляется на протяжении всего жизненного цикла проекта, при этом, естественно, процессы управления реализуются по-разному на различных этапах проектного цикла. Это находит отражение в современной концепции управления стоимостью проекта — управления стоимостью на протяжении проекта (life-cycle costing — LCC) (рис. 14.1.1). Рис. 14.1.1. Управление стоимостью на протяжении жизненного цикла проекта Представленная концепция будет описана по мере рассмотрения процессов, составляющих управление стоимостью, особенно процесса оценки стоимости проекта, так как этот процесс является основным как для бюджетирования и контроля, так и для функции управления стоимостью в целом. Распределение стоимости проекта в течение его жизненного цикла неравномерно и обычно имеет структуру, представленную на рис. 14.1.2. Как видно, основная часть стоимости возникает на фазе реализации проекта. Но следует отметить, что основные решения, обусловливающие показатели стоимости проекта, принимаются на предынвестиционной фазе проекта. Таким образом, возможность управления стоимостью проекта также распределяется неравномерно на протяжении всего его жизненного цикла. Пример халтуры. Стоимость в процентах! Стоимость проекта то нарастает, то падает! Рис. 14.1.2. Распределение стоимости проекта в течение его жизненного цикла 10.4. Оценка стоимости проекта (что-то было) В табл. 14.2.1 представлены различные виды оценок стоимости проекта с указанием цели оценок и их точности. Чтобы оценить стоимость проекта, требуется знать стоимость составляющих проект ресурсов, время выполнения работ и стоимость этих работ. Таким образом, оценка стоимости начинается с определения структуры ресурсов и работ проекта. Данные задачи решаются в рамках планирования проекта (гл. 13), а в модуль оценки стоимости должны поступать результаты выполнения этого процесса. Таблица 14.2.1 Виды оценок стоимости проекта Стадия проекта Вид оценки Цель оценок Погрешность, % Концепция проекта Предварительная Оценка жизнеспособности/ реализуемости проекта Оценка жизнеспособности/финансовой реализуемости проекта 25-40 Обоснование инвестиций Факторная Укрупненный расчет стоимости/ предварительная смета Сопоставление планируемых затрат с бюджетными ограничениями, основа для формирования предварительного бюджета 20-30 Технико-экономическое обоснование Приближенная Сметно-финансовый расчет Принятие окончательного инвестиционного решения, финансирование проекта. Проведение переговоров и тендеров, основа для формирования уточненного бюджета 15-20 Тендеры, переговоры и контракты Разработка рабочей документации Окончательная Сметная документация Основа для расчетов и для управления стоимостью проекта 3-5 Реализация проекта Фактическая По уже реализованным работам Оценка стоимости уже произведенных работ Прогнозная По предстоящим работа Оценка стоимости работ, предстоящих к реализации 3-5 Сдача в эксплуатацию Фактическая Прогнозная 3-5 Эксплуатация Фактическая Прогнозная 3-5 Завершение проекта Фактическая Полная оценка стоимости проекта Стоимость проекта определяется ресурсами, необходимыми для выполнения работ, в том числе: • оборудование (покупка, взятие в аренду, лизинг); • приспособления, устройства и производственные мощности; • рабочий труд (штатные сотрудники, нанятые по контракту); • расходные товары (канцелярские принадлежности и т. д.); • материалы; • обучение, семинары, конференции; • субконтракты; • перевозки и т. д. Все затраты можно классифицировать как: • прямые и накладные расходы; • повторяющиеся и единовременные. Например, ежемесячные платежи за использование производственных мощностей — повторяющиеся затраты, закупка комплекта оборудования — единовременые затраты; • постоянные и переменные по признаку зависимости от объема работ; • плату за сверхурочное рабочее время (см. китайскую классификацию). Техника оценки затрат проекта состоит из 13 шагов. Они могут различаться в зависимости от проекта и включают в общем случае следующие: 8. Определение потребностей работы в ресурсах. 9. Разработку сетевой модели. 10. Разработку структуры разбиения работ . 11. Оценку затрат в разрезе структуры разбиения работ. 12. Обсуждение СРР (структура разбиения работ) с каждым из функциональных управляющих. 13. Выработку основного направления действий. 14. Оценку затрат для каждого элемента СРР. 15. Согласование базовых затрат с высшим уровнем управления 16. Обсуждение с функциональными управляющими потребности в персонале. 17. Разработку схемы линейной ответственности. 18. Разработку детальных графиков. 19. Формирование суммарного отчета по затратам. 20. Включение результатов оценки затрат в документы проекта. Оценка стоимости проекта по сути является оценкой всех затрат, необходимых для успешной и полной реализации проекта. Эти затраты могут иметь различные представления, окрашенные различными экономическими смыслами. При этом различия между такими представлениями подчас бывают весьма тонкими. Различают три вида затрат. 21. Обязательства. Обязательства возникают, например, при заказе каких-либо товаров или услуг заблаговременно до момента их использования в проекте. В результате выставляются счета, оплата по которым может производиться либо в момент готовности товаров к поставке, либо в момент его получения, либо согласно принятой в организации политики оплат. В любом случае при заказе бюджет уменьшается на сумму этого заказа. В ряде случаев она не учитывается до момента получения счета, что некорректно отражает текущее состояние бюджета. В связи с этим возникает потребность в системе планирования и учета обязательств проекта. Кроме выполнения своих основных функций, данная система позволит прогнозировать будущие выплаты 22. Бюджетные затраты (сметная стоимость работ, распределенная во времени); Бюджетные затраты характеризуют расходы, планируемые при производстве работ. 23. Фактические затраты (отток денежной наличности). Фактические затраты отражают расходы, возникающие при выполнении работ проекта, либо в момент выплаты денежных средств. Исходя из структуры жизненного цикла проекта его стоимость включает в себя следующие составляющие: • стоимость исследований и разработок: проведение предынвестиционных исследований, анализ затрат и выгод, системный анализ, детальное проектирование и разработка опытных образцов продукции, предварительная оценка продукции проекта, разработка проектной и другой документации на продукцию; • затраты на производство: производство, сборка и тестирование продукции проекта, поддержание производственных мощностей, материально-техническое обеспечение, обучение персонала и пр.; • затраты на строительство: производственные и административные помещения (строительство новых или реконструкция старых); • текущие затраты: заработная плата, материалы и полуфабрикаты, транспортировка, управление информацией, контроль качества и пр.; • снятие продукции с производства: затраты на переоборудование производственных мощностей, утилизация остатков. 10.5. Карта планирования стоимости 10.5.1. Что такое карта планирования стоимости? Карта планирования стоимости (CPLM Cost Planning Map) — это инструмент, обеспечивающий систематизированный подход к планированию стоимости проектов (рис. 7.2). CPLM формулирует последовательность шагов и подшагов для планирования стоимости. Значит, это типа алгоритма или подпроекта. (рис. Надо?) Рис. 7.2. Пример карты планирования стоимости 10.5.2. Развертывание карты планирования стоимости Подготовка исходной информации. К сведениям, имеющим значительную важность для успешного развертывания CPLM, относятся: • финансовые политики; Ответ на вопрос: «Какие типы оценок стоимости будут использоваться и с какой целью?» — зависит от финансовых политик организации. • организационные политики, которые приняты в компании, выполняющей планирование стоимости При планировании ресурсов необходимо принимать организационные политики по части обеспечения персоналом и аутсорсинга. Определение планирования стоимости. Вопросы. 1. Кто выполняет планирование стоимости? Владелец проекта, подрядчиком, новичок он или опытный специалист. Пример. Определям стоимость выпуска подукции. Компания должна принять во внимание процесс его производства, заводские условия, стратегию поставки материалов, методы достижения максимальной технологичности производства. Но если производство выполняется при помощи аутсорсинга, то подрядчик вполне может иметь собственный производственный процесс, завод и стратегию поставки материалов и не стремиться к максимальной технологичности. В результате получаются два совершенно разных подхода к построению CPLM. 2. Что такое план стоимости. План стоимости проекта обычно включает оценку стоимости и бюджет (?) (он же базовый план стоимости). 3. Для каких целей нужен? Для оценивания основных затрат? Потом обоснуем запрос на кап средства или заем? Оценка может быть независимой, для проверки других оценок. Для формирования базового плана? Календарный базовый план и базовый план стоимости. Тут завязаны реурсы. Из них – длительность операций, потом сочетам с бюджетами. Получается базовый план стоимости, известный также как распределенный во времени бюджет, или кривая потока денежной наличности (?). Базовый план стоимости рассматривается далее в настоящей главе как самостоятельный инструмент. Для оценки рисков? Установление разумного запаса для оценки стоимости, позволяющего вносить вероятные изменения. Резерв на покрытие непредвиденных ситуаций 4. Содержание плана стоимости. Для начала определяем тип оценок. (мб наоборот, от содержания определяем оценки?). Вот некоторые (было?). Рис. 7.3. Типы оценок стоимости Они различаются по многим параметрам, например по назначению, точности, стоимости подготовки, требуемой информации и типу инструмента оценивания [15]. Потом из оценок будет распределенный во времени бюджет, так что нужно соответствие оценок и его. Оценка стоимости обычно дается в денежном эквиваленте, что упрощает сравнение проектов и операций [11]. Однако в некоторых отраслях используются оценки, выраженные в часах трудозатрат, причем трудозатраты разных ресурсов сведены воедино. Такая практика считается приемлемой до тех пор, пока она не препятствует сравнению проектов и операций. Более того, оценки допустимо предоставлять во множестве единиц измерения, если так требуют интересы управления проектами. ПРИМЕРЫ ОПРЕДЕЛЕНИЙ, ОТНОСЯЩИХСЯ К ОЦЕНИВАНИЮ СТОИМОСТИ • прямые расходы. Элемент стоимости либо совокупность элементов, которые могут отождествляться с проектом: прямые расходы на оплату труда, покупку материалов и оборудования; • непрямые расходы. Стоимость труда, услуг или поставок, которые не могут быть однозначно отнесены на счет проекта. Эти расходы рассматриваются как накладные, они накапливаются и заносятся на счета издержек [3]; • наиболее вероятная стоимость. Значение стоимости, вероятность получения которого максимальна. Это значение образуется из значений всех распределенных по статьям элементов и оценки резерва на покрытие неопределенности, которые вместе предполагают 50%-ную долю уверенности [4]; • диапазон погрешности. Прогноз наименьшей и наибольшей ожидаемой стоимости, связанный с наиболее вероятной стоимостью. Чем выше качество оценок, правильнее определение содержания, ниже проектные риски, меньше количество неизвестных факторов и точнее калькуляция стоимости, тем более высокая точность оценки может быть достигнута; • резерв на покрытие неопределенности. Сумма, добавляемая к оценке с целью покрытия будущих изменений, которые с определенной вероятностью могут возникнуть по неизвестным причинам или вследствие наступления непредвиденных условий. Резерв на покрытие неопределенности вычисляется с помощью статистического анализа расходов, имевших место в ходе выполнения прошлых проектов, или исходя из опыта реализации аналогичных проектов. 5. Разработка процесса планирования стоимости. Есть методы. Есть подшаги. 5.1. Начальный подшаг — предварительные наброски планирования стоимости. Вроде лишнее, но полезно. Кто пользователь – формат оценивания, Предельная дата – основа расписания. Оценка расходов на само планирование – надо проинформировать заказчика. 5.2. Разработка описаний элементов (затрат? Ресурсов?). Описания элементов представляют собой определение элементов содержания, для которых нужно получить оценку. Количество и единицы измерения. Далее физическое описание (Милошевич: с максимально возможной степенью детализации(???)). Устранить все предположения, всё описать. Привести источник сведений. (например, стандартные значения темпа производства или величина индекса стоимости, опубликованная торговой ассоциацией). 5.3. Калькуляция себестоимости элемента — третий подшаг, на котором происходит вычисление оценки элемента. По алгоритму или формуле. Там прямые и непрямые расходы. Формулы или алгоритмы называются отношениями оценивания стоимости (CER). Например, когда доступна информация о количестве единиц продукции, которое нужно получить, скорости производства единицы продукции и почасовых расценках на выполнение различных операций, для вычисления общей стоимости труда можно использовать восходящую оценку, основанную на следующем CER: Общая стоимость труда (в уде) = количество * (часов/единицу количества) * (уде/час) = 200 единиц * (5 часов/единицу )  (80 уде/час) = 80 000 уде. Материалы и оборудование – по своим формулам. 5.4. Документируем. 5.5. Суммарная оценка. СОВЕТЫ ПО ПЛАНИРОВАНИЮ СТОИМОСТИ • Знайте своего заказчика. Задавайте вопросы, чтобы понять его потребности, описания элементов, содержание проекта, но сами ничего не предлагайте. • Следуйте процессу планирования стоимости. Не пропускайте шагов, предписываемых процессом. Если процесс не работает, измените его (?). • Выйдите за рамки пустых подсчетов. Посмотрите на общую картину, обдумайте философию проекта и его заказчика. • Документируйте все. Включайте в документацию предположения, ссылки, источники, исключения из содержания и т. д. • Оставляйте возможность для аудита. Процессы аудита повышают качество оценки и вашу степень уверенности. • Документируйте изменения. Оценка, которую вы запланировали, почти наверняка потом будет корректироваться. Записывайте изменения. Ведите контрольные записи о ревизиях документа. • Заручайтесь поддержкой. Постарайтесь привлечь к подготовке оценки специалистов из функциональных отделов — в конце концов, это им с ней работать. • Имейте в виду: точность оценивания зависит от объема доступной информации, времени и ресурсов, а также от типа оценки. 5.6. Проверка. Включает в себя подтверждение корректности сделанных вычислений, верификацию источников, из которых были взяты данные, и обзоры, выполняемые коллегами, которые имеют равное служебное положение («обзор равных») [4]. 5.7. Пересмотр и улучшение. Руководитель должен постоянно контролировать получаемые оценки, чтобы была возможность предугадать основные проблемы. 5.8. Публикация (?) оценки. Но работа продолжается до конца проекта. В самом конце собираем все фактические расходы, сравниваем с планом, делаются выводы. 10.5.3. Использование карты планирования стоимости Когда использовать. Можно везде, полезнее в больших или типовых. Трудоемкость. Построение CPLM требует значительного времени. Привлекаются различные специалисты из отделов (например, технического, финансового, бухгалтерии). Может быть, нужны сотни часов работы для больших проектов. Для малых типовых – побыстрее. Выгоды. Карта планирования – четкая последовательность. Получается хороший адекватный план. Снижает риски, проявляется значение себестоимости. Преимущества и недостатки. Основное преимущество – шаг за шагом, последовательно. Минус – долго. ПРОВЕРКА КАРТЫ ПЛАНИРОВАНИЯ СТОИМОСТИ Убедитесь, что карта планирования стоимости: • основана на необходимой исходной информации; • содержит основные определения, терминологию, типы оценок, а также инструменты для оценивания и формирования базового плана стоимости; • включает критически важные шаги и подшаги в процесс планирования стоимости. 10.6. Оценка по аналогии 10.6.1. Что такое оценка по аналогии? Оценка по аналогии — это получение оценки текущего проекта, называемого целевым, на основе фактической стоимости одного или нескольких предыдущих проектов (аналогичных или исходных) близкого размера, сложности и содержания [16]. Основа оценки: интуиция, историчские данные специально разработанные аналитические расчеты, учитывающие различия между целевым и аналогичным проектами. Пример оценки по аналогии приведен на рис. 7.4, а основные характеристики такой оценки показаны на рис. 7.5. Рис. 7.4. Пример оценки по аналогии для проекта разработки программного обеспечения 10.6.2. Разработка оценки по аналогии Сбор исходной информации. Качественная исходная информация является необходимым условием для разработки качественной оценки по аналогии. К такой информации относятся: • содержание проекта; • историческая информация об аналогичных проектах; • ресурсные требования; • расценки на работу ресурсов. Подготовка оценки. 1. Определение специфики предварительного планирования: конечные пользователи оценки, цель и формат оценивания, список участников процесса и их роли, доступные ресурсы. содержание целевого проекта (основные элементы), их размер и показатели сложности. 3. Определение элементов для поиска аналогичных. Например, на рис. 7.4 содержание разбито на пять основных элементов (столбец 1), каждый из которых имеет оцененный размер (столбец 5). Это может быть для ПО: проектирование, разработка структуры базы данных, программирование, отладка, сопровождение. То есть работы определенного типа. (что там для курсовиков?). 4. Поиск наиболее подходящего аналога (аналогов). Пнплог больен иметь те же параметры [13]! (рис. 7.4). Найти легко (?). Может быть, аналог ищется по характеристикам? Для аналога нашли размер, производительность, подсчитали трудозатраты (столбцы 2, 3, 4=2/3). Это CER аналога. 5. Перенос решения на целевой проект. Элементы, не имеющие полного соответствия, корректируются. Например, у нас неопытная команда. Производительность 0,8 от производительности команды для аналога (0,8 определили на основе здравого смысла). В итоге получаем трудоемкость аналога. Чтобы получить денежный эквивалент затраченного времени, нужно умножить количество часов на расценки. ИСПОЛЬЗУЙТЕ КОМБИНАЦИЮ ИНСТРУМЕНТОВ ОЦЕНИВАНИЯ Ни один из существующих типов оценки — восходящая, параметрическая, по аналогии — не обеспечивает бесспорного преимущества перед другим во всех аспектах. Больше того, все они имеют свои достоинства и недостатки, дополняющие друг друга. Это особенно важно при разработке программного обеспечения, где специалисты обеспокоены неспособностью точно оценить стоимость проекта [2]. На практике нам следует полагаться на комбинацию инструментов оценивания, сравнение их результатов и — при возникновении расхождений — выполнение повторного оценивания [5]. И хотя подобные действия могут потребовать большего количества ресурсов, увеличив стоимость, выгоды, связанные с повышенной точностью оценок, вполне очевидны. 6. Сумма всех оцененных элементов равна общей оценке проекта. Для менеджеров крайне важно умение выявлять скрытые различия между элементами исходного и целевого проектов и оценивать стоимость элемента целевого проекта на основе исходного, в действительности являющегося подобным или аналогичным [16]. Проверка, пересмотр и улучшение, как было сказано в предыдущем разделе, представляют собой финальный шаг в разработке оценки по аналогии. 10.6.3. Использование оценки по аналогии Когда использовать. Оценка по аналогии предпочтительна в том случае, когда детальная информация о проекте отсутствует. Как правило, такая ситуация характерна для ранних фаз жизненно го цикла проекта. Поскольку остальные инструменты оценивания также имеют свои недостатки, оценка по аналогии может применяться в комбинации с восходящей и параметрической оценками (см. врезку «Используйте комбинацию инструментов оценивания»). Трудоемкость. Оценка по аналогии включает допущение о том, что информация о целевом проекте и проекте аналоге очень ограничена. Соответственно, чтобы выполнить оценку по аналогии практически для любого проекта, достаточно нескольких часов. Рис. 7.5. Основные характеристики оценки по аналогии Действия по адаптации Примеры действий по адаптации Определение границ использования Использовать оценку по аналогии в сочетании с параметрическими оценками в процессе принятия решений по просеиванию проектов и бюджетированию Модификация конкретной характеристики Включить отдельные статьи для труда и материалов (важно для проектов с большим количеством материалов) Выгоды. Малое время разработки, работа на ограниченной информации. Преимущества и недостатки. Дешевле других. Нужна репрезентативность. Результат определяется качеством опыта. Точность ниже, чем у других. Вариации. Можно и в целом оценивать, на основе здравого смысла вводя какие-то коэффициенты, например, требуемые ресурсы. ПРОВЕРКА ОЦЕНКИ ПО АНАЛОГИИ Убедитесь, что оценка по аналогии основана на следующих факторах: • содержание, размер и производительность аналогичного проекта; • фактическая стоимость аналогичного проекта. Выработайте на основе здравого смысла некоторый коэффициент и примените его для получения: • оценок по аналогии для элементов содержания проекта, которые при суммировании образуют общую оценку стоимости проекта; • оценки проекта в целом. 10.7. Параметрическая оценка 10.7.1. Что такое параметрическая оценка? Параметрическая оценка использует математические модели соотнесения стоимости с одной или несколькими физическими характеристиками или параметрами производительности проекта, подлежащего оцениванию [3]. Как правило, модели дают CER (Cost Estimating Relationships), которые сопоставляют стоимость целевого проекта с одним или несколькими параметрами, такими как нагрузочная способность, размер, объем, масса, требования к энергопотреблению и т. д. Определение оценки для новой электростанции выполняется очень просто — умножением количества киловатт на предполагаемую долларовую стоимость киловатта. Однако может потребоваться и очень сложный расчет, включающий, например, в уравнение для оценки проекта разработки программного обеспечения 32 параметра (также называемых факторами, или движущими силами расходов). Значения параметров разрешается ввести в CER, а результаты — отобразить в графическом (рис. 7.6) стоимость дома в зависимости от его площади или табличном формате. Основные характеристики параметрических оценок описаны на рис. 7.7. Рис. 7.6. Типичное CER в модели параметрической оценки Рис. 7.7. Основные характеристики параметрической оценки 10.7.2. Разработка параметрической оценки Сбор исходной информации. Для того чтобы разработать параметрическую оценку надлежащего качества, необходимо собрать качественную исходную информацию, в которую должны входить: • основное содержание проекта; • выбранные параметры проекта; • историческая информация. Подготовка оценки. Все как и раньше (планирование, декомпозиция, описание элементов, расчеты). Разница в последнем шаге: он включает в себя построение базы данных, разработку модели и ее применение. 1. Выбор каркаса для структурирования стоимости прошлых проектов, то есть форма желаемого CER. Например, структура может включать расходы по управлению проектом (например, на планирование, контроль), неповторяющиеся расходы (в частности, проектирование, инженерные работы, программное обеспечение, коммунальные услуги) и повторяющиеся расходы (допустим, производство, эксплуатация). Надо также определить тип уравнения. На практике огромное количество сведений о расходах сводится к линейной, степенной, экспоненциальной или логарифмической зависимости. Графически эти модели выглядят либо как прямые линии, либо как гладкие кривые, ведущие себя предсказуемым образом. Рис. 7.6: отношение «доллар за квадратный метр», выражается линейной зависимостью у = ах, где у — оценочная стоимость проекта (зависимая величина), которая является функцией х, площади дома в квадратных метрах (параметр и независимая величина), а а — параметр, получаемый на основе исторических данных и связывающий зависимую величину с независимой. Пример применения. Грубая оценка стоимости нового дома при условии, что для множества, состоящего из нескольких домов площадью от 550 до 700 квадратных метров, стоимость квадратного метра равна 300 долларов, то соответствующее CER может быть выражено формулой: у = 300(х). В жизни, однако, все не так однозначно, и потому часто возникает потребность в использовании нелинейных CER (см. врезку «Параметрическое оценивание программных проектов»), CER с множественными независимыми переменными или множественного регрессионного анализа. Метод наименьших квадратов (какие еще?), выбор вида кривой (что там с условиями применимости). ПАРАМЕТРИЧЕСКОЕ ОЦЕНИВАНИЕ ПРОГРАММНЫХ ПРОЕКТОВ Многие параметрические модели разработки программных продуктов базируются на ключевых параметрах программного обеспечения, определяя по ним стоимость. Эти модели обычно основываются на статистическом анализе результатов предыдущих проектов разработки программного обеспечения [5–8]. В проводимый анализ включаются такие ключевые параметры, как размер системы (например, количество строк кода), сложность (допустим, степень трудоемкости) (как определить сложность по?), область применения (в частности, приложение реального времени, язык, операционная система) и продуктивность разработки (например, производительность труда). Один эксперт предложил 59 параметров, которые способны оказать влияние на результаты моделей стоимости [10 Birrell, N.D.A. 1985 «Practical Handbook of Software Development» Cambridge, Mass.: Cambridge University Press.]. Простая модель может иметь следующую форму: Z = CYL, где Z — оцениваемая трудоемкость проекта (в человекомесяцах), Y — оцениваемый размер проекта (в тысячах строк кода), С — коэффициент регрессии, L — показатель регрессии. Допустимо применить эту модель для оценки трудоемкости нового проекта разработки программного продукта, взяв, например, следующие значения: С = 3,8; L = 1,4; Y = 2. Таким образом, Z = СYL = 3,8 * 21,4 = 10,03 человекомесяцев. 2. Применение модели. Простое допущение: будущие проекты исполняются так же, как и прошлые. 3. Уточнение. Расслоение. Историческая база данных делится на слои слоя, каждый из которых представляет собой семейство точек (представляющих данные), подобных друг другу в том или ином отношении. Затем находятся кривые, наилучшим образом вписывающиеся в каждое из этих семейств. Например, данные по стоимости домов. Видно два слоя. Оказалось, что более дорогие – с централизованной системой очистки от пыли, системой пространственного звучания, электроосветительной арматурой из нержавеющей стали, мраморной облицовкой, полами из твердых пород дерева, лепной штукатуркой и т. д., в то время как остальные 10 были обычными домами с гораздо более простыми и менее дорогими характеристиками. Разделили на 2 слоя. Если известно оценочное значение площади дома (например, 600 квадратных метров), легко считать с рис. 7.8 параметрически оцененную стоимость как роскошного (190 тысяч долларов), так и обычного (177 тысяч долларов) варианта дома. Рис. 7.8. Расслоение, примененное по отношению к CER 3.2. Коррекция стоимости. Один пример. ПО по размеру. Но было и количестыво прототипов. В базе обычно 10, а тут 40. Тут два пути: ищем примеры для 40 пторотипов или определяем стоимость одного прототипа, то есть вводим его в параметры. 10.7.3. Использование параметрической оценки Когда использовать. Параметрические оценки наиболее часто применяются на стадии определения проекта и на начальных стадиях проектирования, когда еще мало информации. CER обычно связывает стоимость проекта с высокоуровневым показателем емкости, пропускной или нагрузочной способности, производительности, поэтому сведения обычно уже имеются. Применяется для для сравнения стоимости нескольких альтернативных решений, взаимного контроля и перекрестной проверки других инструментов оценивания, но не для разработки детального конкурентоспособного предложения [4]. Чтобы параметрическую оценку можно было использовать для этих целей, она должна быть основана на точной исторической информации, измеримых параметрах и масштабируемой (то есть применимой как к большим, так и к малым проектам) модели. Трудоемкость. Наиболее трудная и времяемкая часть параметрического оценивания — это создание методологии, включая построение базы данных и нахождение формулы для CER. В зависимости от сложности базы данных ее разработка и составление CER могут занять от десятков до сотен часов, зато само действие по оцениванию требует нескольких минут или часов. Выгоды. Все-таки не очень трудоемко. Концентрируемся на важных параметрах. Рассмотрим, например, оценивание стоимости дома. Для разработки восходящей оценки (она еще будет) стоимости дома необходимы подробные чертежи, ведомость материалов, информация о требуемых трудовых ресурсах, расценки на виды работ и т. д. Подготовка к выполнению данной операции требует немалых усилий и денег. Для оценивания стоимости того же дома с помощью параметра «количество долларов за квадратный метр» нужно знать лишь конструкцию дома, что позволяет провести процедуру быстрее и проще. Очевидно, что параметрические оценки могут быть получены даже в случае, когда о проекте не известно почти ничего, кроме его физических параметров. Преимущества и недостатки. Основное преимущество параметрической оценки состоит в: легкости использования и повторяемости. Но нужен опыт и здравый смысл. Но бывает некорректное представление трендов и субъективность. Вариации. Много для ПО. Есть программы PRICE, CAAMS и FAST [16], предназначенные для разработки оборудования, ориентированного на аэрокосмические задачи. Адаптация параметрической оценки. Чтобы получить пара метрическую оценку, которая наилучшим образом будет отвечать вашим нуждам и обладать наибольшей ценностью для ваших проектов, необходимо адаптировать описанную обобщенную модель. Ниже приводятся примеры, которые помогут осуществить такую подстройку. Действия по адаптации Примеры действий по адаптации Определение границ использования Использовать параметрические оценки для планирования бюджета и просеивания проектов Модификация конкретной характеристики Скорректировать вычисленное по CER значение стоимости, которое отвечает за усложнение процессов в новых проектах, вызванное быстрыми изменениями технологии (характерно для высокотехнологичных проектов) Удаление отличительной особенности Отказаться от коррекции стоимости для проектов, использующих стабильную технологию ПРОВЕРКА ПАРАМЕТРИЧЕСКОЙ ОЦЕНКИ Убедитесь, что параметрическая оценка: • основана на хорошо структурированной базе исторических данных о стоимости; • разрабатывается на основе наиболее подходящего CER, вытекающего из базы данных; • показывает общую стоимость проекта и, если потребуется, стоимости его элементов. 10.8. Оценка «снизу вверх» 10.8.1. Что такое оценка «снизу вверх»? Восходящая оценка основана на оценивании стоимости отдельных элементов работ с последующим их суммированием и получением общей стоимости [11]. Глубокий анализ всех задач; применяем расценки и цены; получаем денежный эквивалент. Вот простой вариант Рис. 7.9. Пример восходящей оценки Рис. 7.10. Основные характеристики восходящей оценки 10.8.2. Разработка восходящей оценки Сбор исходной информации. • содержание проекта (СДР); • ресурсные требования; • расценки на работу ресурсов; • историческая информация; • расписание проекта Длительность важна, если резерв времени. Определение формата оценки. Обычно – система счетов. Подготовка оценки. 1. Идентифицировать элемент, подлежащий оценке. 2. Определить его количество, 3. стоимость людских ресурсов, 4. накладные расходы и материалы. 5. (для СНиП еще потребное оборудование). 6. Двигаемся вверх до получения общей оценки всего проекта. Некоторые менеджеры ограничиваются затратами труда. Расценки разные для разного труда. Накладные расходы определяются в каждой компании по-разному. Чаще процент от затрат труда или стоимости материалов. И плюс стоимость материалов. КАК ПРОЕКТ ПОСТРОЙКИ ЗДАНИЯ СУДА НАВЛЕК НА СЕБЯ НЕСЧАСТЬЕ Проект постройки здания суда, находящийся на полпути к завершению, выглядел в глазах подрядчика как гарантированный успех. Проект выполнялся по расписанию, платежи по контракту проводились своевременно, владелец был доволен ходом работ. А потом Грег, менеджер со стороны подрядчика и разработчик восходящей оценки стоимости проекта, на основе которой был составлен контракт, ушел из компании. Месяцем позже Пит, новый менеджер, обнаружил, что весь бюджет проекта уже потрачен, хотя осталась еще масса невыполненной работы. Быстрый аудит, предпринятый руководством, вскрыл следующее: • в конце проекта ожидались значительные денежные потери; • оценка стоимости проекта, выполненная Грегом, никогда не анализировалась коллегами или руководством. Когда пять месяцев спустя строительство здания суда было завершено, оно стало одним из крупнейших просчетов в истории компании: стоимость постройки составила 500 тысяч долларов, почти на треть превысив первональный бюджет. На совещании, состоявшемся после окончания проекта и посвященном его разбору, в процесс оценивания стоимости были внесены следующие усовершенствования: • все основные оценки должны рассматриваться коллегами и руководством; • все основные оценки, разрабатываемые в условиях недостатка времени, должны сравниваться с теневой оценкой стоимости, выполняемой независимой фирмой. 10.8.3. Использование восходящей оценки Когда использовать. Восходящая оценка может во всех проектах, но нужна информация. То есть уже где-то 60% планирования выполнено. Хорошо для контроля стоимости, заявок/предложений и оценки ордеров на изменения. НЕТ ВОСХОДЯЩЕЙ ОЦЕНКИ — НЕТ РАБОТЫ! «Мы разрабатываем программное обеспечение высочайшего качества», — так звучал неформальный девиз SP Group, подразделения одной частной компании. Его заказчики, подразделения той же самой компании, соглашались: SP Group работал великолепно, производя программные продукты, почти не имевшие внутренних ошибок. Будучи довольны качеством продуктов, заказчики не волновались о том, сколько фактически стоят эти проекты. Для того чтобы проект был одобрен и оплачен заказчиком, SP Group представляла на рассмотрение только оценку порядка величины, варьирующуюся в диапазоне от 1 до 10 тысяч часов работы ресурсов. Затем компания получила известность и стала действовать в рамках общей тенденции — ориентации на прибыль и демонстрации эффективности капиталовложений, руководители подразделений оказались не в состоянии адекватно отреагировать на изменение политики и были вынуждены уйти, а на их место наняли новых, ориентированных на прибыль руководителей. Изменилась также и практика оценивания стоимости. «Акулы», как называли менеджеры проектов новых руководителей, категорически отказывались ограничиваться оценкой порядка величины. Неся ответственность за прибыли и потери, «акулы» желали управлять своими расходами и требовали выполнения восходящих оценок для утверждения проекта. Не имея опыта разработки таких оценок, большая часть менеджеров проектов также вынуждена была уволиться. Стало ясно, что для SP Group настало время научиться выполнять восходящее оценивание. Трудоемкость. Время разработки восходящей оценки варьируется в зависимости от размера и сложности проекта. Восходящее оценивание проекта, включающего в себя 500 часов работы ресурсов и не содержащего никаких материалов или оборудования, требует одного-двух часов работы. Однако команда может потратить тысячи часов на оценивание проекта стоимостью 400 миллионов долларов. Выгоды. Высокая точность, основа для контроля стоимости. Преимущества и недостатки. Основные преимущества восходящих оценок состоят в следующем: • их легко применять — вручную или в компьютеризованной форме; • люди, привлеченные к процессу подготовки оценки, ручаются за нее. Однако эти два преимущества могут быть нейтрализованы существенным недостатком восходящей оценки: она может быть относительно времяемкой и требовать наличия детальной информации о плане проекта. Адаптация восходящей оценки. Мы описали обобщенную форму восходящей оценки, разработанную таким образом, чтобы отвечать нуждам проектов во множестве различных отраслей, однако она может оказаться не применимой для какого либо конкретного проекта. Если это так, адаптируйте ее, чтобы извлечь максимум пользы. Ниже представлены несколько идей касательно такой подстроки. Действия по адаптации Примеры действий по адаптации Определение границ использования Использовать восходящие оценки для авторизации фондов, выделяемых на исполнение всех внутренних и внешних проектов Добавление отличительной особенности Ввести отдельную оценку «снизу вверх» для материалов, включающую в себя описание элемента, предполагаемого продавца, стоимость единицы, количество, FOB Free On Board — судно в порту свободно. — Прим. ред., стоимость фрахта/ транспортировки, стоимость поставленного материала и т. д. (применительно к проектам с большим количеством материалов) Модификация конкретной характеристики Включить новые столбцы для категорий трудозатрат, характеризуемых профессиональными навыками, — например, старший аналитик, младший аналитик и т. д. (применительно к проектам, в которых активно используется человеческий труд) ПРОВЕРКА ВОСХОДЯЩЕЙ ОЦЕНКИ Убедитесь, что восходящая оценка: • показывает систему обозначения расходов; • отображает описания элементов; • выводит количества элементов; • отражает стоимость трудозатрат для элементов; • показывает размер накладных расходов для элементов; • анализирует стоимость материалов для элементов; • отображает общую стоимость, сопоставляемую с записью; • выводит общую стоимость проекта. 10.9. Базовый план стоимости 10.9.1. Что такое базовый план стоимости? Базовый план стоимости — это распределенный во времени бюджет, используемый для измерения и мониторинга исполнения стоимости проекта [11]. Расходы и срокиРазрабатываемый путем суммирования оценочных расходов в течение определенного временного периода, такой план отражает значение оценочных расходов и срок, когда предполагается их возникновение, при условии следования определенному порядку выполнения (рис. 7.11). Рис. 7.11. Пример базового плана стоимости Часто базовый план изображается в виде S кривой (рис. 7.13). Рис. 7.13. Базовый план, представленный в виде S кривой Бывает отдельно план расходов, поступлений, освоенная сумма расходов, трудозатрат. 10.9.2. Разработка базового плана стоимости Сбор исходной информации. • оценка стоимости; • СДР; • расписание проекта. Оценка стоимости была. Теперь распределяем во времени. По СДР. Идентификация типа базового плана стоимости и элементов стоимости. Если это расходы, то необходимо рассмотреть: • зарплаты персонала проекта (в простейших случаях это единственный элемент, который подлежит включению во внутренние проекты компании); • накладные расходы; • выплаты подрядчикам; • выплаты по выставляемым продавцами инвойсам на закупки оборудования, материалов и услуг; • процентные выплаты по займам, возврат займов, уплата налогов, транспортные расходы, пошлины и т. д. КРИТЕРИИ БАЗОВОГО ПЛАНА СТОИМОСТИ Элемент расходов или выплаты Инициирующее событие расписания или инициирующая информация Интервал между инициирующим событием и выплатой Комментарии Команда управления и проектирования Согласно рабочему расписанию 1 месяц Комментарии Субконтракты с продавцами Контрольные события расписания 1 месяц Политика компании Выставляемые продавцами инвойсы на закупки оборудования и материалов, общая сумма Контрольные события доставки (поставки, изготовления, производства результатов) на площадке 2 недели Устанавливается командой проектировщиков с целью мотивации продавцов Если это входящие потоки, то: • выплаты от заказчиков за поставленное оборудование, материалы и услуги; • займы (ссуды) от финансовых учреждений; • возврат налогов, гранты и т. д. Если нужно управлять потоком денежной наличности, вам потребуются элементы, характеризующие как исходящий, так и входящий потоки. После того как элементы стоимости, подлежащие включению, определены, необходимо установить критерии формирования базового плана стоимости. Установка критериев формирования базового плана стоимости. Какие события инициируют выплаты? Какое время между инициацией и выплатами? Например, для выплат продавцам инициирующими событиями обычно являются контрольные события, которые определяются условиями контракта, устанавливающими время и способ произведения денежных расчетов. В других случаях, например при выплате зарплат членам команд управления проектами, такую роль играет рабочий график этих сотрудников, который и инициирует расчет в конце каждого месяца. Интервалы — для оплат внутри и вне организации — определяются временем, необходимым для внутренней и внешней коммуникации, утверждения и выполнения административных процедур, а также политиками компаний, которые склонны удерживать у себя деньги столь долго, сколь это представляется возможным [19]. Надлежащий анализ критериев и их письменное определение весьма полезны, поскольку позволяют распределить расходы по временным периодам в процессе формирования базового плана. Распределение статей расходов по временным периодам. Обычно по СДР. Но если по аналогии или на параметрической оценке, то по-другому. Отчетность, допустим, помесячно, поэтому и периоды = месяцу. Сколько именно средств будет выделено и когда, зависит от [19]: • расписания проекта, отражающего запланированные начальные и конечные даты элемента, вместе с гистограммами, детализирующими ресурсные требования в течение определенного периода (см. врезку «Простые S кривые в сложном проекте разработки микропроцессора»); • условий контракта; • интервалов между инициирующими событиями и выплатами. Обработав исходную информацию, мы видим, что из 10 тысяч долларов, выделенных на элемент 1.01, 8 тысяч будет выдано в первый месяц 1, а 2 тысячи — во второй, что отражено в виде чисел на полоске (см. рис. 7.11). Аналогично оценки для остальных статей распределены по всему периоду выполнения и показаны в виде чисел на соответствующих полосках, которые являются, по сути, расписанием проекта, представленным в виде ленточной диаграммы. На чертеже, отображающем базовый план стоимости, редко показывается расписание, однако мы включили его в рис. 7.11 для облегчения понимания сути базового плана. Политика БУ? Что там и как? Суммирование оценочных значений расходов по временным периодам. Графическое отображение базового плана стоимости. S кривая является широко распространенным способом показа базового плана стоимости. Это нарастающий итог. ПРОСТЫЕ S-КРИВЫЕ В СЛОЖНОМ ПРОЕКТЕ РАЗРАБОТКИ МИКРОПРОЦЕССОРА При выполнении проекта разработки микропроцессора руководство потребовало предоставить распределенный во времени бюджет расходов на оплату труда инженеров, занятых в этом проекте. Начав с составления расписания проекта, менеджер предпринял следующие шаги: • определил и детально описал ежемесячные потребности проекта в инженерах каждого типа; • преобразовал эти потребности в S-кривые для каждого типа инженеров, а также нарисовал суммарную S-кривую для всей команды проектировщиков, куда входили инженеры. Согласно получившейся кривой, в один из моментов потребность в инженерах достигала почти 300. S-кривые использовались для различных целей. Совокупная S-кривая, которая включала в себя человекомесяцы трудозатрат, распределенные по всему расписанию проекта, служила базовым планом для упрощенной версии управления выполненной стоимостью. Кроме того, кривая имела долларовое выражение, которое информировало руководство о том, какую сумму нужно выделить на зарплату инженерному персоналу. Так как в компании работали инженеры не всех профилей, S-кривые для специалистов отдельных типов применялись также для их своевременной подготовки и найма на рынке труда. 10.9.3. Использование базового плана стоимости Когда использовать. Это прогноз денежного потока. Бывает нужен и для малых проектов. Полезно обновлять базовый план по мере корректировок. КОГДА СЛЕДУЕТ ОБНОВЛЯТЬ ИЛИ ИЗМЕНЯТЬ БЮДЖЕТ? Догматическая приверженность изначально установленному базовому плану или распределенному во времени бюджету в то время, когда назрела необходимость его изменения, бесцельна и непрактична. Эта необходимость изменения носит управленческий или контрольный характер и, в сущности, инициируется несколькими факторами, что ведет к незначительным (обновления) или значительным (изменения) ревизиям базового плана. Обновления могут возникать в силу действия таких факторов, как [1]: • уточнение оценки стоимости. По мере продвижения проекта появляется все больше информации, что помогает получать более точные оценки, начиная с оценки по аналогии или параметрической и заканчивая оценкой «снизу вверх». Такие изменения в оценках должны вести к обновлениям базового плана; • изменения в проекте. Управление этими изменениями может потребовать новых расходов, которые нужно добавить к базовому плану. Изменения возникают вследствие непредвиденных условий или новых требований заказчика; • изменения в расписании. Изменения во временной привязке операций проекта на стадии исполнения довольно часты и приводят к неизбежной модификации базового плана. В дополнение к названным обновлениям (незначительным ревизиям) бывают ситуации, когда нужна значительная ревизия базового плана. По ходу работ возможны непредвиденные календарные, стоимостные или технические проблемы либо необходимость изменить стратегию, что, как правило, приводит к существенному пересмотру плана проекта, включая значительную ревизию базового плана. Такие изменения плана могут возникать очень редко, один или два раза в течение жизни проекта, а могут и не возникать вовсе. Вне зависимости от того, имеете вы дело с обновлением или изменением базового плана, главное — управлять всеми модификациями и сопутствующими им факторами проактивно (упреждающе), а не реактивно (реагируя на уже свершившееся событие), и сохранять контроль над проектом. Трудоемкость. Слабая детализация – 1…2 часа. Сложно – десятки часов. Выгоды. Для прогноза потоков, оценки хода исполнения, контроля фактических денежных потоков Преимущества и недостатки. Действия по формированию базового плана стоимости относительно просты. S кривая наглядна. Но долго. THE MUSEUM DESIGN COMPANY (MDC) Однажды компания MDC попала в парадоксальную ситуацию: у нее имелся ряд контрактов, но отсутствовал положительный поток денежной наличности. Дело в том, что укомплектованная талантливейшими специалистами-дизайнерами и известная великолепным качеством продукции MDC не испытывала трудностей при получении контрактов на выполнение проектов военных выставок и экспозиций. Однако Джон Риддл-младший (John Riddle Jr.), руководитель MDC и сам дизайнер, был вынужден почти каждый месяц брать в банке ссуды на зарплату сотрудникам. Сбитый с толку этой ситуацией, Джон Риддл попросил помощи у профессионалов. Ему посоветовали внимательно изучить S/кривые потоков входящей и исходящей денежной наличности каждого проекта. Менеджеры с помощью консультанта построили такие кривые, и оказалось, что большая их часть выглядит как на рис 7.14а. Разность между фондами, получаемыми от заказчика (входящий поток денежной наличности), и выплатами на зарплаты, накладные расходы и проценты по займам (исходящий поток денежной наличности) была отрицательной. Иными словами, полный поток денежной наличности имел отрицательное значение на всем протяжении работ, исключая момент завершения проекта, когда он становился равным нулю. Это и породило парадоксальную ситуацию, когда в банке постоянно брались ссуды, проценты за которые «съедали» всю прибыль, что со временем могло привести к потере бизнеса компанией. Джон Риддл пришел к выводу, что положения, при котором полный поток денежной наличности становится отрицательным, необходимо избегать во всех будущих проектах. Решено было сделать разность между входящим и исходящим потоками денежной наличности положительной (рис. 7.146), что позволило бы MDC обходиться без дорогостоящих займов и дало бы возможность сохранить бизнес. После детального объяснения за/ казчик принял эту идею. Рис 7.14. Две возможности: отрицательный и положительный потоки денежной наличности Вариации. Можно на ранних, поздних сроках, на средних. Адаптация базового плана. Действия по адаптации Примеры действий по адаптации Определение границ использования — Привести в соответствие со стандартом, используемым в данной отрасли, например для внутренних проектов разработки программного обеспечения применять базовый план стоимости, выраженный в часах рабочего времени, а не в денежном эквиваленте; — основываться на средних значениях ранних и поздних дат начала работ; — использовать понятие потока денежной наличности (входящей и исходящей) для проектов с внешним финансированием; — учитывать ранние даты начала операций Добавление отличительной особенности Указать значение, равное 100%, в верхней точке правой вертикальной оси графика, отображающего S/кривую, а затем проставить промежуточные деления с шагом 10%. Деления должны обозначать долю выполненных работ проекта (данный подход популярен среди технически ориентированных менеджеров, которым нравится измерять ход проекта и вести отчетность в виде степени выполненности) Модификация конкретной характеристики Включить новый столбец в форму на рис. 7.11 между столбцами «Обозначение» и «Элемент» с целью отображения плана контрольного счета для каждого элемента (для тех компаний, в которых применяется формальное измерение выполненной стоимости) ПРОВЕРКА БАЗОВОГО ПЛАНА СТОИМОСТИ Убедитесь, что базовый план стоимости: • показывает обозначение статьи расходов; • отображает описания элементов; • выводит оценки стоимости элементов; • отражает бюджет элемента в течение периода времени; • показывает кумулятивный (до текущей даты) бюджет проекта; • демонстрирует S/кривую (если принят данный способ представления базового плана). 10.10. Свод 11. Планирование качества проекта Рис. 8.1. Роль инструментов планирования качества в процессе стандартизированного управления качеством Цель этих инструментов — сделать процессы управления проектами предсказуемыми. Это свой подпроект. 1. Формулирование целей в отношении качества, политик и стандартов, относящихся к содержанию проекта. 2. Идентификация и разработка процессов управления, действий и обязанностей, необходимых для достижения целей и соблюдения стандартов. Делается синхронно с другими процессами: основными (планирование содержания, расписания и стоимости) и вспомогательными (планирование рисков, команды и закупок) процессами. 11.1. Программа обеспечения качества проекта 11.1.1. Что такое программа обеспечения качества проекта? Программа обеспечения качества проекта — это план действий, обеспечивающий соответствие фактического качества проекта запланированному (рис. 8.2). Есть работы по обеспечению качества работ, например, разработка типового договора с контрагентами. Это сложно (техническая, юрилическая, экономическая часть). Запланировали – надо делать. Написать, юрисконсульт проверит, экономичт проверит,… изменим, утвердим, проверим, доработаем. Есть работы по обеспечению качества выходного продукта. Качественный сайт. План обсуждается, эскиз утверждается, созываются эксперты, проверяем на потребителях (я это все время говорю). Рис. 8.2. Пример программы обеспечения качества. Тут разрабатываептся документ о том, как управлять проектами в организации, годится для всех проектов. 1 Индекс легкости чтения Флеша (Flesch Reading Ease). Психолингвистический параметр. Подсчитывается по среднему числу слогов в слове и слов в предложении. Варьируется от 0 до 100. Чем выше значение, тем легче прочесть текст и тем большему числу читателей он будет понятен. — Прим. ред. 11.1.2. Разработка программы обеспечения качества проекта Подготовка исходной информации. Надо: • политики и процедуры в области качества (обеспечение качества, управление им); Определенная, документированная и поддерживаемая руководством политика представляет собой изложение принципов, убеждений и ключевых целей проектов, которые в совокупности образуют каркас, на который опираются действия по обеспечению качества в организации [5]. Этот каркас в дальнейшем детализируется до уровня процедур обеспечения качества. Политика и процедуры совместно задают направление программы. Например, если процедуры требуют соответствия стандарту ISO 9000, программа должна такое соответствие обеспечить. • голос заказчика (надо, чтобы ему было понятно, понятно, как измерить и выразить в стандарте). Чаще заказчик – руководство организации; • описание содержания и СДР. Выбор элемента СДР. Программа обеспечения качества создается на уровне пакетов работ СДР. Потом всё суммируется. Установка стандартов качества. На рис. 8.2. заказчик (руководство организации?) хочет, чтобы «Руководство» и описываемый в нем процесс соответствовали международному стандарту ISO 9000 и американскому стандарту PMBOK1 Guide. Для того чтобы данное «Руководство» могли использовать проектные команды, оно должно соответствовать трем принятым в компании стандартам: • краткости (максимум пять страниц); • совместимости с организационными политиками в части написания руководств; • легкости чтения по Флешу (индекс должен быть более 70 пунктов). Чтобы выполнять хорошо, надо, чтобы процесс соответствовал используемым стандартам. А это надо измерить. Международные – там всё прописано. Легкость чтения – стандартная процедура. Удовлетворенность заказчика своевременностью – делаем сами процедуру (например, по Ликерту-Лайкерту). Определение задач обеспечения качества. Что делать для того, чтобы соответствовать этим стандартам и выполнить пакет работ согласно ожиданиям заказчика. Для легкости чтения надо преиодически проверять тексты и переписывать при необходимости. Соответствие pmbok – нужна группа экспертов. КАКОВО ВАШЕ ОПРЕДЕЛЕНИЕ КАЧЕСТВА? В проектах часто заняты люди из разных функциональных отделов. Такие понятия, как «продукт, цена, реклама, место», являются критически важными для представителя отдела маркетинга, но мало значат для инженера или дизайнера. Поэтому и качество для всех разное. Есть мнение, что качество не может быть определено точно, но факт его наличия может быть признан, когда оно наблюдается в чем-либо (например, в часах Rolex). Одни ориентируют на продукт (заказчики). Когда некто полагает, что качественное различие есть отражение некоторого количественного различия в каком-либо атрибуте продукта, он использует ориентированное на продукт определение качества. В этом смысле 833-мегагерцевый процессор имеет более высокое качество, чем 366-мегагерцевый. Соответствие спецификациям представляет собой ориентированное на производство определение качества, согласно которому спецификации включают как целевые значения (например, толщина детали 30 см), так и допустимые отклонения (например, 30 см + 0,01). Качественный продукт по ориентированному на ценность определению — это продукт, который столь же ценен, сколь и конкурирующие продукты, но продается по более низкой цене. Совершенно очевидно, что с точки зрения отношения «полезность/цена» постоянные низкие цены на продукт свидетельствуют о его более высоком качестве, чем продажа по специальной цене. Могут быть противоречия. Предпочтительно все-таки ориентация на заказчика: качество есть удовлетворение или превышение ожиданий клиента [6—9]. Распределение областей ответственности, определение расписания. Кто и когда дожен выполнять задачи, отчетность. Матрица ответственности. Гантт. Вопрос: должны ли матрица и расписание браться из программы обеспечения качества и соединяться с матрицей и расписанием проекта? Ответ на оба вопроса — нет. Если взглянуть на типичные матрицу ответственности и расписание проекта, то на них наверняка не окажется задач по обеспечению качества. О чем это говорит? О том, что мы до сих пор не рассматриваем качество как приоритетную задачу проекта и предпочитаем иметь отдельную программу обеспечения качества со своей матрицей ответственности и своим расписанием до тех пор, пока не построим иную систему оценки. 11.1.3. Использование программы обеспечения качества проекта Когда использовать. Согласно проводившемуся в 1997 году исследованию удовлетворенности американских заказчиков, компании, характеризующиеся более высоким значением удовлетворенности клиентов, имели вдвое большую долю акционерного капитала, чем компании, характеризующиеся низким значением. Значит, любой проект может выиграть от использования программы обеспечения качества. Планирование качества окупается. Объем рбаот – по ресурсам. У НАС ЕСТЬ ГРУППА ОБЕСПЕЧЕНИЯ КАЧЕСТВА! В больших проектах делают что-то по качеству. В малых – нет. В одном случае оправдание звучало так: «У нас есть группа обеспечения качества. Пусть она и контролирует качество». Исполнители знают лучше, поэтому они должны дейтствовать! Превентивно! А группа качества – инспекция, то есть коррекция. Трудоемкость. Планирование качества, результатом которого является составление программы обеспечения качества проекта, требует определенного времени. После того как вся исходная информация подготовлена, разработка программы для проекта, содержащего 20 пакетов работ, использующего один или два стандарта качества (столбец 3 на рис. 8.2) на каждый пакет работ и предполагающего по одной задаче обеспечения качества (столбец 4 на рис. 8.2) на каждый стандарт, у опытной команды займет час или два. Если команда не столь опытна, а проект большой, затраты времени могут возрасти. Если время является критическим фактором и команда хочет сфокусировать внимание на нескольких основных пакетах работ, то вполне может хватить 15—20 минут. Выгоды. Превентивность! Преимущества и недостатки. Просто, понятно. Но времяемко и сложно дял неопытных. 11.2. Схема [типового] процесса 11.2.1. Что такое схема процесса? Схема процесса — это изобразительное описание его шагов или задач (рис. 8.4). Много для чего полезен, здесь – для планирования, обеспечения или повышения качества процессов управления, являющихся основными строительными блоками проектов. Рис. 8.4. Пример нисходящей схемы выполнения процесса для проекта разработки продукта 11.2.2. Разработка схемы процесса Разработка схемы процесса начинается с его «владельца». Сбор исходной информации. Нужно ответить на следующие вопросы: • Каково назначение процесса (его значимые результаты. Если делаем продукт, то строим соответствующий бизнес-процесс)? • Что говорит заказчик (чтобы сделать процесс, надо знать, что надо. Например, директору надо понять бизнес-процесмс и утвердить его)? • Каковы критически важные входные данные и результаты процесса? Вдруг это объем продаж? Им важен прогноз продаж. Выбор типа и степени детализации схемы проекта. Схемы процесса могут иметь различные форматы, каждый из которых служит своей цели. Следовательно, знание цели или предполагаемого способа использования схемы является определяющим фактором при выборе ее типа. Основная цель, преимущества и недостатки некоторых типов схем описаны в табл. 8.1. Вот детальная схема. рис. 8.5. Рис. 8.5. Пример схемы развертывания для выполнения плана проекта Для изображения схем процессов используются различные символы. Например, детальная схема может включать: • эллипс. Служит для идентификации входов (задач, информации или материалов), необходимых для начала процесса, или результатов, получением которых завершается процесс; • прямоугольник. Обозначает шаг, задачу или операцию процесса. Входить в прямоугольник могут несколько стрелок, но выходит из него, как правило, только одна; • ромб. Указывает точку (ситуацию), в которой должно происходить принятие решения; • круг с буквой, числом или буквой и числом. Показывает точку стыковки в каком либо другом месте схемы; • стрелка. Определяет направление или течение процесса. Составление схемы процесса. Чтобы построить схему процесса, следует: • начать с проведения мозгового штурма, целью которого должна быть разработка списка из шести или семи основных шагов, необходимых для преобразования входов в выходы результаты; • упорядочить шаги согласно логике выполнения, а затем изобразить их в виде ясной последовательности прямоугольников вдоль верхнего края страницы, соединенной стрелками [13]; • разбить каждый из основных шагов на подшаги, которые могут быть перечислены под основным шагом либо заключены в отдельные прямоугольники и соединены стрелками. В приведенном на рис. 8.4 примере мы выбрали первый способ. Таким образом, наличие подшагов позволяет получить более детальную информацию о последовательности задач, которые необходимо выполнить для осуществления процесса. Это все похоже на структурное проектирование. Не ново. Метод изображения детальной схемы описан во врезке «Разработка детальных схем путем построения обратной цепочки». РАЗРАБОТКА ДЕТАЛЬНЫХ СХЕМ ПУТЕМ ПОСТРОЕНИЯ ОБРАТНОЙ ЦЕПОЧКИ Компания ATT предложила интересный метод разработки детальной схемы процесса — метод построения обратной цепочки. Здесь начать следует с задания результатов и выяснения требований заказчика, а затем, двигаясь в обратном по отношению к естественному ходу выполнения процесса направлении, определить критически важные шаги, необходимые для получения каждого из этих выходов, после чего, достигнув входов, остановиться. Должна соблюдаться описанная ниже процедура [3]: • выяснить, каков последний существенный подпроцесс, который дает результат (выход) процесса; • определить, какой вход требуется данному подпроцессу для получения выхода процесса. Убедиться в том, что данный вход действительно необходим; • идентифицировать источник каждого входа. Весьма часто этот вход является выходом предыдущего подпроцесса, однако иногда может обеспечиваться сторонним поставщиком; • продолжать движение в обратном направлении, проходя по одному подпроцессу за один раз, до тех пор, пока для каждого входа не будет найден сторонний поставщик. Когда движение в обратном направлении — от выходов, необходимых заказчику, к входам, предоставляемым поставщиками, — завершено, метод построения обратной цепочки можно применить для составления детальной схемы каждого подпроцесса, что позволит осуществить дальнейшую детализацию общей схемы процесса. На рис. 8.6 приведен пример детальной схемы процесса. Рис. 8.6. Пример детальной схемы процесса прекращения проекта Защита процесса от ошибок. Цель работы над схемой процесса состоит в том, чтобы сделать этот процесс эффективным и обеспечить высококачественные результаты логически непротиворечивым и повторяющимся образом. По указанной причине необходимо внимательно изучить полученную схему и представляемый ею процесс, а также ответить на следующие вопросы [6]: • Шаги процесса четко определены и выстроены в логической последовательности? Есть ли необходимость их переупорядочить? • Является ли каждый шаг добавляющим ценность? Может ли устранение одних шагов и привнесение других повысить эффективность процесса? Будет ли полезным объединение некоторых шагов? • Имеются ли какие-то шаги, являющиеся узкими местами и замедляющие процесс? Другими словами, сбалансированы ли возможности всех шагов? • Какие навыки и ресурсы необходимы для безукоризненного выполнения процесса? Они доступны или их придется заменять теми, которые уже имеются? • Можно ли использовать какие либо технологии, способные автоматизировать некоторые шаги и повысить уровень исполнения? Настойчивый поиск ответов на перечисленные вопросы крайне важен для качества процесса управления проектами. Даже если вы очень загружены повседневными делами, не игнорируйте эти вопросы, иначе пострадает качество процесса. Определение способов оценивания процесса. Когда, что и как контролировать. 11.2.3. Использование схемы процесса Когда использовать. Это инструмент процессого управления проектами. Можно использвать для сравнения плана и факта. Трудоемкость. Например, разработка полного процесса управления проектом (подобного показанному на рис. 8.4) в некоей организации, выполняющей в год 10—15 проектов стоимостью от 50 тысяч до 1 миллиона долларов, заняла у команды, состоящей из пяти человек, полный рабочий день (не считая времени, затраченного на документирование и описание процесса). В случае больших и более разветвленных процессов может потребоваться больше времени. Выгоды. Защита от тошибок и рационализация. Все понимают, что они делают. Преимущества и недостатки. Легко строить (?), видно графически. Но. Могут стать слешком делальными. ПРОЦЕСС СОСТОИТ ИЗ 1000 ШАГОВ. НО ВСЕ ЛИ НУЖНЫ? В некоей компании процесс управления проектами разработки продуктов (PDPM) состоял более чем из 1000 шагов! Эта новость ошеломила команду PDPM, когда она завершила построение схемы процесса, который эволюционировал с момента основания компании, в его естественном виде — «как есть». Все шаги были тщательно проанализированы, а затем поделены на «добавляющие ценность» и «добавляющие только себестоимость». Назначение этих действий было понятным: следовало отделить зерна от плевел, оставив только необходимые, добавляющие ценность шаги и избавившись от ненужных, увеличивающих стоимость. В итоге оказалось, что требуется немногим более 50 шагов. Последствия переработки процесса PDPM были потрясающими: время выполнения 353 типичного проекта уменьшилось с 18 до 12 месяцев. Мораль этой истории проста: процесс управления проектами необходимо разрабатывать, а не пускать на самотек. Разница в результатах будет грандиозной. СХЕМА ПРОЦЕССА КАК РУКОВОДСТВО ПО УПРАВЛЕНИЮ ПРОЕКТАМИ Во многих компаниях руководства по управлению проектами служат для документирования и направления политики, целей, стратегий, процедур и процессов, применяемых при управлении. Объем этих руководств, написанных в повествовательной форме, может колебаться от десяти до сотни с лишним страниц [2]. Однако наблюдается тенденция к сокращению объема, что облегчает процесс использования и обновления руководств и делает его менее дорогостоящим. На рис. 8.7 представлен набор специальных схем процессов, называемых системограммами. Системограммы представляют процессы компании наглядно и просто, согласуясь с организационной культурой. Для проектного персонала системограммы являются их языком управления проектами. Рис. 8.7. Пример системограммы для процесса планирования проекта 11.3. Аффинная диаграмма 11.3.1. Что такое аффинная диаграмма? (Что-то было выше) Аффинная диаграмма — это инструмент для эффективной организации информации посредством классификации идей или фактов (рис. 8.8). Рис. 8.8. Классификация идей или фактов 11.3.2. Разработка аффинной диаграммы Сбор исходной информации. О контексте, требованиях и процессах проекта. Определение вопроса. Работа над аффинной диаграммой начинается с поиска ответа на какой либо ключевой вопрос. Например, надо разработать систему балльной оценки проекта заказчиком. Эти оценки даются руководству для контроля проекта. Ключевой вопрос: «Каковы основные элементы карты балльных оценок проекта?» Генерация идей. При помощи интервью с руководителями высшего звена члены команды собирают множество идей, фиксируя каждую на отдельном листке клейкой бумаги. Те сотрудники, которые занимались сбором предложений, зачитывают их вслух всей команде, что стимулирует генерацию дополнительных идей и еще больше увеличивает список (см. рис. 8.8). Листки клейкой бумаги размещаются на стене (можно также использовать лекционный плакат или экран монитора). Часто новые идеи рождаются в ходе мозгового штурма, устраиваемого командой. Классификация и группировка идей. Каждый член команды группирует листки с идеями согласно логике, размещая их там, куда они вписываются лучше всего. Приветствуются создание новых групп и переупорядочивание уже существующих. Поскольку количество предложений велико, задача осмысления всех идей на первый взгляд выглядит невыполнимой, но по мере устранения избыточностей и объединения похожих вариантов становится более реальной. Именование групп. Когда все идеи сгруппированы, члены команды должны придумать для каждой такой группы фразу, выражающую основное значение темы. Эти фразы после рассмотрения и внесения необходимых исправлений приобретают статус заголовков, показывающих, что ключевые требования заказчика к карте балльных оценок проекта — это выбор правильных мер хода исполнения, установка правил использования этих мер и принудительное внедрение (см. рис. 8.8). Если группы оказываются слишком большими, полезно разбить их на подгруппы, определив подзаголовок для каждой. Построение и пересмотр окончательного варианта аффинной диаграммы. Наконец, команда составляет окончательный вариант диаграммы, связав заголовки с группами. В это время все члены команды еще раз внимательно изучают интервью с руководителями и извлеченные из этих интервью идеи. Сравнение с финальным вариантом диаграммы показывает отсутствие необходимости внесения каких либо изменений, что ранее было неочевидно. 11.3.3. Использование аффинной диаграммы Когда использовать. Для планирования качества проекта, для его улучшения. Помогает структурировать множество вопросов. Может применяться в любых ситуациях, где требуется структурирование больших объемов информации, например при восходящей разработке СДР. Особенно полезен этот инструмент в условиях командной работы. СОВЕТЫ ПО ИСПОЛЬЗОВАНИЮ АФФИННОЙ ДИАГРАММЫ • Фиксируйте идеи на листках бумаги с клейкой поверхностью. Текст должен читаться с расстояния 2—3 м. Используйте лишь несколько необходимых слов, в идеале — глагол и существительное. • Рассчитывайте на то, что типичная диаграмма содержит от 20 до 30 идей, но не удивляйтесь, если их окажется больше 100. • Сортировку и группировку выполняйте молча, чтобы не пропустить возможные взаимосвязи между идеями. • Заводите несколько карточек с одной идеей, если эта идея последовательно перемещается из одной группы в другую. Располагайте эти дубликаты в разных группах. • Стремитесь придумать такие заголовки, которые отражают суть всех идей в группе. Трудоемкость. Небольшой команде, обладающей определенными навыками, на разработку трехуровневой аффинной диаграммы из 15 идей требуется от 30 до 45 минут. По мере увеличения размера диаграммы и численности команды время разработки будет расти. Выгоды. Творческий подход, снимает коммуникационные барьеры и развивает чувство сопричастности будущим результатам. Преимущества и недостатки. Простота использования и понимания, наглядность графического представления. Но долго при работе со значительным количеством уровней классификации Вариации. Аффинная диаграмма — это упрощенная форма метода KJ, разработанного в 1960 х годах японским антропологом Кавакитой Джиро (Kawakita Jiro) [6]. В отличие от аффинной диаграммы, метод KJ может включать как идеи, так и факты. Кроме того, процесс уточнения, ведущий к созданию диаграммы, здесь лучше структурирован. Адаптация аффинной диаграммы. Чтобы получить от аффинной диа 11.4. Свод 12. Планирование риска Рис. 9.1. Роль инструментов планирования риска в процессе стандартизированного управления проектами 12.1. План реагирования на риски (тема практики) 12.1.1. Что такое план реагирования на риски? План реагирования на риски оценивает риски и определяет действия по увеличению числа благоприятных возможностей и уменьшению количества опасностей для целей проекта [3]. Эффективный план должен быть реалистичным (в части оценки серьезности рисков), своевременным, учитывающим себестоимость, требующим от всех участников осознания своей сопричастности проекту и находящимся во «владении» ответственного лица. Но главное — план должен быть упреждающим, предполагающим заблаговременную (до наступления события риска) разработку действий (рис. 9.2). План – не средство обеспечения полного контроля событий, а как способ подготовки к возможным неблагоприятным событиям. 12.1.2. Разработка плана реагирования на риски Приходится работать в условиях неполной информации и неопределенных результатов. Это и есть область управления рисками проекта. За пределами данной сферы лежит область полной неопределенности, характеризующаяся абсолютным отсутствием информации. Континуум «полная определенность (известные) — риски (известные неизвестные) — полная неопределенность (неизвестные неизвестные)» изображен на рис. 9.3. Рис. 9.2. Пример плана реагирования на риски Рис. 9.3. Континуум неопределенности и планирования реагирования на риски Из “Project and Program Risk Management: A Guide to Managing Project Risks and Opportunities” by R. Max. Wideman. Copyright © 2000 by Project Management Institute. Перепечатано с разрешения Project Management Institute. Мы акцентируемся на области рисков путем разработки плана реагирования в ходе простого цикла, состоящего из идентификации, оценивания, реагирования и документирования. Основные определения, относящиеся к рискам: • риск проекта. Кумулятивный эффект вероятностей наступления неопределенных событий, способных оказать отрицательное влияние на цели проекта [1]; • событие риска. Описание потенциально вредоносных событий, которые могут произойти, нанеся ущерб проекту; • вероятность риска. Вероятность (возможность Н.П.) того, что событие риска наступит; • влияние риска (последствие риска, сумма ставок). Степень воздействия на цель проекта; • статус события риска (величина критерия, ранг). Мера значительности события риска; • резерв на покрытие неопределенности. Сумма денег или промежуток времени, обычно включаемые в базовый план стоимости или расписания проекта для снижения риска перерасхода, связанного с достижением целей проекта, до приемлемого уровня [6]; • управленческий резерв. Сумма денег или промежуток времени, не включаемые в базовый план стоимости или расписания проекта и используемые руководством для предотвращения негативных последствий будущих ситуаций, которые невозможно спрогнозировать. Подготовка исходной информации. Нужны: • план управления рисками; • результаты планирования проекта; • категории рисков; • историческая информация. План управления рисками — это документ, разрабатываемый в начале проекта и представляющий собой график работы с рисками в течение жизни проекта. В план может быть включено следующее [5]: • методология. Идентифицирует и описывает подходы, инструменты и источники данных, используемые для работы с рисками; • роли и обязанности. Определяет, кто и какую работу выполняет в ходе управления рисками проекта, начиная от членов проектных команд и заканчивая членами команд управления рисками компании; • бюджетирование и временные рамки. Устанавливает бюджет для управления рисками проекта, а также частоту процессов управления рисками; • инструменты. Описывает, какие конкретные методы качественного и количественного анализа рисков следует использовать и когда; • отчетность и отслеживание. Определяет формат плана реагирования на риски и отчета, способы документирования результатов действий по управлению рисками, доведения информации о них до сведения заинтересованных сторон и ее сохранения для накопления опыта и извлечения уроков. Очевидно, что предназначение плана управления рисками состоит не в том, чтобы работать с отдельными рисками проекта, а в том, чтобы руководить проектной командой при разработке и последующем мониторинге исполнения плана реагирования. Результатом планирования проекта является базовый план, включающий в себя базовые планы содержания, стоимости, времени (расписания) и качества — всего, что подвергается риску. Важно для того, чтобы противостоять рискам. Риски можно сгруппировать по разным признакам. Например, по воздействию, оказываемому на проект, выделяются риски содержания, риски качества, риски расписания и финансовые риски. Другой способ классификации — деление по источнику рисков на внешние (но непредсказуемые), внешние предсказуемые (но неопределенные), внутренние нетехнические, технические и легальные (риск нарушить закон? Или закон не даст сделать) [1]. Не все? Форс-мажор? Технический прогресс, … Если трансакция нелегальна, то имеется ассоциированный легальный риск быть пойманным. Анна Левитова ... советует приобретать недвижимость в объектах, которые полностью построены, но документы о собственности еще не получены. В таких проектах риск больших задержек сроков завершения строительства невелик, так как основная часть строительных и отделочных работ завершена. Легальный риск в таком вложении тоже ниже, чем при покупке на ранних стадиях, - доля города выделена, претензии по земле или другие недостатки документов уже выявлены. Такой вид размещения несет легальный риск, поскольку судом может быть принято решение о возвращении ребенка в биологическую семью. Экстра-легальный риск означает любое событие, источник которого находится вне существующих легитимных структур страны: терроризм, саботаж. Вообще-о, как классифицируешь, такая будет и политика фирмы. Идентификация рисков. Мозговой штурм, эксперты, консультации у опытных. Уровень риска меняется по ЖЦ. Сначала высок, топтом снижается. Есть особве риски (приемо-сдаточных испытаний). Значит, надо пересматривать. ЯВЛЯЕТСЯ ЛИ РИСКОМ ДОПУЩЕНИЕ? При выводе продукта допущение: рост рынка 10%. Задокументировали. Надо проверить. Надо определить, как проверяь, какое значение критично для начала каких-то действий. Был спад, решили, что настал риск, запущен план реагирования. Плохо, что взаимодействуют и в сочетании приводят к возникновению больших рисков. Поиск таких взаимодействий является важной частью процесса идентификации рисков. Возникают систекматически, так что надо не наступать на те же грабли. Есть СДР, там довольно типовые работы. Качественное оценивание. Рисков много, надо выбрать самые важные. Оценка в баллах. (не очень корректно, но внимательно читать надо, думая, что аезде баллы!!!) Шкала оценок вероятности обычная: 1 — весьма маловероятно; 2 — маловероятно; 3 — вероятно; 4 — весьма вероятно; 5 — почти наверняка [7]. Воздействий – тоже: 1 — очень слабое воздействие; 2 — слабое воздействие; 3 — среднее воздействие; 4 — значительное воздействие; 5 — весьма значительное воздействие. Если влияет на стоимость, время и качество, то определяем всё, потом выбираем самую сильную оценку. Формула (некорректная) Серьезность = вероятность + N * воздействие. N — повышающий коэффициент. Например, N = 2. Строим матрицу. Рис. 9.4. Разделение рисков по степени серьезности с помощью матрицы «Вероятность — воздействие» Такая матрица обычно делится на красную, желтую и зеленую зоны, соответствующие рискам с высокой (критические и имеющие наивысший приоритет), средней серьезностью (околокритические и имеющие средний приоритет) и низкой (некритические и имеющие наинизший приоритет) серьезностью, на основе принятых в организации пороговых значений. Крупные проекты обычно фокусируются на первых 10 рисках максимального ранга. Напротив, в малых проектах могут ограничиться первыми тремя рисками, поскольку недостаточное количество ресурсов не позволяет учитывать большее их число. Оба описанных подхода опасны: если эти проекты имеют больше 10 или больше трех рисков в красной зоне соответственно, то из рассмотрения неизбежно будут исключены некоторые критические риски. С другой стороны, если в красной зоне находится всего один риск, а остальные расположены в зеленой зоне, то на отслеживание первых 10 или первых трех рисков тратятся лишние ресурсы. Надо заранее задать порог. Можно и остановиться. Можно идти дальше. Количественное оценивание. Либо вместе с качественной, либо отдельно. 1. Численно выражаем вероятность (возможность) натупления каждого риска. Обычно по аналогии, либо экспертно. 2. Определить воздействие риска, то есть степень тяжести его последствий. Хотя воздействие может быть выражено практически в любых единицах (процент, потерянная доля рынка, показатель уменьшения количества заказчиков), мы остановимся на оценке воздействия рисков на стоимость и сроки. 3. Определить статус события риска (называемый также величиной критерия или рангом) по следующей формуле [1]: Статус события риска = вероятность риска * воздействие. 4. Определить, какие из них действительно важны и заслуживают внимания, а какие незначительны. Установать пороги для критического, околокритического, некритического статуса. Например, в одном небольшом проекте статус события риска считался критическим при превышении срока в 15 дней, от 7 до 14 дней — околокритическим, менее 7 дней — некритическим. Во вторых, реагировать на риски, имеющие рейтинг от наивысшего до заранее оговоренного уровня. В рассматриваемом случае внимание требовалось сфокусировать на первых 10 рисках. 5. Идентифицировать, влияет ли данное событие на другие события риска. Дело в том, что множество малых рисков могут взаимодействовать, и в результате воздействие суммы рисков становится значительно большим, чем сумма воздействий отдельных рисков. Для предотвращения такой возможности информация о зависимых рисках будет использоваться на следующем шаге для организации действий по реагированию. Реагирование — определение упреждающих действий из диапазона действий, возможных по отношению к данному событию риска, с целью снижения угроз для проекта. Подобное действие должно опираться на политики и процедуры, установленные в плане управления рисками. В частности, проактивное действие по реагированию включает в себя три практических шага: превентивное действие (может и не сработать), точка инициализации и действие в случае наступления события риска. Например, превентивным действием для события 9 на рис. 9.2 (выше) является аутсорсинг — тестирование качества программного обеспечения усилиями сторонней (более крупной и лучше укомплектованной персоналом) фирмы. Если к 1 июня вендор (носитель торговой марки(?)), обеспечивающий тестирование, не будет выбран, а наряд на закупку будет выпущен, превентивное действие считается неуспешным и приостанавливается. Это и является точкой инициации, в которой реализуется «запасное» действие — возврат к прежнему вендору, который, хоть и не является крупной фирмой, тем не менее имеет время для проведения тестирования. Любое приемлемое действие по реагированию может быть отнесено к одному из четырех обширных классов: избегание изменение плана или условий проекта с целью устранения некоторого риска (не окажется эксперта – пригласим), перенос, на третью сторону Сами плохо протеистируем – отдадим задачу сторонним. снижение уменьшение вероятности. Есть вероятность занятости – уменьшим количество просматриваемых материалов. Три стратегии реагирования — избегание, перенос и уменьшение — применяются тогда, когда возникшие риски имеют наивысший ранг. Очевидно, эти способы реагирования должны быть встроены в план проекта. принятие риска. План не меняется по ситуации. Может быть, добавим резерв времени. Можно резервировать на всё, можно по работам. Второе часто, но ленятся. Резерв можно ввести по статусу. Важно знзвать «владельцев» - лиц или сторон, ответственных за каждые превентивное действие, точку инициации и действие в случае наступления события риска. Учтите, что одни риски являются автономными («владельцы» единолично и полностью отвечают за управление ими), а другие могут быть взаимозависимыми. В последнем случае разработка относящихся к ним превентивных действий, точек инициации и действий при наступлении события риска, равно как и «владение» ими, должны осуществляться с учетом имеющихся зависимостей. Документирование. Важно. 12.1.3. Использование плана реагирования на риски Когда использовать. Всегда хорошо. Трудоемкость. Малые проекты – от одного до нескольких часов. Большие – десятки часов. Выгоды. Анализ неопределенностей, выделить опасные, проактивно. Преимущества и недостатки. Просто. Но акцент на отдельных событиях. Вариации. Шкалы. Например, расчет воздействия риска на расписание служит для определения весового коэффициента его вероятности (Wsp) и воздействия (Wsi). Повторив эти операции для воздействий на стоимость и качество, мы получим общий рейтинг риска, равный (Wsp + Wsi) + (Wcp + Wci) + (Wqp + Wqi). Затем полученные величины используются для ранжирования рисков. Этот подход называют еще полуколичественным [4]. Аналогичные подходы могут применяться для вычисления статуса события риска и ранжирования рисков в плане реагирования. 12.2. Анализ Монте-Карло 12.2.1. Что такое анализ Монте-Карло? Метод Монте-Карло (Monte-Carlo Analysis — MCA) использует модель проекта, например сетевой график, для анализа поведения. 12.2.2. Выполнение анализа Монте-Карло Обычно MCA имеет дело с рисками для расписания, стоимости и потока денежных средств, хотя могут анализироваться и другие аспекты, например качество конечного продукта проекта. В целом выполнить анализ рисков расписания сложнее, чем анализ рисков стоимости, поскольку в таком случае потребуется установить взаимозависимости между операциями проекта с целью идентификации критического пути. По этой причине мы рассмотрим метод Монте Карло применительно к анализу рисков расписания (рис. 9.6). Сбор исходной информации. Ключевая роль в анализе Монте-Карло принадлежит следующим информационным элементам: • плану управления рисками (должен и это предусмотреть); • плану реагирования на риски (что когда делать); • логической схеме (сетевой диаграмме) или расписанию проекта; • распределениям вероятностей. Рис. 9.5. Кумулятивное распределение длительности проекта, полученное в ходе анализа Монте Карло Из “Risk Analysis: A Quantitative Guide” by D. Vose. Copyright © 2000 by John Wiley & Sons Limited. Перепечатано с разрешения John Wiley & Sons. Рис. 9.6. Проведение анализа Монте Карло для рисков расписания Вся эта информация применяется в анализе Монте Карло для генерации диапазона возможных значений длительности проекта. Здесь нужен сетевой график, который упорядочивает операции проекта, одновременно отображая их взаимозависимости. Некоторые менеджеры предпочитают начинать не с сетевого графика, а с детерминистского расписания проекта, отображаемого, например, в формате каскадной диаграммы «операции на стрелках» во временном масштабе (рис. 9.7). Подходящим вариантом является также использование расписания по методу критического пути. Рис. 9.7. Пример диаграммы «операции на стрелках» во временном масштабе для анализа рисков по методу Монте Карло Распеределение. На основе опыта. База данных для операций. Задание. КЛЮЧЕВЫЕ ПОНЯТИЯ МЕТОДА МОНТЕ-КАРЛО • случайное событие — процесс или измерение, результат которого заранее не известен; • непрерывное распределение — способ представления какой-либо величины в пределах заданного диапазона; • дискретное распределение — распределение, при котором величина принимает одно из идентифицируемых значений, каждое из которых имеет вычислимую вероятность возникновения; • детерминистская модель — модель, в которой все параметры являются фиксированными и имеют одиночные оценки; • ожидаемое (среднее) значение (EV) — взвешенное с учетом вероятности среднее значение всех возможных результатов; • мода — конкретный результат, являющийся наиболее вероятным, то есть самая высокая точка на кривой распределения; • модель — упрощенное представление исследуемой системы, например диаграмма критического пути: она отражает результат проекта (в частности, его длительность) и значение этого результата (допустим, 18 месяцев); • вероятность (возможность, шанс) — число в диапазоне от 0 до 1 (или эквивалентное процентное значение), показывающее вероятность наступления некоторого события; • распределение вероятности (функция плотности вероятности, вероятностная функция) — математически или графически представленный диапазон значений (допустим, от 2 до 14 дней), которые может принимать переменная (например, длительность операции), и вероятность того, что эта переменная примет то или иное конкретное значение; • сценарий проекта (итерация, испытание) — будущее состояние проекта; • случайная выборка — процесс генерации случайного числа в диапазоне между 0 и 1, который определяет значение входной переменной на основе распределения вероятности; • случайная величина (случайная переменная, стохастическая переменная) — мера случайного события; • однозначная (точечная) оценка — оценка в виде одиночного числа, имеющая только одно значение; • стандартное отклонение — квадратный корень из дисперсии; • стохастическая (вероятностная) модель — модель, которая включает в себя случайные переменные; • дисперсия — ожидаемое значение суммы возведенных в квадрат отклонений от среднего значения. Представим, что операция 1 повторялась чрезвычайно часто, и ее длительность оказалась заключена в диапазоне от 5 до 39 дней (диапазон результатов). Для каждого значения, которое принимала длительность операции 1, мы зафиксировали соответствующую долю испытаний. Эта доля для конкретного результата приблизительно равна вероятности (p) его наступления для операции 1. Полученные приблизительные вероятности (чем больше испытаний будет проведено, тем ближе к истинной вероятности окажется зна чение найденной доли) для всех возможных выходов нужно отобразить в виде распределений вероятности (см. соответствующую кривую для операции 1 на рис. 9.6). Предположим далее, что распределения вероятностей, основанные на опыте, существуют и для других операций проекта (см. длительность операции 2 на рис. 9.6). В таком случае они были бы близки к объективным вероятностям, которые по определению получаются на основе полного знания о системе и не зависят от субъективного мнения (см. врезку «Часто используемые распределения вероятности»). Однако длительности некоторых операций могут быть одно значными (например, длительность операции n на рис. 9.6), а значит, допустима комбинация распределенных и однозначных длительностей. До тех пор пока длительность одной или нескольких операций (входов модели) представляет собой распределенную величину, длительность проекта (выходы) также будет распределенной величиной [10]. Некоторые компании имеют основанные на опыте базы данных, в которых хранятся приблизительные распределения для длительностей их проектных операций, но это скорее исключение, чем правило. На практике распределения подготавливаются на основе субъективных вероятностей, то есть личного мнения о том, примет ли длительность проекта данное значение. Дальше моделируется работа проекта. ЧАСТО ИСПОЛЬЗУЕМЫЕ РАСПРЕДЕЛЕНИЯ ВЕРОЯТНОСТИ Для описания популярного треугольного распределения (рис. 9.8a) используются три величины: минимальное значение L (5), наиболее вероятное значение M (10) и максимальное значение H (20). Приведенные числа показывают длительность операции в днях. Среднее значение равно (L + M + H) / 3. Бета-распределение (рис. 9.8б), используемое для оценки длительностей операций в методе PERT, требует для расчета тех же трех параметров, а именно: минимальное значение (5), наиболее вероятное значение (10) и максимальное (20), однако среднее вычисляется как (L + 4M + H) / 6. Логарифмически нормальное распределение (рис. 9.8в) описывается двумя параметрами — средним значением (10) и стандартным отклонением (2). Известное своей гибкостью произвольное распределение (рис. 9.8г) допускает изменение формы кривой таким образом, чтобы отразить мнение экспертов [4], и описывается массивом значений (7, 10, 15) с соответствующими им вероятностями (2, 3, 1), которые находятся в диапазоне между минимумом (5) и максимумом (20). Рис. 9.8. Распределения вероятности, часто используемые при анализе рисков расписания методом Монте Карло Дальше генерируем величину (как?) – надо узнать. Тема реферата. И рассчитываем по алгоритму. Количество задано (100 или 1000). Строим на выходе распределение. Обработка результатов. После завершения испытаний у нас будет N значений длительности проекта, каждое из которых отражает возможный вариант расписания. Обработка полученных данных программным способом может дать следующие результаты (см. правую часть рис. 9.6): • ожидаемое значение (EV) длительности проекта. Усреднение значений длительности проекта, полученных в ходе испытаний, дает приблизительное значение ожидаемой длительности — то есть взвешенное с учетом вероятностей среднее всех результатов. Чем больше количество испытаний, тем выше точность наиболее вероятного значения и аппроксимации формы распределения для длительности проекта; • частотное распределение. Эту гистограмму, показывающую относительную частоту встречаемости, получают путем груп пировки сгенерированных значений длительности проекта в определенное количество столбцов или классов. Частота соответствует количеству значений в каждом классе. Поделив ее на общее количество значений, мы узнаем, насколько вероятно то, что длительность проекта (выходная переменная) будет находиться в диапазоне, соответствующем данному классу (рис. 9.9); • кумулятивная частота. Данная диаграмма может быть выполнена в восходящем или нисходящем форматах (см. рис. 9.5). Первый показывает вероятность того, что длительность проекта будет равна значению на оси X или меньше его, а последний — вероятность того, что длительность равна значению на оси X или больше его. Мы рассмотрим восходящий формат, поскольку он используется чаще. Ожидаемое значение отмечено на графике черной точкой; Рис. 9.9. Гистограмма частотного распределения длительности проекта • диаграмма торнадо. Эта диаграмма показывает, до какой степени неопределенность длительностей отдельных операций влияет на неопределенность длительности проекта (рис. 9.10), а точнее — насколько сильно операция (входная переменная) влияет на расписание проекта (выход модели). Следовательно, чем длиннее вертикальная полоска, тем сильнее влияние операции на длительность проекта. Согласно сложившейся практике, размер полоски соответствует степени воздействия, поэтому при наличии как положительных, так и отрицательных влияний диаграмма слегка напоминает торнадо. Чтобы не загромождать диаграмму, ограничьтесь изображением тех операций (переменных), которые оказывают влияние от максимального до четверти максимального [4]. Рис. 9.10. Пример диаграммы торнадо Анализ и интерпретация результатов. Результаты анализа рисков расписания должны интерпретироваться так, чтобы дать ясные ответы на поставленные вопросы. По этой причине целесообразно следовать четырем принципам анализа рисков [4]: • фокусироваться на проблеме; • сводить статистику к минимуму; • использовать графическое отображение везде, где необходимо; • понимать допущения, принятые в модели (например, в диаграмме «операции на стрелках» во временном масштабе). Предположим, что проектная команда намеревается выполнить анализ рисков расписания, чтобы получить ответы на следующие вопросы: • Насколько вероятно, что команда сумеет завершить проект к крайнему сроку (20 мая), установленному руководством? • Если вероятность благоприятного исхода составит менее 90% (такое значение предпочтительно с точки зрения команды), как договориться с руководством о сдвиге крайнего срока? • Если вопрос о переносе крайнего срока будет успешно решен, как определить три операции, наиболее сильно влияющие на длительность проекта? Для того чтобы получить ответ на первый вопрос, необходимо на графике кумулятивной частоты (рис. 9.5): • отметить на оси X дату, которая соответствует крайнему сроку (20 мая), установленному руководством; • сдвинуться от этой даты вверх до пересечения с кривой кумулятивной частоты; • сдвинуться от точки пересечения влево до пересечения с осью Y. Значение, находящееся на оси Y (40%), и есть вероятность того, что проект удастся завершить к установленному сроку. Совершенно ясно, что вероятность очень мала, — значительно ниже, чем предпочитаемые 90%. Далее члены команды обращаются к руководству с просьбой добавить к крайнему сроку еще шесть дней (резерв неопределенности), в результате чего проект будет завершен к 26 мая с вероятностью 90% (второй вопрос). Чтобы иметь твердую позицию при ведении переговоров с руководством, команда разрабатывает еще один вариант действий: использует сжатие расписания (выделение большего количества ресурсов в операции проекта) в сочетании с быстрым проходом (наложением операций в максимально возможной степени), получая новую логическую диаграмму проекта и новые распределения вероятности для операций, и повторно выполняет MCA. Построив график кумулятивной вероятности, команда выясняет, что теперь вероятность завершения проекта к установленному сроку (20 мая) составляет 90%. Вооруженные этим графиком, не содержащим излишней (избыточной) статистики, затем члены команды идут к руководству, показывают оба возможных варианта и получают обещание выделить в проект дополнительные ресурсы в соответствии со вторым вариантом. Диаграмма торнадо (рис. 9.10) выявляет три операции, оказывающие наибольшее влияние на дату завершения проекта и потому требующие особого внимания при выполнении проекта (третий вопрос). Команда понимает, что проводимый анализ Монте Карло основан на: (а) измененной логике диаграммы «операции на стрелках» во временном масштабе и (б) измененных распределениях вероятности для операций, базирующихся на новых обязательствах по выделению ресурсов. Иными словами, в своих действиях команда руководствовалась четырьмя принципами анализа рисков расписания. 12.2.3. Использование анализа Монте-Карло Когда использовать. Раньше в больших. Теперь много малых, но важных. Теперь программы. И теперь проектные офисы поддерживают много проектов. Поэтому распространяется. Если проект чувствителен к крайнему сроку завершения, анализ Монте Карло будет предпочтительным вариантом. Аналогично, когда есть множество сценариев проекта, которые необходимо исследовать по принципу «что, если», MCA будет удобнее, чем дерево решений [10]. В ситуации, когда определяющими при выборе проекта, например, в процессе отбора внутри компании, становятся очень тонкие нюансы, анализ Монте Карло также представляется верным выбором. Трудоемкость. Для небольших проектов, содержащих порядка 50 операций, ввод данных и проведение анализа Монте Карло может занять от 10 до 30 минут. (?) Если логическая диаграмма проекта уже существует, подготовка распределений вероятности в ходе мозгового штурма и организация их в виде таблицы для передачи в главный офис может занять от часа до двух. При увеличении размера и сложности проекта неизбежно возрастет и время проведения MCA. – (думаю, неделя. Н.П.) Выгоды. Рассмотрим, к примеру, ситуацию, когда решается судьба компании: если результатом нового проекта не станет разработка продукта, который появится на рынке раньше продуктов конкурентов, компания перестанет быть лидером в своей области. Метод Монте Карло способен значительно повысить качество принимаемых решений, предлагая четкий анализ рисков, различных сценариев и вероятности достижения цели. От менеджера в любой момент могут потребовать выполнить проект быстрее, чем это возможно, или при явно заниженном бюджете. В этом случае анализ Монте-Карло позволит составить план снижения рисков и собрать аргументы против необъективного подхода и за выделение ресурсов, необходимых для завершения проекта желаемым образом. Таким образом, ценность MCA состоит в его способности исследовать каждый сценарий проекта, включая экстремальные варианты, чтобы посмотреть, какие условия приводят к тем или иным результатам. Это позволяет не только проверить проект на реалистичность, но также отделить возможное от невозможного и понять, как сделать невозможное возможным [10]. Преимущества и недостатки. Простая математика. Легкость использования (пакеты есть) не верю!!!; легкость изменения; ему верят (я- нет). Но. Сложность, так как вероятность, приблизительность раппределений и результатов, если нет большого числа опытов; Компьютер долго работает (не верю!) • времяемкость. Компьютеру нужно много времени для генерации итераций (спорно). НАВЕРНЯКА ИЛИ ВЕРОЯТНО? 12.3. Дерево решений 12.3.1. Что такое дерево решений? Дерево решений — это графический инструмент для анализа проектных ситуаций, находящихся под воздействием факторов риска. Дерево решений (рис. 9.11) отображает последовательные решения в виде ветвей дерева, располагающихся слева направо. Ветви берут свое начало из исходной точки принятия решения и «разрастаются» вплоть до получения конечных результатов [11]. Путь вдоль ветвей дерева состоит из последовательности отдельных решений и случайных событий. Чтобы оценить решения, необходимо рассчитать ожидаемое значение каждого пути, «свернув» дерево в обратном направлении — от конечных точек до исходной [12]. ПЯТЬ КОМПОНЕНТОВ ТИПИЧНОГО ДЕРЕВА РЕШЕНИЙ • Узлы решений (точки принятия решения). Моменты времени, когда происходит принятие решений либо выбор альтернатив. На схеме изображаются в виде квадратов и контролируются менеджером. Начальный узел называется корнем. • Узлы случайных событий (вероятностные узлы, точки). Моменты времени, когда наступает случайное событие с тем или иным результатом. На схеме обозначаются кружками. Менеджеры не обладают контролем над этими моментами. • Ветви. Линии, последовательно соединяющие узлы решений и узлы случайных событий. Ветви, выходящие из узла решения, соответствуют возможным решениям, а линии, ответвляющиеся от узлов случайных событий, — возможным результатам вероятностных событий. • Вероятности. Вероятности наступления событий, показанные на ветвях, которые представляют эти события. Как правило, подчиняются определенным условиям. Для любого случайного узла сумма вероятностей равна 1. • Отдача. Результат каждой альтернативы, отображаемый в конце соответствующей ветви: приведенные стоимости, дисконтированные к дате корневого решения, либо стоимости. 12.3.2. Анализ дерева решений Надо определить альтернативы, которые дают максимальную чистую приведенную стоимость или минимальную стоимость (расходы). ЭЭто минимизирует риски. Пример: сокращение длительности расписания. Актуально. Подготовка исходной информации. Нужно: • план управления рисками (какие решения); • план реагирования на риски (что делать в разных ситуациях); • прочая информаця о проекте (например, сетевые графики альтернатив решений). Рис. 9.11. Дерево решений для проектной ситуации, находящейся под воздействием факторов риска Описание решения в условиях риска. Чотбы стало понятно. Пример. Компания Fast Corporation основывает свое конкурентное преимущество на минимизации времени выхода на рынок. Начиная с фазы проектирования нового проекта разработки сервера предприятия целью фирмы становится скорейшее завершение работ. Длительность проекта рассматривается как параметр первостепенной важности, зато на стоимость практически не обращают внимания. Основная неопределенность заключается в том, сколько дней требуется для проектирования центрального модуля продукта. Имеются три альтернативы, каждая из которых идентифицируется одним словом: • зеленая (G). Внедрить правила маршрутизации в дизайн центрального модуля на ранней стадии; • желтая (Y). Предсказать правила маршрутизации на ранней стадии и модифицировать их в конце проектирования центрального модуля; • красная (R). Внедрить правила маршрутизации в дизайн центрального модуля в конце его проектирования. Вторая неопределенность связана с той частью центрального модуля, которая поставляется в готовом виде и не зависит от избранной альтернативы. Этот блок производят два конкурирующих вендора, повлиять на которых невозможно; более того, они анонсировали одну и ту же дату появления обновленного блока на рынке. Построение модели. Начать следует с отображения узла решения (обозначенного квадратом с номером 1), затем пририсовать к его правой стороне три ветви — по числу возможных проектных альтернатив — зеленую, желтую и красную (см. рис. 9.11). На конце каждой ветви нужно разместить случайный узел (?) (кружки с номерами 2, 3 и 4) и вывести из них по две ветви, каждая из которых представляет собой выход вероятностного события — появление на рынке первым вендора 1 или вендора 2. Стало видно, что за чем идет. Оценивание вероятности возможных результатов. Фактически блока еще нет. Надо оценить возможость. Субъективно. Возможность того, кто — вендор 1 или вендор 2 — поставит нужный блок первым. Исследования и опыт: вендор 1 поставит на рынок необходимую часть первым с вероятностью 60%, соответственно для вендора 2 эта вероятность составит 40%. Определение отдачи возможных результатов. Разная трудоемкость своих работ и разная трудоемкость включения сторонней части. Оцениваем в днях. Оценивание альтернатив и выбор стратегии. Чтобы оценить возможные выходы и дизайнерские альтернативы и выбрать тот вариант, который обеспечит кратчайшее расписание, необходимо решить дерево. Это – формализованная задача. Применение этих шагов выглядит следующим образом. Шаг 1. Ожидаемое значение для случайного узла 2: (0,60 · 60 дней) + + (0,40 · 50 дней) = 56 дней. Ожидаемое значение для случайного узла 3: (0,60 · 50 дней) + + (0,40 · 55 дней) = 52 дня. Ожидаемое значение для случайного узла 4: (0,60 · 55 дней) + + (0,40 · 55 дней) = 55 дней. Шаг 2. Наилучшая альтернатива — это альтернатива с наименьшим ожидаемым значением, то есть с наикратчайшим расписанием, равным в данном случае 52 дням. Следовательно, команда выберет желтую альтернативу. Анализ дерева решений позволяет не только выявлять наилучшие альтернативы. 12.3.3. Использование дерева решений Когда использовать. Практикующие менеджеры рассматривают дерево решений скорее как инструмент для работы с повседневными проблемами, требующими быстрого выбора наилучшей альтернативы. Иначе - комбинаторный взрыв. Трудоемкость. Можно описать две крайние ситуации. С одной стороны, построить и оценить дерево решений с двумя альтернативами и четырьмя путями вполне реально за 10—15 минут. Есть программы. Даже можно на Excel. Выгоды. Всё сводится к единому показателю, которым измеряется успех. Часто он денежный. И проникает в суть проблемы. Но субъективно. Преимущества и недостатки. Удоная визуализация, но непопулярно и сложно. Вариации. Можно использовать табличное представление. Но это менее наглядно. 12.4. Свод 13. Построение команды Рис. 10.1. Роль инструментов планирования команды в процессе стандартизованного управления проектами 13.1. Четырехстадийная модель создания проектной команды 13.1.1. Суть 1965 г., B. W. Tuchman [2]. Он идентифицировал 4 стадии, которые должна пройти любая группа в процессе трансформации в единую сплоченную высокопроизводительную рабочую команду: формирование, притирка (накал страстей), нормализация и (работа). Широко применяется. Рис. 10.2. Четырехстадийная модель создания проектной команды 13.1.2. Построение четырехстадийной модели Заполняется для каждого проекта. Подготовка исходной информации. Вовлечение всех заинтересованных сторон весьма важно! Важно их мнение. Заинтереснованные стороны появляются новые. Документирование структуры развивающейся проектной команды должно являться частью плана проекта, равно как и обновление этой документации по мере прохождения проекта через фазы жизненного цикла. Традиционные инструменты, такие, как 1) список задач, 2) матрица задач или матрица ответственности, 3) N мерная диаграмма взаимодействий, 4) устав проекта, могут быть полезны для документирования обязанностей по исполнению задач и их организационных взаимодействий, а также для доведения этой информации до сведения соответствующих лиц. Характеристики команды и лидерство во время развития команды. [3]. Рис. 10.3. Сопоставление стиля лидерства и уровня интеграции команды • Стадия формирования. Есть лидер и есть руководитель. Вожак упряжки – лидер, каюр – руководитель. Здесь работает руководитель. Собирает рабочую группу. Он может не разибраться в технике, но разбираться в управлении проектами. Пока получается набор людей. Беспорядок, недоверие. Нужны четкие указания, руководство, создание сильного имиджа, разделение точек зрения, непосредственного наблюдения и в значительной степени нисходящего принятия решений. • Стадия притирки. Собираем многих членов команды. Рабочая группа включается в работу. Начинают разбираться в ролях. Опасаются конфликтов, постепенно начинают доверять. Задают типичные вопросы. ТИПИЧНЫЕ ВОПРОСЫ, НА КОТОРЫЕ НЕОБХОДИМО ОБРАТИТЬ ВНИМАНИЕ НА СТАДИИ ПРИТИРКИ • Каковы конкретные цели, которые должны быть достигнуты этим проектом? • Кто отвечает за это? • Кому я подотчетен? Какого типа двойные обязанности я имею? • Каков приоритет проекта и каковы обязательства руководства перед ним? • Какие существуют каналы взаимодействия? • Процедур, планов или протоколов какого типа мы придерживаемся? • Какого типа обзоры проекта ожидаются и когда (в какие моменты жизненного цикла проекта) они возникают? • Какие факторы являются критически важными для успеха проекта? • Каковы наши роли и обязанности в части выполнения задач и взаимодействия с другими функциями? • Как происходит оценивание нашей производительности и кто выполняет это оценивание? • Работа в данном проекте является частью моего карьерного пути или отклонением от него? • Какого типа конфликтов можно ожидать и кто будет их разрешать? • Каким образом может происходить эскалация проблем (последовательный перенос проблем на более высокие уровни иерархии для их решения)? • Какого типа обучение и помощь доступны? • Каким образом мы будем поступать с рисками и неопределенностями? Начинает набирать силу стиль принятия решений, основанный на опыте, и лидерство, что дает менеджеру проекта возможность разделять полномочия с членами команды и поощрять способность к самостоятельной постановке целей и самоконтроль в широких пределах. Но надо продолжать процесс формирования команды. • Стадия функционирования. Команда – единое целое. Способна к самостоятельной постановке целей. Дваерие, уважение, лидерство, но еще нужна поддержка руководства. 13.1.3. Использование четырехстадийной модели создания проектной команды Когда использовать. Обычно на ранних фазах. Особенно для крупных, сложных и высокотехнологичных проектов. Конечный результат четырехстадийной модели — план развития команды. Трудоемкость. Есть разные задачи на разных фазах. • Начальное моделирование формирования команды и ее включения в работу. Менеджер проекта вполне может проделать это самостоятельно — продумывать вопросы и отмечать те, которые имеют критически важное значение, и требования. Требуемое время: 30 минут. • Детальное моделирование формирования команды и ее включения в работу. Эта процедура может быть выполнена рабочей группой. Мозговой штурм и бенчмаркинг предыдущих разработок команды приведут к созданию плана развития команды. Требуемое время: от 2 до 4 часов. • План развития, генерируемый командой. Участвуют все. Требуемое время: от 3 до 6 часов. Преимущества и недостатки. Предлагает шаблон процесса развития комакнды; вовлекает членной команды и руководствоб повышается от этого доверие, достигается понимание целей. Но. долго и нужны навыки. Возможны конфликты в борьбе за власть, ценности могут на совпадать, Адаптация четырехстадийной модели создания проектной команды. Должно соответствовать компании. Особенно чувствительны к культуре компании количество стадий и их названия. Например, изменение названия стадии II с «притирки» на «прояснение» или «старт» может привести к значительной разнице в части восприятия участниками целей, ожидаемого поведения и результатов. 13.2. Матрица заинтересованных сторон 13.2.1. Суть Была матрица ответствнности. Там были члены команды-люди или подразделения. Тут – все, и работники, и юрлица: головные организации, вспомогательные группы, эксперты, вендоры, заказчики, группы с особыми интересами и госорганы [4]. Матрица обеспечивает каркас для оценивания нужд и ожиданий всех основных заинтересованных сторон проектаБазовая структура матрицы заинтересован ных сторон показана на рис. 10.4. Рис. 10.4. Матрица заинтересованных сторон 13.2.2. Построение матрицы заинтересованных сторон Рис – тппично, годится как шаблон. Подготовка исходной информации. Источники информации – самые различные руководители высшего ранга, знакомые с конкретными областями сообщества заинтересованных сторон. Определяют их состав, степень влияния на успех проекта. Используют 4 балльную шкалу. Согласовываем с остальными документами, описывающими взаимодействие, такими, как список задач, матрица задач, N мерная диаграмма взаимодействий, а также с инструментами управления отношениями с заказчиками, используемыми в организации. Документируем. В дополнение к простому отображению влияний, оказываемых заинтересованными сторонами, может быть сгенерирована сетка влияния заинтересованных сторон, используемая для поддержки управления отношениями между заинтересованными сторонами, как показано в приводимом ниже заштрихованном прямоугольнике «Сетка влияния заинтересованных сторон». СЕТКА ВЛИЯНИЯ ЗАИНТЕРЕСОВАННЫХ СТОРОН Влияние различных заинтересованных сторон на параметры проекта может быть отображено еще одним способом — в виде сетки влияния заинтересованных сторон (см. рис. 10.5). Для каждой заинтересованной стороны данная сетка показывает соответствующую этой заинтересованной стороне (а) важность поддержки и (б) степень приверженности. В примере слева пузырьками А, В и С обозначены различные заинтересованные стороны, а размер пузырька показывает степень воспринимаемого влияния, которой обладает данная заинтересованная сторона. Сетка делит заинтересованные стороны на 4 основные категории: • «Находящиеся полностью в деле». Заинтересованные стороны, которые очень важны для успеха проекта и которые полностью привержены ему. • «Добросовестные возражающие». Заинтересованные стороны, которые очень важны для yспexa проекта, но которые не привержены ему. • «Искренние сторонники». Заинтересованные стороны, которые в высшей степени привержены проекту, но не очень важны для успеха проекта. • «Группа поддержки». Заинтересованные стороны, которые и не важны, и не привержены проекту. Как вариант сетка может показывать как существующее, так и желаемое положение дел. Сетка может использоваться для управления отношений между заинтересованными сторонами. Рис. 10.5. Сетка влияния заинтересованных сторон 13.2.3. Использование матрицы заинтересованных сторон Когда использовать. Лучше на ранних стадиях. Показывает игроков и их влияние. Трудоемкость. Матрица заинтересованных сторон может быть разработана в две стадии: • схематичное построение матрицы делает менеджер проекта за полчаса. • детальное построение матрицы. Это может быть выполнено небольшой группой лиц высокого ранга, знакомых с интерфейсами проекта. Полезно привелекать извне заказчиков, контракторов (подрядчиков). Требуемое время — от 2 до 4 часов. Выгоды. Взаимоотношения важны. Тут всё видно. Видно, какие нужнго создать условия. Меняем удовлетворение нужд на приверженность. Преимущества и недостатки. Хороший шаблон сводного представления для структуры взаимосвязей, управления взаимоотношениями, соблюдения стратегии компании, проактично разрешать конфликты. Но. Затраты времени, особенно на входные данные и построение, различное восприятие взаимоотношений бывает у участинков, не надо слишком доверять, надог обновлять. Вариации. Сетка влияния лучше. Иногда делают ранжирование. ПРОВЕРКА МАТРИЦЫ ЗАИНТЕРЕСОВАННЫХ СТОРОН Убедитесь, что матрица заинтересованных сторон надлежащим образом структурирована и эффективно применяется. Если это так, то вы должны быть способны: • Идентифицировать элементы для каждой оси матрицы: 1) заинтересованных сторон и 2) параметры проекта, после чего сгруппировать их по категориям. • Обозначить степень влияния заинтересованных сторон на различные параметры проекта. • Показать степень влияния символически или численно, не вдаваясь сверх меры в детали. • Разрабатывать матрицу в несколько шагов: первый шаг выполняется силами менеджера проекта и представляет собой рассмотрение заинтересованных сторон и параметров проекта, на втором шаге привлекаются ключевые члены команды и персонал, отвечающий за интерфейсы проекта. • Оси матрицы заинтересованных сторон должны быть согласованы с фактической организацией проекта. Адаптация шаблона, показанного на рис. 10.5, под конкретную ситуацию, абсолютно необходима. • Использовать матрицу как источник информации и катализатор для разработки более всесторонних карт интерфейсов и планов развития команды. • Вовлекать всю проектную команду в разработку матрицы и использовать окончательный документ совместно со всеми членами команды. • При применении матрицы основной акцент делать на управление отношениями, пересекающими организационные границы, механизмы обучения в организации и совершенствование. 13.2.4. Отображение организационных зависимостей Полезно. Видно, • В чьей поддержке и сотрудничестве мы нуждаемся? • Какие организационные конфликты существуют между заинтересованными сторонами? • Имеем ли мы необходимые обязательства со стороны группы поддержки, имеющей критическую важность для успеха проекта? • Кто будет разрешать те или иные конкретные проблемы? • Какие пути взаимодействия существуют между интерфейсами? • Какие средства мы имеем для того, чтобы повлиять на наших заинтересованных сторон? • Включили ли мы надлежащих людей из группы с особыми интересами АВС? • Как мы можем помочь в развитии влияния команды KLM? • Как мы можем достичь влияния на ресурс Q? • Как мы можем усилить взаимодействие по интерфейсу ITF? • Чье согласие нам необходимо для того, чтобы приступить к выполнению? • Кто является ключевыми лицами, принимающими решения, для данного релиза? • Чьего противодействия нам следует ожидать? • Какие отношения мы имеем с PQR? • Какие мы имеем альтернативы ресурсу X? • Как мы разделяем эту ответственность с XYZ? • Как эти люди оценивают нашу производительность? 13.3. Реестр навыков Есть знания и есть навыки. Теперь какие-то еще компетенции. 13.3.1. Что такое реестр навыков? Реестр навыков — это инструмент для систематической идентификации совокупностей навыков, необходимых членам проектной команды и их лидерам. Пример на рис. 10.6. ГРУППИРОВКА СОВОКУПНОСТЕЙ НАВЫКОВ ПО КАТЕГОРИЯМ ДЛЯ ЛИДЕРОВ ПРОЕКТОВ Сейчас всё сложно, горизонтальные связи, коммуникации, самостоятель ность. Лидеры проектов должны быть компетентны как в техническом смысле, так и в социальном, они должны понимать культуру и систему ценностей организации, в которой работают. Поэтому и есть эти категории. Технические навыки. Большая часть проектов включает в себя выполнение специализированных многофункциональных работ. Для лидеров уметь все делать ни необходимо, ни желательно. Но надо понимать технологии, рынки, бизнес-среду. Чтобы общаться, для оценивания рисков, поиска компромиссов в пространстве стоимости, сроков и технических аспектов. Административные навыки. Планирование, комплектование персоналом, бюджетирование, календарное планирование, измерение производительности и техники контроля. Но надо освобождаться от деталей. Навыки межличностного общения и лидерства. Способность четко руководить и отдавать указания, способность планировать и добиваться приверженности, навыки взаимодействия (общения), оказание помощи в решении проблем, эффективная работа с руководителями и персоналом поддержки кросс-функциональных линий и часто при малой формальных полномочиях или отсутствии таковых, навыки обработки информации, способность собирать и отфильтровывать относящиеся к ситуации данные, важные для принятия решений в динамичном окружении, и способность объединять отдельные запросы, требования и ограничения в такие решения, которые идут на пользу всему проекту. способность к разрешению межгрупповых конфликтов и построению многофункциональных команд. Стратегические навыки / бизнес-навыки. Эти навыки включают в себя способность видеть бизнес как целое, руководить им и отслеживать его общую эффективность. Они включают в себя такие компоненты, как понимание характера отрасли, общее чувство перспективы и деловая хватка. Решения в сфере политик, стратегическое мышление и долговременные цели Нужно для организационного управления и мобилизации организационных ресурсов. Знания в области теории систем, стратегического планирования и общего управления бизнесом. ПРОФИЛЬ ЛИДЕРСТВА МЕНЕДЖЕРОВ ПРОЕКТОВ • Сбор в одном месте нужной совокупности компетентных людей, которые впоследствии разовьются в команду. • Построение каналов взаимодействия между группами, решающими отдельные задачи, организациями поддержки, высшим руководством и сообществами заказчиков. • Развитие специфических навыков и построение организационных систем поддержки, необходимых проектной команде. • Координирование и интеграция многофункциональных рабочих команд и выполняемых ими операций в целостную систему. • Действия в условиях изменяющихся технологических требований и приоритетов при одновременной необходимости поддерживать направленность проекта и единство команды. • Действия в условиях беспокойства, борьбы за власть и конфликтов. • Работа с подразделениями поддержки: ведение переговоров, координирование, интеграция. • Действия в условиях технических сложностей. • Определение необходимых проектной команде людских ресурсов и ведение переговоров с целью их получения. • Поощрение риска, сопутствующего новаторскому подходу при том условии, что фундаментальные цели проекта не будут подвергаться угрозе. • Облегчение процесса командного принятия решений. • Развитие рабочей среды, стимулирующей профессиональный рост, — такой среды, в которой люди мотивированы на эффективную работу во благо установленных целей проекта. • Объединение людей с различными навыками и позициями в цельную рабочую группу, сфокусированную на решении единой задачи. • Поддержание в высшем руководстве вовлеченности, заинтересованности и стремления к оказанию поддержки. • Руководство многофункциональными группами, решающими отдельные задачи, с целью получения единого результата вопреки часто встречающимся сложностям организационных структур и систем контроля. • Поддержание руководства проектом и контроля за ним без подавления инноваций и творчества. • Обеспечение организационного каркаса для сплочения команды. • Обеспечение беспристрастного и справедливого вознаграждения отдельным членам команды либо оказание влияния для обеспечения такого вознаграждения. • Поддержание высокого уровня приверженности отдельных людей установленным целям и усилий на благо их достижения. Реестр навыков для персонала проекта, класс: менеджер проекта Категории и компоненты навыков Определение, применение и влияние (воздействие) Рейтинг критичности (от 1 до 4) Рейтинг способностей (от 1 до 4) План действий Технические навыки (категория I) Способность управлять проектом и его технологией Оказание помощи в разрешении проблем Взаимодействие с техническим персоналом Облегчение достижения компромиссов Поощрение новаторского окружения Интеграция технических, деловых и человеческих целей Способность к системному видению Доверие к техническим знаниям (подготовке) Понимание инструментов и методов поддержки инжиниринга Понимание технологий и трендов (тенденций) Понимание прикладных задач маркетинга и применение продукта Сплочение технической команды Административные навыки (категория II) Привлечение и удержание работников высокого класса Способность к эффективному общению (устному и письменному) Способность к эффективному делегированию обязанностей Оценивание ресурсов и ведение переговоров с целью их получения Измерение состояния и хода исполнения работ и производительности Минимизация изменений Планирование и организация многофункциональных программ Календарное планирование многодисциплинарных операций Понимание политик и рабочих процедур Работа (сотрудничество) с другими организациями Навыки межличностного общения и лидерства (категория III) Способность управлять в неструктурированной рабочей среде Ориентация на действия, способность к самостоятельной активации Оказание помощи при принятии групповых решений Оказание помощи в решении проблем Построение многофункциональных команд Создание имиджа лица, имеющего высокий приоритет Ясность управленческих инструкций Общение (письменное и устное) Обеспечение вовлеченности персонала на всех уровнях Формирование перспективной точки зрения Доверие Определение четких и ясных целей Способность к получению обязательств Получение поддержки и приверженности от высшего руководства Управление конфликтами Мотивация людей Понимание профессиональных нужд Понимание организации Стратегические навыки (категория IV) Построение альянсов, коалиций и достижение сотрудничества Способность работать в условиях рисков и неопределенностей Способность лидировать в многофункциональной лидерской среде Мотивирование и вдохновление других Ведение переговоров о ресурсах и мобилизация ресурсов Стратегическое мышление, планирование и применение решений Стиль мышления предпринимателя Понимание бизнес окружения Дальновидность Рис. 10.6. Образец реестра навыков для менеджера проекта. 13.3.2. Создание реестра навыков Для каждой категории работников. Сам в четырех категориях: понятно и иерархично. Данные на основе сужденийо том: 1) насколько важен каждый компонент навыков для производительности команды и успеха проекта и 2) каков уровень текущих способностей рассматриваемого класса персонала или отдельного лица. Несмотря на то, что в некоторых ситуациях для оценки рейтингов могут разрабатываться детальные шкалы, в общем и целом рекомендуется стремиться к простой шкале рейтингов. Пример – на основе Лайкерта-Ликерта: Рейтинг/ балл Критичность Способности 1 Маловажно или неважно Малые или отсутствующие способности 2 В некоторой степени важно Некоторые базовые способности 3 Очень важно Эффективный и умелый 4 Критически важно для успеха В высшей степени эффективный и умелый Есть еще 2 важных столбца, отмеченные жирным. Первоначальное построение. Определяем для категории работников: менеджера проекта, главного проектировщика, специалиста по маркетингу и т. д. Последующее применение. Шаблон (рис.) годится и для последующих проектов. При движении к топ-менеджменту преобладание и критичность навыков смещаются от «технических» в сторону «административных», а в конечном счете — в сторону «межличностного общения и лидерства» и «стратегических и деловых». Рис. 10.7. Относительное распределение совокупностей навыков Подготовка исходной информации. Оценки лучше из разных источников, кто больше знает. Реестр индивидуальных и групповых ресурсов. Реестры навыков могут разрабатываться и применяться по отношению к: • индивидуальным ресурсам, таким как менеджеры проектов; • группам, таким как группа НИОКР, группа разработки продуктов или проектная команда в целом; • отдельно для лидера и каждого из основных сегментов команды: НИОКР, разработка, производство. Доведение информации о реестре навыков до сведения соответствующих лиц. Документировать и обновлять. Нужна согласованность с остальными докумен тами, такими как устав проекта, список задач, матрица задач, а также с инструментами управления отношениями с заказчиками, используемыми в проектной организации. 13.3.3. Использование реестра навыков Когда использовать. На ранних стадиях. Для отбора. Время разработки. Перводначально. Всё, но главное – строки таблицы. 3…4 часа. Затем уточнение по текущему состоянию и планирование развития. 2…3 часа. Выгоды. Можно оценить факт. Тут полезно также потенциал для улучшения, действия, переоценка. Преимущества и недостатки. Шаблон, карта балльных оценок, Полезен для построения полной проектной команды, связывает ресурсы и бизнес-стратегии, помогает в идентифиации заинтересованных сторон, помогает обучению в масштабах организации. Но. Потроение требует времени и лидерских навыков, Трудно стандартизировать навыки, возможно разное восприятие, возможно неправильное использование в переговорах о ресурсах. Вариации. Можно применять для тестирования способностей, для тестированяи готовности команды, послепроектного анализа (что надо было), анализа зрелости системы управления проектами. Балл 1 … 10 Тест способностей для менеджеров проектов Используйте 10 балльную шкалу для выражения своего согласия или несогласия с каждым из нижепроводимых утверждений (1 = полное несогласие, 5 = нейтральная позиция, 10 = полное согласие) Личное желание быть менеджером 1. Управление людьми профессионально более интересно мне и в большей степени стимулирует меня, чем решение технических проблем. 2. Мне интересно, и я желаю принимать на себя новую и большую ответственность. 3. Я желаю вкладывать значительное время и прилагать значительные усилия для развития управленческих навыков. 4. У меня есть степень МВА (либо я активно работаю над ее получанием). 5. Я готов к тому, чтобы обновлять мои управленческие знания и навыки путем путем постоянного обучения. 6. Я рассмотрел специфические обязанности, проблемы и требуемые навыки. 7. Я определил свои конкретные карьерные цели и составил план их достижения. 8. Я бы хотел поменять область моей профессиональной деятельности на передовые благоприятные возможности в области управленческой деятельности. 9. Проблемы в сфере управленческой деятельности более интересны мне и сильнее стимулируют меня, чем технические проблемы. 10. Продвижение на более высокие ступени админитсративной лестницы в течение ближайших нескольких лет имеет наивысший приоритет и очень важно для удовлетворения моих профессиональных нужд Технические знания 1. Я понимаю технологические тренды как в своей области ответственности, так и в бизнес среде своей компании. 2. Я понимаю применение продуктов, маркетинговые аспекты и экономические условия в сфере моего бизнеса. 3. Я способен к эффективному взаимодействию с моими техническими коллегами из других дисциплинарных отделов. 4. Я могу сплотить техническую команду на достижение целей проекта и облегчить процесс группового принятия решений. 5. Я обладаю системной перспективой в области моей технической деятельности. 6. Я пользуюсь доверием в технической области со стороны своих коллег. 7. Я могу использовать новейшие технологии проектирования и инструменты инжиниринга. 8. Я распознаю работу, имеющую возможность технического прорыва, на ее ранних стадиях. 9. Я могу измерять статус работ / проекта и техническое исполнение других людей или своей команды. 10. Я могу объединять техническую работу членов моей команды Административные навыки 1. Я не возражаю против выполнения административных обязанностей. 2. Я знаком с методиками планирования, составления расписаний, бюджетирования, организации и управления персоналом и способен хорошо применять их. 3. Я могу эффективно оценивать ресурсы и вести переговоры о них. 4. Я могу измерять состояние и ход исполнения работ и подавать отчеты о них. 5. Я нахожу политики и процедуры полезным средством направления моих действий. 6. Я не вижу проблемы в том, чтобы делегировать работу, даже если сам я могу выполнить ее быстрее. 7. Я не возражаю против написания отчетов и подготовки к совещаниям, и я делаю это хорошо. 8. Я могу эффективно справляться с изменениями в требованиях и перерывами в работах. 9. Я хорошо себя проявляю в организации общественных мероприятий. 10. Я могу эффективно работать с группами административной поддержки по всей компании Навыки общечеловеческого общения 1. Я легко и свободно общаюсь с людьми из других технических и административных отделов. 2. Я могу эффективно решать конфликты по техническим и межличностным вопросам и не возражаю против участия в этом процессе. 3. Я могу работать (взаимодействовать) со всеми уровнями организации. 4. Я — хороший посредник в контактах с другими отделами и внешними организациями. 5. Мне нравится общаться с людьми. 6. Я могу уговорить людей делать то, что они изначально делать не хотят. 7. Я могу заручиться приверженностью других людей (обязательствами со стороны других людей), даже если они не отчитываются непосредственно передо мной. 8. Людям нравится работать со мной и следовать моим предложениям (указаниям). 9. Мои коллеги часто спрашивают моего мнения и просят представить их идеи высшему руководству. 10. Я думаю, что большинство людей в моем отделе выбрали бы меня на роль лидера команды Деловая проницательность 1. Я мог бы хорошо руководить операциями в моем отделе на благо достижения общих целей компании. 2. Я продуктивен. 3. Мне нравится заниматься долгосрочным планированием, и я нахожу время для этого. 4. Я готов принимать риски, связанные с исследованием благоприятных возможностей. 5. Я чувствую себя комфортно, работая в динамичном окружении, связанном с неопределенностями и изменениями. 6. Мне бы понравилось руководить своей собственной компанией. 7. Я рассматриваю себя в большей степени как бизнесмена, чем как рационализатора. 8. Исполняя общественные функции, я больше склонен к участию в деловых дискуссиях, чем в технических. 9. Мне нравится, когда меня оценивают как часть, на основе моего вклада в бизнес окружение моей компании. 10. Я был скорее прав, чем неправ, в предсказании бизнес окружения Общая оценка теста (деленная на 5) = нормализованный бал [ ] Рис. 10.8. Тест способностей для менеджера проекта ПРОВЕРКА РЕЕСТРА НАВЫКОВ Убедитесь, что реестр навыков структурирован надлежащим образом и эффективно применяется. Он должен включать в себя следующие компоненты. • Структура (конструкция) должна перечислять компоненты навыков, сгруппированные в категории навыков. • Компоненты навыков должны быть адаптированы к данной проектной ситуации. • Компоненты навыков должны быть рассмотрены / оценены по таким показателям, как степень критичности и степень текущих способностей (текущего обладания навыками). • Высший персонал проекта должен принимать участие в разработке реестра и проставлении балльных оценок в нем. • Требования к навыкам не должны подвергаться микроанализу. • Реестр следует использовать как источник информации и катализатор для создания плана развития команды. • К разработке реестра навыков следует привлекать всю проектную команду, и результирующий документ должен совместно использоваться всеми членами команды. • Применение реестра навыков должно концентрироваться на обучении в организации и совершенствовании. 13.4. Карта балльной оценки приверженности В русскоязычной литературе — матрица мотивации. — Прим. ред 13.4.1. Что такое карта балльной оценки приверженности? Все считают важным, но мало кто развивает и поддерживает. Тут работал Милошевич. Основная структура карты балльной оценки приверженности показана на рис. 10.9. 13.4.2. Построение карты балльной оценки приверженности Как показано на рис. 10.9, карта балльной оценки приверженности структурирована в виде, пригодном к непосредственному использованию. Она использует предварительно протестированные утверждения для измерения степени приверженности проекту и его целям. Утверждения разделены на 10 первичных и 25 вторичных, или производных, движущих сил, идентифицирующих наиболее общие компоненты, которые поддерживают и направляют как индивидуальную, так и командную приверженность. Для каждого утверждения в карте предусмотрено место для проставления оценки, полученной на основе суждения и согласованной со всеми заинтересованными сторонами. Образец карты балльной оценки, при веденный на рис. 10.9, состоит из двух подразделов: 1) восприятие лидера проекта и 2) восприятие команды проекта. Количество столбцов может быть увеличено для включения дополнительных заинтересованных сторон и их суждений. Для оценки утверждений предлагается 5-балльная шкала Ликерта, показанная ниже: —2 = сильно не согласен с утверждением —1 = не согласен с утверждением 0 = нейтральное отношение или не могу сказать + 1 = согласен с утверждением + 2 = сильно согласен с утверждением. В дополнение к оценке, полученной на основе суждения и согласованной со всеми заинтересованными сторонами, карта балльной оценки приверженности содержит еще два столбца: для 1) анализа проблем при достижении приверженности и 2) планов действий по усилению приверженности и повышению производительности команды. Подготовка исходной информации. Заполнить вопросник. Индивидуальное или групповое (???) суждение. Особо подчеркнем — при оценке командной приверженности вовлечение работающих над отдельными задачами групп или всей проектной команды в интерактивные групповые совещания способно принести наиболее осмысленные и реалистичные результаты. Такое вовлечение также способно помочь в создании здорового морального климата и построении взаимной уверенности, доверия и уважения — то есть того, что в конечном счете помогает усилить приверженность. Не верю. Расчет балльных оценок приверженности. Сумма. Первичные драйверы имеют весовой коэффициент в 2,5 раза выше, чем вторичные драйверы. Интерпретация балльных оценок приверженности. Учитывая весовые коэффициенты, получаемые на основе суждения оценки варьируются от —50 до +50 как для первичных, так и для вторичных драйверов. Соответственно, диапазон композитной оценки составляет от —100 до +100 баллов. Приводимая ниже интерпретация балльных оценок может указать вам на то, какой уровень приверженности имеет место в вашей ситуации. • Композитный балл отрицателен. Практически никакой приверженности не наблюдается у опрошенных людей. Неясные планы проекта, боязнь неудачи, недостаток стимулирования и интереса часто являются причиной недостатка приверженности. • Композитный балл 0—50. Имеется некоторая приверженность и огромный простор по ее увеличению. Ситуация типична для команды, находящейся в стадии притирки или только что вступившей в стадию нормализации. • Композитный балл 51—75. Это говорит о достаточно высоком уровне приверженности. Однако, следует нацелиться на его повышение путем развития команды. • Композитный балл свыше 75. Это говорит об очень высоком уровне приверженности проекту и обязательств перед командой. Лишь 10% всех проектных команд (15% всех лидеров проектов), протестированных нами, достигают такого уровня приверженности. Эффективное лидерство необходимо для подпитки и поддержания приверженности столь высокого уровня приверженности. Доведение информации о карте балльной оценки приверженности до сведения соответствующих лиц. Карта балльной оценки должна подлежать документированию отдельно от плана проекта и совместному использованию проектной командой и заинтересованными сторонами из руководителей. Он также служит в качестве инструмента для непрерывного развития команды, помогая поддерживать, подпитывать и хранить высокие уровни приверженности. 13.4.3. Использование карты балльной оценки приверженности Когда использовать. Особенно на ранних стадиях. Трудоемкость. Разработка карты балльной оценки приверженности представляет собой четырехступенчатый процесс, который может проводиться как индивидуально, так и силами группы: Шаг процесса Индивидуальная карта балльной оценки (требования ко времени) Групповая карта балльной оценки (требования ко времени) Шаг 1. Рассмотрение утверждения и его оценка 30 минут 2 часа Шаг 2. Расчет суммарных значений баллов 5 минут 10 минут Шаг З. Диагностика / анализ первопричины барьеров на пути к приверженности 30—60 минут 1—3 часа Рекомендации / план действий по устранению барьеров на пути к приверженности 1—3 часа 1—3 часа Выгоды. Диагностика. Акцент на важном. План развития. Преимущества и недостатки. Выгоды, шаблон для подведения итогов, дает план развития. Но. Долго, плохо стандартизируется, разное восприятие, не решает все проблемы только по балльной оценке. Н.П.: кто же будет говорить правду? Будут бояться, что просто уволят. Особенно те, которые что-то прочитали про менеджмент. Адаптация карты балльной оценки приверженности. Вопросник объясняет более 70% различий степени приверженности. Так что если менять, то надо подумать. Для вопросов давать без столбцов комментариев. Если пишем отчет, то надо соответствовать принятому формату отчетов (!!!). РЕКОМЕНДАЦИИ ПО ДОСТИЖЕНИЮ И ПОДДЕРЖАНИЮ ПРИВЕРЖЕННОСТИ (матрицы мотивации – ред.) Есть некоторые общие соображения. Ориентированное на людей влияние. Наиболее важные драйверы вытекают из самой работы, включая личный интерес, гордость и удовлетворение от работы, решение проблем профессионального характера, достижения и признание, равно как доверие, уважение и уверенность в лидере проекта. К другим важным факторам относятся эффективное горизонтальное взаимодействие между членами проектной команды и отделами поддержки, хороший командный дух, взаимное доверие, низкий уровень межличностных конфликтов, чувство персональной гордости, а также возможности карьерного развития, повышения квалификации и до некоторой степени гарантия занятости. Организационные процессы, инструменты и методы. Системы эффективного планирования и поддержки проекта, четкое взаимодействие, организационные цели и цели проекта, равно как и общее административное руководство (лидерство). Эффективная кросс-функциональная поддержка, совместные обзоры и оценивания исполнения, а также доступность необходимых ресурсов, навыков и производственных мощностей. Еще: структура команды, административная власть (полномочия) и ее разделение между членами команды и организационными единицами, автономность и свобода и, что более важно, техническое руководство и лидерство. Для руководства важно осознавать, что эти параметры влияют на восприятие командой рабочей среды, как то: организационной стабильности, доступности ресурсов, степени вовлеченности и поддержки руководства, персональных вознаграждений, организационных целей, задач и приоритетов, и, как следствие этого, оказывают прямое влияние на приверженность. Ориентированное на работу и задачи влияние. Персональные аспектами работы: интерес к проекту (заинтересованность в проекте), способность решать проблемы, минимизация рисков и неопределенностей, трудовые навыки и опыт. Важно объяснять цели, уодвлетворять нужды, короче, лидеры проекта должны быть способны привлекать и удерживать людей, обладающих правильными совокупностями навыков, подходящими для подлежащей выполнению работы. ПРОВЕРКА КАРТЫ БАЛЛЬНОЙ ОЦЕНКИ ПРИВЕРЖЕННОСТИ Убедитесь, что карта балльной оценки приверженности структурирована надлежащим образом и эффективно применяется. • Совокупность вопросов и их весов, как показано на рис. 10.7, должен рассматриваться как «стандартный», а его модификация должна являться исключением, но никак не правилом. • Вопросник должен содержать утверждения, разделенные на две группы: первичные и вторичные движущие силы приверженности, причем, каждая группа должна иметь свой вес. • Каждый инструмент рассмотрения должен содержать только один столбец с оценкой во избежание путаницы и необъективности. • По каждому вопросу должно быть вынесено суждение и выставлен балл после тщательного рассмотрения данного вопроса в контексте конкретной проектной ситуации. • Результаты обзора (данные, полученные в результате обзора), включая анализ и рекомендации, должны быть резюмированы (представлены в итоговом формате) согласно стандартизованному формату. • Результаты обзора карты балльной оценки должны быть совместно использованы всеми членами проектной команды. • Результаты обзора карты балльной оценки должны быть использованы как план и катализатор постоянного развития команды и организационного обучения в течение всего жизненного цикла проекта. 14. Документирование плана проекта Результаты стадии планирования проекта должны быть задокументированы и представлены для утверждения. 14.1.1. План проекта План проекта может включать в себя следующие основные разделы: Краткий обзор проекта; Введение; Цели и ожидаемые результаты проекта; Стратегия; Объем работ; Организационные связи; Ссылки на внешние документы; Структура проекта; Роли и ответственности; Процесс управления проектом; Обзоры и утверждения; Комплекс работ; Работы проекта, оценка объема работ и квалификации; Внешние задачи; Возможные изменения; График работ; График работ по этапам; Список вех; Ресурсное обеспечение; Персонал; Оборудование; Средства; Прочее; Финансирование; История финансирования подобных проектов; Бюджет; План затрат; Фонды; Предположения; Ограничения, риски и неопределенности проекта; Зависимости от внешних проектов/событий; Риски и неопределенности; Процесс решения проблем. Информация в удобной форме. Надо провести все исследования для выяснения неточностей. Надо, чтоб руководство согласилось (и подписало) все соглашения по поставкам и ресурсам, вехи, проуедуры. После подписания изменения должны согласовываться и документироваться. Двусторонние подписи. Планирование закончено, начинается исполнение. Конец части 1