Что не является инструментом по управлению проектами. Основные инструменты проектного менеджмента. Общая характеристика проекта

На управление проектами оказывает влияние окружение проекта, которое можно разделить на внешнее и внутреннее.

Внешнее окружение:

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

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

Внутреннее окружение. Наиболее существенными факторами "внутреннего" окружения являются:

стиль руководства проектом. Он определяет психологическую атмосферу в команде проекта, влияет на ее творческую активность и работоспособность;

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

участники проекта. Они реализуют различные интересы в процессе осуществления проекта, формируют свои требования в соответствии с целями и мотивацией и оказывают влияние на проект в соответствии со своими интересами, компетенцией и степенью "вовлеченности" в проект;

команда проекта. Она является мотором и исполнительным органом проекта, от команды во многом зависит прогресс и успех проекта;

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

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

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

организация, система документации проекта .

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

PMI PMBOK 2015 Guide 4d Edition (оценка проектов на основании британской методики) состоит из двух частей:

Часть 1 - это структура знаний управления проектами, которая обеспечивает базовую структуру для понимания управления проектами, и его методологию, это введение, которое определяет ключевые термины и обеспечивает обзор остальной части документа;

Часть 2 - описывает основное содержание стандарта - это 39 основных процессов и их взаимодействие при управлении проектами. Это 9 областей знаний управления проектами (таблица. 1.2.). Область знаний - это специфическая сфера компетенции менеджера проекта, которую ему необходимо знать, для того, чтобы успешно осуществить проект.

Таблица 1.2.

9-областей знаний по управления проектами

Примечание: источник .

Как правило, для удобства управления, проекты разбиваются на несколько фаз. Все фазы вместе называются жизненным циклом проекта (Project Life Cicle). Внутри каждой фазы и в целом по проекту процессы организованы в пять групп (табл. 1.3).

Таблица 1.3

Процессы внутри фазы по проекту

Примечание: источник .

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

международная организация по стандартизации ISO опубликовала стандарт ISO 10006 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов». В настоящее время выполняется разработка стандарта ISO 21500 «Руководство по менеджменту проектов». Однако официально данный стандарт будет утвержден только в 2012 году;

международная ассоциация проектного менеджмента (International Project Management Association - IPMA) объединяет 45 национальных ассоциаций и является авторитетной профессиональной организацией в области управления проектами. Россию в IPMA представляет национальная ассоциация управления проектами СОВНЕТ. Основным стандартом, разработанным IPMA, является ICB (IPMA Competence Baseline, 3-я версия выпущена в 2015 году), определяющая требования к квалификации специалистов в области управления проектами и являющаяся основой для международной сертификации. В соответствии с правилами и требованиями IPMA в России разработаны национальные требования к компетенции менеджера проекта и программа сертификации специалистов по управлению проектами. Специалисты, прошедшие сертификацию по этой системе, получают сертификаты международного образца, которые признаются во всем мире;

институт управления проектами США (Project Management Institute - PMI) сегодня «де факто» также можно назвать международной профессиональной организацией. Членами PMI являются специалисты в области управления проектами со всего мира, в различных странах функционируют отделения института. PMI ведет активную разработку стандартов в области управления проектами. В настоящее время опубликовано 3 основных стандарта, регламентирующих процессы управления на уровне проекта, программы, портфеля проектов и более 10 дополнительных стандартов. Дополнительные стандарты определяют как требования к отдельным методикам управления проектами (разработка иерархической структуры работ, разработка календарного плана, управление рисками и другие), так и к применению проектного менеджмента для определенных типов проектов (управление строительными проектами, управление государственными проектами и другие) .

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

применимые к отдельным объектам управления (проект, программа, портфель проектов) и регламентирующие соответствующие процессы управления;

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

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

Некоторые Окончание табл. 1. наиболее известные стандарты международного и национального уровня представлены в следующей таблице 1.4. .

Таблица 1.4.

Наиболее известные стандарты международного и национального уровня

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

В рамках организационно - деятельностей (“менеджерской”) модели (ICB IPMA) проект как понятие определяется через предприятие, усилие и деятельность.

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

те, которые можно описать в виде процессов, объектов, методов;

те, которые не описываемы в принципе или трудно описываемы в виде процессов, объектов, методов.

Современные подходы к стандартизации в области РМ основаны на следующем:

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

для тех областей РМ, описание которых в виде объектов для стандартизации нецелесообразно или невозможно, используются профессиональные квалификационные стандарты (требования) к деятельности специалистов по РМ (Project Management Professional) и менеджеров проектов (Project Manager).

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

Вывод по первой главе

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

В систему управления проектами можно включить: разработку миссии организации, стратегии организации, портфеля программ, программы портфеля проектов. Также необходимо применять разнообразные программно-целевые методы управления (особенно планирования), предусматривающие формирование и организацию выполнения целевых комплексных программ и проектов (ЦКП). Эти задачи представляют собой комплекс взаимосвязанных мероприятий, направленных на достижение конкретных социально-экономических целей. Глобальных систем международных стандартов по РМ не существует. Это связано как с принципиальной невозможностью комплексной стандартизации управления социотехническими системами, какими являются современные проекты, так и с нецелесообразностью разработки стандартов по большому кругу вопросов современного РМ.

В рамках управления качеством проектов используется широкий арсенал методов и инструментов - от классических «семи инструментов управления и контроля качества» до современных, инновационных. Рассмотрим основные методы и инструменты управления качеством проектов.

• 1. Метод плана улучшения качества (QIM - Quality Inspection Management). Он основан на структурированном подходе к решению проблем улучшения качества проектов. QIM предполагает проведение тщательного анализа проблем проекта, выявление их потенциальных причин и принятие возможных решений. Проводимый анализ опирается на конкретные данные, а не на мнения участников проекта, что исключает возможность субъективного подхода и позволяет сосредоточить внимание участников команды проекта на основных проблемах, не отвлекаясь на второстепенные. Основными этапами составления данного плана являются:
  • сбор исходной информации;
  • определение проблемы;
  • анализ причин;
  • реализация корректирующих воздействий;
  • подтверждение результатов;
  • обеспечение стандартизации корректирующих воздействий с обоснованием эффективности.

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

Таким образом, основной эффект от применения метода плана улучшения качества - это упрощение процессов проекта при улучшении качества.

2. Диаграмма Парето. Эта диаграмма имеет вид гистограммы из нескольких столбцов, показывающих частоту возникновения проблем или причины их появления (рис. 8.1).

Рис. 8.1

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

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

3. Диаграмма причин и следствий (CED - Cause and Effect Diagram - диаграмма «рыбий скелет», или диаграмма Ишикавы) содержит идентификацию, соотнесение и графическое отображение причин той или иной проблемы. Описание проблемы расположено в голове «рыбьего скелета» и используется в качестве начальной точки для выявления источника проблемы и ее причины, требующей устранения. В отличие от диаграммы Парето этот инструмент применяется в случае уникальных, неповторяющихся подпроцессов, когда нельзя набрать статистику повторений (рис. 8.2).

Выявленные причины группируются по ряду признаков: люди (теп), машины (machines), методы (methods), материалы (materials), среда (media), менеджмент (management). Далее визуально соединяют все причины с проблемой, продолжают поиск и анализируют информацию. Такая структура позволяет исследовать максимально возможный список причин.

Главными преимуществами использования данного инструмента являются:

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

Рис. 8.2.

Выбор того или иного метода или инструмента управления качеством проекта определяется спецификой проекта, а также тем, насколько и каким образом заказчик понимает данную специфику. Очень часто на практике цели и содержание проектов не до конца ясны даже инициаторам проекта, ибо не всегда понятно, что получится. Это прежде всего касается так называемых мягких проектов. В управлении их качеством применяется концепция Agile Project Management (АРМ). Согласно данной концепции разработка проекта состоит из множества быстро реализуемых итеративных циклов, в рамках которых планируется ровно столько, сколько нужно для реализации текущего этапа проекта. Команда проекта изучает и улучшает качество продукта, а также качество управления проектом в каждом успешном цикле. Короткие циклы планирования позволяют команде проекта постоянно оценивать качество продукта и оперативно получать отзывы заказчика и всех заинтересованных сторон проекта.

• См.: Милошевич Д. Набор инструментов для управления проектами: пер.с англ. М.: АйТи; ДМК Пресс, 2008. С. 587.

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

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

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

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

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

Руководители образуют координационную группу, в задачи которой входит:

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

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

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

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

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

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

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

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

В современном менеджменте действуют девизы:

• - Семь раз отмерь, один раз отрежь!
• - Подумай, прежде чем делать!

В этапах выполнения проекта принимаются решения:

• · нужно продолжать или скорректировать задания;
• · не надо ли уточнить последний этап;
• · форма завершения последнего этапа.

Подразделение на этапы позволяет контролировать ход выполнения проекта.

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

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

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

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

Одним из эффективных инструментов управления проектом является структура разбиения работ (СРР). Она позволяет определить, какие работы необходимо выполнить для реализации проекта, и установить единую структуру управления этими работами.

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

В понятие структуры разбиения работ входят:

• · структура -- совокупность отношений между элементами системы, необходимых и достаточных для достижения цели проекта;
• · разбиение -- разделение на составные части или категории,на более простые составные части, декомпозиция;
• · работа -- продолжительное физическое или умственное усилие направленное на достижение результата; деятельность обязанность, функция, операция, выполняемая сотрудником или коллективом; часть трудового процесса, требующего затрат времени и ресурсов Управление организацией: Учебник / Под ред. А.Г.Поршнева, З.П.Румянцевой, Н.А.Саломатина. - 2-е изд., перераб. и доп.-М.:ИНФРА-М, 1998.-669 с. - с.43.

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

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

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

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

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

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

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

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

• · что он представляет из себя?
• · из каких составных частей состоит?
• · каким образом составные части работают в единой системе?
• · на удовлетворение каких потребностей направлено использование продукции?

Общий процесс создания структуры разбиения работ проекта состоит из следующих шагов:

Шаг 1. Идентификация конечной продукции проекта (что должно быть создано и сдано заказчику для достижения цели проекта?) . Тщательное изучение документов содержащих общее описание проекта (например, техническое задание, технический проект, состав работ и пр.).

Шаг 2. Определение основных производственных результатов проекта, которые могут быть промежуточными результатами, например проектная документация.

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

Шаг 4. Совершенствование дерева работ до тех пор пока оно не будет удовлетворять потребностям всех участников проекта и заинтересованных лиц.

Пример шаблона структур разбиения работ

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://allbest.ru

Введение

В условиях быстро развивающихся технологий и растущих рынков все острее возникает необходимость принятия быстрых и эффективных ответных мер на то или иное событие, что требует детального планирования проекта на стадии его инициации и высокого уровня контроля в течение реализации всего проекта. Вследствие этого, развиваются различные системы управления проектами, которые могут быть наиболее оптимальными для управления в IT сфере, а успех проекта является одним из главных факторов выживания и процветания организации. Актуальность данной работы обуславливается тем, что в IT области наблюдается большое количество не решенных до сих пор проблем. К примеру, если даже и удалось завершить проект, то зачастую это сопровождается перерасходом затрачиваемых средств от 40 до 200%, в то время как другие проекты вовсе закрываются, не достигнув стадии завершения, но при этом принеся значительные затраты как материальные, так и трудозатраты. Таким образом, можно сделать вывод о несовершенстве существующих (традиционных) методов управления и оценки эффективности проектов, что приводит к необходимости поиска альтернатив.

Одним из таких альтернатив может выступать подход, основанный на системной динамике, который предполагает целостный взгляд на организацию, включая в себя следующее: построение системных диаграмм с указанием связей объектов, определением переменных, входящих в эти объекты, темпов их роста, построение гипотез о наличии той или иной зависимости темпов роста и обозначенных переменных, построение дифференциальных или разностных уравнений, решение полученных систем с помощью вычислительных экспериментов, основанных на изменении исходных значений параметров, внешних сценариев и гипотез. Таким образом, подход, основанный на системной динамике, может объединять в себе как традиционные методы УП, так и один из наиболее распространенных на данный момент методов в управлении IT-проектами - Agile-методологию. Помимо известного перечня рисков, предупреждением которых может заниматься риск-менеджмент, имеется достаточно большая группа непредсказуемостей, обусловленных по большому счету человеческим фактором.

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

Целью данной работы является разработка рекомендаций для снижения продолжительности реализации IT-проектов с использованием основ системной динамики в управлении проектами.

Научной новизной работы является определение рекомендаций с условием совместного использования различных методологий управления IT-проектами таких, как традиционные методы, методы Agile-методологии и подход, основанный на системной динамике при учете влияния возникновения обратных связей и циклов ПВР.

Объектом исследования является подход в управлении проектами на основе системной динамики; предметом исследование - влияние циклов ПВР на продолжительность IT-проектов.

Методика работы включает в себя теоретическую и практическую части.

В теоретической части:

· Обзор и интеграция существующего знания об управлении проектами на основе системной динамики;

· Обзор и интеграция существующего знания о циклах ПВР и методах их изучения;

· Качественный анализ выявленных в ранее проведенных исследованиях факторов, влияющих на циклы ПВР.

В практической части:

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

· Проведение анкетирования экспертной группы с целью установления причин возникновения циклов ПВР и последствий их возникновения;

· Проведение глубинного интервью с экспертной группой для перепроверки и подтверждения результатов анкетирования и проведенного наблюдения;

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

Глава 1. Использование системной динамики в управлении IT-проектами

1.1 Внедрение управления проектами в IT-области

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

В работе Lee S.L. и Anderson R.M. было доказано, что введение системы управления проектами положительно влияет на возможности, извлекаемые организацией при реализации IT-проектов. Исследователи использовали в своей работе метод Делфи для определения набора факторов, в том числе, оказывающих влияние на продуктивное использование менеджмента. По результатам получилось, что при введении управления проектами в IT-сфере необходимо обращать внимание в первую очередь на командные факторы и организационные. Кроме того, значительное влияние оказывает уровень зрелости компании.

Командные факторы включают в себя такие, как:

· наличие определенных критериев успеха реализации проекта;

· отчетливое понимание каждым участником команды собственной роли в реализации проекта;

· лояльное отношение каждого участника к реализуемому проекту.

Организационные факторы включают в себя следующие:

· поддержка и вовлеченность в процесс руководителя проекта;

· наличие определенной стратегической цели организации;

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

· соответствие цели реализуемого проекта стратегической цели организации;

· наличие четко определенной для всех подразделений роли управления проектами.

Здесь стоит отметить важный фактор, который оказывает одно из самых значительных положительных влияний на продуктивное использование управления проектами в IT-области: соответствие реализуемых проектов стратегической цели компании и наличие четкого определения этой цели для всех участников проектной деятельности. Как говорилось ранее, в IT-области на данный момент распространено использование Agile-методологии, при использовании методов и инструментов которой конечная цель проекта может размываться в ходе самого процесса. Рассмотрим данный недостаток в следующем разделе и сравним Agile-методологию с традиционными методами управления проектами.

Используемые методы управления IT-проектами

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

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

Таким образом, agile-методология решает основной недостаток традиционных методов - значительный ущерб (как по срокам, так и по бюджету) при внесении изменений в проект на поздних стадиях реализации, что наиболее характерно для проектов, выполняемых в IT-сфере. Отсюда возникает идея совмещения agile-методологии и традиционных методов для повышения эффективности УП. С другой стороны, в обоих этих методах имеется еще один большой недостаток - пренебрежение учетом человеческого фактора и других обратных связей, которые возникают на протяжении всего процесса. Подобные обратные связи могут оказывать значительное негативное влияние на основные характеристики реализации проекта - сроки и бюджет; в первую очередь это происходит из-за возникновения циклов повторного выполнения работы (циклов ПВР), когда при получении дополнительной информации необходимо заново выполнять ту или иную работы. Избежать, точнее - снизить вероятность возникновения данного недостатка возможно с использованием подхода, основанного на системной динамике.

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

Таблица 1. Традиционные методы и подходы в УП

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

Такие методы, как PERT, и инструменты, как WBS, и т.д. подразумевают детальную разработку плана проекта:

· определение работы;

· разработка расписания с точным определением сроков для каждого события;

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

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

Если рассматривать четыре основных этапа, то получается следующее:

· Планирование: рассматривается компромисс между задержкой завершения проекта и наймом новых сотрудников; модель включает различные стратегии по управлению персоналом и вопросы, связанные с приемлемостью задерживания проектов.

· Менеджмент управления человеческими ресурсами: несмотря на то, что традиционно этот этап включается в этап планирования, в системной динамике он рассматривается отдельно и затрагивает проблемы, связанные с наймом дополнительного персонала для проекта. Обычно сюда включаются такие факторы, как проведение тренингов и обучение персонала, уровень опыта рабочей силы, время, затрачиваемое на ассимиляцию.

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

· Контроль: рассматриваются проблемы, связанные с отслеживанием нынешнего статуса проекта.

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

В целом, подход к управлению проектами на основе системной динамики имеет достаточно большие преимущества по сравнению с традиционными подходами. Доказательства этого так же можно найти в работе P.E.D. Love, G.D. Holt, L.Y. Shen, H. Li, Z. Irani , где очень четко высказано мнение относительно того, что любой проект постоянно подвергается влиянию окружающей его среды, причем не только каких-то внутренних факторов, как отношения внутри команды и их мотивация, но и различных внешних, так называемых, регрессоров как, например, политическая ситуация в стране и в мире, изменения в социальных и культурных отраслях и т.п. При этом авторы указывают на некоторые недостатки риск-менеджмента, заключающихся в том, что все его методы направлены на риски, которые возможно заранее определить, но в целом система не включает в себя какие-либо методологии относительно того, как предугадать появление риска, индивидуального для данного проекта. Таким образом, авторы высказывают мнение, что подход, основанный на системной динамике, позволяет улучшить процесс принятия решений на стратегическом уровне, в то время как традиционные методы позволяют справиться только с третью основных задач, возникающих в процессе управления проектом.

Например, в работах Rodrigues A, Bowers J. высказано предположение, что управление проектом можно разделить на следующие ступени:

· Уровень 1 - взаимодействие проекта и компании-подрядчика; важным вопрос здесь оказывается то, совпадают ли цели проекта с целями компании;

· Уровень 2 - так называемые, стратегические альтернативы конкретного проекта; например, какие основные задачи определены в проекте, их соответствие основным целям, форма организационной структуры;

· Уровень 3 - здесь определяются конкретные детали проекта, включая в себя объем необходимой рабочей силы, сроки и расписание проекта и т.д.

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

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

Ключевые моменты, характеризующие преимущество управления проектами на основе системной динамики:

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

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

Можно выделить несколько проблем, связанных с основными характеристиками проектов, которые решает системная динамика :

1) Разрабатываемые проекты сложны и состоят из множества взаимозависимых компонент.

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

2) Разрабатываемые проекты очень подвижны

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

3) Во всех проектах имеются обратные связи и отдача.

Существуют позитивные и негативные петли обратной связи. Позитивные петли характеризуются следующими признаками:

· самовоспроизводящиеся;

· вызывающие рост;

· дестабилизирующие систему;

· ускоряющие систему.

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

· противодействующие росту;

· целенаправленное поведение;

· стабилизирующие систему;

· возвращающие систему к балансу.

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

Традиционные инструменты по снижению затрат и управлению расписанием как, например, метод CPM (critical path method) не могут в полной мере справляться с эффектом отдачи и обратной связи. Оценка людей, как правило, субъективна в таких ситуациях, что приводит к недооценке возможных отдач. Никто из людей не застрахован от ошибок. Поэтому, даже методы, направленные на управление расписанием, как диаграммы Ганта, PERT и CPM не могут решить данной проблемы, что, впрочем, не означает, что данные методы не являются важными; наоборот, традиционные инструменты и системная динамика дополняют друг друга.

4) Разрабатываемые проекты состоят из нелинейных связей.

Наличие нелинейных связей вполне логично для сложных систем; это означает, что все причинно-следственные связи не имеют простой, пропорциональной зависимости. Например, рассматривая приведенный выше пример, увеличивая количество рабочих часов с 40 до 44 в неделю, можно увеличить отдачу на 10%. Но, опять же, как говорилось ранее, длительные и частые переработки приводят к быстрому угасанию производительности работников, их невнимательности, снижению мотивации, увеличению совершаемых ошибок и так далее. Системная динамика в своих моделях берет во внимание все возможные варианты развития события.

5) Разрабатываемые проекты включают в себя и «жесткие», и «мягкие» данные.

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

Рисунок 1. Схематичное представление потоков и накопителей; Ист.

С помощью потоков и накопителей очень наглядно изображаются обычные причинно-следственные связи. Накопителями являются «стоки», потоки бывают исходящие и входящие. Облако при исходящем потоке показывает какой-то источник, который в данном исследовании может не конкретизироваться; такое же облако может быть на наконечнике исходящего потока. Есть стандартизированные требования к данным обозначениям :

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

· накопители всегда выражаются в единицах модели;

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

Влияние обратных связей и циклов ПВР на продолжительность IT-проектов

Основными причинами увеличения продолжительности IT-проектов, как и проектов в других областях, можно назвать снижение производительности членов команд и возникновение описанных ранее циклов ПВР. Все эти факторы взаимосвязаны между собой преимущественно за счет наличия обратных связей в ходе протекания любого процесса. Как только менеджер проекта замечает какое-либо отклонения от планового срока реализации всего проекта или отдельной задачи, он предпринимает различные инструменты для корректировки отклонения. Зачастую применяется три основных способа:

· увеличение трудозатрат членов команд (частые переработки);

· давление на членов команд;

· добавление новых участников в команду (привлечение дополнительных человеческих ресурсов).

В результате, всё это оказывает негативное влияние на мотивацию сотрудников, выражаясь в конечном итоге в снижение производительности. Снижение производительности, в свою очередь, влияет на увеличение возникновения циклов ПВР и увеличение их продолжительности. Таким образом, наблюдается возникновение многочисленных позитивных петлей, которые способствует экспоненциальному росту отклонения фактических сроков от плановых [Рис.2].

Рисунок 2. Обратные связи при использовании менеджером различных методов для корректировки задержки; Ист.

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

Рисунок 3. Схематичное изображение цикла ПВР; Ист.

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

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

Рисунок 4. Влияние циклов ПВР на сроки и качество; Ист.

Рассмотрим пример . Размер проекта предполагается равным 64 000 DSI (специальная размерная величина для оценки количества строк кода) . Размер номинальной потенциальной производительности обычного рабочего со средним уровнем опыта равен 1 заданию за рабочий день, а значимость 1 задания равна 60 DSI. Таким образом, получается, что размер проекта в терминах выполненных задач равен 64 000/60 = 1,067.

На начальном этапе менеджеру предстоит оценить размер проекта. Никогда не известна настоящая величина, поэтому оценка очень приблизительна. Представим, что проект был недооценен и было предположено, что его размер составит только 33% от реального, т.е. 0,67*64 000 = 42 880 DSI. Далее на основании этого уровня проводится оценка необходимых усилий и расписания с помощью модели COCOMO Это алгоритмическая модель оценки стоимости разработки программного обеспечения, разработанная Барри Боэмом (Barry Boehm). Модель использует простую формулу регрессии с параметрами, определенными из данных, собранных по ряду проектов. Ист. . По данной модели получилось, что необходимое количество рабочих дней равно 2 359 дней, а продолжительность проекта = 296 дней.

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

На фоне всех этих условий строится оценочный график, на котором видно, что при таких изначальных предположениях в реальной ситуации проект будет выполнен более, чем за 440 дней (это происходит за счет того, что в процессе выполнения установленных задач, все детальнее становится видно всю ситуацию и ее реальные значения):

Рисунок 5. Оценочный график 1. Ист.

Рассмотрим более подробно ситуацию с производительностью.

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

В проекте существует две причины снижения производительности. Первый тип причин включает мотивацию и общение; влияет этот тип на образование пробела (gap) между потенциальной производительностью и реальной. Второй тип причин влияет на снижение уровня средней производительности.

Рассмотрим еще один график:

Рисунок 6. Оценочный график 2. Ист.

Здесь видно, что в самом начале проекта фактическая доля человеко-дней (рабочих дней) (AFMDPJ) составляла 0,6, что означает, что члены команды тратили по 0,6*8 = 4,8 часов в день на проект. На последнем этапе наблюдается резкий взлет этой кривой, что говорит о значительных переработках, которые, в свою очередь, возникли из-за изначальной недооценки проекта.

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

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

В работе S. B. Yu and J. Efstathiou циклы ПВР делятся на 5 типов:

a) обратный цикл ПВР - простая система обратной петли, которая подразумевает, что переделанный объект возвращается в основной поток, в котором снова подвергается проверке; здесь необходимы высокий уровень квалификации и значительный опыт «инспектора»;

b) прямой цикл ПВР означает, что после того, как какой-то объект или процесс переделан, он не проверяется заново, а включается уже полноценно в поток; соответственно, такая система обусловлена значительными рисками в плане того, что если «ремонт» объекта не исправил каких-то недочетов, то это может оказать негативное влияние на последующую работу;

c) цикл «отбрасывания» - после выявления какого-то дефекта, объект не отправляется на доработку, а выкидывается из работы совсем; это явление может быть обусловлено высокими финансовыми затратами, которые в последующей работе скорее всего не оправдаются;

d) двойной обратный цикл - подразумевает наличие еще одной (дополнительной) инспекции после устранения неполадок дефектного объекта, причем, объект не будет возвращен в общий поток, пока не будет окончательно пройдена данная инспекция;

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

Рисунок 7. Нарушение последовательности при наличии цикла ПВР; Ист.

Как видно на Рисунке 1 (а) и (b) во время того, как объект 3 находился на доработке, другие три объекта (6, 5 и 4) успели пройти проверку, поэтому на выходе (с) получилась нарушенная последовательность. В работе введена величина, которая измеряет данное изменение последовательности и равна тому, на сколько «объектов назад» был отброшен исправленный объект - длина беспорядка (в данном случае, равна 3), обозначается.

Ниже приведен рисунок, на котором схематично указаны перечисленные выше типы циклов ПВР:

Рисунок 8. Схематичное изображение типов циклов ПВР;Ист.

Для каждого проекта или даже для каждого отдельного процесса в проекте необходимо выбирать наиболее подходящий цикл ПВР. Интересен следующий результат, полученные в ходе этого исследования: повышение сложности нарушенной последовательности находится в прямой зависимости с наличием цикла ПВР, но в обратной с проводимой «инспекцией», что, впрочем, логично, т.к. чем чаще проводится проверка объектов на наличие дефектов, тем меньше вероятность, что время, затраченное на исправление этих ошибок, будет достаточно велико для нарушения последовательности; с другой стороны, часты «проверки» могут оказаться более затратными, нежели последующее восстановление последовательности, но все равно при этом остается преимущество в плане сохранения сроков выполнения всего процесса в целом (правда, «инспекция» частая инспекция может не выявить никаких отклонений, в то время как значительные материальные средства на ее проведение будут затрачены). Кроме того, в результате проведенного исследования, были полученные следующие результаты по достоинствам и недостаткам всех типов циклов ПВР по достигнутому уровню той или иной характеристики:

Таблица 2. Сравнение различных типов циклов ПВР

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

Необходимость наличия подобного буффера обуславливается еще одним фактором - потребность в дополнительном времени на обработку задач, ожидающих повторного выполнения. Исследование Hazhir Rahmandad и Kun Hua предлагает интересный подход к изучению циклов ПВР. Интересна модель, предложенная авторами, которая рассматривает циклы ПВР не только с точки зрения выполняемых задач и задач, отправляемых на «инспекцию», но и с точки зрения самих дефектов. Два процесса могут протекать параллельно: процесс проверки на наличие дефектов самих задач и жизненный цикл самих дефектов, и эти два процесса очень тесно взаимосвязаны.

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

Исследователи предложили очень интересный вариант расчета вероятности выявления дефектов. Для этого было предложено понятие дефектной плотности - общее количество дефектов на полный объем работ. То есть если 100 задач, 113 дефектов, то плотность равна 1,3. На нижнем рисунке данное явление представлено схематично (зеленое поле - общий объем работ, красные точки - разброс дефектов, область в правом нижнем углу - проводимый тест на выявление дефектов, площадь этой области обозначается буквой a и рассчитывается в задачах):

Рисунок 9. Дефектная плотность; Ист.

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

Отсюда была выведена формула вычисления вероятности выявления k дефектов в тестовой зоне размера a:

таким образом, если плотность (d) равна 1,3, а a=1, k=0, тогда существует 27 процентная вероятность выявления этих дефектов. Если k=1, тогда вероятность повышается до 35%, что вполне логично. Причем, при увеличении области проверки, вероятность тоже значительно увеличивается, если k мало; если k достаточно велико (примерно соразмерно с количеством проверяемых задач), то вероятность увеличивается, но не значительно.

Кроме того, была выведена формула расчета вероятности безуспешного прохождения тестирования:

Значение обозначает вероятность того, что была протестирована с k дефектами и k дефектов были упущены.

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

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

Моделирование процесса производства на основе непрерывной цепи Маркова позволяет рассмотреть прямое влияние возникновения циклов ПВР на бюджет проекта. В основе лежит идея того, что каждый производственный этап находится в переходном состоянии, которое подразумевает пересмотр незавершенного объекта. Существует два варианта развития событий для каждого объекта на определенном производственном этапе: объект оказывается удачно завершенным и переходит с вероятностью p на следующий производственный этап и объект возвращается на доработку по результатам проведенной проверки с вероятностью q; при этом величина «поглащающий» момент, характеризующий отбрасывание объекта в виду выявленных ошибок, не подлежащих исправлению, исчисляется следующим образом:

Ниже представлена цепь Маркова порядка 2n+1:

Рисунок 10. Цепь Маркова порядка 2n+1; Ист.

Стоимость, затрачиваемая на объект, проходящий через проверку в первый раз, ниже стоимости объекта, проходящего повторную проверку в силу того, что на последний объект затрачиваются материальные средства на исправление идентифицированных ошибок и на «время ожидания», то есть, в случае материального производства, на хранение объекта на складе, на его обслуживание и др. Для определения итоговой стоимости на объект, перешедший в «поглащающий» момент (подразумевает как возможность попадания в брак, так и в финальный - успешный - этап) на том или ином этапе производства необходимо учитывать ожидаемое количество прошедших производственных этапов, ожидаемое время до попадания в это состояние, ожидаемые затраты, ожидаемое количество циклов повторного выполнения работы для устранения ошибок и ожидаемые время и затраты на проведение подобных циклов с данным объектом. Здесь авторами исследования вводится понятие «веса» посещения производственного этапа k = . При, на каждом попадании в очередной производственный этап затраты увеличиваются на 1. Так, - доля объектов, проходящих первую проверку на производственном этапе k со стоимостью, а - доля объектов, проходящих повторную работу со стоимостью. Тогда средняя стоимость прохождения через каждый производственный этап составит:

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

1) Вероятность попадания объекта из первого этапа в финальный - успешный - этап = 0,93;

2) Количество проходимых производственных этапов для каждого объекта перед попаданием в «поглащающий» момент = 2,987, что близко к 3 (полной цепи); здесь небольшое отклонение обусловлено как раз небольшой вероятностью попадания некоторых объектов в брак;

3) Количество проходимых производственных этапов для каждого объекта, попадающего в финальный - успешный - момент, = 3,212, где 0,212 - разница, обусловленная циклами ПВР и небольшой неэффективностью управления качеством;

4) Ожидаемые затраты на финальный продукт = 6,457, где 0,457 включает в себя затраты на циклы ПВР (которые по результатам исследования = 0,208) и затраты на запуск новой продукции взамен бракованной (т.е. минимальная теоретическая стоимость брака = 0,249).

Интересным является результат относительно того, что при изменении только одной вероятности перехода из одного производственного этапа в последующий, максимальное снижение стоимости достигается при увеличении вероятности перехода из предпоследнего этапа в последний:

Рисунок 11. Влияние увеличения вероятности перехода на итоговую стоимость; Ист.

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

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

Многими исследователями сейчас изучается и совершенствуется одна из наиболее приближенных к реальному миру моделей под названием RCPSP (Resource-Costrained Project Scheduling model). Одним из наиболее интересных моментов этой модели является идея о «перекрывании» или «нахлестывании». Это явление подразумевает под собой начало выполнения последующего действия еще до получения полной информации, что позволяет значительно сократить время, затрачиваемое на выполнение всего проекта. С другой стороны, это может привести к появлению циклов ПВР в будущем, т.к. полная информация может затребовать выполнения каких-то других действий или выполнения их другим образом.

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

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

Ограничения

Здесь введены определенные допущения, как и в любой другой модели.

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

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

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

Обратные связи

Известные нам виды сетевых моделей построения проектов такие, как «ребро-работа» и «вершина-работа» имеют один большой недостаток - они не позволяют отображать взаимозависимые работы, повторение каких-то работ и процесс создания потока информации между двумя работами. Имеется такой инструмент как структурная матрица DSM (Design Structure Matrix), которая позволяет рассматривать передвижение информации от одной работы к другой. В ней (матрице) может отображаться, когда была начата последующая работа - в середине предыдущей, в конце или т.п., то есть, при каком объеме информации началось следующее действие. Таким образом, появляется возможность учета обратной связи, про которую говорилось выше. Для упрощения моделирования, каждый процесс можно рассматривать отдельно, то есть разбить всю совокупность работ на множество различных взаимосвязей, тогда поток информации будет однонаправлен, что примерно и сделано в рассматриваемой работе - дабы избежать возможности появления обратных связей.

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

Величина нахлестывания

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

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

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

Расчет величины «переделывания»

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

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

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

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

Подобные документы

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

контрольная работа , добавлен 09.12.2014


Информационные системы управления проектами. Классификация и краткий обзор программного обеспечения управления проектами. Внедрение специализированного программного обеспечения при проведении автоматизации управления Фитнес-клубом с выкупом территории.

курсовая работа , добавлен 01.12.2013


Сущность и функции корпоративной системы управления проектами (КСУП), ее элементы и предъявляемые к ней требования. Базовые методологии и процессы управления проектами. Характеристика основных ролей в контексте КСУП, этапы ее разработки и внедрения.

контрольная работа , добавлен 13.06.2013


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

реферат , добавлен 29.09.2012


Понятие и структура корпоративной системы управления проектами. Основные методы диагностики уровня зрелости управления проектами. Инициация и планирование, финансирование проектов. Управление программами, рисками, коммуникациями и портфелем предприятия.

дипломная работа , добавлен 20.08.2017


Понятие управления проектами как важной части функционирования любого предприятия. Внедрение информационных систем. Стандарты по управлению проектами. Интеграция проекта и управление его содержанием. Особенности управления временем и стоимостью.

практическая работа , добавлен 07.04.2015


Анализ существующих информационных технологий в области управления проектами. Разработка методики внедрения в работу образовательного учреждения программного комплекса управления проектами Microsoft Project и оценка эффективности его использования.

курсовая работа , добавлен 14.01.2014


Теоретические аспекты международных и национальных стандартов в области управления проектами. Описание международных и национальных стандартов управления проектами. Практическое использование стандартов на примере организации ОАО "Молоко" г. Калининград.

курсовая работа , добавлен 26.12.2016


Сущность и актуальность управления проектами. Методы исследования и обоснования инвестиций в проекте. Управление рисками и стоимостью проекта. Организация финансирования проекта, торги и контракты. Планирование и формы структуры управления проектами.

реферат , добавлен 14.02.2011


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

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

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

• традиционный проект-менеджмент;
• PRINCE2;
• Scrum;
• Kanban;
• Agile;
• Six Sigma;
• Lean.

Классическое управление проектами

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

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

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

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

Agile

Не все проекты можно разделить на последовательные этапы, поэтому классический метод считается малоэффективным и даже невозможным для реализации. Инструменты Agile - это совокупность итеративно-инкрементальных методов, что используются в управлении проектами.

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

Scrum

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

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

Lean

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

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

Kanban

Инструментарий вышеуказанного метода используется вместе с Lean, это позволяет добиться конкретики и простоты в практической сфере применения. Данный метод подразумевает проектное производство по этапам, что учитывают колебания уровня значимости конкретных задач. Можно сделать вывод, что в рамках методологии можно решить одновременно несколько задач или прекратить, если нужно.

Достаточно часто Kanban приравнивают к Agile, так как здесь схожи принципы, что выражены в отдельных инструментах метода.

Six Sigma

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

Six Sigma схожа с Kanban, особенно их методы. Существенная разница прослеживается исключительно в определении этапов контроля качества, целеполагания, планирования.

PRINCE2

Такой метод представлен как гибрид традиционного подхода к проектному управлению и концепции Six Sigma. Если говорить о методологии, то огромную роль играет состав проектной группы и распределение отдельных ролей. PRINCE2 не отличается определенными практическими инструментами, а является неким руководством к действенной организации по проектному управлению.

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