Реферат: Spider Project - первая российская система управления профессионального уровня

1. Введение

Нарынке программных средств управления проектами в России наряду с известнымизарубежными пакетами, такими как Microsoft Project, Open Plan, Suretrak,Primavera Project Planner присутствует и Российский пакет Spider Project. ВРоссии этот пакет наиболее популярен и используется крупнейшими корпорациямидля управления самыми престижными проектами.

Упакета Spider Project много отличий от своих зарубежных аналогов, которыеделают его привлекательным для Российских потребителей. Это связано и спринятой в России технологией управления проектами, которая отличается от той,которая лежит в основе зарубежных пакетов, и с тем вниманием, которое в Россиитрадиционно уделяется оптимизации использования ресурсов и адекватностиматематических моделей объектов. Вообще в России складывается впечатление, чтоне пакеты управления проектами разрабатываются для поддержки технологииуправления проектами, а наоборот методология управления проектами и в том числеA Guide tо the PMBOK исходит из возможностей программных средств. Так,например, в России практически во всех областях приложения управления проектамипланируются физические объемы работ, а длительность рассчитывается исходя изпроизводительностей назначенных ресурсов, а не является исходной информацией.

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

2. Структура данных

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

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

2.1. Операции

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

2.2. Взаимосвязи работ

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

2.3. Ресурсы

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

2.4. Календари

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

2.5. Назначения

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

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

Ресурсы,принадлежащие различным командам, работают на операции независимо. При этомможно задать объемы или длительности работ для каждой команды, а можно этого ине делать. Последнее означает, что команда будет работать, пока операция небудет выполнена. При этом к ней могут присоединяться и другие назначенныекоманды, но может создаться и ситуация, когда работа будет закончена до того,как некоторые из назначенных команд приступят к исполнению операции. Такойподход позволяет эффективно моделировать сменную работу. Ресурсы могут бытьназначены на исполнение операции частично. Тогда в Spider Project задаетсяпроцентная загрузка назначенных ресурсов наряду с количеством. Тем самым несоздается ситуация, обычная для других пакетов, когда необходимое количестворесурсов остается неизвестным (две единицы ресурса с 50% загрузкой в другихпакетах эквивалентны одной единице, загруженной полностью).

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

2.6. Стоимости

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

2.7. Центры

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

2.8. Иерархические структуры

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

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

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

2.9. Архивы

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

3. Вычисления

Задачи,решаемые с помощью пакетов управления проектами обычно включают: n разработкурасписания исполнения проекта без учета ограниченности ресурсов, n разработкурасписания исполнения проекта с учетом ограниченности ресурсов (leveling), nопределение критического пути и резервов времени исполнения операций проекта, nопределение потребности проекта в финансировании, материалах и оборудовании влюбые периоды времени, n определение распределения во времени загрузкивозобновляемых ресурсов, n анализ рисков и планирование расписания и другиххарактеристик проекта с учетом рисков, n ведение учета исполнения, n анализотклонений хода работ от запланированного (в том числе Earned Value Analysis) ипрогнозирование основных параметров проекта.

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

3.1. Расписание исполнения проекта сучетом ограниченности ресурсов

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

 Какни странно, но для этого проекта расписания, составляемые другими пакетами приусловии, что имеется только один Аналитик и один Менеджер, на три неделидлиннее. В большинстве реальных проектов расписания Spider Project существеннокороче расписаний, составляемых другими пакетами при тех же ограничениях наресурсы проекта. Не менее важной является и устойчивость расписания, особеннона фазе исполнения.

Впроцессе исполнения оставшиеся плановые длительности операций меняются, поэтомуи расписания, составленные пакетами в автоматическом режиме могут оказатьсясовершенно другими. Так, например, изменив плановую длительность операции“Negotiations with Vendors” в нашем примере с 15 дней на 14, вы получитесовершенно другое расписание в пакете Microsoft Project. Изменение длительностиоперации на один день влечет за собой изменение планового срока завершенияпроекта на три недели в ту или другую сторону! Новое расписание будетоптимальным, соответствующим расписанию Spider Project, однако встает вопрос — а что, если вы уже заключили контракты, запланировали поставки и т.д.? С этогомомента вы не сможете использовать автоматический расчет расписания проекта,если только вы не пересмотрите свои соглашения. Именно поэтому в пакете SpiderProject имеется дополнительная опция — поддержка расписания предыдущей версиипроекта, в качестве которой вы можете выбрать любую версию из архива проекта.

3.2. Критический путь и резервы

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

Поэтомув Spider Project вычисляется ресурсный критический путь и резервы сроковисполнения операций с учетом ограниченности ресурсов. Мы довольно давнопредлагали эту концепцию (в частности, в презентациях на конференциях PMI иконгрессе IPMA в Париже в 1996 году) и рады тому, что сейчас концепцииресурсного критического пути стали уделять внимание. Имея возможность определенияи использования ресурсного критического пути и ресурсных резервов, мыкритически относимся к теории Critical Chain.

3.3. Определение потребности проекта вфинансировании, материалах и оборудовании

Вбольшинстве пакетов вычисляются потребности проекта в финансировании,материалах и оборудовании на базе составленного расписания проекта. Еслитребуемое финансирование или поставки материалов не могут быть обеспечены, топользователи вынуждены корректировать графики вручную. В пакете Spider Projectможно моделировать не только расходы финансовых средств, но и доходы, не толькопотребление материалов, но и поставки. Тем самым можно подсчитать не толькозатраты проекта, но и Cash Flow, отслеживать не только потребности, но идвижение материалов. Кроме того, в Spider Project можно рассчитать расписаниеисполнения проекта с учетом не только ограниченности возобновляемых ресурсов,но и графиков поставок и финансирования, причем не только по суммарнымзатратам, но и по отдельным составляющим и центрам затрат и материалов.

3.4. Определение распределения во временизагрузки возобновляемых ресурсов

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

3.5. Анализ рисков и планирование с учетомрисков

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

3.6. Ведение учета исполнения

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

3.7. Анализ отклонений хода работ отзапланированного

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

4. Базы данных

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

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

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

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

Потехнологии разработки расписания проекта, которую мы внедряем и котораяподдерживается пакетом Spider Project, проекты составляются из фрагментов. Приэтом, добавляя в проект очередной фрагмент, пользователь отвечает на запрос ореальном объеме работ фрагмента в проекте и Spider Project автоматическиизменяет объемы работ фрагмента при вставке в проект, заодно корректируяпотребности в материалах и стоимости работ. Интересным побочным эффектомиспользования библиотек типовых фрагментов является технология формированияиерархической структуры работ не сверху вниз, как обычно, а снизу вверх. Втакой структуре типовые фрагменты служат пакетами работ. Поскольку мы обычноиспользуем несколько структур в одном проекте, то технологии снизу вверх исверху вниз используются параллельно и взаимно дополняют друг друга.

5. Отчеты

Нарядусо стандартными графическими отчетами — диаграммой Гантта, сетевой диаграммой,диаграммами загрузки ресурсов, расхода материалов и графиками затрат по проектуи отдельным фазам, Spider Project предлагает пользователям Ресурсную диаграммуГанта и Линейную диаграмму, которые будут описаны далее.

5.1. Ресурсная диаграмма Ганта

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

5.2. Гистограммы загрузки ресурсов

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

5.3. Линейная диаграмма

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

6. Заключение

ВРоссии выработаны собственные подходы к управлению проектами в России, которыеотличаются от принятых в других странах и описанных в A Guide to the PMBOK. Этиотличия нашли свое отражение и в Российском пакете управления проектами SpiderProject.

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

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

Список литературы

ВладимирЛиберзон, Россия Игорь Лобанов, Нидерланды