Как реализовать управление проектами в компании?
Если решение организовать корпоративное управление проектами принято, то будущий руководитель проектного офиса, после недолгого этапа обследования существующего состояния проектной деятельности, начнет создавать конкретные регламентирующие документы для данной конкретной организации. 
Владея теоретическими основами управления проектов, он, скорее всего, будет опираться на один из существующих стандартов. Например, ANSI/PMI PMBOK - Свод знаний по управлению проектами. Последовательно описывая процессы и их взаимодействие для каждой из областей знаний управления проектами, согласуя с существующей организационно-штатной структурой предприятия, руководитель проектного офиса будет создавать свой OPUS MAGNUM, состоящий из большого числа перекрестно ссылающихся друг на друга инструкций и регламентов. 
Оценив по достоинству его труд, руководство компании попробует либо само внедрить их в повседневную практику, либо попросит сделать это автора. И тут встанет первая проблема - трудно заставить всех вовлеченных лиц просто прочитать эту кипу бумаги, а уж использовать ее в повседневной работе по реализации конкретного проекта: В лучшем случае, от руководителя проектного потребуют написать еще один документ, описывающий в каких случая извлекать на свет божий каждый из созданных ранее регламентов. 
Возможны два варианта:
Первый - регламентирующие документы, разработанные с учетом специфики типичных проектов компании, будут не столь уж объемны, взаимодействие между ними будет относительно прозрачно. Они хорошо опишут и стандартизуют процесс реализации большинства проектов компании. В таком случае, мы свели проектную деятельность к процессной. Такое возможно, например, для строительных компаний, реализующих типовые проекты застройки. Подобная деятельность лишь по традиции называется проектной, а по сути (при должной организации) является хорошо отлаженным производственным процессом. Однако, для большинства проектов в динамичных, развивающихся компаниях, это не так. Их проекты отличаются изменчивостью, большой степенью неопределенности на старте и в процессе реализации, трудностью планирования и выбора единственно правильных подходов. 
Второй вариант - результат этой титанической деятельности будет слабо сочетаться с практикой реализации проектов. Следование эти документам войдет в противоречие с самой сутью проектной деятельности, будет вызывать активное неприятие людей, которым их попытаются навязать, проекты не будут приносить желаемых результатов. 
Что делать? - Искать компромисс между творческим началом и порядком, опираясь на основную движущую силу развития - на людей. Кроме того, хотелось бы, чтобы этот найденный компромисс - один среди нескольких возможных - оказался бы сильным решением - приносящим при 20% затраченных усилий 80% результата. 
Как и в какой области искать этот компромисс? Возможно, там, где он уже был найден - в области управления разработкой программного обеспечения. Имеются ввиду agile подходы, в частности, экстремальное программирование. Попытка экстраполировать и адаптировать эти специфические методы к управлению практически любыми проектами основана на том, что: 
Многое в практику управления проектами было привнесено из управления разработкой программного обеспечения после соответствующей адаптации, в том числе, многие специалисты по управлению проектами вышли из управления разработкой и внедрением программного обеспечения; 
Теория и практика экстремального программирования развиваются достаточно давно. Они устоялись и доказали свое право на жизнь, свои преимущества, а в ряде случаев являлись единственно возможными. 
Рассмотрим, интерпретируем (да простят нам отцы-основатели) и адаптируем основные положения экстремального программирования, сформулированные Кентом Беком ("Экстремальное программирование", второе издание), попробовав применить их к управлению любыми проектами, в меру своего понимания этих идей. 
Прежде всего, следует сформулировать основные ценности, которые должны быть приняты всеми участниками проекта - заказчиком, спонсором, менеджером и командой. Осознание и убежденности в них - краеугольный камень проектного управления. 
1.	Общение
Анализ практики выполнения проектов показывает, что большинство ошибок и неудач связано с недостатком общения. Лучшая форма общения - прямое, очное общение между людьми. К нему надо постоянно стремиться, расширять его. Используйте другие формы общения только в том случае, если без них не обойтись, а не тогда, когда кому-то они кажутся удобней и проще. В случае необходимости других форм общения, в частности - посредством документов, следует стремиться к реализации другой ценности - простоты. 
2.	Простота
Эта ценность базируется на старинном, всеобщем, проверенном веками, но часто недооцениваемом на практике принципе "Бритвы Оккама". Решайте стоящую перед вами проблему простейшим для этой проблемы способом. Другую проблему будете решать простейшим для нее способом. Не стоит специально пытаться убить двух зайцев одним выстрелом. Практика показывает, что так получается только хуже. Решайте задачи по порядку, просто и эффективно. 
3.	Обратная связь
Несмотря на кажущуюся специфичность термина он универсален. Ведь любой проект это сложная система взаимодействия людей, организаций, ресурсов. Она будет устойчива, не развалиться только при наличии обратной связи. Обратная связь должна иметь как можно меньше задержек чтобы система быстрее реагировала на внешние изменения и, тем более не входила в резонанс с последующим разрушением. Если нашу большую проектную систему можно разбить на несколько меньших подсистем, каждую из них лучше снабдить обратными связями, помимо одной большей обратной связи. В этом случае внешние возмущение (изменение требований, финансирования, реализация рисков) будут вызывать меньшие колебания системы в целом, смежных подсистем, колебания будут быстрей затухать. То есть проект будет меньше лихорадить, работа будет быстрей входить в нормальное русло, на это будет тратиться меньше сил. А что такое обратная связь применительно к проектному управлению. Во-первых - общение, во-вторых - большое число промежуточных конкретных результатов и требований, выполнение которых должно проверяться часто, прозрачно и просто. 
4.	Решительность
Не ограничиваться констатацией серьезных проблем - всегда искать решения, стремиться к достижению результата, несмотря на трудности. Не бояться простых решений - простота сама по себе означает не больший, а меньший риск. Не бояться перемен - новизна - свойство самих проектов. 
5.	Уважение
Руководители уважают труд своих сотрудников, его результаты, их мнение, их потребности. Сотрудники уважают взвешенные и понятные решения руководителей. Контрагенты уважают интересы друг друга. Уважение строиться на понимании, понимание - на общении. Одним из проявлений уважения является признание факта самостоятельности сотрудников, их способности принимать взвешенные решения. Общение не должно вырождаться в тотальный контроль и управление каждым шагом. Следование описываемым методикам должно основываться не на принуждении, а на понимании их преимуществ. 
Вышеперечисленные ценности, безусловно, применимы к управлению любыми проектами. 
Далее следует сформулировать принципы, руководствуясь которыми участники проекта принимают большие и малые решения: 
1.	Человечность
Проект реализуют конкретные люди. От них, от их качественной работы, в конечном итоге, зависит успех проекта. Поэтому, решения и мероприятия по управлению проектами должны быть направлены на удовлетворение их потребностей с целью стимулирования их эффективной деятельности в рамках проекта. Одного материального стимулирования, несмотря на его необходимость, оказывается недостаточно. Должны удовлетворяться основные потребности работников как членов команды: 
Базовая безопасность - возможность справляться с работой 
Чувство собственной значимости 
Возможность причислять себя к группе 
Потребности в росте и перспективах 
Возможность понимать и быть понятым 
Необходимо стимулировать командный дух в противовес индивидуализму, т.к. лучшая проектная деятельность - командная. 
2.	Прагматичность
Как проект в целом, так и составляющие его работы должны быть направлены на получение конкретных, понятных, реальных прозрачных для всех участников проекта преимуществ. Для этого цели проекта должны быть сформулированы максимально честно. Все действия в рамках проекта должны быть оправданы с точки зрения получения выгоды и конкретных результатов. Необходимо стремиться к минимизации затрат и максимизации доходов. Рубль, потраченный сегодня дороже рубля потраченного завтра - не делайте затрат, кроме необходимых сегодня. Платите только за то, чем пользуетесь. Рубль, полученный сегодня дороже рубля, полученного завтра - стремитесь начать пользоваться результатами проекта как можно быстрее. Если это невозможно - значит проект инициирован слишком рано и часть затраты, пусть даже в только виде рабочего времени, понесены напрасно. 
3.	Взаимовыгодность
Легко найти и продавить решение, которое устраивает только одну из сторон. Такой подход разрушителен. Необходимо искать решения устраивающее обе стороны. Убеждайте партнера в том, что такое решение в сложившихся обстоятельствах является оптимальным, опираясь при этом на ценность уважения. Показывайте конечную стратегическую выгоду в противовес сиюминутности. Акцентируйте внимание заказчика на том - что конечная цель - проекта - удовлетворение его потребностей на момент завершения, а не старта проекта, отмечая, вместе с тем, что реальные затраты должны быть возмещены, а выгода получена и исполнителем. Участники проекта должен быть постоянно осведомлены о текущем балансе взаимовыгодности, чтобы сохранять его и своевременно принимать решения о судьбе проекта. Этому способствуют общение и обратная связь. 
4.	Единство подходов
Стремитесь к единству подходов, принципов, решений, как в смысле исключения двойных стандартов, так и в смысле повторного использования, тиражирования, масштабирования удачных находок. То, что хорошо показывает себя сегодня, вероятно, хорошо покажет и завтра. Удачное в малом, возможно, будет работать и в большом. 
5.	Постоянное улучшение
Постоянно задавайте себе вопрос о том, как можно улучшить результат или упростить процесс. Всегда честно анализируйте недостатки и то, как можно избавиться от них сейчас и избежать в будущем. Извлекайте уроки, опираясь на ценности общения и обратной связи. И главное - внедряйте улучшения. В конце концов, постоянное улучшение - сама суть той проектной деятельности к которой мы применяем рассматриваемый подход. Нужно только следить, чтобы улучшения не переросли в страшную болезнь - перфекционизм. 
6.	Разнообразие
Если единство подходов служит уменьшению издержек, то соблюдение принципа разнообразия при формировании команды, хотя возможно и приведет к росту числа конфликтов, будет способствовать генерации и конкуренции идей. Разнообразие идей при выборе решений позволяет надеяться на то, что среди них появиться и будет выбрано сильное решение, позволяющее получить при минимуме затрат максимум результата. 
7.	Анализ результатов
Анализируйте результаты работ, делайте выводы, объясняйте себе свои действия - почему принято именно это решение, выбран именно этот подход - были ли доводы в его пользу достаточно сильны, не отдано ли решение на волю случая, не было ли оно ошибочным. Честно признавайте свои ошибки и исправляйте их. Не уделяйте излишнего внимание детальному планированию на основе недостаточной информации - больше пробуйте, анализируя полученных результат и переделывайте в случае необходимости. Закладывайте и готовьтесь к возможности изменений изначально. 
8.	Равномерность и непрерывность
Простои, как правило, приходятся на начало и середину работ, а авралы (ведущие к ошибкам, снижению качества и сопровождаемые риском превышения сроков) - на конец работ. Лучшая, эффективная работа - равномерная и непрерывная - без авралов и простоев. Прикладывайте усилия для организации именно такой работы. Глядя на вас, и ваши партнеры будут стремиться работать также. Это позволит получить лучший результат в лучшие сроки. 
9.	Позитивизм
Старайтесь видеть в проблемах возможности улучшить что либо, получить новый опыт или новое неожиданное положительное качество. 
10.	Избыточность
Решайте или планируйте решение сложных проблем двумя различными способами для подстраховки. Объясняйте исполнителям причины, по которым делается двойная работа. Убеждайте их в необходимости и оправданности такого подхода для каждого конкретного случая. Мотивируйте это обязательностью достижения заданного качества и конечной цели проекта. 
11.	Принятие возможности ошибок
Будьте морально готовы к ошибкам сами и признайте право на ошибку за коллегами. Главное исправлять их и извлекать уроки. Больше пробуйте и экспериментируйте. 
12.	Качество
Получение продукта надлежащего качества - это то ради чего затевался проект. Зачастую в ходе реализации проекта качество приносится в жертву срокам и стоимости. Это происходит из-за недостаточной вовлеченности в проект заказчика и спонсора, перевес меркантильных принципов и отношений заказчик/исполнитель, а не партнерских и командных. При этом менеджер проекта находиться фактически на стороне заказчика. Менеджер проекта должен следить за балансом качества/сроков/стоимости и объяснять всем участникам последствия изменения этого баланса. 
13.	Постепенность и дискретность
Идите к цели маленькими шагами. Ставьте перед собой конкретные задачи и всегда разрабатывайте требования к ним, способы проверки их результатов с позиции решения задач проекта. Сразу после исполнения тестируйте, проверяйте результаты, корректируйте на основе тестов следующий шаг. 
14.	Ответственность
Возложенная ответственность всегда должна быть добровольно принята тем, на кого она возлагается. 
Теперь перейдем к практикам, т.е. к наборам стандартных действий, подходов и процедур, регулярно применяемых проектной командой в ходе реализации проекта. Эти элементы экстремального программирования, безусловно, нуждаются в большей адаптации для использования в управлении проектами. Практики разделены на основные и дополнительные, но не по принципу большей или меньшей важности, а по порядку применения. Сначала применяются основные, затем - дополнительные. 
Основные практики: 
1.	Практика рассказов
Техническое задание в привычном виде - малоконструктивная для непосредственного исполнения проекта вещ. Оно больше соответствует жестким отношениям заказчик/исполнитель, а не проектной команде и партнерским отношениям. Косность и неизменность технического задания входит в противоречие с изменчивостью проекта и его конечной целью - удовлетворением потребностей заказчика. Работу лучше строить на основании большого числа компактных документов - рассказов, в которых заказчик человеческим языком излагает свои требования. Рассказы просто исполнять и легко контролировать качество их исполнения. Допускается появление новых рассказов на всех этапах проекта, при условии корректировки стоимостных и временных показателей на основе взаимного согласия его участников. Рассказы должны легко выстраиваться в единый динамичный документ, отражающий ход работ по проекту и решаемые задачи. 
2.	Практика коротких циклов контроля и планирования
Во время коротких (обычно недельных) циклов проверяется реализация выполнения предыдущего требования (рассказа) и заказчик выбирает, какие из требований будут реализованы следующем цикле. 
3.	Практика длинных циклов контроля и планирования
Во время длинного цикла охватывается взглядом весь проект. Анализируется качество работы команды и скорость хода проекта. 
4.	Практика резерва
Не давайте сомнительных обещаний. Имейте взаимосогласованный с заказчиком резерв в виде задач, от выполнения которых можно отказаться ради соблюдения сроков в случае возникновения непредвиденных проблем. 
5.	Практика большой комнаты
Участники проекта должны обладать как можно большей информацией по ходу проекта, в том числе неофициальной, чувствовать себя варящимися в этом котле, задавать любые вопросы и быстро получать на них ответы. В тоже время, они должны быть по возможности ограждены от информационного мусора и отвлекающих факторов, не имеющих отношения к текущему проекту. Этим потребностям в наибольшей степени отвечает размещение команды в одной общей комнате. Именно такие условия культивировались для сотрудников конструкторских бюро, создававших электростанции, корабли, самолеты. В таких условия наиболее полно реализовывался синергетический эффект взаимного усиления творческой энергии. Не всегда легко создать такие условия, однако, необходимо прикладывать усилия для реализации этой практики т.к. опыт показывает, что она не менее важна для успеха проекта, чем правильный подбор команды, достаточное финансирование или грамотное планирование. 
6.	Практика команды
Если от человека требуется какой либо вклад в проект необходимо формально и фактически включить его в команду, со всеми вытекающими морально-психологическими последствиями. Люди от которых в какой либо степени зависит исход проекта, находящиеся вне команды и не чувствующие себя ее частью, могут своим действием или бездействием существенно помешать успешному выполнению проекта. 
7.	Практика информативности
Необходимо создавать информационное пространство проекта, в котором бы человек жил и мог в любой момент получить представление об общей картине проекта, его ходе, составных элементах. Не ограничивайтесь использованием персонального компьютера. Применяйте плакаты, крупномасштабные схемы, настенные диаграммы, большие экраны, чтобы ощущение текущего состояния проекта, прогресса, вектор его развития входил в участника проекта на подсознательном уровне. 
8.	Практика энергичной работы
Энергичная работа - работа которую человек выполняет с ощущением внутренней энергии, достаточного запаса сил для ее выполнения, желанием их потратить. Поэтому нельзя допускать переработки, накопления усталости и вынужденных простоев. 
9.	Практика парной работы
Исполнитель не должен оставаться один на один с проблемой. Всегда должен быть конкретный человек, с которым можно посоветоваться - его напарник. Кроме того, в условия отсутствия (нерациональности и практической невозможности) тотального документирования, парная работа решает задачу преемственности и устойчивости проекта в случае выбытия членов проектной команды. Пары желательно составлять так, чтобы добиться синергетического эффекта или решать другие важные задачи. Например, из опытного и молодого работников. При этом, для создания конструктивного позиционного конфликта, способствующего развитию, продвижению вперед, предлагается формально разделить роли в паре на ведущего, генератора идей, придумывающего и реализующего решения и эксперта, соизмеряющего их с общими целями, задачами, ресурсами проекта, выдвигающего возражения. Для обеспечения комплексного, системного подхода к работе в ходе реализации проекта члены команды попарно или циклическим сдвигом регулярно меняются ролями. 
10.	Практика инкрементного проектирования
Эта практика соотносится с принципом бегущей волны при планировании. Тщательно планируйте только следующий шаг. Фокусируйте внимание на его практической ценности, достижении целей и полезности его результатов для планирования и оптимизации следующего за ним шага. С каждым шагом должен все рельефней проявляться вектор, ведущий к цели проекта. Если результаты выполненных шагов выглядят разрозненно, значит, была неправильно выбрана последовательность их реализации. 
11.	Практика первичности тестов
Прежде чем приниматься за какую то работу или поручать ее исполнителю, партнеру необходимо определиться с тем, как мы будем принимать ее результаты. Причем, способ испытаний должен быть выбран так, чтобы ясно показывать насколько результат этой конкретной работы соответствует и способствует достижениям целей и задач проекта. Т.е. должно не только прослеживаться выполнение конкретных технических параметров, но и причина их появления и выбора их конкретной величины с точки зрения достижения конечного результата. Необходимо стремиться как можно полнее реализовать условия реальной эксплуатации в процессе испытаний. Тестирование в реальном окружении, во всем диапазоне изменяющихся внешних параметров (или их модельных аналогов) должно быть единственным критерием завершенности работы. Обязательное и регулярное тестирования позволит вовремя обнаружить отклонение от движения к цели, вернуться на верный путь быстро и без больших потерь. Если разработать тесты трудно, значит, либо реализация проекта заходит не туда, либо неправильно выбрана последовательность работ и мы также можем двигаться в сторону от цели. 
12.	Практика постоянной готовности
Система должна последовательно строиться таким образом чтобы последующие тесты не мешали проведению предыдущих и все достигнутые результаты можно было в кратчайшее время собрать воедино и предъявить их, выполнив один большой тест, состоящий из последовательности всех пройденных тестов. 
13.	Практика регулярного предъявления результатов
Результаты всех выполненных работ и тестов должны быть прозрачны и доступны всем участникам проекта в кратчайшее время с тем, чтобы они координировали и планировали свою деятельность в соответствии с текущим состоянием проекта и полученными результатами, минимизировали ошибки, вызванные решениями и действиями, предпринятыми в условиях недостаточности или неактуальности информации. 
Дополнительные практики: 
1.	Практика непосредственного вовлечения заказчика
Представители заказчика должны формально и фактически стать частью команды проекта, разделять ее стремления и ценности, участвовать в коротких и длинных циклах планирования. Должны информироваться обо всех изменениях состояния проекта, иметь возможность участвовать в принятии решений по проекту на основе полной, достоверной, оперативной информации. Членов команды проекта как со стороны заказчика, так и со стороны исполнителя должна объединять общность целей и путей их достижения. 
2.	Практика инкрементной поставки продукта
Меняйте или внедряйте постепенно, но функционально завершенными частями. Даже в случае прекращения проекта (в том числе по обоюдному согласию сторон по причине прекращения финансирования) потраченные ресурсы не пропадут зря. 
3.	Практика контрактов с оговоренным объемом работ
Оговаривайте с заказчиком именно такую этапность внедрения, закрепляя если необходимо, формальными соглашениями. Добивайтесь формального и неформального признания и удовлетворенности (в том числе и виде оплаты) результатами каждого этапа. Настраивайте заказчика заранее на такой подход, убеждая в оптимальности и соответствии его интересам. 
4.	Практика оплаты за результаты
Убеждайте заказчика в справедливости и конструктивности оплаты работ по проекту не по наступлении какого либо формального события (завершении этапа, выпуска новой версии, сдачи объекта), а за достигнутую функциональность. Постоянно информируйте заказчика о достигнутой функциональности и ее стоимости, а также о планируемой стоимости требуемой новой функциональности. Обладая этой объективной информации заказчик может реально влиять на ход работ и максимизировать свою удовлетворенность результатом. Использование этой и предыдущих трех практик в случае прекращения проекта, сокращения его объема, смены направления реализации позволит сохранить у всех сторон проекта (заказчика, исполнителя, спонсора) хотя бы частичную удовлетворенность достигнутыми на тот момент результатами. 
5.	Практика постоянства
Старайтесь оставлять состав команды проекта (или ее костяк) постоянным. В этом случае, усилия потраченные на ее развития не пропадут даром. 
6.	Практика постоянства нагрузки
Если команда справляется с работой все более и более эффективно - не увеличивайте ей нагрузку. Дождитесь, пока полностью не высвободиться человек и используйте его вне этой команды. Он может войти в новую команду с новым кругом задачам. 
7.	Практика анализа причин и следствий
Обнаружив ошибку - исправляйте, ищите корневую причину, найдя - устраняйте. 
8.	Практика документирования через работу и проверки
Идеальный продукт состоит из отдельных элементов, с понятной функциональностью. Должно быть ясно, какое требование этот элемент удовлетворяет и каким образом это делает. Система не должна быть черным ящиком, и не благодаря документации, а благодаря естественной, прозрачной и понятной структуре. Заказчик должен осваивать результаты проекта (учиться пользоваться ими) и понимать их через тесты. Не надо создавать безадресной документации, которую никто не прочтет. Избегайте наличия потенциально используемых, но не тестируемых элементов. 
9.	Практика общей работы и результатов
Любой член команды должен иметь право возможность в любой момент изменить способ реализации или результат промежуточной работы, выполнить часть работы по проекту. Эти изменения с его стороны должны быть доступными (как можно быстрее) и понятными для остальных. 
10.	Практика одного экземпляра проекта и одного потока работ
Существует только одна официальная версия реализующегося проекта. Не допускайте разветвления проекта и его одновременного развития по двум параллельным ветвям. Если необходимо опробовать два варианта реализации сначала опробуйте один потом второй. 
11.	Практика постоянной сборки в целое
Как можно чаще публикуйте результаты своей работы и встраивайте их в проект и общий поток работ. Не уединяйтесь со своей работой. Настаивайте на включении результатов своей работы в общую картину. Стыкуйте и проверяйте. 
Ценности, принципы и практики, адаптированные для конкретной организации должны быть изданы в виде некоего компактного манифеста. В нем можно более подробно остановиться на порядке применения практик. Данный документ не навязывается насильно. В ходе реализации проектов руководитель проектного офиса выступает в роли тренера, который, поправляя и направляя, постепенно внедряет вышеописанные методы в сознание членов команды проекта. 
Гибкость самих методик не исключает жесткости и комплексности их применения. По каждому проекту должен создаваться устав, регулярно обновляться описание содержания проекта, план и реестр рисков. Эти документы (особенно устав и описание содержания) должны быть компактными и максимально наглядными (описание содержания, план и реестр рисков). 
P.S. 
Приведенные выше рассуждения представляют собой личное мнение автора, его понимание и интерпретацию доступной ему информации на основе личного опыта и вероятных допущений.