что влияет на сложность проекта
Классификация и характеристика сложности проектов
Рубрика: Экономика и управление
Дата публикации: 15.01.2020 2020-01-15
Статья просмотрена: 4464 раза
Библиографическое описание:
Галимзянов, М. Д. Классификация и характеристика сложности проектов / М. Д. Галимзянов. — Текст : непосредственный // Молодой ученый. — 2020. — № 3 (293). — С. 332-333. — URL: https://moluch.ru/archive/293/66323/ (дата обращения: 11.12.2021).
Ключевые слова: управление проектами, классификация проектов, сложность проекта, КСУП.
Прежде, чем подходить к вопросу формирования проектной команды на предприятии надо решить один из таких важных вопросов, как классифицировать все проекты по степени сложности, т. к. именно от этого основополагающего фактора будут зависеть подходы к решению тех или иных технических или организационных вопросов касательно корпоративной системы управления проектами [2].
Исходя из того, какими уровнями сложности будут обладать выполняемые на предприятии проекты, будет формироваться проектная команда, ответственная за тот или иной проект, или же портфель проектов. Для проектов, отличающихся низкой сложностью, характерно формирование команды в рамках экономии ресурсов, только самые важные члены, которые, по прогнозам руководителя проекта смогут гарантировать успех его выполнения. Для проектов, уровнем выше команда формируется в соответствии с компетенциями проекта. При формировании паспорта проекта будут учитываться все необходимые ресурсы и, разумеется, в условиях наличия тех или иных ресурсов, руководитель проекта будет формировать команду, стараясь максимально заполнить её теми специалистами, которых он сочтёт нужными. В случае, когда сложность проекта имеет максимально высокий уровень, а следовательно, и наивысший приоритет, процесс побора проектной команды в некоторых случаях может занимать весьма существенный отрезок времени, т. к. в данном случае важно подобрать такую команду, которая могла бы даже в условиях ограниченных ресурсов, сжатых сроков и высокой сложности отдельных задач, справиться с установленной при формировании проекта задачей с учётом всевозможных рисков и факторов.
Разумеется, формирование проектной команды будет только одной из особенностей, которые учитываются в зависимости от сложности проекта. К остальным можно также отнести:
– формирование проектного бюджета;
– оценка степени значимости проекта;
– уровень и фактор влияния рисков;
– модель управления и взаимодействия со стейкхолдерами;
– анализ оценки результатов;
– метод методики подхода к решению отдельных проектных задач и др.
Для того, чтобы понять, каким проект является по сложности, существует модель классификации проектов, которая призвана выделить все уровни сложности. Сам процесс оценки сложности в упрощенном виде представлен в таблице 1 [1].
Классификация проектов
По масштабу (размеру) проекта
По срокам реализации
По требованиям к качеству и способам его обеспечения
По совокупности проектов
По уровню участников
По характеру целевой задачи
По объекту инвестиционной деятельности
По главной причине возникновения проекта
Необходимость структурно-функциональных преобразований
Технически-сложным признаются проекты, в которых частично неизвестна технология получения результата, или же имеется ряд трудностей в техническом плане различного рода для реализации проекта.
Организационно-сложным является проект, в котором много участников, либо члены проектной команды территориально разнесены (могут находится в разных регионах, городах, странах), для их контроля требуются дополнительные инструменты и затраты.
Комплексно-сложный проект заключает в себе совокупность проблем и организационного, и технического плана.
Простым проектом считается тот, в котором проектная команда уже реализована и имеет опыт в работе своим составом и у которых не возникало проблем с реализацией проекта. Почти все многоразовые команды (за исключением поправок на специфику и сферу бизнеса) считают командами простых проектов, деятельность которых должно быть отлажена и поставлена на поток [3].
В данном случае сложные проекты подразумевают под собой наличие неких ресурсных, организационных или технических задач, для решения которых предполагается внедрение нетрадиционных или необычных подходов, а также повышения уровня затрат на их решение. В современной практике также встречаются варианты усложненных проектов, где наблюдается повышенное влиянием, какого-либо из описанных выше видов сложности — углубленные схемы финансирования, значительное увеличение участников проекта, использование нетрадиционных технологий исполнения и многое другое.
Следует также отметить, что не так давно «Центр оценки и развития проектного управления» предоставил свою модель и степень оценки сложности проектов. По его классификации для каждого из типов сложности присущи и характерны свои факторы сложности, с которыми в процессе работы проектной деятельности связаны типичные проблемы управления. Для каждого из таких видов и факторов определяются примерные параметры, на основании которых тому или иному проекту присваивается оценка сложности в бальной системе:
0 — низкая сложность;
1 — средняя сложность;
2 — высокая сложность.
Проект будет считаться сложным в том случае, если по параметрам сложности наберёт сумму баллов не менее трёх (если, например по одному из критериев сложность оценивается как «высокая», ещё по одному — «средняя»). По их системе легко определить в какой степени сложности проект будет ранжироваться и оцениваться. Определять числовые показатели проекта должен руководитель проекта или его непосредственное начальство [4].
7 причин провала проекта и как этого избежать
Мы все были в такой ситуации. Вы начинаете быть очень увлечены проектом, продумываете, проводите исследования, хорошенько планируете, собираете хорошую команду и приступаете к работе. А потом где-то по пути все разваливается. Сроки просрочены. Результаты не оправдывают ожиданий. Заказчики и начальство, мягко говоря, недовольны. Почему?
Но почему так много проектов с таким огромным потенциалом заканчиваются провалами?
Проект становится неудачным, если он не выполняет то, что требовалось, в рамках согласованного бюджета и времени. Однако в большинстве случаев заинтересованные стороны решают, был ли проект успешным или неудачным, на основании их суждений и удовлетворенности результатом.
Общие причины провала проекта:
Некоторые проекты также считаются провальными, если они не соответствуют финансовому прогнозу или не достигают целевого показателя рентабельности инвестиций.(прочитать подробнее можно о ссылке)
Есть ряд причин, и хорошая новость заключается в том, что вы можете устранить каждое препятствие и добиться успеха в следующем проекте (а также в следующем и последующем) с помощью руководства по управлению проектами, управляя проектами.
Вот некоторые причины неудач проекта и то, что вы можете сделать, чтобы изменить ситуацию.
Один из способов практически гарантировать провал проекта — начать работу без четких целей и задач проекта. В конце концов, невозможно узнать, добились ли вы успеха, если вы не совсем уверены в том, чего пытаетесь достичь.
Возьмем простой пример на личном уровне. Допустим, вы решили «привести себя в форму». Что это значит?
Хотите сбросить несколько килограммов? Нарастить мышечную массу? Развить выносливость?
Если вы просто начнете тренироваться и / или лучше питаться — что мы все должны делать, если честно, — ваше физическое состояние улучшится, но вы не будете точно знать, добились ли вы успеха. Вам нужны четко определенные цели. Неясные цели в профессиональной жизни также могут привести к неудаче.
Как этого избежать:
Существует несколько популярных структур для постановки целей, таких как цели SMART и CLEAR, но суть в том, что ваши цели должны быть измеримыми и реалистичными. Не просто говорите, что хотите «похудеть», скажите, что вы хотите похудеть на 15 килограмм за следующие четыре месяца. Это измеримо и реально. Проекты, которыми вы управляете, более сложны, поэтому еще более важно четко определить свои цели.
Планируем сроки. Планируем встречи. Планируем структуру и темы и интерфейсы. Но иногда, в разгар всего этого планирования проекта, мы забываем спланировать наши ресурсы. Это большая причина того, почему проекты терпят неудачу. Управление проектами включает управление ресурсами, часто с учетом других проектов. Большинство из нас знает, что планирование финансовых ресурсов важно.
Вот несколько вопросов, которые вы можете задать при планировании других ресурсов в вашем следующем проекте:
Какие человеческие ресурсы требуются? Какие люди и как долго? Кто-нибудь из них в настоящее время работает над другим проектом или их можно будет отозвать до завершения моего проекта?
Какие средства необходимы? Есть ли у нас офисные помещения, столы, компьютеры, конференц-залы и производственные помещения, необходимые для успеха этого проекта?
На каких сторонних поставщиков мы будем полагаться? Каковы их временные рамки и ограничения?
Каких ресурсов знаний нам может не хватать? Могу ли я пригласить эксперта или провести обучение, чтобы развить у моей команды необходимые навыки управления проектами?
Независимо от того, насколько хорошо спланирован ваш проект, отсутствие прозрачности может быстро привести к провалу. Очень важно создать систему, которая обеспечивает видимость не только для руководителя проекта, но и для всех членов команды. Видимость включает в себя прозрачность проекта статуса задачи, четкую коммуникацию и хорошее управление документами.
Как этого избежать:
Когда все знают статус каждой задачи проекта, они могут помочь или внести соответствующие коррективы. Он поощряет активную работу и решение проблем. Управление документами не должно быть сложным. Фактически, наличие централизованного цифрового хранилища для всех проектных документов облегчает вашу работу в качестве менеджера проекта, а также способствует наглядности.
Само собой разумеется, но общение в управлении проектами является ключевым. Инструменты, которые ваша команда использует для общения, должны быть объяснены и реализованы с самого начала вашего проекта.
Как этого избежать:
Будь то электронная почта, текстовые сообщения, чат или другое сочетание вещей, убедитесь, что все в команде понимают, чего от них ждут, и могут использовать выбранную вами технологию. Помимо метода коммуникации, убедитесь, что вы установили четкие ожидания и руководящие принципы в отношении видов информации, которую необходимо передать.
Поначалу это кажется таким невинной причиной. Простой запрос клиента на добавление элемента сюда, блестящая идея для расширения услуги там, и, прежде чем вы это узнаете, объем вашего проекта перерос, а ваша команда чрезмерно расширена. Вот и все, произошел полный перевес задач над настоящими требованиями и происходит отклонение от цели.
Параметры проекта не были четко определены с самого начала или
существует внутреннее давление со стороны команды или извне со стороны заказчиков или руководителей, чтобы они взяли на себя задачи, которые не были частью первоначального плана проекта.
Как этого избежать:
Проблема смещения объема работ заключается в том, что оно часто приводит к провалу проекта. Вы не предусмотрели в бюджете время или ресурсы, необходимые для выполнения дополнительных задач, поэтому то, что могло быть ошеломляющим успехом, оборачивается разочаровывающей неудачей.
Иногда замаскированные под нереалистичный оптимизм нереалистичные ожидания разрушили многие проекты. Руководителю проекта необходимо иметь четкое представление о том, чего ваша команда может достичь и в какие сроки. Как только вы согласовали свои ожидания с реальностью, вы должны сообщить о них покупателю, а зачастую и своему начальству.
Как этого избежать:
Имея реалистичные ожидания и понимаемые всеми участниками проекта, ваша команда имеет гораздо больше шансов на успешное завершение проекта.
Лидерство имеет решающее значение и является общей точкой успеха или неудачи. Менеджер проекта не может жаловаться на то, что команда вышла из-под контроля. И команда не должна оставлять чувство, что они не знают, что делать или чего ожидать от одного дня до следующего — это огромный рецепт неудачи. Убедитесь, что все знают, чего от них ждут, и возложите на них ответственность за достижение этих целей или выполнение этих задач. Подавайте пример — если вы не опаздываете на собрания, членам вашей команды тоже нет оправдания!
Если вы делаете все возможное, чтобы хорошо руководить командой, но у вас есть члены команды, которые постоянно отстают, не отвечают на отзывы и что-то просто не работает — тогда вы все равно обязаны поднять флаг, который вам нужно заменить члена команды или членов команды и подтолкнуть к этому. Менеджер проекта, который отрицает свое собственное лидерство, не сможет заслужить уважение и поддержку со стороны членов своей команды, и, скорее всего, ему будет труднее управлять кораблем.
Оценка и восстановление провалившегося проекта может быть одной из самых сложных задач для менеджера проекта в организации. Однако отдача может быть огромной, поскольку проект, реализованный в результате неудачи, может принести фирме значительную ценность. Семь факторов, описанных в этом документе, имеют решающее значение для оценки производительности неудачного проекта и планирования корректирующих действий, чтобы сделать проект успешным. Для успеха необходимы все семь факторов. Когда один фактор становится отрицательным и не исправляется, катастрофа неизбежна.
Риски проекта и все, что нужно о них знать
Вряд ли вам встречался проект, который волшебным образом шел в точности, как его запланировали в самом начале. Любой проект подвержен рискам — всевозможным событиям, которые на него влияют и обычно создают проектному менеджеру головную боль. Вообще, если не считать планирования, главная головная боль проектного менеджера как раз и заключается в разрешении рисков. Чтобы уменьшить ее, можно подумать об угрозах заранее. Оно того стоит — управлять рисками куда дешевле и проще, чем управлять реальными проблемами. Об этом и расскажем в статье: как правильно работать с рисками при управлении проектами и почему это важно.
Что такое риск
Если вам предстоит запустить проект, рано или поздно вы задумаетесь, что в нем может пойти не так. Вы начнете предугадывать слабые места проекта. Это и есть риски. Риск проекта — это неопределенное событие или условие, которое положительно или отрицательно влияет на цели проекта. Например, цель — закрыть проект, не превышая бюджет. Тогда любые события с непредвиденными расходами будут считаться риском. Или цель — создать качественный продукт раньше конкурента. Тогда есть риск опоздать с запуском или потерять проверенного поставщика и проиграть в качестве. Как только у проекта появляется цель, пора подумать о факторах, которые могут ей помешать.
Обычно риски возникают не просто так — к ним приводят действия участников проекта или они появляются из-за внутренних и внешних условий. Скажем, из-за плотной занятости руководителей проекта или плохой организации внештатных сотрудников.
Но иногда риски проекта бывают позитивными. Часто это удачные случайности или неожиданные результаты работы с негативными рисками. Представьте, что вы перестраховались и заложили в бюджет трудозатраты сотрудника-заместителя. Теперь если ваш ключевой сотрудник вдруг заболеет, а заместитель окажется эффективнее его, показатели улучшатся. Такие риски головной боли не приносят, но и встречаются очень редко. Поэтому управление рисками нужно в первую очередь для негативных событий.
Зачем управлять рисками
Управление рисками проекта — это страховка, с помощью которой можно вовремя спасти важную составляющую проекта, будь то деньги, время или даже уровень качества продукта. К тому же, профилактические меры часто выходят дешевле и быстрее решения возникших проблем. Пример рисков проекта: вы боитесь, что в середине проекта заказчик изменит требования — вам придется все переделывать и расширять бюджет. Подумайте об этом заранее. Уже на первом этапе вы можете согласовать подробное ТЗ и обговорить условия для пересмотра требований. Потратив пару дней на такую страховку, вы защитите проект от крупных задержек и сэкономите ресурсы.
По большому счету для любого риска есть два решения: игнорировать его и надеяться на лучшее или сразу попытаться устранить. Если надежда оправдается, первый вариант принесет выигрыш. Но для этого нужна скорее удача, чем расчет и планирование. В противном случае это просто принятие риска со всеми его последствиями — потерями в деньгах, времени или качестве.
Второй вариант — разрешение риска, ряд действий, чтобы снизить или устранить вероятность опасного события. Разрешение риска обычно требует дополнительных ресурсов и тщательного анализа. Но с ним проектному менеджеру немного спокойнее — проходит головная боль, появляется уверенность и защищенность. Этот вариант подходит для угроз, которые значительно выгоднее предотвратить, чем разбираться с негативными последствиями.
Получается, главная проблема и вместе с тем задача в управлении рисками — найти баланс между затратами на страховку и потенциальным ущербом от принятия риска.
Какие риски проекта самые опасные
Управление рисками проекта начинается с анализа. Предполагается, что к этому моменту вы уже знаете, какие риски проекта могут возникнуть на проекте, а лучше — имеете готовый реестр рисков. О том, как составить реестр, мы уже рассказывали в нашем журнале. Для начала можете просто сделать таблицу с рисками, их причинами и последствиями.
Задача анализа — сравнить сэкономленные ресурсы, если риск был принят, но не реализовался, с затратами на его разрешение. Оценка должна быть всесторонней, поэтому проводится в два этапа: сначала качественный, а потом количественный анализ.
Качественный анализ рисков проекта
Во время качественного анализа выбираются самые опасные и приоритетные угрозы. То есть все риски проекта делятся на важные и второстепенные. Критерии оценки руководитель выбирает самостоятельно, в зависимости от целей. Обычно решающие факторы — вероятность и возможные последствия.
Например, всегда есть опасность природных катаклизмов, скажем, наводнения. Но реальный риск существует только для производства в определенных географических районах — близко к воде. Для полноценного анализа этой угрозы нужно как минимум изучить статистику таких ЧП и посчитать потенциальный ущерб. Так, для производства в сухих районах риск маловероятен. Поэтому даже несмотря на большой потенциальный ущерб, нет смысла тратить на этот риск ресурсы.
Для определения вероятности рисков распределите их по шкале вероятности. Она может быть относительной или с цифровыми значениями.
Оценка последствий — подсчет потенциального ущерба проекту, например, расходы на зарплату сотруднику-заместителю или процент качества продукта. На универсальной шкале воздействие риска расположить сложно: ущерб зависит от целей проекта. Попробуйте записать последствия в виде таблицы, соотнося угрозы с целями.
Результаты качественного анализа ложатся в основу количественного.
Риски проекта — количественный анализ
На этот этап попадают наиболее вероятные и опасные риски. При плохом сценарии они напрямую угрожают целям проекта. Задача количественного анализа — выявить негативное влияние главных рисков и распределить их по степени этого влияния.
При количественном анализе, в отличие от качественного, значения определяются точно. Выделить высокие и низкие риски проекта недостаточно. Для оценки используются разные способы от анализа ожидаемой денежной стоимости (ОДС) до создания дерева решений.
Здесь вам может понадобиться помощь экспертов. Используйте опыт и знания сотрудников или внешних специалистов. Постоянно пересматривайте оценку, так как условия реализации проекта и его специфика могут меняться.
Управление рисками проекта — сложная область знаний со своими методиками и инструментами. Для углубления в нее можно почитать Руководство к своду знаний по управлению проектами — PMBOK. Там подробно описаны все необходимые методы управления рисками проекта, в том числе инструменты для качественного и количественного анализа.
Как найти выход
Главная цель работы с рисками — выбрать и применить верную стратегию управления. Какие риски проекта как лучше решать, подскажет тщательный анализ. Для каждого риска можно подобрать одну стратегию или скомбинировать несколько. В результате должна быть готова основная стратегия и на случай неэффективности основной — резервная.
Для работы с рисками есть несколько стратегий:
Стратегии управления рисками
Уклонение — исключение опасности. Включает все меры, чтобы защитить цели проекта от угрозы. Возможно, придется изменить сами цели — смягчить требования, узнать дополнительную информацию. Например, если появляется риск сорвать сроки проекта, можно попробовать упростить продукт и сократить количество задач.
Передача — передача ответственности за последствия риска третьей стороне. Угроза все еще реальна, но устранить ее предстоит другим людям. Стратегия эффективная, но за принятый риск придется выделить вознаграждение. Главные примеры ведения этой стратегии — страховка, гарантии выплат и гарантийное обслуживание.
Снижение — снижение вероятности риска или его негативных последствий с помощью профилактических мер. Чтобы перестраховаться, можно, например, покрыть все основные кейсы программного продукта автотестами. Пусть они в обязательном порядке запускаются перед попаданием кода в продакшн. Более простой пример снижения — заранее выбирать только опытных и проверенных участников проекта и партнеров.
Принятие — реагирование на последствия рисков без вмешательства в сам проект. Когда исключить или снизить риски проекта невозможно, их приходится принимать — работать с негативными событиями уже после того, как они произошли. Принятие может быть пассивным и активным. Пассивное представляет собой игнорирование событий риска и экстренные меры по устранению последствий. Активное принятие — создание резерва ресурсов на случай опасности. К резервным ресурсам относятся, например, деньги, время, загруженность сотрудников.
Как управлять рисками с помощью BPM-системы
Разобраться с рисками раз и навсегда невозможно — нужно постоянно следить за результатами решенных рисков и появлением новых. Управление рисками — долгосрочный процесс, поэтому на всех его этапах должна быть возможность:
собирать и документировать риски проекта;
хранить и передавать информацию о выполненных задачах;
обеспечивать мониторинг статусов рисков;
обеспечивать контроль со стороны проектного менеджера над всеми работами.
Учесть все эти требования помогает процессный подход. Он позволяет построить последовательную цепочку задач и обеспечивает контроль их исполнения.
Процессный подход реализуется с помощью BPM-системы, в которой работа организована в виде бизнес-процессов. Бизнес-процесс — это совокупность взаимосвязанных операций, направленных на достижение цели.
Одним из примеров BPM-систем является система ELMA. С помощью дополнительного модуля Проекты+ она позволяет запустить бизнес-процесс прямо из карточки проекта. А используя мониторинг процессов, проектный менеджер сможет контролировать все этапы работы и получать подробную аналитику после завершения процесса.
Процессы управления рисками проекта могут запускаться несколько раз за проект. Например, в начале проекта для планирования и после прохождения контрольных точек — для актуализации реестра рисков. В зависимости от структуры компании и самого проекта, задачи бизнес-процесса могут отличаться, но этапы работы общие:
После запуска бизнес-процесса проектный менеджер самостоятельно или вместе с командой выявляет все опасности. Лучше сразу разделить риски по целям, которым они угрожают, источнику и силе последствий. Можно собрать общий реестр для всех проектов компании и выбирать из него угрозы для определенного проекта.
Для оценки всех рисков или отдельной группы выбираются эксперты. Им приходит задача в виде сформированного реестра с комментариями менеджера. Эксперты проводят качественный анализ и для каждой угрозы определяют статус. Во время оценки также должна быть возможность вносить в реестр новые незафиксированные риски проекта.
Реестр возвращается к проектному менеджеру с проставленными статусами и замечаниями экспертов. Дальше нужно провести количественный анализ. Для этого можно снова привлечь экспертов или оценить риски силами команды проекта. Важно зафиксировать все результаты количественного анализа в реестре и передать в следующую задачу. Еще один вариант: отказаться от детальной оценки и сразу перейти к выбору стратегии.
Менеджер проекта подводит итоги анализа, пересматривает реестр рисков и приступает к выбору стратегии. Любое изменение статуса риска, например, если он состоялся или решился, менеджер сможет зафиксировать в реестре.
Когда для всех рисков появится план решения, остается продумать необходимые мероприятия и поставить по ним задачи.
После выполнения работ проектный менеджер оценивает эффективность всего процесса.
Бизнес-процессы по управлению рисками выполняются многократно, так что менеджер получает достаточно данных для глобальной оценки всей работы: сколько времени требует оценка, риски какого типа наиболее опасны, какая стратегия выигрышная. При этом у него есть возможность непрерывно следить за статусом угроз.
Если кратко
Гарантировать успех проекта невозможно — всегда будет оставаться элемент неопределенности и риски проекта, угрожающие целям. Чтобы уменьшить неприятности, можно подстраховаться и устранить угрозы заранее. По большому счету работа с рисками заключается в поиске баланса между затратами на решение рисков и потенциальным ущербом в случае их принятия. Достичь этот баланс получится, опираясь на результаты анализа. Только после аргументированной оценки угроз можно приступать к выбору стратегии управления: уклонение, передача, снижение или принятие. Работать с рисками удобнее с помощью бизнес-процесса, а в качестве инструмента для управления рисками использовать BPM-систему.
Вот небольшой чек-лист, как начать работу с рисками проекта:
Найдите слабые места проекта и запишите все возможные риски.
Проведите качественный анализ: разделите все риски проекта на важные и второстепенные.
Проведите количественный анализ: определите влияние рисков на проект в точных значениях.
Подберите и примените к каждому риску одну или несколько стратегий управления.
Следите за поведением решенных рисков и регулярно начинайте сначала: риск может возникнуть на любом этапе проекта.