Управление проектами в картинках

Для того, чтобы познакомиться с общей идеей CCPM (Critical Chain Project Management), нужно обязательно прочесть книгу автора - Элияху Голдрата. Она написана как художественное произведение, а не как учебник, и по-настоящему заставляет проникнуться идеей. Я попробовал сделать конспект книги в виде mindmap (щелкните на рисунок, чтобы увидеть полноразмерную карту).

Конспект книги “Критическая цепь” Голдрата в формате mmap

Попробуйте его рассмотреть - поможет ли он вам понять основные мысли книги?

Сегодня я прочел книгу Голдратта "Critical Chain", и испытал настоящий сдвиг парадигмы. К сожалению, не нашел её русского издания, читал в электронном виде по-английски (можно найти вот здесь, например).

Так вот, друзья, "Critical Chain"  - замечательная книга, написанная очень легким художественным языком, которая заставила меня по-другому взглянуть на то, чем я занимаюсь и то, как надо управлять проектами.

Вообще я достаточно долго шел к изучению этой теории (посыпаю голову пеплом). Знаете, это обычно происходит следующим образом: где-то краем уха услыхал о том, что есть интересная теория (Theory of Constraints, TOC), которая позволяет совершенно по-другому посмотреть на управление в самом широком смысле этого слова. 

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

Кроме того, масла в огонь подливал ailev, который периодически у себя в блоге дает очень интересные ссылки, среди которых фигурирует и TOC, и CCPM (Critical Chain Project Management). 

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

Сейчас, начал изучение книги по CCPM, которая так и называется: "Critical Chain Project  Management".

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

Если кто-то из читателей знает, как используется TOC в реальной российской жизни, делитесь.

На сайте Di Ellis наткнулся на интересную статью , в которой уничтожение кольца всевластия из книги Толкиена предлагают рассмотреть, как проект. Хочется поделиться переводом с моими читателями.

Представим себе, что уничтожение кольца всевластия во "Властелине Колец" - проект. Это не так уж и странно - попробуем оценить этот поход по следующим критериям:

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

Похоже на проект, не так ли? А если это проект, то кто же был руководителем проекта?

Роль руководителя проекта заключается в следующем:

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

По моему мнению, есть четыре претендента на роль руководителя проекта: Арагорн, Гэндальф, Фродо и Элронд. Рассмотрим каждого детально.

Элронд

На собрании совета именно Элронд огласил цели проекта и он же выбрал тех, кто будет в команде проекта.

Однако, вскоре после этого, Элронд ушел в тень, и появился вновь лишь в финальной битве против Саурона. Большую часть похода никак не влиял ни на сам проект, ни на то, как он выполнялся.

Таким образом, будем считать, что Элронд был спонсором проекта или владельцем проекта.

Фродо

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

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

Поэтому будем считать Фродо ключевым исполнителем проекта, но никак не РП.

Арагорн

Арагорн проявил замечательные лидерские качества, и принимал стратегические и тактические решения. Он планировал нападение и защиту на различные крепости, и воодушевлял войска.

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

Будем считать Арагорна, как и Фродо, ключевым участником проекта, но не РП.

Гэндальф

Итак, мы дошли до Гэндальфа.

До того, как Гэндальф пропал в бездне Мории, все участники проекта считали его лидером, и когда он вновь вернулся, он опять взял бразды правления в свои руки. Он послал Арагорна к Теодену, и отправился в Хельмову Падь.

Именно он предложил поручить уничтожение кольца Фродо, и предложил Сэму сопровождать Фродо (хороший ход, который обеспечил успех проекта).

Кроме того, Гэндальф победил Сарумана.

Вопрос вот в чем: Если бы поход провалился, можно ли было считать Гэндальфа ответственным за это?

Я думаю, да.

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

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

Рассмотрим составные части ИСУП (здесь и далее цитируется книга "Управление высокотехнологичными программами и проектами" Р.Арчибальда) :

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

ИСУП - единое пространство для хранения и обработки информации, и в рамках основных групп процессов управления проектами информация может быть сгруппирована в следующие документы:

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

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

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

Есть и другие способы группировки таких программных продуктов. Например, в статье википедии  с перечнем существующего ПО по управлению проектами выделены категории:

• управление проектами (планирование, контроль, отчетность по проекту)
• распределенное управление проектами (ПО для совместной деятельности, сотрудничества)
• управление инцидентами (service desk)
• управление портфелями проектов
• управление ресурсами

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

Ссылки:

• Карта типовых документов в информационной системе управления проектами (mmap)
• Карта категорий ПО для управления проектами (mmap)

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

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

Итак, пойдем по порядку:

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

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

P.S. 28.03.08 Спасибо коллективному разуму (hemule, Максим, Алексей, Алексей Павлов) за добавления :)