Организация планирования и управления проектами в строительстве

Андреева Анастасия Олеговна
ФГБОУ ВПО «Магнитогорский Государственный технический университет им. Г.И.Носова»
студентка

Аннотация
Планирование – одна из важнейших составляющих управления проектами. От качества планирования во многом зависит результат всего начинания. Данная тема важна для современного мира, так как большая часть бизнеса основывается на выполнении проектов. В данной статье будут рассмотрены методы, способствующие эффективному планированию проектов. Так же будет приведен сравнительный анализ этих методов, благодаря которому менеджер проекта может выбрать более подходящий для себя.

Abstract
Planning — one of the most important components of project management. The quality of the planning depends largely on the result of the whole undertaking. This topic is important for the modern world, as most of the business is based on the implementation of projects. This article will examine methods for facilitating efficient planning projects. There will also be a comparative analysis of these methods by which the project manager can choose more suitable for you.

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

Библиографическая ссылка на статью:
Андреева А.О. Методы эффективного планирования проекта // Экономика и менеджмент инновационных технологий. 2015. № 3 [Электронный ресурс]. URL: https://ekonomika.snauka.ru/2015/03/7579 (дата обращения: 05.10.2022).

В современном мире деятельность успешных организаций заключается в выполнении проектов. Проекты могут осуществляться в любой области деятельности, например, разработка программного средства, проведение предвыборной компании, проектировка оборудования и прочее.

Планирование – это то, с чего начинается любой проект. Планирование является одним из главных процессов управления проектом, определяющим во времени все работы по осуществлению проекта. Таким образом, планированию следует уделять много внимания и усилий. В большинстве случаев провальность проектов заключается в том, что менеджер отнесся к планированию пренебрежительно.

В настоящее время существует множество методик для эффективного планирования. Эти методики помогают корректировать планирование, находить более оптимальные варианты, выявляют узкие места в проекте. Однако некоторые методики имеют большую популярность среди менеджеров проектов, а другие никак не используются.

Методами эффективного планирования занимались многие исследователи[1,2,3,4,5,6 и др.]. Однако, анализ состояния проблемы эффективного планирования проекта, показывает, что на долю успешных проектов приходится всего 47%, доля рискованных проектов в 37%, из них: 25% – восстановленные, 12% – провальные и доля закрытых проектов равная 6%. Среди причин неуспешности проектов, планирование занимает 4 место, тем самым подтверждая свою значимость. От качества планирования во многом зависит результат всего начинания[7,8 и др.].

Проблемы планирования объясняются следующим:

— недостаточно данных для планирования проекта;

Проектная Среда СОВНЕТ: Современные методы управления проектами в строительстве

— недостаточное внимание к определенным аспектам проекта, вследствие чего не все учтено, недостаточно деталей;

— плохая осведомленность о работах, проводимых в проекте, как следствие ошибочные расчеты при планировании.

Для устранения проблем с планированием используется ряд подходов:

1. Теория расписаний (ТР) – это раздел исследования операций, в котором строятся и анализируются математические модели календарного планирования различных целенаправленных действий с учетом целевой функции и различных ограничений. Содержательно многие задачи ТР являются оптимизационными. Для решения задач ТР необходимо разработать алгоритм решения. Основная цель при исследовании задач ТР – это построение эффективных, то есть быстрых, алгоритмов решения[4].

2. Метод планирования проектов – Диаграмма Ганта. Предназначена для иллюстрации этапов работ проекта. У каждой работы указываются сроки выполнения, дата начала и окончания работы, связи между работами, а на самой диаграмме все работы показываются в виде полосок, соединенные стрелками, на этих полосках показан процент выполнения работы и назначенные на нее ресурсы. Визуализация значительно облегчает работу менеджеру проекта.

3. Сетевые методы планирования так же являются графическим отражением работ проекта. Изображается сетевой граф – схема, состоящая из вершин соединенных между собой дугами. Вершины – это работы проекта (события), дуги – это последовательности работ.

По формулам просчитываются такие показатели, например, как: критический путь, ранний срок наступления события, поздний срок наступления события, резерв времени. Далее на графе указываются просчитанные показатели. Так же можно проводить оптимизацию сетевых планов.

4. Метод Pert – это способ анализа времени, которое требуется для выполнения каждой из работ. Этот метод позволяет определить минимальное необходимое время для выполнения проекта. По данному методу можно строить сетевые диаграммы, наподобие тех, что рассматривались выше, а можно и провести оценку сроков проекта: оптимистическую, пессимистическую и реальную. Все показатели просчитываются по формулам.

5. Эвристические методы оптимизации. Эвристические методы обеспечивают выявление, обработку и упорядочение системы закономерностей, механизмов и методологических средств конструирования нового задания и целеустремленных способов деятельности на основе обобщения прежнего опыта и опережающего отражения моделей будущего с целью решения поставленной задачи наиболее эффективно.

Некоторые эвристические методы оптимизации функций:

— искусственные иммунные системы;

— метод перекрестной энтропии.

Помимо этого был создан ряд эффективных эвристических методов календарного планирования:

— метод «Сглаживание»[9,10 и др.].

6. Метаэвристические методы оптимизации. К наиболее эффективным и популярным эвристическим методам относятся так называемые метаэвристики – обобщенные стратегии поиска оптимума в пространстве решений. Начальная их реализация как правило достаточно проста и позволяет быстро получить практический результат.

Некоторые метаэвристические методы:

— алгоритм имитации отжига;

— муравьиные алгоритмы[11,12,13,14 и др.].

В ходе исследования был проведен сравнительный анализ (см. табл.1).

Таблица1 – Сравнительный анализ методов планирования проектов

Название метода

Плюсы

Минусы

1. Возможность составления оптимального расписания из большого количества работ

1. Сложный для понимания способ;
2. Выполнение математических расчетов

1. Визуализация проекта;
2. Значительное облегчение работы менеджера проекта при планировании

1. Негибкость, при изменении каких – либо факторов в проекте всю диаграмму приходится перерабатывать

1. Визуализация проекта;
2. Возможность просчета разных сроков наступлений событий;
3. Возможность проведения оптимизации

1. Проведение математических расчетов;
2. При визуализации требуются пояснения

1. Тройная оценка, сразу видно чего ожидать в худшем случае, а к чему нужно стремиться;
2. Существует показатель, показывающий достоверность оценки

1. Формулы приближенные, получается оценка близкая к средним значениям

1. Способность обработки работ большой размерности;
2. Нахождение приемлемого решения в ситуациях любой сложности

1. В эффективности уступают точным алгоритмическим подходам;
2. Находит не всегда эффективное решение

1. Позволяют исследовать большое пространство поиска для нахождения решения близкого к оптимальному;
2. Короткие сроки нахождения решения

1. Более затратные по сравнению с другими методами;
2. Сложны в применении

Все методы по-своему эффективны, у них есть плюсы и минусы, каждый метод хорош в разных направленностях и особенностях проекта. Но некоторые из них более популярны среди менеджеров проектов по объективным причинам, которые можно отследить по сравнительному анализу. Один из главных критериев – визуализация.

Люди значительно лучше воспринимают информацию, представленную визуально, так как на осознание такой информации уходит меньше времени, представление о ней не нужно додумывать самому, она уже есть перед глазами. Так же доказанный факт, что зрительная память работает лучше. Другой немаловажный критерий – простота использования. В современном мире важно время.

От времени зависит успешность и заработок. Чем проще использовать метод планирования, тем быстрее пройдет этап планирования проекта и начнется выполнение самого проекта.

Связь с автором (комментарии/рецензии к статье)

Оставить комментарий

Вы должны авторизоваться, чтобы оставить комментарий.

https://ekonomika.snauka.ru/2015/03/7579″ target=»_blank»]ekonomika.snauka.ru[/mask_link]

Процессы планирования

PMI, PMBoK. Группа процессов планирования

Группа процессов планирования состоит из процессов, осуществляемых для определения общего содержания работ, постановки и уточнения целей и разработки последовательности действий, требуемых для достижения данных целей. В процессах планирования разрабатываются план управления проектом и документация проекта, которые будут использованы для выполнения проекта.

Комплексный характер управления проектами порождает цепочки обратной связи для дополнительного анализа. По мере поступления и осмысления большего объема информации или характеристик проекта может потребоваться дополнительное планирование. Значительные изменения, происходящие на протяжении жизненного цикла проекта, приводят к необходимости вновь вернуться к одному или нескольким процессам планирования, а, возможно, и к процессам инициации. Эта последовательная детализация плана управления проектом часто называется «планированием набегающей волной» (“rolling wave planning”), что указывает на то, что планирование и документирование – повторяющиеся и постоянно идущие процессы.

Разработка плана управления проектом – это процесс документирования действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов. План управления проектом определяет, как будет исполняться проект, как будет проводиться его мониторинг, контроль и закрытие. Содержание плана управления проектом различается в зависимости от прикладной области и сложности проекта. План управления проектом разрабатывается в рамках серии интегрированных процессов до завершения проекта. Результатом данного процесса является план управления проектом, который постепенно разрабатывается путем внесения обновлений, контролируется и утверждается в процессе Осуществления общего управления изменениями.

Разработка плана управления проектом: входы

Устав проекта

Выходы процессов планирования

Выходы многих процессов планирования, интегрируются для создания плана управления проектом. Любые базовые и вспомогательные планы управления, являющиеся выходами других процессов планирования, являются входами для данного процесса. Кроме того, обновления данных документов могут привести к корректировке плана управления проектом. План управления проектом – это совокупность всех проектных планов.

Возможный состав плана управления проектом:

Корректировка «плана управления проектом» – осуществляется в течение всего проекта, в ответ на изменившиеся внешние условия, реализовавшиеся риски и т.д. Предсказать, где и когда понадобятся изменения заранее невозможно, посему их не планируют заранее, а осуществляют при помощи механизма «контроля изменений».

Процесс первоначальной разработки плана может быть точно регламентирован и предполагает четкую последовательность шагов. Один из вариантов «лучшей практики»:

• Определение самой процедуры планирования
• Собрать и финализировать требования
• Сформировать концепцию (scope)
• Принять решение «что закупаем»?
• Определить команду
• Создать ИСР (иерархическую структуру работ) (WBS)
• Создать перечень действий (activity list)
• Создать сетевую диаграмму (network diagram)
• Оценить требуемые ресурсы
• Оценить продолжительность действий и стоимость
• Сформировать расписание
• Создать бюджет
• Планировать качество – создать метрики
• Создать план улучшения процессов
• Распределить роли и ответственности
• Создать план коммуникаций

Спланировать управление рисками, идентифицировать риски, качественный анализ, количественный анализ, планировать реагирование на риски.

Многие элементы «планов» уже прорабатывались во время инициации и были включены в устав, то-есть уже создавались грубые (ROM), высокоуровневые оценки. Они годились для предварительных договоренностей со спонсором, но совершенно не подходят для коммуникаций с командой и контроля выполнения работ.

В ходе планирования первичные оценки последовательно уточняются и корректируются. Здесь очень важным моментом моментом является соотношение проектной документации и договорной.

Каждая организация по-своему строит свою работу по заключению договоров и контрактов. Как правило, наблюдается некий компромисс между необходимостью «подстраховаться» (уточняя планы) и «не работать бесплатно» (ведь пока контракт не подписан, всю вашу деятельность по инициации и планированию проекта оплачивает ваш высший менеджмент).

Планирование содержания

• устав проекта
• состав «плана управления проектом»

Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить конечный результат (продукт).

Для описания всех необходимых работ по проекту нужно: определиться с требованиями и ожиданиями заказчика, разобраться, какие из них реально выполнимы, и что для этого понадобится, то-есть:

Формирование концепции и создание ИСР (WBS) разделены еще двумя этапами из других областей знаний.

Первый шаг (собрать и финализировать требования) неявно включает в себя два компонента: дальнейшее выявление заинтересованных лиц и собственно сбор требований.

Собрать и финализировать требования – один из наиболее трудоемких и плохо формализуемых процессов. Все что известно сейчас – крупноуровневые требования, зафиксированные в уставе.

Чтобы конкретизировать их необходимо понять, кто является источником требований на проекте и что он конкретно хочет получить по окончании работ.

Крайне опасно на данном этапе поддаться искушению «назначить» ответственным за все требования спонсора или заказчика. Кто бы ни подписал наш устав, а, в дальнейшем, и контракт на выполнение работ – он никогда не станет единоличным источником информации о требованиях.

Лучшие проектные практики гласят:

• проект с неудовлетворенными ожиданиями заказчика не является успешным
• проект, результаты которого не используются конечными пользователями, не является успешным

Выявление заинтересованных лиц началось еще в фазу инициации, теперь оно должно быть продолжено и результатом должен стать реестр заинтересованных лиц. Пример такого документа:

Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.

По какому принципу можно отнести того или иного человека к «заинтересованным лицам»:

1. Это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
2. Заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае нельзя пренебрегать их интересами в проекте!).
3. Начальники членов вашей команды.
4. Те, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.
5. Последняя группа заинтересованных лиц – наиболее трудна к выявлению, однако порой вклад таких «серых кардиналов» очень велик. В качестве примера можно привести гипотетическую ситуацию, когда сын заказчика является в его глазах авторитетом в сфере информационных технологий и привлекается отцом к принятию принципиальных решений о внедряемых системах. При этом сын не является сотрудником ни одной из участвующих в проекте организаций (или, допустим, вообще еще школьник). Однако высказанные им советы имеют для папы больший вес, чем экспертные заключения его же сотрудников. Возможно, «добраться» до такого «заинтересованного лица» в ходе проекта вам и не удастся, но, знать (или, хотя бы, предполагать его существование) – достаточно важно.

В реестр можно включать большое количество людей — всегда можно классифицировать их по «степени влияния на проект» позднее и работать только с самыми главными. Сейчас важнее никого не забыть (ибо влияние заинтересованного лица не проекте, со временем, может и возрасти).

Далее предстоит выбрать один или несколько методов «вытягивания» из заинтересованных лиц их ожиданий и требований .

Выбирая методы, необходимо тщательно взвесить потребности в информации и способности второй стороны ее предоставить.

Из наиболее распространенных можно выделить:

Интервью – является одним из самых надежных методов, он же – самый трудозатратный. Непосредственное общение позволяет собрать наиболее полную и достоверную информацию, а также установить конструктивный рабочий контакт с собеседником. Главный минус – трудозатраты (вам придется тратить свое и чужое время в больших количествах). Кроме того – с некоторыми заинтересованными лицами общение может оказаться невозможным по причине их «статусности» (так, не всегда возможно уговорить топ-менеджмент компании-заказчика уделить вам часок-другой на очной встрече, даже если это в интересах проекта).

Опросники – это хороший способ быстро собрать информацию с множества людей (к тому же предоставив им вводить информацию в удобное для них время). Увы, у метода масса недостатков, главные из которых: «однобокость» собранной информации, высокая вероятность формального подхода к заполнению анкет (по принципу «чтобы отстали»).

Мозговой штурм – весьма условно можно назвать «коллективным интервью». Проведенный по определенным правилам, мозговой штурм может оказаться крайне эффективным. Однако помните, что некоторым людям трудно общаться даже в небольших коллективах – чтобы они не «отмалчивались» и не стеснялись в высказываниях, развивайте навыки ведения подобных мероприятий.

Прототипирование – это прекрасный способ собрать или уточнить требования. Под прототипом мы можем понимать любой понятный вашему собеседнику образ продукта (будь то картинка, макет или какой-либо аналог). Прототипирование удобно сочетать с другими техниками (например, интервью); главное не ограничиваться только им, дабы не упустить существенные моменты, не реализованные в прототипе, но важные для продукта.

После того, как процесс запущен, и требования стали поступать – необходимо фиксировать их. Для этого рекомендуется обзавестись выделенным списком, называть его можно «матрицей требований». Пример такого документа приведен в Приложении3.

Матрица позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор.

Осуществляя сбор требований и заполняя матрицу, мы не пытаемся с ходу принять решение, «беремся ли мы за их реализацию в данном проекте, или нет». Проще говоря – собираем «все, что есть» (в рамках разумного, конечно). На этом этапе заинтересованным лицам не дается никаких обещаний. Происходит только сбор требований и ожиданий (последние также превращая в требования с помощью авторов). И по мере того, как сбор требований завершается – необходимо приступить к их «балансировке» (т.е. оценке того, что войдет в проект).

Проектные практики призывают собрать все требования, которые могут относиться к проекту и только после этого двигаться дальше.

Многие методологии разработки ПО обосновано считают строгую последовательность «спланировал» – «сделал» – «показал» – «сдал» (без демонстрации промежуточных результатов заинтересованным лицам и регулярной корректировки исходных планов) злом, повышающим риски провала.

Сбор требований в рамках начального планирования должен быть разумно-глубоким и максимально широким. Однако речь не идет о том, что на этом работа с требованиями должна прекратиться, а их список оказаться «фиксирован» до конца проекта. Работа с ожиданиями заказчика, накопление его согласия, корректировка планов в течение всего жизненного цикла проекта – основа проектного управления.

Иногда процесс первоначального сбора требований оказывается столько трудоемким и растянутым во времени, что целесообразно выделить его в отдельный проект.

Факторы среды предприятия

Факторы среды предприятия, которые могут оказывать влияние на процесс разработки плана управления проектом, включают в себя, среди прочего:

• государственные и промышленные стандарты;
• информационные системы управления проектами (например, автоматизированные средства, такие как программное обеспечение для управления расписанием, система управления конфигурацией, система сбора и распространения информации или веб-интерфейсы к другим автоматизированным системам, работающим в режиме онлайн);
• организационную структуру и культуру;
• инфраструктуру (например, существующие сооружения и капитальное оборудование);
• управление персоналом (например, директивы по найму и увольнению, оценки эффективности работы сотрудников и документы об обучении).

Б алансировка требований – отбор требований, реализация которых предполагается в рамках проекта.

Процесс балансировки основан на сочетании интуиции и здравого смысла. Сначала необходимо приоритезировать требования (выделяя наиболее значимые), а затем отобрать к реализации те из них, которые возможно уложить в рамки проектных ограничений (стоит помнить, что некоторые требования могут оказаться взаимосвязаны и включать или исключать их из треугольника можно только вместе).

На данном этапе возможны лишь предварительные (грубые) оценки стоимости и сроков проекта и пока неизвестно точно, сколько «будут стоить» и длиться отдельные работы. В своих текущих оценках необходимо полагаться на профессиональный опыт и чутье (свое и команды).

Позже, когда себестоимость и продолжительность работ будет оценена, можно вернуться к этой части плана и скорректировать ее (возможно, от каких-то требований придется отказаться или пересмотреть). Однако важно понимать – процесс балансировки требований не должен противоречить уставу проекта. Если в уставе, прописано как одно из главных требований к продукту – скорость реакции интерфейса не более чем за 0,5 секунды, то нельзя выбросить подобное требование из реестра (его невыполнение похоронит проект).

Технически балансировка может представлять простановку соответствующих отметок в матрице требований. Результаты сбора и балансировки можно утвердить у заинтересованных лиц проекта. Необходимо продумать заранее – нужно ли получать подтверждение, в какой форме.

Де-факто, матрица требований (а также схемы и описания, на которые она ссылается) представляет собой техническое задание. Однако на практике ТЗ – это статичный документ, который является неотъемлемой частью некоторых видов контрактов.

Именно статичность технического задания делает его неудобным для всех заинтересованных лиц проекта. Правильно организовав работу с требованиями, снижается риск «промахнуться мимо ожиданий заказчика» (одновременно и прислушиваясь к ним весь проект, и отсекая невыполнимые). ТЗ может оказать обратный эффект.

Активы процессов организации, которые могут оказывать влияние на процесс разработки плана управления проектом, включают в себя, среди прочего:

• типовые руководящие указания, рабочие инструкции, критерии оценки предложений и критерии измерения исполнения;
• шаблон плана управления проектом – элементы плана управления проектом, которые могут быть обновлены, включают, среди прочего:

руководящие указания и критерии для адаптации набора стандартных процессов организации с целью удовлетворения конкретных потребностей проекта;
руководящие указания или требования к закрытию проекта, например критерии подтверждения и приемки продуктов;

• процедуры управления изменениями, включающие действия, согласно которым будут модифицироваться официальные стандарты компании, политики, планы и процедуры или любые документы проекта, а также порядок одобрения и подтверждения любых изменений;
• архивы по прошлым проектам (например, базовые планы по содержанию, стоимости, расписанию и измерению исполнения, календари проектов, сетевые диаграммы проекта, реестры рисков, запланированные ответные действия и определенные последствия рисков);
• историческую информацию и базу накопленных знаний;
• базу знаний по управлению конфигурацией, содержащую версии и базовые планы по всем официальным стандартам компании, политикам, процедурам и любым документам проекта.

Разработка плана управления проектом: инструменты и методы

Экспертные оценки

При разработке плана управления проектом экспертные оценки используются для:

• адаптации процесса для удовлетворения требований проекта;
• разработки технических и управленческих деталей, которые будут включены в план управления проектом;
• определения ресурсов и уровней развития навыков, необходимых для выполнения работ по проекту;
• определения уровня управления конфигурацией, который будет применяться в проекте;
• определения того, какие документы проекта будут подвержены процессу формального управления изменениями.

Разработка плана управления проектом: выходы

План управления проектом

План управления проектом интегрирует и консолидирует все вспомогательные планы управления и базовые планы, полученные в результате процессов планирования, и включает в себя, среди прочего:

• выбранный для проекта жизненный цикл и процессы, которые будут применяться в каждой фазе;
• результаты адаптации, полученные от команды управления проектом, а именно:

процессы управления проектом, выбранные командой управления проектом;
уровень реализации каждого выбранного процесса;
описания инструментов и методов, которые будут использованы для выполнения данных процессов;
порядок использования выбранных процессов для управления конкретным проектом, включая зависимости и взаимодействия между данными процессами, а также необходимые входы и выходы;

• порядок выполнения работ для достижения целей проекта;
• план управления изменениями, документирующий порядок мониторинга и контроля изменений;
• план управления конфигурацией, документирующий порядок управления конфигурацией;
• порядок поддержания целостности базовых планов исполнения;
• потребности в коммуникации между заинтересованными сторонами проекта и методы ее реализации;
• ключевые мероприятия по анализу управления в отношении содержания, границ и сроков, облегчающие рассмотрение проблем и решений, ожидающих принятия.

План управления проектом может быть составлен как на уровне сводки, так и в деталях, и может состоять из одного или нескольких вспомогательных планов. Каждый из вспомогательных планов детализован до той степени, которая требуется для конкретного проекта. После утверждения плана управления проектом он может изменяться только после того, как будет создан запрос на изменение и одобрен в рамках процесса осуществления общего управления изменениями.

Базовые планы проекта включают в себя, среди прочего:

• базовое расписание;
• базовый план выполнения стоимости;
• базовый план по содержанию.

Вспомогательные планы включают в себя, среди прочего:

Часто базовые планы по содержанию, расписанию и стоимости объединяют в базовый план измерения исполнения, используемый в качестве общего базового плана проекта, с которым может сравниваться общее исполнение. Базовый план измерения исполнения используется для измерения освоенного объема.

Источник: www.smlogic.ru