Учебная работа. Инструменты управления проектами

Инструменты управления проектами

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WBSНачальное/базовое определение всего проекта. Оценки стоимости и наброски расписанияМатрица ответственностиОпределение ответственностей, организационной структуры проектаДиаграммы ГантаПростое и наглядное представление расписания проекта без отображения зависимостей между отдельными событиямиСтоимостные расписанияОценка и разработка реалистичного бюджета, подходящего под все стандарты, относительно которого отслеживаются все работы проектаИСПОЛЬЗОВАНИЕ ВЫШЕПЕРЕЧИСЛЕННЫХ МЕТОДОВ СОВМЕСТНОPERT, CPM, PDM, GERT и т.д.Разработка расписания; определения взаимозависимости и уровней влияния событий; определение критических работ; основы стоимостной оценки, распределения ресурсов и анализа рисков

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

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

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

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

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

·разработка бюджета.

Далее, каждый нынешний этап, на котором находится проект, сравнивается с планом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·целенаправленное ·стабилизирующие систему;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В работе S. B. Yu and J. Efstathiou [50] циклы ПВР делятся на 5 типов:)обратный цикл ПВР — простая система обратной петли, которая подразумевает, что переделанный объект возвращается в основной поток, в котором снова подвергается проверке; здесь необходимы высокий уровень квалификации и значительный опыт «инспектора»; )прямой цикл ПВР означает, что после того, как какой-то объект или процесс переделан, он не проверяется заново, а включается уже полноценно в поток; соответственно, такая система обусловлена значительными рисками в плане того, что если «ремонт» объекта не исправил каких-то недочетов, то это может оказать негативное влияние на последующую работу;)цикл «отбрасывания» — после выявления какого-то дефекта, объект не отправляется на доработку, а выкидывается из работы совсем; это явление может быть обусловлено высокими финансовыми затратами, которые в последующей работе скорее всего не оправдаются;)двойной обратный цикл — подразумевает наличие еще одной (дополнительной) инспекции после устранения неполадок дефектного объекта, причем, объект не будет возвращен в общий поток, пока не будет окончательно пройдена данная инспекция;)обратный цикл с буфером — подразумевает наличие буфера, который дает возможность упорядочить сбившийся из-за повторного выполнения работы информационный или материальный поток; такой буфер несет дополнительную стоимость, но, в свою очередь, смягчает влияние на сроки, т.к. в нем изначально учитывается дополнительный временной ресурс. Если же буфер не предусмотрен, то может возникнуть следующая ситуация:

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

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

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

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

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

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

Тип цикла ПВРСложности в последовательностиЗатратыКачествоОбратныйсреднийсреднийвысокийПрямойнизкийсреднийсредний«Отбрасывания»-низкийвысокийДвойной обратныйсреднийвысокийвысокийОбратный с буферомнулевойсреднийвысокий

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

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

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

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

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

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

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

,

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

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

дефектами и k дефектов были упущены.

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Целевая функция и ограничения

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

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

На основании всех этих выводов, авторами была предложена следующая визуализация всех возможных вариантов оценки величины нахлеста и переделывания при наличии работ без перехлеста (таблица 2а), при наличии одной приоритетной работы с перехлестом (таблица 2b) и при наличии двух работ-предшественников с перехлестом (таблица 2c).

Рисунок 12. Оценка величины нахлеста; Ист. [3]

где m — количество возможных режимов, nij — количество возможных режимов построения каждой пары работ (по правилу приоритета), aijm — величина нахлестывания, rjm — величина переделывания.

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

В целом, существует три варианта развития событий:

)если работы не подлежат перехлестыванию, то они выполняются последовательно;

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

)если работы подлежат перехлестыванию, то они выполняются последовательно.

Авторы определили следующий вид системы принятие решений — в качестве бинарной дамми-переменной:

где S — набор работ, период от 0 до Т — максимальная продолжительность всего проекта, определенная методами прямого расчета и обратного (от конца к началу).

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

Выводы

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

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

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

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

1.2 Определение основных типов проблем, влияющих на возникновение циклов ПВР

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

В работах Rodrigues A, Bowers J. [37] все процессы, протекающие в проектной деятель, разделяются на две группы: запланированные и неопределенные.

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

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

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

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

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

К неопределенностям, в свою очередь, могут относиться внутренние и внешние события.

Внутренние:

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

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

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

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

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

внешние:

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

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

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

-влияние условий «легальности» (существенное влияние могут оказывать изменения в различных строительных ГОСТ’ах, в законе о безопасности и т.п.);

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

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

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

—влияние форс-мажорных обстоятельств.

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

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

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

·командная адаптация;

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

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

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

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

Все эти факторы приводят к аффективной и когнитивной интеграции сотрудников, т.е. к возникновению недопонимания участниками проекта друг друга [49]. Это может обуславливаться их уровнем образования, жизненной позицией и другими факторами, упомянутыми ранее в работе. Если рассматривать эту проблему более детально, то интересной может оказаться работа Cronin M.A., Bezrukova K., Weingart L.R., Tinsley C.H. [6] по изучению влияния на успех проекта такого явления, как разбиение проектной команды на подгруппы.

В этом исследовании рассматривается проблема формирования подгрупп в командах с точки зрения не процессов, которые способствует появлению этого явления как это сделано в работах Zellmer-Bruhn et al. (2008), а процессов, которые происходят в команде уже после того, как подгруппы сформированы. Практическая актуальность заключается в рассмотрении таких распространенных явлений, как аффективная и когнитивная Интеграция членов команд. Образование отдельных подгрупп в командах — явление достаточно частое, которое зачастую, как предполагается, вызывает отрицательные эмоциивлияние указанных видов интеграций.

Аффективная интеграция заключается в наличии у каждого члена команды уважения, доверия и симпатии к своим коллегам (Jehn & Mannix, 2001; Konar-Goldband, Rice, & Monkarsh, 1979). Когнитивная Интеграция показывает, насколько доступны знания всех участников друг другу. Данный вид интеграции очень важен в том смысле, что он позволяет эффективно и быстро решать наиболее сложные задачи, когда информация, имеющаяся у каждого участника, ограничена его знаниями в той или иной сферах. В итоге получаем, что если аффективная Интеграция отражает чувства, испытываемые тем или иным членом команды к своему коллеге, но не означает обоюдного понимания, то когнитивная восполняет этот недостаток, но при этом не означает наличия позитивного отношения членов команды друг к другу. таким образом, авторами рассматривается, как может повлиять образование подгрупп на данные виды интеграций и как данные интеграции, в свою очередь, могут повлиять на членов команды и результаты их деятель в условиях наличия подгрупп.

Зачастую в подгруппах наблюдается наличие неоднородной информации, что дает больше «сырья» для всей команды при решении той или иной задачи (Hoffman & Maier, 1961; Nemeth, 1986; Triandis, Hall, & Ewen, 1961). различные исследования (Burt, 1992; Granovetter, 1973; Krackhardt & Brass, 1994) показали, что разнообразие и неоднородность информации выше в командах, где имеются подгруппы, так как в данном случае вся информация локализуется достаточно густо в отдельных районах всей группы. Тем не менее, знания участника должны быть доступны всей команде, иначе они не смогут влиять на итоговые решения (Okhuysen & Eisenhardt, 2002). только в таком случае, информация может храниться и использоваться всей командой (Hinsz, Tindale & Volrath, 1997); так команды вступают во взаимодействие и образуют синергию, опираясь на знания друг друга (то есть через информационные разработки, см. van Knippenberg et al., 2004). однако наличие хорошо отлаженных путей для обмена информации не является достаточным, чтобы гарантировать ее использование (e.g., Gruenfeld, Martorana, & Fan, 2000; Kooij-de Bode, van Knippenberg, van Ginkel, 2008; Thompson, 1991), и большинство исследований фокусируется на отсутствии мотивации, как препятствия для использования информации. Например, в работе Homan и соавт. (2007) показано, что открытость информации относительно чьего-либо опыта снижает критику и отторжение идей этого участника со стороны других членов команды, то есть коллеги более охотно начинают использовать его знания.

толкование одной и той же информации может быть отличным для различных участников или подгрупп, в связи с разницей их точек зрения. Такая разнообразная интерпретация одной и той же информации затрудняет интеграцию знаний, так как участники, использующие схожую основу для работы, могут неправильно понять коллег, использующих отличную базу. В исследованиях Carlile (2002, 2004) и Bechky (2003) что недопонимание может возникнуть, когда между участниками не налажен «общий язык». Проблема непонимания является проблемой разной интерпретации информации; так люди могут использовать одни и те же слова, но иметь ввиду при этом абсолютно разные вещи (например, значение слова «слайд» у инженеров и монтажников, см. Bechky, 2003; последние исследователи в своих работах показывают, что источником появления различных точек зрения является функциональный тренинг, но авторы данной работы настаивают, что причиной могут являться и сами подгруппы; а Brown и Duguid (1991) вводят такое либо практической группы принимают определенную точку зрения и язык.

Другая классификация возникающих проблем представлена в работе David W Daniel [8]. автор делит проблемы на те, которые возникают среди людей (унитарные), имеющих одну цель, и те, которые возникают среди людей, преследующих различные цели (множественные). Эти две группы также могут быть простыми или сложными, то есть возникать в каких-то простых системах (механических) или сложных. Последние возникают из-за упомянутых выше поведенческих реакций, которые в свою очередь могут быть обусловлены политическими факторами, культурными, социальными, религиозными и т.д. опять же, в подтверждении выводов, сделанных в работе ранее, автор указывает на то, что если с простыми проблемами (будь то унитарные или множественные) могут справиться традиционные методы управления проектами или обычная аналитика, то сложные требуют вмешательства SSM (soft System Methods, «мягкие» методы системного подхода). Что интересно, в исследовании указывается на то, что со сложными унитарными проблемами возможно справиться с помощью кибернетики, в то время как сложные множественные проблемы наиболее оптимально решаются с помощью SSM.

Интересным является исследование A. G. Rodrigues и T. M. Williams [38]. На приведенном ниже рисунке показано, как влияют вносимые изменения в систему Заказчиком в середине выполняемого проекта. На верхнем рисунке (Рис. 7а) показано, что при вводе на 65ом дне каких-либо изменений (кривая 4) количество выполненной работы резко снижается (кривая 3), что к тому же увеличивает количество ошибок необходимых к доработке (кривая 5). В итоге увеличиваются сроки выполнения работы затраченный бюджет (кривая 2).

На нижнем изображении (Рис. 7b) изображено, как в это время меняется распределение человеческих ресурсов. Как видно, при внесении изменений в систему резко увеличивается количество людей, задействованных в непосредственной доработке системы (кривая 2), при этом снижается количество людей, занимающихся исправлением дефектом и выявлением этих дефектов, т.к. в условиях сжатых сроков рабочие стараются как можно скорее выполнить само задание. Этим объясняется увеличение циклов ПВР, обозначенное ранее.

Рисунок 13. влияние внесения изменений в проект; Ист. [38]

В результате своего исследования авторы пришли к выводу, что при внесении каких-либо изменений корректировка сроков должна составлять около 60%. То есть, например, если по договоренности с Заказчиком изначальный срок был установлен в 100 дней, то при внесении им 30% изменений, дополнительное количество дней на доработку должно составить 100*(30%*60%) = 18 дней. При таком уровне количество ошибок минимально (Рис. 8):

Рисунок 14. Корректировка расписания; Ист. [38]

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

Рисунок 15. Корректировка расписания; Ист. [38]

интересным исследованием является работа S. Howick и C. Eden [19], в которой рассматриваются непривычные для системной модели управления проектами дискретные факторы, оказывающие влияние на рабочий процесс. авторы отталкиваются от принятой методологии рассмотрения непрерывных потоков, аргументируя это наличием множество как внешних, так и внутренних факторов, оказывающих резкое влияние в определенный момент времени на реализацию проекта, что приводит к, по сути, бинарной модели развития дальнейших событий. Так, к эндогенным дискретным факторам относится нарушающее его гомеостаз»>стресс, испытываемый менеджером проекта. При превышении уровня этого стресса определенного значения k происходит смена менеджера проекта, что, в свою очередь, приводит к изменению политики принятия решений в целом по проекту. Отсюда вытекает уже экзогенный фактор: при смене менеджера проекта наблюдается такое явление как «одностороннее» принятие решений данным менеджером из-за недопонимания или недостатка полной информации, что обычно при «вводе» в уже действующий проект.

В работе исследователей Donald E. Harter, Mayuram S. Krishnan и Sandra A. Slaughter [16] рассматривается влияние такого явления как уровень зрелости процессов и влияние этого явления на качество, время производства и количество человеко-часов, затрачиваемых на разработку (рассматривается на примере IT-индустрии). При построении матрицы корреляций и регрессионных моделей по логнормальному распределению также учитывались такие два фактора, как размер продукта (объем выполняемой работы) и неопределенность требований. Последний фактор подразумевает под собой время, затрачиваемое на окончательное согласование первичных требований к разработке, когда зачастую работы начинают выполняться до финального согласования (подготовка различных макетов, драфтов и т.д.); в таком случае после утверждения крайней версии выполняемых работ вводная информация может измениться, что приводит к появлению циклов ПВР; либо новые вводные вносятся в проект на любой стадии, что приводит к тому же результату. Исследователи получили достаточно интересные результаты (все регрессионные модели полученные коэффициенты, перечисленные ниже, являются значимыми; мультиколлинеарность исключено, тест Уайта на гетероскедастичность не дал положительных результатов):

)качество:

·Качество разрабатываемых продуктов имеет сильную положительную зависимость от уровня зрелости процессов (улучшение зрелости на 1% уже дает повышение качества на 1,589%);

)Время производства:

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

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

·При добавлении в уравнение влияния качества, время производства обратно зависит от уровня зрелости процессов;

)Трудозатраты:

·Количество затрачиваемых человеко-часов положительно зависит от уровня зрелости процессов: как говорилось выше, совершенствование внутренних процессов требует больших затрат как временных ресурсов, так и трудовых;

·количество затрачиваемых ресурсов имеют сильную обратную зависимость от качества производства: выше уточнялось, что высокое качество производства предполагает низкий уровень дефектов и низкую вероятность появления циклов ПВР (повышение качества на 1% дает снижение в трудозатратах на 0,611%)

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

)Общий эффект:

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

Рисунок 16. Влияние уровня зрелости процессов; Ист. [16]

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

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

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

)Циклы ПВР и обратные негативно влияют на сроки реализации проекта, увеличивая их;

2)большое количество циклов ПВР положительно влияет на качество выполнения работ;

3)На появление циклов ПВР оказывают влияние «твердые» и «мягкие» факторы:

a.«твердые» включают в себя ограничение по срокам и по бюджету;

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

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

a.производить 60% корректировку сроков (при учете размера вносимых изменений);

b.увеличивать вероятность выхода из цикла ПВР объекта на последних стадиях реализации проекта;

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

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

)трудозатраты и сроки проекта зависят от типа циклов ПВР (5 типов: прямой, обратный, отбрасывания, двойной обратный, обратный с буфером):

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

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

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

Глава 2. анализ влияния факторов возникновения циклов ПВР на продолжительность проекта

2.1 Определение факторов

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

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

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

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

·Появление циклов ПВР и их продолжительность негативно влияют на сроки реализации проекта.

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

.2 влияние факторов

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

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

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

·Параллельное выполнение работ;

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

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

)Наиболее интересные количественные результаты наблюдений:

·Запараллеливание работ наиболее оптимально при запуске выполнения последующей работы на 60%-ом уровне завершения предыдущей работы;

·Наиболее оптимальным количеством циклов ПВР для работ, находящихся на финальной стадии спринтов (выпуск релизов), является 2 цикла (для остальных — 1-2 цикла).

Касательно оптимального уровня выполнения первой работы до запуска последующей работы стоит отметить важный момент: для области IT этот уровень оказался ниже для ряда задач таких, как разработка пользовательского интерфейса и наращивание «типового» функционала на уже эксплуатируемую систему. В этих случаях данный уровень составил 40%. При обозначенных уровнях вероятность возникновения циклов ПВР снижается незначительно (примерно, с 0,6 до 0,4), но их влияние на итоговую реализацию проекта (особенно, в части соответствия фактических сроков реализации плановым) снижается. Происходит это за счет снижения продолжительности циклов ПВР. При этом, если уровни оказываются ниже, тогда циклы ПВР оказываются весьма затратными как в части количества требуемого времени на их выполнения, так и в части ресурсов, как человеческих, так и материальных. Кроме того, запуск выполнения последующей работы на более ранних стадиях приводит к повышению вероятности возникновения цикла ПВР на работе-предшественнике за счет наличия обратных связей (доработки работы-предшественника в таких случаях составляют не более 10%, но это значительно увеличивает продолжительность цикла ПВР последующей работы).

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

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

Анкетирование проводилось среди членов проектных команд, преимущественно — менеджеров проектов. Это дало возможность проверить предположения, описанные в главе 2, относительно влияние менеджера проекта и метода принятие им решений на управление циклами ПВР. перечень вопросов, включенных в анкету, приведен в Приложении (1.1 Форма анкеты).

Согласно полученным ответам, самой распространенной причиной возникновение циклов ПВР являлось появление новых вводных:

Рисунок 17. Анкета: причины возникновения циклов ПВР

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

рисунок 18. Анкета: этапы реализации проекта, на которых происходило получение новых вводных

При этом, степень влияния циклов ПВР на продолжительность реализации проекта была оценена средней:

рисунок 19. Анкета: степень влияния циклов ПВР на продолжительность реализации проекта

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

Рисунок 20. результате получения новых вводных

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

Рисунок 22. Стоит отметить, что влияние адаптации новых членов команд на некачественное выполнение работ было оценено значительным только в 10% случаев.

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

Таблица 3. Матрица корреляции. Сверхурочные работы

YX1X2X3Y10.315-0.390-0.154X10.31510.1770.101X2-0.3900.17710.190X3-0.1540.1010.1901

где переменная y — наличие значительных сверхурочных работ (более 2х раз в неделю);

x1 — процент изменения запланированных работ в результате получения новых вводных (при более, чем на 20%, принимается равным 1);

x2 — стадия проекта, на которой получены новые вводные (более 50% реализации проекта — критичная стадия для получения новых вводных, т.е. равны 1);

x3 — процент работ от общего объема работ, подверженный повторному выполнению работ (более 30% работ, т.к. в основном, согласно выше приведенным диаграммам, ПВР возникали при выполнении проекта более, чем на 50%, т.е. 1);

все переменные бинарные.

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

Рассмотрим модели, использующие в качестве результирующего признака дискретную переменную. Начнем с построения моделей бинарного выбора — моделей, разработанных для описания ситуаций, когда результирующая переменная принимает значение 1, если индивид курит, и 0 в обратном случае (не курит). Основными моделями бинарного выбора являются:

·logit-модель. Данная модель предполагает логистическое распределение функции вероятности события. вероятность события определяется по формуле:

где Z — линейная комбинация объясняющих переменных:

Если рассчитанное значение вероятности превышает 0,5, то прогнозируемое значение y принимается равным 1, в обратном случае — 0.

·probit-модель, использующая нормальное распределение. вероятность события определяется с помощью функции стандартного нормального распределения F(Z), где Z — линейная функция переменных, определяющих вероятность:

Z = β0+ β1×1+…+ βkxk

pi=F(Zi)

·gompit-модель, вероятности в которой рассчитываются по формуле:

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

где n — суммарное число наблюдений, n1 — число наблюдений, в которых y принимает значение 1.

Рассчитываются показатели качества модели:

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

k — число параметров модели, n — число наблюдений, ln L — максимизированное наименьшие значения критериев.

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

Таблица 4. Информационные критерии

LogitProbitGompitAIC1.1639691.1587391.142302SC1.3040891.2988591.282422HQ1.2087951.2035651.187128

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

Получаем следующее регрессионное уравнение:

Тогда:

Таблица 5. Вероятности частых сверхурочных

Как видно, при появлении циклов ПВР действительно вероятность того, что будут увеличены сверхурочные работы, не велика. При этом, практически в каждом случае появления новых вводных, из-за которых объемы запланированных работ изменяются более, чем на 30%, увеличиваются сверхурочные работы. Скорее всего это обусловлено тем, что в большинстве случаев респонденты в анкете указывали, что новые вводные добавляются в проект после 50%-ой его реализации (поэтому же переменная x2 была отброшена при построении регрессии, т.к. в ней количество «успехов», то есть случаев, когда переменная принимает значение равное 1, значительно превышает количество «провалов»; использование подобной переменной негативно влияет на качество построение регрессии по бинарным переменным). Данный вывод интересен в силу того, что многими из респондентов указывалось в ходе глубинного интервью, что в большинстве проектов использовалась методология Agile, которая позволяет с наименьшим ущербом вносить изменения на поздних стадиях реализации проекта.

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

y — смена команды;

x1 — сверхурочные работы;

x2 — появление циклов ПВР;

x3 — процент изменения запланированных работ в результате получения новых вводных (при более, чем на 20%, принимается равным 1).

здесь наиболее оптимальной моделью из бинарных моделей оказалось probit-модель.

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

Далее была построена бинарная регрессияy — превышение фактических сроков над плановыми;

x1 — решение о смене команды;

x2 — появление циклов ПВР;

x3 — сверхурочные работы.

Таблица 6. Матрица корреляции. Превышение плановых сроков

YX1X2X3Y10.0800.5770.032X10.08010.1450.015X20.5770.1451-0.154X30.0320.015-0.1541

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

Таблица 7. вероятность превышения плановых сроков

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

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

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

.3 Управление циклами ПВР

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

одна из моделей, позволяющих это сделать, рассматривалась в работе Kut C. So и Christopher S. Tang [43]. В своем ключевом моменте она напоминает модель, описанную последней в предыдущем разделе — учитываются затраты на ожидание объекта к проведению повторной проверки, т.е. ожидание к попаданию в цикл ПВР. Исследователи выделяют целью своей работы оптимизация процесса в узком месте — «горлышко» («bottleneck»), которое оказывает влияние на стоимость всего проекта. При прохождении объектов через «горлышко» принимается решение, переключиться дальше на цикл ПВР, либо запустить проверку следующего объекта. При запуске цикла ПВР другие объекты выполненных работ ожидают в буфере обычных работ; при запуске проверки выполненных работ, объекты, отправленные на доработку, ожидают в буфере цикла ПВР:

Рисунок 23. Цикл ПВР с "горлышком"; Ист. [43]

Вводятся следующие параметры:

·Время, затрачиваемое на обработку обычных объектов, является случайной величиной со случайным распределением и средним значением u;

·q — вероятность перехода объекта из статуса «обычных» работ в статус «дефектных» работ;

·время, затрачиваемое на обработку дефектных работ (цикл ПВР), является случайной величиной со случайным распределением и средним значением v (причем, подразумевается время, затрачиваемое на полное исправление объекта, т.е. сумма продолжительности всех циклов ПВР, которые проходит объект);

·B — объем работ; для объектов в статусе «обычные» работы объем фиксированный и удовлетворяет условию ≥1;

· и — время (независимые случайные величины) переключения процесса из обработки «обычных» работ в обработку «дефектных» работ (уточняется, что переключение из обработки «дефектных» работ происходит только после исправления всех доступных к доработке объектов);

· — количество объектов, находящихся в буфере цикла ПВР.

Соответственно, стоимостная структура процесса включает три пункта:

· — затраты на хранение объектов, когда запущен процесс доработки деффектных объектов;

· — вознаграждение за каждый объект, когда запущен процесс обработки «обычных» объектов (эквивалентно ru за обработку «обычного» объекта);

·s — фиксированная ставка за переключение процесса обработки «обычных» работ на процесс доработки дефектных работ и обратно (не зависит от и ).

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

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

количество переключений процессов (n*) снижается с увеличением ставки h, при этом общая средняя стоимость g увеличивается (обусловлено тем, что с увеличением ставки за хранение объектов, ожидающих проверки, увеличивается время, затрачиваемое на доработку объектов для снижения количества циклов ПВР):

Рисунок 24. влияние увеличения ставки h на n и g; Ист. [43]

Интересным является еще один результат: при высоком количестве объема работ (высокое B) n снижается при увеличении вероятности того, что объект окажется дефектным (q); при низком B увеличение q, наоборот, влечет за собой увеличение n:

Рисунок 25. влияние q и B на n; Ист. [43]

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

Таким образом, в данной главе были получены следующие выводы:

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

·Параллельное выполнение работ;

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

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

)Наиболее интересные количественные результаты наблюдений:

·появление циклов ПВР оказывает значительное негативное влияние на продолжительность реализации проекта (увеличение сроков);

·Запараллеливание работ наиболее оптимально при запуске выполнения последующей работы на 60%-ом уровне завершения предыдущей работы (для IT-проектов, на 30% уровне);

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

·В условиях использования Agile-методологии в управлении IT-проектами ввод новых данных на поздних стадиях реализации проекта приводит к увеличению сверхурочных работ, если изначально запланированные работы корректируются более, чем на 30%: связано с тем, что при использовании Agile-методологии размывается финальная общая цель реализации проекта и достижение стратегической цели компании путем реализации данного проекта, четкое понимание которой необходимо для высокой производительности и мотивации членов команд;

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

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

Глава 3. рекомендации по снижению продолжительности IT-проектов через учет циклов ПВР

3.1 Моделирование ситуации

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

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

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

рисунок 26. Потоковая диаграмма, трудозатраты

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

Рисунок 27. Изменение трудозатрат при вводе новых данных

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

Рисунок 28. Потоковая диаграмма: влияние трудозатрат на процент выполненной работы

рисунок 29. Влияние трудозатрат на процент выполненной работы

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

Рисунок 30. Потоковая диаграмма: трудозатраты при ПВР

Рисунок 31. Изменение трудозатрат при ПВР и получении новых данных

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

Рисунок 32. Потоковая диаграмма: продолжительность ПВР и продолжительность проекта

Рисунок 33. Изменение трудозатрат и ПВР: обратная связь

Как видно, продолжительность циклов ПВР снижается через увеличение трудозатрат на проекте. При этом, продолжительность всего проекта в целом увеличивается, что обусловлено большим количеством трудозатрат на проекте, которые проходят через стадию адаптации и набора опыта. Но стадия завершения проекта наступает быстрее, в силу того, что, как было показано ранее в статистическом анализе и уточнено в ходе проведения глубинного интервью, адаптация сотрудников не занимает большого количества времени и не оказывает значительного влияние на превышение плановых сроков над фактическими. При этом управление увеличением трудозатрат можно снизить продолжительность работ и оказать значительное влияние на более скорое достижения стадии завершения проекта. Как видно, продолжительность циклов ПВР значительно падает уже при увеличении трудозатрат на 20%; при большем относительном изменении команды значительного эффекта на снижение продолжительности циклов ПВР не оказывается, а негативное влияние на продолжительность работ остается. Таким образом, оптимальным изменением состава команды составляет 20-25%.

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

рисунок 34. Потоковая диаграмма: нахлест работ и циклы ПВР

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

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

Из приведенного результата видно, что при нахлесте в 30% продолжительность проекта значительно сокращается, а при нахлесте в 60% значительно увеличивается, что говорит о том, что ранее выдвинутая гипотеза подтверждается.

.2 Управление IT-проектами в госсекторе

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

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

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

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

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

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

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

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

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

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

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

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

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

)продолжительность циклов ПВР снижается через увеличение трудозатрат на проекте;

)увеличение трудозатрат оптимально не более, чем на 25% для достижения наиболее оптимального результата по снижению продолжительности циклов ПВР и, соответственно, снижению продолжительности проекта без значительного ущерба качеству;

4)Допустимый размер нахлеста для оптимального расписания проекта — 30% завершения работы-предшественника; при 60% нахлесте продолжительность проекта увеличивается.

Выводы

В начале работы были сформулированы следующие гипотезы:

·Появление циклов ПВР и их продолжительность негативно влияют на проект (приводят к срыву сроков и превышению бюджета).

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

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

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

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

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

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

)запараллеливание работ с лагом в 30% для получения оптимального количества информации;

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

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

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

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

Таким образом возможно применение следующих рекомендаций для управления сроками реализации IT-проектов:

)на стадии инициации и планирования проекта при подготовке расписания проекта учитывать необходимость запараллеливания допустимых работ не более и не менее, чем на 30%-40%;

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

)при получении новых вводных в процессе реализации проекта увеличивать трудозатраты не более, чем на 20-25%;

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

)при получении новых вводных в процессе реализации проекта необходимо корректировать расписания на 60% путем добавления временного буфера после окончания цикла ПВР.

список использованной литературы

1.Каталевский, Д.Ю. «Основы имитационного моделирования и системного анализа в управлении», 2011

2.Abdel-Hamid, T.K., Madnick, S., «Software productivity: potential, actual, and perceived», 1989

3.Berthaut, F., Greze, L., Pellerin, R., Perrier, N., Hajji, A. «Optimal Resource-Constraint Project Scheduling with Overlapping Modes», 2011

4.Cioffi, D.F. «Completing Projects According to Plans: An Earned-Value Improvement Index» The Journal of the Operational Research Society, Vol. 57, No. 3 (Mar., 2006), pp. 290-295

5.Cooper, K.G. «Naval ship production: a claim settled and a framework built», 1980, Interfaces 10(6): 20-36

6.Cronin M.A., Bezrukova K., Weingart L.R., Tinsley C.H. «Subgroups within a team: The role of cognitive and affective integration», Journal of Organizational Behavior. Aug2011, Vol. 32 Issue 6, p831-849

7.Dangerfield, B., Roberts, C. «An Overview of Strategy and Tactics in System Dynamics Optimization», The Journal of the Operational Research Society, Vol. 47, No. 3 (Mar., 1996), pp. 405-423

8.Daniel, W. D. «Hard problems in a soft world», 1990

9.Davies, R.M.G., Saunders, R.G. «Applying systems theory to project management problems», 1988

10.Duffuaa, S.O., Khan, M. «An Optimal Repeat Inspection Plan with Several Classifications», The Journal of the Operational Research Society, Vol. 53, No. 9 (Sep., 2002), pp. 1016-1026

11.Dutta, A., Roy, R. «A Process-Oriented Framework for Justifying Information Technology Projects in e-Business Environments», International Journal of Electronic Commerce, Vol. 9, No. 1, Measuring the Business Value of Information Technology in e-Business Environments (Fall, 2004), pp. 49-68

12.Eden, C., Williams, T., Ackermann, F., Howick, S. «The Role of Feedback Dynamics in Disruption and Delay on the Nature of Disruption and Delay (D&D) in Major Projects», The Journal of the Operational Research Society, Vol. 51, No. 3 (Mar., 2000), pp. 291-300

13.Ford, D. N. and J. D. Sterman (1998). «Dynamic modeling of product development processes» System Dynamics Review 14(1): 31-68.

14.Ford, D. N. and J. D. Sterman (2003). «Overcoming the 90% syndrome: Iteration management in concurrent development projects. » Concurrent Engineering-Research and Applications 11(3): 177-186.

15.Gardener, T., Moffat, J. «Changing Behaviours in Defence Acquisition: A Game Theory Approach», The Journal of the Operational Research Society, Vol. 59, No. 2, Operational Research in Government (Feb., 2008), pp. 225-230

16.Harter, D.E., Krishnan, M.S., Slaughter, S.A. «Effects of Process Maturity on Quality, Cycle Time, and Effort in Software Product Development», Management Science, Vol. 46, No. 4, Information Technology Industry (Apr., 2000),pp. 451-466

17.Hadjinicola, G.C. «Manufacturing Costs in Serial Production Systems with Rework», The Journal of the Operational Research Society, Vol. 61, No. 2 (Feb., 2010), pp. 342-351

18.Howick, S. «Using System Dynamics to Analyse Disruption and Delay in Complex Projects for Litigation: Can the Modelling Purposes Be Met?», The Journal of the Operational Research Society, Vol. 54, No. 3 (Mar., 2003), pp. 222-229

19.Howick, S., Eden, C. «The Impact of Disruption and Delay When Compressing Large Projects: Going for Incentives?», The Journal of the Operational Research Society, Vol. 52, No. 1 (Jan., 2001), pp. 26-34

20.Howick, S., Eden, C. «On the Nature of Discontinuities in System Dynamics Modelling of Disrupted Projects», The Journal of the Operational Research Society, Vol. 55, No. 6 (Jun., 2004), pp. 598-605

21.Lane, D.C. «Diagramming Conventions in System Dynamics», The Journal of the Operational Research Society, Vol. 51, No. 2 (Feb., 2000), pp. 241-245

22.Lee, L.S., Anderson, R.M. «An Exploratory Investigation of the Antecedents of the IT Project Management Capability», e-Service Journal, Vol. 5, No. 1 (Fall 2006), pp. 27-42

23.Levitt, R. E., J. Thomsen, T. R. Christiansen, J. C. Kunz, Y. Jin and C. Nass (1999). «Simulating project work processes and organizations: Toward a micro-contingency theory of organizational design» Management Science 45(11): 1479-1495.

24.Love, P.E.D., Holt, G.D., Shen, L.Y., Li, H., Irani, Z. «Using systems dynamics to better understand change and rework in construction project management systems», 2000; IJPM 20 (2002) 425-43

25.Lyneis, J.M., Cooper, K.G., Els SA. 2001. «Strategic management of complex projects: a case study using system dynamics» System Dynamics Review 17: 237-260

26.Lyneis, J.M., Ford, D.N. «System dynamics applied to project management: a survey, assessment, and directions for future research», 2007

27.Makhov, S.A. «Mathematical simulation of world dynamics and sustainable development by the example of Forrester’s model», Preprint, Inst. Appl. Math., the Russian Academy of Science, 2006

28.Maxwell, K., Luk Van Wassenhove, Dutta, S., «Performance Evaluation of General and Company Specific Models on Software Development Effort Estimation», Management Science, Vol. 45, No. 6 (Jun., 1999), pp. 787-803

29.Morris, M., Hough, G.H. « The Anatomy of Major Projects: Study of the Reality of Project Management», 1987

30.Niehaves, B., Klose, K., Becker, J.: «Governance Theory Perspectives on IT Consulting Projects: The Case of ERP Implementing», e-Service Journal, Vol. 5, №1 (Fall 2006), pp. 5-26

31.Park, M, Pena-Mora, F. 2003. «Dynamic change management for construction: introducing the change cycle into model-based project management» System Dynamics Review 19(3): 213-242

32.Pinto, J.K. «Lies, damned lies, and project plans: Recurring human errors that can ruin the project planning process», 2013 Kelley School of Business, Indiana University. Published by Elsevier Inc.

33.Rahmandad, H., Kun Hu, «Modeling the rework cycle: capturing multiple defects per task», System Dynamics Review vol 26, No 4 (October-December 2010), pp. 291-315

34.Richardson, G. P. and A. L. Pugh (1981). «Introduction to system dynamics modeling with DYNAMO» Cambridge, Mass., MIT Press.

35.Roberts, N. «Teaching Dynamic Feedback Systems Thinking: An Elementary View», Management Science, Vol. 24, No. 8 (Apr., 1978), pp. 836-843

36.Rodrigues, A, Bowers, J. «The role of system dynamics in project management», International Journalof Project Management 1996;14(4):1996 213-220

37.Rodrigues, A., Bowers, J. «System dynamics in project management: a comparative analysis with traditional methods», 1996

38.Rodrigues, A. G., Williams, T. M. «System Dynamics in Project Management: Assessing the Impacts of Client Behaviour on Project Performance» The Journal of the Operational Research Society, Vol. 49, No. 1 (Jan., 1998), pp. 2-15

39.Saboo, S., Wang, L., Wilhelm, W.E. «Recursion Models for Describing and Managing the Transient Flow of Materials in Generalized Flowlines», Management Science, Vol. 35, No. 6 (Jun., 1989), pp. 722-742

40.Saunders, R.G. «Project management: a systems perspective», 1992

41.Sengupta, K. and T. K. Abdelhamid (1993). «Alternative Conceptions of Feedback in Dynamic Decision Environments — an Experimental Investigation» Management Science 39(4): 411-428

42.Smith, B.J., Nguyen, N., Vidale, R.F., 1993 «Death of a software manager: how to avoid career suicide through dynamic software process modeling» American Programmer 6(5): 10-17

43.So, K.C., Tang, C.S. «Optimal Operating Policy for a Bottleneck with Random Rework», Management Science, Vol. 41, No. 4 (Apr., 1995), pp. 620-636

44.Sterman, J. (2000). «Business Dynamics: systems thinking and modeling for a complex world» Irwin, McGraw-Hill.

45.Weingart L.R., Cronin M.A., Bezrukova K., Tinsley C.H. «Subgroups within a team: The role of cognitive and affective integration», Journal of Organizational Behavior. Aug2011, Vol. 32 Issue 6, p831-849

46.Williams, T., Eden, C., Ackermann, F., Tait, A. «The Effects of Design Changes and Delays on Project Costs», The Journal of the Operational Research Society, Vol. 46, No. 7 (Jul., 1995), pp. 809-818

47.Williams, T.M., 1999. «Seeking optimum project duration extensions. Journal of the Operational Research Society 50: 460-467

48.Wrigley, C.D., Dexter, A.S., «A Model for Measuring Information System Size», MIS Quarterly, Vol. 15, No. 2 (Jun., 1991), pp. 245-257

49.Yeo, K.T. «Systems thinking and project management — time to reunite», 1993

50.Yu, S.B., Efstathiou, J. «Complexity in Rework Cells: Theory, Analysis and Comparison», The Journal of the Operational Research Society, Vol. 57, No. 5 (May, 2006), pp. 593-602

приложение

1.1 Форма анкеты

Укажите Ваш пол: *

o Мужской

o женский

В какой отрасли преимущественно работает Ваша компания: *

o строительство

o Промышленность

o Торговля

o IT

o Консалтинг

o Банки

o Другое:

Тип учреждения: *

o Коммерческое

o Государственное

Вы являетесь: *

o Менеджером проекта

o Участником команды проекта

o Другое:

Как часто фактическая продолжительность сопровождаемых Вами проектов превышала плановую: *

o Все проекты выполнялись ли в установленный срок, либо ранее

o В 25% проектов

o В 50% проектов

o В 75% проектов

o Во всех сопровождаемых проектах

Имело ли место отклонение фактических затрат от плановых в сопровождаемых Вами проектах? *

o Да

o Нет

Имело ли место получение новых вводных в проекте после его запуска? *

o Да, на этапе планирования проекта

o Да, на этапе реализации проекта (менее 25% реализации проекта)

o Да, на этапе реализации проекта (от 25% до 50% реализации проекта)

o Да, на этапе реализации проекта (от 50% до 75% реализации проекта)

o Да, на этапе завершения проекта

o Нет

Насколько получение новых вводных изменяло состав работ относительно первоначально установленного? *

o Менее, чем на 15%

o Менее, чем на 30%

o менее, чем на 45%

o Более, чем на 45%

Принималось ли в процессе выполнения проекта решение об изменении состава команды? *

o Да, в части увеличения количества участников

o Да, в части уменьшения количества участников

o Да, в части замены участников новыми людьми

o Нет

Как часто членам команды приходилось работать сверхурочно? *

o 1 раз в неделю

o 2-3 раза в неделю

o Чаще 3х раз в неделю

o Не приходилось

Какой процент выполняемых работ от общего объема работ проходил через повторное выполнение (доработки)? *

o менее 10%

o 10-19%

o 20-29%

o 30-39%

o 40% и более

o Не возникало повторного выполнения работ

Что в большей мере оказывалось причиной появления циклов ПВР?

o Появление новых вводных

o Не соответствие результатов изначальным требованиям

o некачественное выполнение работ

o Недостаток информации для выполнения работы из-за незавершенности связанных работ

o Другое:

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

Оцените от 1 до 7, где 1 — не оказывал; 7 — являлся основной причиной

1234567Сжатые сроки выполнения работНе достаточно детальное изучение возможных рисков на этапе планирования проектовДлительная адаптация новых членов командыНизкая мотивация членов командыЧастые сверхурочные членов командыПлохо налаженные коммуникации внутри команды

Оцените степень оказанного влияния циклами ПВР на превышение сроков реализации проекта:

Оцените от 1 до 7, где 1 — не оказало влияния; 7 — оказало сильное влияние

1234567

Оцените степень оказанного влияния циклами ПВР на превышение запланированного бюджета:

Оцените от 1 до 7, где 1 — не оказало влияния; 7 — оказало сильное влияние

1234567

Если применялись меры по контролю циклов ПВР, перечислите их:

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

Если у Вас возникли вопросы или замечания по анкете, напишите их, они будут учтены при исследовании. Спасибо!

структура глубинного интервью

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

.Закладывали ли Вы при первоначальном планировании сроков проекта временной буфер на выполнение доработок некоторых работ? Каким образом Вы определяла наиболее необходимые места для установки данного буфера?

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

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

.Знакомы ли Вам понятия аффективной и когнитивной интеграции? Учитывали ли Вы данные явления при составлении команды проекта?

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

Регрессионный анализ. Сверхурочные работы.

Dependent Variable: YMethod: ML — Binary Probit (Quadratic hill climbing)Date: 04/25/15 Time: 13:03Sample (adjusted): 1 30Included observations: 30 after adjustmentsConvergence achieved after 4 iterationsCovariance matrix computed using second derivativesVariableCoefficientStd. Errorz-StatisticProb. X11.0639830.1645083.7037160.0084X3-0.5444860.242271-2.0040850.0321C0.1750640.4557102.6961580.0070McFadden R-squared0.112813 Mean dependent var0.766667S.D. dependent var0.430183 S.E. of regression0.409704Akaike info criterion1.163969 Sum squared resid4.532154Schwarz criterion1.304089 Log likelihood-14.45954Hannan-Quinn criter.1.208795 Deviance28.91908Restr. deviance32.59637 Restr. log likelihood-16.29818LR statistic31.67723 Avg. log likelihood-0.481985Prob(LR statistic)0.001593Dependent Variable: YMethod: ML — Binary Logit (Quadratic hill climbing)Date: 04/25/15 Time: 13:04Sample (adjusted): 1 30Included observations: 30 after adjustmentsConvergence achieved after 4 iterationsCovariance matrix computed using second derivativesVariableCoefficientStd. Errorz-StatisticProb. X11.8325810.1360123.6405610.0082X3-1.0296190.183244-2.0032070.0029C0.3364720.4100712.5607890.0067McFadden R-squared0.117626 Mean dependent var0.766667S.D. dependent var0.430183 S.E. of regression0.407640Akaike info criterion1.158739 Sum squared resid4.486597Schwarz criterion1.298859 Log likelihood-14.38109Hannan-Quinn criter.1.203565 Deviance28.76218Restr. deviance32.59637 Restr. log likelihood-16.29818LR statistic31.83418 Avg. log likelihood-0.479370Prob(LR statistic)0.001473Dependent Variable: YMethod: ML — Binary Extreme Value (Quadratic hill climbing)Date: 04/25/15 Time: 13:04Sample (adjusted): 1 30Included observations: 30 after adjustmentsConvergence achieved after 4 iterationsCovariance matrix computed using second derivativesVariableCoefficientStd. Errorz-StatisticProb. X11.6961690.1323143.6318730.0065X3-1.0736590.179056-2.0031510.0014C0.6336850.3970222.5577820.0005McFadden R-squared0.132754 Mean dependent var0.766667S.D. dependent var0.430183 S.E. of regression0.402281Akaike info criterion1.142302 Sum squared resid4.369400Schwarz criterion1.282422 Log likelihood-14.13453Hannan-Quinn criter.1.187128 Deviance28.26907Restr. deviance32.59637 Restr. log likelihood-16.29818LR statistic32.01711 Avg. log likelihood-0.471151Prob(LR statistic)0.001102

Регрессионный анализ. Смена команды

Dependent Variable: YMethod: ML — Binary Probit (Quadratic hill climbing)Date: 04/25/15 Time: 13:38Sample (adjusted): 1 30Included observations: 30 after adjustmentsConvergence achieved after 4 iterationsCovariance matrix computed using second derivativesVariableCoefficientStd. Errorz-StatisticProb. X10.2210850.7187290.3076050.0084X20.5523890.3970222.5577820.0005X30.0617950.7217690.0856160.0078C0.6970140.7956120.8760730.0038McFadden R-squared0.033197 Mean dependent var0.866667S.D. dependent var0.345746 S.E. of regression0.362853Akaike info criterion1.025944 Sum squared resid3.423224Schwarz criterion1.212771 Log likelihood-11.38917Hannan-Quinn criter.1.085712 Deviance22.77833Restr. deviance23.56047 Restr. log likelihood-11.78023LR statistic0.782136 Avg. log likelihood-0.379639Prob(LR statistic)0.853735Obs with Dep=04 Total obs30Obs with Dep=126

Регрессионный анализ. Превышение плановых сроков

Dependent Variable: YMethod: ML — Binary Probit (Quadratic hill climbing)Date: 04/25/15 Time: 15:08Sample (adjusted): 1 30Included observations: 30 after adjustmentsConvergence achieved after 4 iterationsCovariance matrix computed using second derivativesVariableCoefficientStd. Errorz-StatisticProb. X10.0197600.7432960.0265850.0788X22.0069250.6855792.9273430.0034X30.6523570.6809550.9580030.0381C-0.9379040.919669-1.0198280.0062McFadden R-squared0.302548 Mean dependent var0.600000S.D. dependent var0.498273 S.E. of regression0.429046Akaike info criterion1.205453 Sum squared resid4.786095Schwarz criterion1.392280 Log likelihood-14.08180Hannan-Quinn criter.1.265221 Deviance28.16360Restr. deviance40.38070 Restr. log likelihood-20.19035LR statistic12.21710 Avg. log likelihood-0.469393Prob(LR statistic)0.006675Obs with Dep=012 Total obs30Obs with Dep=118

Учебная работа. Инструменты управления проектами