Планирование объекта

Лекция 4 . Планирование проекта Цели и задачи планирования проекта. Структурный план проекта. Процессный план проекта Проекты необходимо тщательно планировать, чтобы вопреки множеству воздействующих факторов достичь желаемого успеха проекта. Планирование проекта устанавливает ход его выполнения Общее содержание планирования проекта наглядно представлено на рис. 1. Поскольку на начальном этапе детали проекта еще не известны, то начинают с грубого планирования, а затем по мере прогресса проекта его все более детализируют. Планирование проекта представляет собой динамический процесс, результаты которого постоянно проверяются, актуализируются и уточняются. Рисунок 1 – Содержание планирования проекта Результаты планирования проекта являются существенной основой для принятия решений, и прежде всего, для решения о его проведении. Очень часто, особенно в больших проектах, возникают значительные отклонения по ходу проекта. Это порой приводит к сомнению в целесообразности планирования вообще. Фактом же является то, что отклонения становятся видимыми только при сравнении фактического состояния с планом. Поэтому необходимо найти баланс между обязательностью планов и достаточной гибкостью, чтобы не держаться за них тупо, когда в связи с изменениями или появившейся новой информацией целесообразнее их изменить. К примеру, понятно, что поставленные задачи по разработке нового изделия должны быть скорректированы, если конкурент в это время вышел на рынок с изделием, которое превосходит по своим характеристикам разрабатываемое. Планы существуют не ради самих планов, а для того, чтобы достигать целей. Если они своевременно помогают не пойти по ошибочному пути, то они свою задачу уже исполнили, даже если их приходится при этом заменить на новые. Увеличенные затраты времени на планирование обычно с лихвой окупаются меньшей общей продолжительностью проекта и меньшими общими затратами. Опыт создания военной техники показал также, что к моменту, когда 1 закончено планирование прототипа изделия и еще ничего не изготавливалось, уже предопределено 85 % будущих затрат на его разработку, изготовление, эксплуатацию и ремонт . Аналогичное соотношение справедливо не только для крупных военных разработок, но и для малых изделий гражданского назначения. Очень важно, чтобы в планировании проекта принимала участие вся команда проекта. Даже прекрасно составленный план, спущенный сверху, будет встречен скептически. Члены команды обычно желают быть успешными в работе, и все их протесты и сомнения по поводу плана работ, как правило, имеют под собой достаточно серьезные основания и должны быть внимательно рассмотрены. Исполнителям могут быть известны многие специфические детали работ и условия их выполнения, которые даже опытный планировщик может упустить. Кроме того, причастность членов команды к планированию приводит к тому, что они воспринимают планы как свои и готовы брать на себя ответственность за их соблюдение. Планирование начинается с описания структуры проекта, то есть описания состава входящих в проект работ и взаимосвязей между ними. Деление проекта на целесообразные и обозримые частичные задачи является существенным шагом в начале процесса планирования. Поскольку на начальном этапе детали проекта еще не известны, то начинают с грубого планирования, а затем по мере прогресса проекта его все более детализируют. Исходным и главным плановым документом, служащим основанием для всех остальных планов, является структурный план проекта. Структурный план проекта Структурный план проекта (WBS – Work Breakdown Structure) представляет собой стройную иерархическую декомпозицию проекта на составные части (элементы, модули), необходимые и достаточные для планирования и контроля осуществления проекта для различных участников проекта. Как следует из этого определения, структурный план проекта (СПП) представляет собой основной стержень для всех частей проекта и всех его участников. Иногда его называют также «планом планов» СПП используется в основном для реализации следующих целей: структурирования технических и административных плановых документов проекта, контроля над ходом выполнения проекта, установления графика отчетности, структурирования проектной документации, распределения работ между участвующими в выполнении проекта фирмами и между структурными подразделениями предприятия, создания баз данных по проекту. Деление проекта на составные части необходимо, чтобы каждая составная часть могла отдельно планироваться, управляться и контролироваться (рис. 2). Последняя, далее не декомпозируемая в структурном плане проекта задача (т.е. находящаяся на последнем уровне декомпозиции), носит название рабочего пакета или просто работы. Она должна быть точно определимой, контролируемой и четко ограниченной, а также относящейся к совершенно определенным ответственным за нее подразделениям или лицам. Этим определяется требуемое число уровней иерархии. Для небольших проектов может быть достаточно трех уровней, в то время как для больших и сложных проектов нередко требуется шесть и даже семь уровней. Работы с высокой степенью риска приходится порой разбивать до мельчайших деталей, чтобы спланировать 2 меры по их уменьшению. Прежде чем вкладывать в проект значительные инвестиции, необходимо его детально рассмотреть (рис. 2) и принять решение о целесообразности инициации проекта. Рисунок 2 – Структурирование проекта Желательно, чтобы по времени выполнения рабочие пакеты были по возможности относительно короткими. Это уменьшает потребность оценки степени выполнения по ходу работ. Установление состояния проекта становится возможным на базе законченных рабочих пакетов. Необходимо с самого начала выбрать подходящую цифровую систему кодирования работ. Коды работ могут быть использованы в течение всего проекта как уникальные индикаторы для самых разных целей: для определения ответственных за них лиц, отнесения издержек, отслеживания хода работ, отчетности. Весьма желательно, чтобы система кодирования была совместима с используемой системой управленческого учета, что существенно упрощает контроль издержек проекта. Большинство современных программных средств автоматически генерируют коды работ в процессе составления СПП. При этом они оказываются одинаковыми при планировании и контроле времени и издержек. Базой планирования является проектное/техническое задание (ТЗ). Особенно важно составление технического задания по инвестиционным проектам. В. А. Дьяченко по этому поводу пишет : «1. Без Техзадания вы никогда не сможете объективно сравнить результаты тендера, так как окажется, что один подрядчик имел в виду одно, а другой – совсем другое. 2. Без Техзадания (подписанного подрядчиком, которого вы выбрали) вы никогда не докажете подрядчику, что он что-то не сделал или сделал не так, как вы хотел 3. Без Техзадания вам никогда не получить близкую к реальности калькуляцию стоимости объекта до того момента, пока этот проект не выполнен» [8]. Прежде чем приступить к декомпозиции и детальному планированию, составитель плана должен ознакомиться с имеющейся информацией, из которой важнейшей является формулировка цели и ее описание. Желательно, чтобы она была представлена в форме технических требований (ТТ) и всегда в виде письменного документа. В технических требованиях на разработку материального продукта как минимум должны быть зафиксированы следующие данные 58: 3 идентификация продукта (название, обозначение, номер) с коротким пояснением применения. Целесообразно указать также родственные продукты (свои или чужие), а также родственную группу продуктов; цели маркетинга, которые предполагается решить с помощью разработки (группы потребителей, объем производства, целевые рынки по отраслям и регионам, имидж, уровень претензий); предварительные представления о цене и издержках; функциональные требования (техническая концепция): - принцип работы, рабочие области, - данные по рабочим характеристикам, граничные значения, допуски, - условия приемки; размеры и вес: - форма, конструктивные размеры, положение и функции подвода энергии, - места и конструктивные требования к точкам подключения энергии, газа, воды, стоков; условия эксплуатации, включая условия окружающей среды (например, для страны, в которую продукт предполагается экспортировать); конструктивные требования: - удобство обслуживания, доступность, - условия ухода, возможность ремонта, - возможность разборки на вторичное сырье, - системы контроля; требования по безопасности: - безопасность в эксплуатации, - защита от нанесения вреда, защита от шума, - условия ликвидации, защита окружающей среды. Начиная планирование проекта, следует сразу зафиксировать известные опорные даты. К ним относятся промежуточные и конечные сроки выполнения проекта, например предусмотренные договором. Они могут быть заданы как в виде точной даты, так и в виде интервала времени. Кроме того, они могут быть выражены в виде пожелания либо в виде твердо установленного договорного срока, в экстремальном случае с соответствующими финансовыми (или иными) санкциями за их нарушение. Следующая существенная для планирования информация касается различных ограничений, например информация по вопросам получения разрешений от различных инстанций. При этом следует уяснить, какие виды деятельности могут быть начаты только после получения таких разрешений. Для обзорности в качестве первого шага планирования составляется список известных к данному моменту частных задач (табл. 1). Таблица 1 4 Структурирование проекта может осуществляться по различным принципам: по объектам/предметам, например по изделиям, по видам деятельности или функциям, по фазам проекта, в виде комбинации из двух или трех вышеназванных подходов. Схема деления структурного плана проекта должна по возможности соответствовать естественному делению рассматриваемой системы. Предметная структуризация (рис. 3) не предоставляет достаточно информации для формирования рабочих пакетов Рисунок 3 - Предметная структура СПП Для формирования рабочих пакетов лучше подходит структурирование по видам деятельности или по функциям (рис. 4). Для малых, легко обзорных проектов зачастую достаточно структурировать СПП по видам деятельности, но многим проектам требуется большая детализация. Для них часто используется комбинированное структурирование СПП (рис. 5). Не существует единого, пригодного на все случаи жизни структурного плана, и, соответственно, нет и патентованных рецептов, каким образом выбрать оптимальный структурный план для конкретного проекта. Он зависит от вида проекта, установившихся традиций на предприятии и его организационных структур, а также от руководителя и команды проекта. 5 Рисунок 4 - Структурирование СПП по видам деятельности Структурный план проекта не рекомендуется составлять в один «проход». Он развивается циклично от грубого (в качестве первого эскиза) до все более детального плана. В каждом цикле появляются дополнительные представления о взаимосвязях, и наряду с другой информацией это дает основу для дальнейшей детализации. Порой становится очевидным, что первоначально выбранное деление целесообразнее заменить другой структурой, поскольку она лучше подходит для наглядного представления дальнейшей работы над проектом. Как правило, тщательная работа на этом этапе окупается за счет экономии времени и усилий на последующих этапах планирования и выполнения проекта. Уточнить структурный план проекта позволяет также анализ рисков. Дело в том, что должны быть выделены не только действия, связанные с подлежащими выполнению работами, но и действия, связанные с рисками и мерами противодействия им. Подход с позиций рисков особенно полезен для социальных проектов (работа с молодежью, проблемы безработицы и др.). Для этих проектов, в отличие, скажем, от строительства дома, нельзя уже на ранних этапах сказать, что необходимо сделать, и уж совсем невозможно оценить требуемые для этого время и средства. Если же подойти к делу с другой стороны и поставить вопрос о том, какие риски могут помешать достижению поставленной цели, то очень быстро можно выйти на действия, способные предупредить провал проекта. 6 Рисунок 5 - Комбинированный СПП В конечном счете СПП должен быть составлен так, чтобы: − весь проект мог быть описан как сумма всех элементов; − могло быть выполнено детальное планирование проекта; − могли быть определены издержки и бюджет проекта; − могли отслеживаться время, издержки и выполнение предметной области (работы); − цели могли быть логическим образом увязаны с ресурсами компании; − могли быть установлены процедуры контроля хода выполнения проекта; − могла быть установлена ответственность за каждый элемент проекта. Структурный план проекта содержит базовую информацию для всех дальнейших частных планов – организационного, временного, ма-териального снабжения, ресурсного, плана издержек, финансового. К сожалению, универсального алгоритма, который позволял бы абсолютно надежно идентифицировать все составные части проекта, до сих пор создать не удалось. На первом этапе целесообразно составить укрупненный структурный план проекта, ограничившись первой ступенью иерархии работ. Для дальнейшей декомпозиции структурного плана командой проекта могут быть применены обычные инструменты: 7 мозговой штурм, картографирование мыслей и др. Большую помощь могут оказать также различного рода вопросники. Даже весьма тщательное выполнение этой работы не может исключить риск пропуска существенных элементов проекта (порой с тяжелыми последствиями), однако сводит его к минимуму. В результате должен быть составлен по возможности полный список работ проекта. Каждый рабочий пакет должен иметь хозяина и быть четко описан. В общем случае описание пакета должно содержать: название проекта и фамилию руководителя проекта; название рабочего пакета; идентификационный номер пакета; описание пакета; фамилию ответственного за пакет и/или его непосредственного исполнителя; точное описание цели пакета; срок выполнения и время раннего начала и раннего окончания работы; технические и материальные предпосылки для реализации пакета; оценку объема работ; потребные ресурсы; если известны предшественники и последователи пакета, то фамилии их ответственных с указанием, с кем должен быть установлен контакт. Для описания пакетов может быть подготовлен бланк или заведены отдельные файлы. Для небольших единичных проектов часть вышеприведенных пунктов может быть опущена. Уровень детализации структурного плана должен быть таким, чтобы для каждого конечного рабочего пакета мог быть определен конкретный исполнитель (или организация), для которого дальнейшая детализация не требуется. При этом следует убедиться, что каждый исполнитель знает состав своего пакета и действительно достаточно компетентен для его качественного выполнения. К примеру, ответственный за пакет «Регистрация участников конференции» должен принять решения о том, когда, где и как будет проводиться регистрация, кто будет ее вести, обеспечить место регистрации мебелью, анкетами, раздаточными материалами, указателями «Регистрация участников конференции», передать итоги регистрации в президиум, организовать запись на экскурсии, а материалы передать для архивирования. Если имеются малейшие сомнения в том, что ответственный знает досконально весь объем работы по пакету и способен оценить затраты времени и ресурсов, может потребоваться введение следующего уровня иерархии СПП. Объем действий или операций, объединяемых понятием «работа», обычно соразмеряют со связанным с ним риском (как в отношении времени, так и в отношении затрат). Так как риск большой работы трудно оценить и еще труднее с ним управляться, каждому руководителю проекта следует стремиться к тому, чтобы раздробить работы до определенного уровня. Этот уровень определяется достижением обзорности работ. В результате риск оказывается достаточно хорошо просчитываемым. Далее лица, ответственные за работы, должны позаботиться об этих рисках с помощью соответствующих предупредительных мер. В отдельных случаях для пакетов, сопровождаемых большим риском, может быть целесообразна их дальнейшая детализация с позиций менеджмента рисков. В СПП в блок «Завершение проекта» целесообразно также сразу включить работу по оценке уроков проекта, а также заключительные мероприятия (ликвидация структур проекта, решение судьбы человеческих и материальных ресурсов, оформление заключительных финансовых и технических документов, архивирование, проведение заключительного собрания, награждение участников и т.п.). 8 На практике нередко возникают недоразумения по поводу структурного плана проекта и его организационной структуры. Обе структуры действительно являются организационными инструментами, однако служат различным целям. Структурный план проекта касается содержания проекта (что необходимо сделать?), а проектная организация касается организации работ (кто должен это делать?). Поэтому СПП нельзя рассматривать как органиграмму. Представленные в СПП иерархические уровни (ступени входимости) не идентичны уровням организационной структуры даже в том случае, когда имеется большое сходство. Должно быть выдержано правило: для каждого элемента СПП и для каждого рабочего пакета имеется ответственная единица (но только одна) в органиграмме. С другой стороны, та же единица (работник, подразделение) может быть ответственной за выполнение ряда элементов или рабочих пакетов СПП. Процессный план проекта Планирование процесса выполнения проекта (Project Logic Evaluation – PLE) осложняется тем обстоятельством, что многие работы связаны с выполнением других работ. Процессный план содержит информацию о том, какие работы связаны между собой и как их следует располагать во времени с учетом этих зависимостей, и. может быть представлен в виде графа (рис. 6) или таблицы (табл.2). Рамки проекта могут быть уточнены путем документирования процессов выбора Рисунок 6 – План процесса приготовления чая Часть этих причин почти не поддается управлению, другие же в определенных рамках могут быть изменены либо путем переговоров, либо за счет дополнительных затрат. Одни работы могут выполняться параллельно, другие же могут начинаться и выполняться только после полного или частичного завершения других работ 9 Таблица 2 10 Определить все взаимосвязи в объемных и сложных проектах возможно только при систематическом подходе к их определению. На практике используются два основных метода. Наиболее употребительным является способ, в котором начинают с конца проекта и идут шаг за шагом к его началу. Для каждой определенной работы определяют все предшествующие действия (работы), которые должны быть завершены, чтобы можно было приступить к выполнению данной работы. Другой, менее употребительный способ заключается в том, что начинают с первой от старта проекта работы и определяют все последующие работы, к которым можно приступать. Разработка плана процесса выполнения проекта осложняется еще и тем, что часто последовательность выполнения некоторых работ можно изменять. С одной стороны, это усложняет планирование, но, с другой стороны, за счет перестановки работ можно достичь оптимизации процесса выполнения проекта как с точки зрения времени, так и с точки зрения эффективного использования человеческих и материальных ресурсов. Далее следует иметь в виду, что даже если ряд работ может выполняться параллельно, в реальности может существовать (и, как правило, всегда существует) ограничение по ресурсам. Это может привести к изменению исходной логической последовательности работ. Так в примере, приведенном на рис. 6, три работы после старта могут выполняться одновременно (у них нет предшественников). Однако если чай готовит 11 один человек, у него просто не хватит рук (ограничение по ресурсам). Поэтому две работы он будет выполнять в период кипячения воды. Для небольших и простых проектов процессный план может быть составлен без привлечения программных продуктов. Но даже для относительно несложных проектов полезно применить достаточно простые программные продукты, например программу MS Project. Для больших и сложных проектов может потребоваться использование более мощных программных пакетов. Удобно вначале составить укрупненный процессный план проекта, а затем постепенно разворачивать каждый блок. Литература: 1. Заренков, В.А Управление проектами: Учебное пособие.-2-е изд-е – М.: изд-во АСВ;СПб.:СпбГАСУ,2006.-312с 2. Дульзон A. A. Управление проектами: учебное пособие / А. А. Дульзон; Национальный исследовательский Томский политехнический университет. – 3-е изд., перераб. и доп. – Toмск : Изд-во Томского политехнического университета, 2010. – 334 с. : ил. 3. Управление проектами / В. Д. Шапиро и др. СПб.: ДваТрИ, 1996. 610 с. 4. Archibald Russel D. Managing High-Technology Programs and Projects. – New York: John Wiley & Sons, 1976. 5. Мир управления проектами: основы, методы, организация, применение / под ред. Х. Решке, Х. Шелле. – М., 1994. 6. Руководство кСводу знаний по управлению проектами Третье издание (Руководство PMBOK®) 7.Управление проектами: Основы профессиональных знаний, Нацио-нальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0) / Андреев А. А., Бурков В. Н, Воропаев В. И.,Дорожкин В. Р., Дубовик М. Ф. ,Миронова Л. В.,Палагин В. С., Полковников А. В., Секлетова Г. И., Титаренко Б. П., Товб А. С., Трубицын Ю. Ю., Ципес Г. Л.; СОВНЕТ. – М., 2010. 8. Дьяченко В. А. Организация промышленного инвестиционного проекта: краткое пособие для «промбоцманов» / В. А Дьяченко. – Уфа, 2000. 12