Проекты особенно чувствительны к рискам потому что ответ

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

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

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

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

1. Отсутствие менеджера проекта

Коллективная ответственность — это не всегда эффективно. Если сотрудники не понимают, кто поможет решить проблему и к кому можно обратиться с вопросом — проект рискует превратиться в хаос.

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

2. Недостаточное внимание рискам

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

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

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

3. Отсутствие контроля за исполнением задач

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

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

Источник

Риски проекта: анализ, оценка и стратегии управления

Эту статью мы написали вместе с Анастасией Борисюк, руководителем проектной группы в Актион Технологии. Вот ее телеграм-канал.

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

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

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

Время на чтение: 9 минут

Что будет в статье:

Какие бывают источники рисков

Шаблон реестра рисков

Как выбрать стратегию управления рисками

Что такое риски

Прежде чем понять, как работать с рисками, давайте проговорим, что это такое и какие они бывают.

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

Риски можно делить на внешние и внутренние.

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

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

Также можно категоризировать риски по этапам проекта.

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

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

В статье вы встретитесь с терминами, которые могут быть вам незнакомы. Их использует в своей работе Анастасия Борисюк в Актион Технологии. Давайте введем определения, чтобы говорить на одном языке.

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

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

Как работать с рисками

Рабочая неделя начинается с проверки Google-календаря. На сегодня у вас стоит созвон с Оливией — опытным проджектом, которая давно работает в компании и будет вашим ментором.

Вы заходите в Google Meet

Вы открываете почту, переходите по ссылке и погружаетесь в чтение.

Как анализировать риски

Работа с рисками начинается с их анализа. Он включает три этапа: выявление проблем, определение причин возникновения этих проблем и систематизация причин.

Рассмотрим подробнее каждый этап.

Как выявлять проблемы

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

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

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

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

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

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

Как определять причины проблем

Чтобы предотвратить проблемы, нужно определить их триггеры — причины возникновения. Для этого можно воспользоваться методом “5 почему”.

Метод “5 почему” заключается в том, чтобы постепенно отвечать на вопрос “Почему это произошло?” Вопросов не обязательно должно быть пять — их может быть как больше, так и меньше. Главная задача — добраться до корневой причины.

Например, проблема в том, что команда не попала в оценку:

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

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

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

Как систематизировать причины

Причины, полученные с помощью метода “5 почему”, следует включить в реестр рисков — документ, в котором собраны все риски. Чем масштабнее, длительнее и сложнее становятся проекты, тем труднее контролировать ситуацию. Без централизованного мониторинга рисков вы можете что-то забыть или упустить.

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

Задание

Как вы думаете, какие риски относятся к этапу “Разработка”?

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

Вы вносите в реестр риски и их триггеры.

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

Бесплатный курс по проджект-менеджменту

За 5 часов вы узнаете, какие 5 soft skills необходимы для работы в проджект-менеджменте и как их развить

Как оценивать риски

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

Риски принято делить на три группы: высокий, средний и низкий:

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

С рисками из средней группы можно работать двумя способами:

1. Снизить их влияние и переместить в низкие

2. Переместить в высокие и составить план их отработки

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

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

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

Осталось разобраться с тем, как работать с этими рисками.

Читайте лучшие статьи о запуске и росте продуктов

Раз в неделю будем отправлять свежий дайджест вам на почту. Наc читает 12000 человек 🚀

Как управлять рисками

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

Составить план действий, чтобы риск не произошел.

Определить, что делать, если риск станет проблемой.

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

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

Стратегия «Принять риск»

Суть стратегии. При использовании данной стратегии проджект-менеджер принимает то, что риск станет проблемой, и сразу планирует ее решение.

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

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

Задание

Как вы думаете, какой риск можно принять?

Стратегия «Уклониться от риска»

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

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

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

Стратегия «Снизить влияние»

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

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

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

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

Стратегия «Передать другому»

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

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

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

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

Проработка рисков для SportLife

После чашки кофе вы приступаете к выбору стратегии управления выявленными рисками.

❌ Стратегия «Принять риск». Все ваши риски на этапе оценки достаточно значимы. Вы не можете просто принять их.

❌ Стратегия «Передать другому». Передать задачу другому тоже не получится — по договору все задачи по проекту лежат на вашей проектной команде.

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

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

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

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

Вы вносите план действий в реестр рисков и спешите показать Оливии результат.

Источник

Итоговый тест. «Ваш мини-РМР»

Комментарий к тесту

Данный тест содержит вопросы или утверждения с возможными ответами или продолжениями, похожие на те, которые предлагаются при сдаче экзаме­на на РМР (разд. 10.5) и охватывают основные разделы, обсуждаемые в посо­бии. Конечно, это только примеры вопросов, которых может уже и не быть в реальной базе вопросов PMI.

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

При сдаче реального экзамена вам будет предложено 200 вопросов и на один вопрос у вас будет примерно одна минута.

Пояснение к тесту.На каждое из предложенных ниже определений или фраз даны четыре продолжения или варианта ответа, обозначенные буллита­ми.Выберите одно, единственно верное, с вашей точки зрения.

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

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

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

• помогает структурировать все работы, которые необходимо сделать в проекте;

• определяет пакеты работ и работы с персональной ответственностью.

2. Система числового или буквенного кодирования СРР позволяет:

• идентифицировать и определять ее элементы;

• определять контрольные точки проекта;

• оценивать затраты на ее элементы;

• обеспечивать подтверждение значимости проекта.

3. Разногласия между заинтересованными лицами проекта должны разрешаться в пользу:

• генерального директора компании-исполнителя;

4. Правильная последовательность для деятельности по управлению рис­ками это:

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

• идентификация рисков, описание рисков, разработка методов реакции на риски, контроль рисков;

• идентификация рисков, разработка методов реакции на риски, контроль рисков;

• идентификация рисков, передача рисков, контроль рисков.

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

7. Что из нижеследующего наиболее важно для руководителя проекта:

• обладание степенью МВА (мастер делового администрирования) или DBA (доктор делового администрирования);

• знания и умения в области информационных технологий;

• высшее образование в технической области;

• хорошие способности к работе с людьми.

8. Проекты особенно чувствительны к рискам потому, что:

• есть закон Мэрфи: «Если что-нибудь может быть плохо, то это обяза­тельно будет!»

• каждый проект обладает уникальностью в некотором смысле;

• средства управления проектами обычно недоступны на уровне команды проекта;

• ресурсов всегда не хватает.

9. Критический путь называется критическим потому, что:

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

• он определяет общую длительность проекта;

• он может привести к проблемам реализации проекта и ему нужно осо­бое внимание.

• деятельность фирмы, многократно повторяющаяся в течение длитель­ного времени;

• инновационное мероприятие, реализуемое в условиях ограничений;

• подготовленная для дальнейшей реализации плановая документация;

• неограниченная во времени инициатива команды по решению проблемы.

11. График Гантта применяется в качестве рабочего инструмента:

• исключительно при планировании качества;

• только при построении S-кривой;

• при построении плана проекта и последующего управления проектом;

• только при отчетах вышестоящему руководству.

• может быть осуществлено постепенно, по мере наступления этой фазы или этапа;

• делается только в необходимом случае.

• имеет длительность, определенную руководителем проекта при планировании;

• работа, запланированная при составлении плана, но не выполненная в срок;

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

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

14. Статья затрат, определяемая как процент от сметы проекта, использу­ется для:

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

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

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

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

15. Среди девяти областей управления проектами по стандарту PMI есть:

16. Что из следующего верно относительно ограничений и предположений:

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

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

• ограничения предполагают, что ресурсы и поставщики рассматривают­ся как имеющиеся в наличии при планировании;

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

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

• руководитель проекта должен обеспечить, чтобы его команда не раскры­ла правды о риске поставщику до момента подписания контракта;

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

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

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

18. Диаграмма Гантта наиболее удобна для:

• отображения начала и окончания работ;

• отображения связей между работами;

• показа структуры разбиения работ;

• просмотра назначений ресурсов на работы.

19. Все утвержденные изменения в проекте должны быть отражены:

• в базовом (календарном) плане проекта;

• в плане управления изменениями;

• в плане контроля качества;

• в текущем плане проекта.

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

• разрешить, поскольку удовлетворение заказчика является главной це­лью;

• не разрешать, поскольку изменится масштаб проекта, кроме того, заказ­чик не заказывал это улучшение;

• внести изменения в план проекта, чтобы выполнить это улучшение;

• попросить заказчика выделить дополнительные средства для выполне­ния этого улучшения.

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

22. Что является целью Устава проекта:

• назначение куратора проекта;

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

• признание существования проектной команды, руководителя проекта и спонсора проекта;

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

24. Ваш недавний отчет о проекте содержит следующую информацию:
EV = 3000, АС = 3500, PV = 4000. Оценочный итоговый бюджет проекта:

• будет превышен на 16,7%;

• даст экономию в 16,7%;

• будет превышен на 85,7%;

• даст экономию в 85,7%.

25. Правила 50/50 или 50/100 применяются при:

• анализе имеющихся ресурсов;

26. Правило 20/80, или закон больших чисел Парето, также реализуется
и при управлении проектами, а именно:

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

• при управлении командой, временем и ресурсами;

• только при контроле вопросов качества;

• только в управлении рисками и временем.

27. Функциональные руководители:

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

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

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

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

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

• больший процент персонала работает в проектах весь рабочий день;

• руководитель проекта работает в проекте по совместительству с другой деятельностью;

• управленцы компании полностью заняты в проектах;

• руководитель проекта имеет много управленческой власти.

29. Проект считается успешным, когда:

• произведен продукт проекта;

• проект удовлетворяет требованиям заинтересованных лиц или превосходит их ожидания;

• спонсор проекта объявил об окончании проекта;

• продукт проекта передан в серийное производство.

30. В понятиях отчетности по заработанной стоимости проект считается
завершенным, когда:

Литература

2. Андерсен Э., Груде К., Хауг Т. Сфокусированное управление проектом. — М.: ФАИР-ПРЕСС, 2006.

3. Арчибальд Р. Управление высокотехнологичными программами и проек­тами/Пер. с англ. под ред. А. Д. Баженова. 2-е изд. — М.: ДМК Пресс, 2002.

4. Арчибальд Р. Управление высокотехнологичными программами и про­ектами / Пер. с англ. под общей ред. А. Д. Баженова. 3-е изд. — М.: ДМК Пресс, 2006.

5. Афанасьев Н. В., Рогожин В. Д., Рудыка В. И. Управление развитием пред­приятия: Монография. — Харьков: Издательский дом «ИНЖЭК», 2003.

7. Баттрик Р. Техника принятия эффективных управленческих решений. 2-е изд. / Пер. с англ. под ред. В. Н. Фунтова. — СПб.: Питер, 2006.

8. Безкоровайный В. П., Бурков В. Н., Воропаев В. И., Михеев В. Н., Секлето-ва Г. И., Титаренко Б. П. и др. Основы профессиональных знаний и на­циональные требования к компетенции специалистов по управлению проектами / Под ред. Воропаева. — М.: СОВНЕТ, 2001.

9. Бек К., Фаулер М. Экстремальное программирование: планирование. — СПб.: Питер, 2003.

10. Богданов В. Управление проектами в Microsoft Project 2002. Учебный курс. Автоматизированный менеджмент проектов. — СПб: Питер, 2003.

11. Богданов В. Управление проектами в Microsoft Project 2003. Учебный курс. Автоматизированный менеджмент проектов. — СПб: Питер, 2004.

12. Брукс Ф. Мифический человеко-месяц, или Как создаются программ­ные системы. — СПб.: Символ-Плюс, 2000.

13. Бурков В. Н., Новиков Д. А. Как управлять проектами. — М.: СИНТЕГ-ГЕО, 1997.

14. Бусыгин А. Деловое проектирование и управление проектом. — М.: Ин­ститут МВШСЭН, 2001.

16. Бьяфоре Б. Все по плану! Успешное управление проектами с использо­ванием Microsoft Project (+ CD-ROM). — М.: Русская Редакция, 2006.

17. Бэгьюли Фил. Управление проектом / Пер. с англ. — М.: Издательско-торговый дом «Гранд», ФАИР Пресс, 2002.

19. Гаврилов Н. Н., Карамзина Н. С. и др. Анализ и управление проектами. Практический курс: Учебное пособие. — М.: Российская экономическая академия, 2000.

20. Гейзлер П. С, Завьялова О. В. Управление проектами: практическое по­собие/ Под ред. Гейзлера. — Минск: Книжный Дом «Мисанта», 2005.

21. ГОСТ Р ИСО 10006-2005: Системы менеджмента качества. Руководство по менеджменту качества при проектировании. — М., 2005. ISO 10006: 2003 (Е). Quality management systems — Guidelines for quality management in projects (IDT).

22. Грачева М. В., Бабаскин С. Я., Волков И. М. Риск-анализ инвестиционно­го проекта: учебник для вузов. — М.: ЮНИТИ, 2001.

23. Грашина М., Дункан В. Основы управления проектами. — СПб.: Питер, 2006.

24. Грей Клиффорд Ф., Ларсон Эрик У. Управление проектами: практическое руководство. — М.: Дело и Сервис, 2003.

25. ДеМарко Т. Deadline. Роман об управлении проектами / Пер. с англ. — М.: Вершина, 2006.

26. ДеМарко Г., Листер Т. Вальсируя с медведями. Управление рисками в проектах по разработке программного обеспечения / Пер. с англ. — М.: Компания p.m. Office, 2005.

27. Дитхелм Г. Управление проектами. В 2 т. — СПб.: Издательский дом «Бизнес-пресса», Корпорация «Двадцатый Трест», 2003.

28. Заренков В. А. Управление проектами: Учебное пособие. — М.: АСВ; СПб.: СПбГАСУ, 2005.

29. Зубов A. Microsoft Project 2003. Популярный самоучитель. — СПб.: Пи­тер, 2005.

30. Иванец В. К., Резниченко В. С, Богданов А. В. Управление проектами и предприятиями в строительстве. — М.: Издательский дом «Слово», 2001.

31. Ильин В. Проектный офис — Центр управления. проектами. Систем­ный подход к управлению компанией. — М.: Вершина, 2007.

32. Ильин В. В. Руководство качеством проектов. Практический опыт. — М.: Вершина, 2006.

33. Исаев В. В. Организация работы команды проекта. Психология, страте­гия, тактика: учебное пособие. — СПб.: Издательский дом «Бизнес-прес­са», 2006.

34. Йордон Э. Путь камикадзе. Как разработчику программного обеспече­ния выжить в безнадежном проекте. — М.: ЛОРИ, 2001.

35. Йордон Э. Управление сложными интернет-проектами. — М.: ЛОРИ, 2003.

36. Кантор М. Управление программными проектами. — М.: Вильямс, 2002.

37. КендаллДж. И., Роллинз С. К. Современные методы управления портфеля­ми проектов и Офис управления проектом. — М: ЗАО «ПМСОФТ», 2004.

38. Керцнер Г. Стратегическое планирование для управления проектами с ис­пользованием модели зрелости. — М.: Компания АйТи; ДМК Пресс, 2003.

39. Клайм Р., Лудин И. Ноев проект. Экономический роман. Секреты прак­тического проектного менеджмента / Пер. с англ. — СПб.: Издательский дом «ВЕСЬ», 2002.

40. Коберн А. Быстрая разработка программного обеспечения. — М.: Лори, 2002.

41. Ковалев А., Курдюмов И. Управление проектом по созданию интернет-сайта. — М.: Альпина Паблишер, 2001.

42. Колесников А. А., Колесникова Т. Г., Олейник А. В. Управление качеством инновационных проектов. Методические рекомендации. — М.: Мини­стерство образования Российской Федерации, 2003.

43. Колосова Е. В., Новиков Д. А., Цветков А. В. Методика освоенного объема в оперативном управлении проектами. — М.: ООО НИЦ «Апостроф», 2000.

44. Королев Д. Эффективное управление проектами. — М.: ОЛМА-ПРЕСС Инвест: Институт экономических стратегий, 2003.

46. Куперштейн В. И. MS Project в делопроизводстве и управлении. — СПб.: БХВ-Петербург, 2003.

48. Лапыгин Ю. Управление проектами: от планирования до оценки эффек­тивности: Практическое пособие. — М.: Омега-Л, 2007.

49. Литке Х.Д., Кунов И. Управление проектами / Пер. с нем. — М.: Омега-Л, 2005.

50. Локк Д. Основы управления проектами / Пер. с англ. — М.: «HIPPO», 2004.

51. Мазур И. И., Шапиро В. Д. и др. Управление проектами. Справочник для профессионалов. — М.: Изд-во «Высшая школа», 2001.

52. Мазур И. И., Шапиро В. Д., Ольдерогге II. Г. Управление проектами: Учеб­ное пособие для вузов. — М.: ЗАО Издательство «Экономика», 2001.

53. Мазур И. И., Шапиро В. Д., Ольдерогге Н. Г. Управление проектами: Учеб­ное пособие / Под ред. И. И. Мазура. 2-е изд. — М.: Омега-Л, 2004.

54. Мартин П., ТейтК. Управление проектами / Пер. с англ. — СПб.: Питер, 2006.

55. Милошевич Д. Набор инструментов для управления проектами. — М.: ДМК Пресс, 2006.

57. Пайпе С. Проектный менеджмент: ускоренный курс / Пер. с нем. — М.: Дело и Сервис, 2005.

58. ПиитоДж. Управление проектами / Пер. с англ. под ред. В. Н. Фунтова. — СПб.: Питер, 2004.

60. Попов Ю. И., Яковенко О. В. Управление проектами. — М.: ИНФРА-М, 2005.

61. Портни С. Управление проектами для чайников / Пер. с англ. — М.: Ви­льямс, 2005. Постоянный адрес документа: http://www.iteam.ru/publica-tions/quality/article_558/

63. Пурба С, Зуккеро Д. Спасение проекта. Как избежать катастрофы при управлении проектом. — М.: НТ Пресс, 2007.

64. Разу М. Л., Воропаев В. И., Якутии Ю. В. и др. Управление программами и проектами: 17-модульная программа для менеджеров «Управление раз­витием организации». Модуль 8. — М.: ИНФРА-М, 2001.

65. Ройс У. Управление проектами по созданию программного обеспечения. — М.: Лори, 2002.

66. Романова М. В. Управление проектами: Учебное пособие. — М.: ИНФ­РА-М, 2007.

67. Руководство к Своду знаний по управлению проектам (Project Mana­gement Body of Knowledge — PMBoK). 3-е изд. — Project Management Institute, 2004.

68. Салливан Э. Время — деньги. Создание команды разработчиков программ­ного обеспечения. — М.: Русская редакция, 2002.

69. Смирнов В. С, Власов С. А., Ваулинский Е. С, Лебедев Б. И. Методы и модели управления проектами в металлургии. — М.: Синтег, 2001.

70. Стовер Т. Эффективная работа: Microsoft Project 2002. — СПб.: Питер, 2003.

71. Тернер Дж. Родни. Руководство по проектно-ориентированному управ­лению. — М.: Издательский дом Гребенникова, 2007.

72. Товб А. С, Ципес Г. Л. Управление проектами: стандарты, методы, опыт. — М.: ЗАО «Олимп-Бизнес», 2003.

73. Тренев В. Н., Магура М. И., Леонтьев С. В. Управление человеческими ресурсами при реализации проектов. — М.: ПРИОР, 2002.

74. Уикхэм Ф. Консалтинг в управлении проектами. — М.: Компания АйТи; ДМК Пресс, 2006.

75. Уилсон С., Мэйплс Б., Лэндгрейв Т. MCSD. Принципы проектирования и разработки программного обеспечения. — М.: Русская редакция, 2000.

76. Уильямс Д., Парр Т. Управление программами на предприятии. — Днеп­ропетровск: Баланс Бизнес Бук, 2005.

77. Управление инвестиционно-строительными проектами: международный подход: руководство / Под ред. И. И. Мазура, В. Д. Шапиро. — М.: Аввал-лон, 2004.

79. Управление проектами: Основы профессиональных знаний, национальные требования к компетенции специалистов по управлению проектами / Под ред. В. И. Воропаева. — М.: Консалтинговое Агентство КУБС Групп-Коо-перация, Бизнес-Сервис, 2001.

80. Уткин Э., Кравченко В. Проект-менеджмент. — М.: ТЭИС, 2002.

81. Фатрелл Роберт Т., Шафер Дональд Ф., Шафер Линда И. Управление программными проектами. Достижение оптимального качества при ми­нимуме затрат. — Минск: Вильяме, 2003.

82. Фатрелл Роберт Т., Шафер Дональд Ф., Шафер Линда И. Управление проектами в России. Основные понятия, история, достижения перспек­тивы. — Минск: Вильяме, 2003.

83. Ферн 3., Либерзон В., МакГурти К., Постма У., Вулф Н. Шесть шагов в будущее. Как массовая индивидуализация меняет наш мир. — Киев: ООО «Технологии управления Спайдер», 2003.

84. Ферн Э. Управление проектами Time-to-Profit. Руководство для менед­жеров проектов разработки новой продукции. — Киев: ООО «Техноло­гии управления Спайдер», 1999.

87. Флэннес Стивен У., Левин Джинджер. Навыки работы с людьми для менед­жеров проектов. — Киев: ООО «Технологии управления Спайдер», 2004.

89. Хелдман К. Подготовка к экзамену РМР / Пер. с англ. — СПб.: Нестор-История, 2005.

90. Цветков А. В. Стимулирование в управлении проектами. — М: ООО НИЦ «Апостроф», 2001.

91. Ципес Г. Л., Товб А. С. Менеджмент проектов в практике современной компании. — М.: Олимп-Бизнес, 2006.

92. Шапиро В. Д. Управление проектами. Толковый англо-русский словарь-справочник. — Киев: Высшая школа, 1999.

93. Шмалътц Д. Слепые и слон / Пер. с англ. — М.: HIPPO, 2005.

Источник