Главная Все Маркетинг Я — менеджер проекта! Введение (управление проектами)

Я — менеджер проекта! Введение (управление проектами)

Мы хорошо знаем, как бывает сложно и неустойчиво, если в голову пришла гениальная идея, которую очень хочется реализовать – но нет картинки в голове, представления, что делать, как и зачем.
Чтобы помочь вам в этом, мы будем публиковать поэтапно пошаговое практическое руководство «Я – менеджер проекта!» Вратенкова Сергея. (Управление проектами по стандарту PMBOK)

Отметим, что Сергей не только получил профильное образование в МФТИ и в аспирантуре Всероссийского научно-исследовательского и проектно-технологический института кибернетики, имеет сертификат PMP PMI (Project Management Professional), но и занимается консультированием и преподаванием в области управления уже больше десяти лет. Клиенты Сергея – крупные корпорации, такие как Альфа.Банк, РАО ЕЭС России, Luxoft, Юганскнефтегаз и другие.

Сегодня мы публикуем введение, а дальше, поэтапно – вы сможете прочитать все руководство.

О ЧЁМ И ДЛЯ КОГО ЭТА КНИГА?

В любой деятельности есть один извечный вопрос: «Как делать?». В любом управлении деятельностью есть столь же извечный вопрос: «Как управлять?». Это обобщение множества вопросов типа: «Как управлять хорошо или правильно? Как принято или как рекомендуется управлять? Какими инструментами и методами надо овладеть? …». Все это – вопросы практиков управления, вопросы руководителей. Но в этом мире есть еще один не менее извечный вопрос: «Почему? Почему управлять надо именно так?». Этот вопрос – вопрос любопытных романтиков управления, исследователей и методологов. Есть даже бунтарский вариант последнего вопроса: «Зачем? Зачем управлять именно так?». Этот вопрос, согласитесь, легко докатывается до своей крайности: «Зачем вообще управлять?». Вопросы, вопросы, вопросы…

Эта книга для тех, кто задает вопросы. Вопросы по управлению проектами. Я тоже задаю разные вопросы к управлению проектами. Задаю их уже более 10 лет. Сначала я задавал их как практик, и они начинались со слова «Как?». Затем задавал их как учитель практиков, и главным словом стало «Почему?». Впрочем, нередко добирался и до крамольного «Зачем?».

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

Итак, вас посетила идея, прекрасная идея, может, даже безумная идея! Или вашего начальника посетила, а он посетил вас. В любом случае, идея есть. Но вместе с идеей есть и сомнения – удастся ли воплотить эту идею в жизнь? Каким образом избежать ясно видимые уже сейчас препоны и затруднения? И как быть с невидимыми сейчас, но ожидаемыми и даже неизбежными в дальнейшем препонами? Знаете ли Вы, как идею превратить в проект? Не в прожект, а в последовательную, планомерную работу по реализации идеи. Знаете ли Вы, с чего начать? Какие конкретные шаги надо предпринять после встречи с идеей?

Очень многие скажут, что начинать надо с анализа идеи. Или с поиска соратников и обсуждения идеи в их кругу. Или с плана действий. Или с чего-то еще не менее важного. И все это правильно. Но этих самых «или» уже многовато для начала. А основной вопрос остается – с чего начинать любое «или»? Какие конкретные шаги нужны в каждом «или»? Наиболее упорные и дотошные могут сказать: — все просто, надо каждый «или» разделить на более мелкие «или» и продолжать до тех пор, пока не получим совершенно ясные и понятные небольшие «или». Согласен, тем более, что только что на наших глазах вновь открыт основной алгоритм познания – декомпозиция, «разделяй и властвуй».

Но где гарантия, что все эти «или» правильные, что не упущены какие-нибудь зловредные «или»? И сколько времени и усилий понадобится на подобные исследования? А главное – зачем? Ведь все это проделывалось уже миллиарды раз миллиардами людей в подобной ситуации. И ответ известен – он называется «Управление проектами». Он описан во многих книгах и стандартах. Читайте и действуйте по написанному!

Но основной вопрос никуда не исчез, он остался, он только слегка изменился – какую книгу читать? Ведь книги дают слегка разные ответы, более того, ответы изменяются и уточняются с течением времени, и, несомненно, будут изменяться и дальше. Вопрос остается… Можно выбрать из всех книг наиболее авторитетную, и претендент на самую-пре-самую книгу по управлению проектами есть, сейчас это – стандарт PMBOK Guide. Но… Но… Надеюсь Вы не удивитесь, если я сообщу, что и в этом случае основной вопрос спокойно себе остается. Он не исчезает, он преобразуется в свои близнецы-братья: — А кто сказал, что именно этот стандарт – главный, не все с этим согласны, — А Вы знаете, что этот стандарт пересматривается раз в 4 года, причем иногда довольно существенно? – А … — А … — А…

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

Для понимания этой книги не требуется никакого практического опыта или теоретических знаний управления проектами. Требуется только здравый смысл и желание грамотно реализовать свою идею. Все, о чем здесь написано, в той или иной степени известно каждому, каждый так или иначе соприкасался с большинством или со всеми аспектами управления проектами. В этой книге нет почти ничего авторского – есть только подборка тех методов и инструментов, и той последовательности их применения, которые сейчас считаются общепринятыми буквально везде и всеми. Авторское в этой книге только одно – соображения и комментарии по разным тонким или неочевидным моментам, в основном в аспекте «почему так, а не иначе?» или даже «что будет, если делать не так?».

ГЛАВА 1

ПРОЕКТЫ И ИХ ОКРУЖЕНИЕ

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

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

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

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

1.1 ЧТО ТАКОЕ ПРОЕКТ?

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

Каждый из нас, безо всяких глубоких размышлений, сходу назовет множество звеньев-аспектов проекта, как-то: люди, деньги, работы, результаты, ресурсы, риски, …, далее везде, в этот список можно включить, наверное, все, что есть в нашем мире. Если же нас спросить, какой из аспектов самый главный, есть ли среди них один, ради которого проекты затеваются? — то мы, быстро проанализировав каждый из аспектов, скажем, что люди, деньги, ресурсы – это компоненты работ, и не могут быть главными аспектами проекта. Риски – это разные сопутствующие события, и также не могут быть главными. На роль главных аспектов неплохо претендуют работы и результаты. Но в этой парочке есть существенное неравенство, а именно: результаты производятся работами. И мы легко заключаем, что проекты затеваются не ради работ, а ради результатов! Итак, мы можем дать такое предварительное определение проекта:

— Проект – это начинание, которое производит определенный результат.

Наше определение проекта выглядит пока простенько, но кое-что мы уже имеем! А имеем мы вот что.
Во-первых, мы исключили из сферы проектов любую деятельность, которая не нацелена на результат – это занятия типа: «работа ради работы», «искусство для искусства», «главное – процесс», и так далее. Такого рода занятия для большинства из нас наиболее интересны и притягательны, но их нельзя относить к проектам. К сожалению.

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

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

— Проект – это начинание, которое производит определенный результат и ограничено во времени.

Уже лучше, но замечания остаются. Мы ограничили проекты во времени, и это правильно. Но мы с вами живем в мире, где есть еще одно существенное ограничение – ограничение по ресурсам. И проекты должны учитывать эти суровые реалии. Поэтому надо добавить ограничение по ресурсам. Учитывая, что ресурсы определяют стоимость проекта, получаем дополненное определение:

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

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

Теперь мы готовы дать наше рабочее определение проекта:

Проект – это начинание, которое:

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

1.2 ОПРЕДЕЛЕНИЕ ПРОЕКТА В СТАНДАРТАХ ISO 21500 И PMBOK GUIDE

Стандарт ISO 21500 опубликован в середине 2012 года и дает такое развернутое определение проекта:

«A project is a unique set of processes consisting of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective. Achievement of the project objective requires deliverables conforming to specific requirements, including multiple constraints such as time, cost and resources.
Although many projects may be similar, each project is unique as differences may occur in the deliverables provided by the project; the stakeholders influencing the project; the resources used; and the way processes are adapted to create the deliverables.

Every project has a definite start and end, and is usually divided into phases. The project starts and ends as defined in clause 4.3.1.»

Перевод:

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

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

Другие основные моменты определения:

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

Стандарт PMBOK Guide во всех редакциях (до 5-й включительно) дает такое определение проекта:

«A project is a temporary endeavor undertaken to create a unique product, service or result.»

Перевод:

Проект – это временное начинание, предпринятое для создания уникального продукта, услуги или результата.

Это – самое лаконичное определение проекта, которое я встречал. Но не зря говорят, что краткость – сестра таланта. Лично мне всегда очень импонируют краткие, конкретные и я бы даже сказал акцентированные заявления. Они позволяют сосредоточиться на ключевых аспектах проблемы и не утонуть в академическом море «всестороннего рассмотрения».

Стандарту PMBOK Guide около 20-ти лет – с середины 90-х и до появления стандарта ISO 21500 в 2012-ом – он был мировым стандартом де-факто. Основной причиной этого был процессный подход. В отличие от других стандартов управления проектами, PMBOK уже в первой своей редакции был не повествовательной книгой, а справочником по типовым процессам управления и неудивительно, что он легко овладел умами и сердцами практиков управления проектами.
Определение PMBOK отличается от нашего рабочего определения двумя моментами.

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

Во-вторых, определение PMBOK относит уникальность только к продукту проекта, а не к любым иным особенностям окружения, участников и так далее. Это вызвано, скорее всего, историческими причинами – определение появилось в прошлом веке в начале 90-х. И с тех пор не менялось ни за что и никогда. Просто во всех редакциях PMBOK за определением следовали пояснения, что не надо понимать уникальность продукта слишком узко, надо понимать уникальность проекта шире – как любую необычность в деятельности, что-то типа: «такой продукт в таких условиях эта команда из этих ресурсов за такие сроки и стоимость, …, еще не создавала». Уникальность проекта – эта любая существенная необычность!

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

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

1.3 ПРОЕКТ – ЭТО ПРОИЗВОДСТВО

Итак, проект – это начинание для создания некоторого результата. То есть проект – это производство результатов. И это – главное назначение проекта! Проекты нужны для создания чего-либо.
Что проект может произвести? Что может быть результатом проекта? Да все, что угодно, например:

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

Итог этого перечисления довольно обескураживающий, по крайней мере, для меня! — результатом проекта может быть все, что угодно, от еще одной скрепки до еще одной вселенной! Я не вижу ничего в этом мире, что не укладывается в этот список, и если кто-то что-то этакое увидит – сообщите, буду искренне признателен.

Но хватит копаться в определениях, давайте просто констатируем, что проект может произвести все то, что может быть произведено любым иным образом, например, на конвейере или просто в гараже. И раз уж это так, то по своему продукту проект не отличается от любого другого производства, здесь нет никакой проектной специфики! Пока мы имеем только одну констатацию: проект – это производство продукта. Но ведь проектная специфика должна быть? Должна. И она есть. Специфика – не в продукте производства, а в особенностях производства. Обсудим их.

1.4 УНИКАЛЬНОСТЬ

Уникальность проекта – это любая необычность в деятельности, что-то типа: «такой продукт в таких условиях эта команда из этих ресурсов за такие сроки и стоимость, …, еще не создавала». Уникальность проекта – эта любая существенная необычность!

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

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

Я бы подытожил это так:

— Чем сильнее уникальность, чем выше уровень рисков, тем ближе деятельность к проектной. И наоборот.

1.5 ВРЕМЕННОСТЬ

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

Пример:

Я – сотрудник, имею свою узкую специализацию, скажем, разрабатываю типовые документы. И имею приличный опыт в своей области.

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

А теперь вопрос на засыпку – кто угадает, что я буду делать в первую неделю? Или даже по-другому, не в бровь, а в глаз – что будете делать Вы в такой ситуации? Вопрос, конечно, не в том, чем конкретно я буду заниматься – занятия находятся всегда. Вопрос в том, приступлю ли я к заданию?
Про себя я четко знаю ответ на этот вопрос – никогда и ни за что я не приступлю к заданию в первую неделю! Вернее, уточню, чтобы Вы не подумали обо мне черт знает чего – для того, чтобы я взялся за него сразу, должно произойти нечто невероятное: мне совершенно нечего делать, или задание на самом деле не рядовое, не рутинное, а архиважное, или вообще весь мир перевернулся!

Но это еще цветочки! Я даже не буду повторять этот вопрос про вторую и третью недели – ответ вряд ли изменится! Я сразу перехожу к принципиальному вопросу: что я буду делать в первый день последней недели? Когда откладывать уже некуда?

Я вам честно отвечу, что максимум, чего я реально достигал – это «плавное начало работ», гораздо чаще и этого не случалось. Причин всегда много! Первая причина – наличие иных заданий, в первую очередь, неустранимой и всегда неотложной текучки. Вторая причина — наличие скрытых резервов в большинстве заданий, это не только нерабочее время (выходные, вечера, ночи), но и скрытые резервы планирования. Когда я оценил длительность работы в 5 дней, то эти 5 дней были с учетом текучки и других отвлекающих факторов, а они отнимают у меня около 50% рабочего времени! И пять дней – это «всего лишь» 2,5 дня, или 20 часов чистого времени! А до сдачи задания у меня 5 Х 24 = 120 часов. Чувствуете разницу: 20 и 120 часов? И это еще без 48 часов выходных! Далее список причин каждый может продолжить сам.

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

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

Ко мне подходит мой начальник, и сообщает, что надо разработать очередной документ. Спрашиваю про сроки, отвечает, что срок – вчера! По своему опыту я знаю, что на разработку документа мне понадобится 5 рабочих дней, а на выполнение задания мне дано максимум день.

Как Вы думаете, что будет? Да будет все просто – документ будет готов! Я отключусь от всего, что мешает, и концентрированно займусь конкретным делом!

А представляете, что будет, если ВСЕ задания мы станем исполнять подобным образом?

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

— Чем жестче ограничения по срокам, тем ближе деятельность к проектной. И наоборот.

1.6 ОГРАНИЧЕННОСТЬ ВО ВРЕМЕНИ

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

К ресурсам относится все, что требуется для производства работ – люди, оборудование и материалы. Практически на каждом занятии я произношу фразу, которая вызывает недоумение и даже возмущение у части аудитории.

Вот эта фраза:

— Проектам деньги не нужны, им нужны ресурсы.

Усиленный вариант:

— Людям деньги не нужны, им нужны ресурсы.

Экстремальный вариант (определение для инопланетян):

— Деньги – универсальный обменный квази-ресурс варварских экономик.

Когда я поясняю, что из денег стену не построишь, что деньги не съедобны, и все такое прочее, то обычно мы приходим к очевидному консенсусу: деньги в производстве не используются непосредственно, деньги являются квази-ресурсом (а именно – расходным материалом), который нужен для обмена на любой «настоящий» ресурс. И если «настоящих» ресурсов достаточно, то в деньгах нужды нет.

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

Следующее утверждение также вызывает дебаты:

— Стоимость работы = стоимость всех затраченных ресурсов

— Стоимость проекта = стоимость всех работ = стоимость всех затраченных ресурсов

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

Итог такой:

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

1.7 ПРОДУКТ ПРОЕКТА

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

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

Получается такая ситуация: проект производит продукт, который затем, уже без проекта, начинает жить своей собственной бизнес-жизнью. И неизбежно возникает основной вопрос философии – насколько проект ответственен за бизнес-успешность произведенного им продукта? А точнее говорить про НЕ успешность, потому что в успешной бизнес-жизни вопросов почему-то не возникает. Есть такой вопрос? – Да сколько угодно! Вспомните обваливающиеся крыши сооружений, особенно снежной зимой. Вспомните сбои программного обеспечения, парализующие работу организаций и сетей. Вспомните все! Примеров достаточно. Спрашивается, кто виноват? По большому счету, если нет конкретного природного или людского разрушителя, то выбор виновного возможен всего из двух вариантов – виноват либо создатель-разработчик продукта, то есть проект, либо владелец-хозяин, обычно это организация, которая обеспечивает бизнес-жизнь продукта, например, эксплуатирует здание или сопровождает информационную систему. К моменту разборок самого проекта уже нет, проект завершен и закрыт, тогда как вторая сторона вполне себе есть и, конечно же, сделает все возможное, чтобы защититься от обвинений. Как Вы думаете, у кого больше шансов победить в такой разборке – у несуществующего проекта или действующей организации? Чтобы Вы не напрягались, вот обычный исход подобных баталий – признаются виновными руководители проектов или архитекторы и программисты.

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

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

1.8 ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ

Все рассмотренные выше определения говорят, что главным в проекте является его результат, что проект – это начинание, которое производит какой-то результат. И, хорошенько разобравшись с результатом, можно существенно облегчить бремя производства этого результата. И многовековой опыт исполнения проектов, казалось бы, подтверждает такой вывод. Заметили тщательно замаскированное «казалось бы»? Это «казалось бы» из разряда тех очевидных истин, которые ведут прямиком в тупик. В тупик, полный проблем, трудных проблем, трудных потому, что корни этих проблем не в технике или методике, не в том, что мы чего-то не знаем, не умеем или не так исполняем. Проблемы коренятся в интересах людей, которые затрагиваются проектом. А такие проблемы – это, согласитесь, всем проблемам проблемы!

Давайте разбираться в проблеме. Если результат – это главное в проекте, то стремление сделать результат как можно лучше выглядит достаточно естественным. Но ведь лучше – это дороже и дольше! А вот «дороже и дольше» — это уже не так естественно и очевидно! Согласны?

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

Пока мы можем дать такое уточнение определения проекта:

— Проект – это производство результатов для удовлетворения чьих-то потребностей.

Сделать лучше для заказчика результата можно только за счет исполнителя. И хотя отношения заказчик-исполнитель очень сложны, они, тем не менее, в основных аспектах достаточно понятны. Мы пока не упоминаем многообразные и многочисленные другие стороны, чьи интересы могут быть затронуты проектом и которые могут потребовать соблюдения своих интересов. И не только потребовать, но и добиться! Причем так, что мало не покажется! За примерами далеко ходить не надо – включайте телевизор, лезьте в интернет, историй про блокирование больших проектов небольшой группой жителей предостаточно.

Спрашивается, как быть со всеми этими проблемами? Мы детально обсудим эти вопросы позже, а сейчас можно сказать одно – надо отказаться от представления, что проект – это производство продукта. От очень опасного представления, от опасного для самого проекта, и, в первую очередь, для менеджера и исполнителей проекта. Гораздо правильнее и безопаснее считать, что проект – это производство продуктов для каждой заинтересованной стороны. Или, если кому-то больше нравится, то же самое, но с другой стороны: проект – это производство сложного, составного продукта, по кусочку для каждого интересанта.

Проект – это начинание, которое:

— производит согласованные результаты с целью удовлетворения потребностей заинтересованных сторон

— ограничено во времени, ресурсах и стоимости

— имеет существенную уникальность

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

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

1.9 РАБОЧАЯ МОДЕЛЬ ПРОЕКТА

Предшествующее обсуждение приводит вот к такой модели проекта:

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

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

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

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

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

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

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

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

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

Наша модель – не исключение. Наверное, главным упрощением является то, что в реальных проектах каждый элемент модели является иерархией. Например, считать Заказчика цельной единой заинтересованной стороной со вполне определенными требованиями – это, зачастую, прямой путь к провалу проекта. Если в организации Заказчика явно присутствуют группы и лица с разными требованиями к проекту, то все эти требования должны быть отражены. А это означает, что вместо одного интересанта появляется иерархия интересантов. Более того, это означает тиражирование этой иерархии вправо по ветке модели – появление соответствующих иерархий в требованиях, результатах, работах, ресурсах и показателях. Страшно? На самом деле – не очень. На помощь всегда придёт лучший друг менеджера – компьютер! Гораздо страшнее – не учесть существенное требование. Тут уж на помощь никто не придет…

1.10 ЧТО ТАКОЕ УПРАВЛЕНИЕ ПРОЕКТОМ?

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

Попробуем порассуждать от простого к сложному. Пусть у нас есть очень простой объект управления, скажем – тележка на колесах, которую можно передвигать туда-сюда.

Управление в таком простом случае выглядит так:

— Определяем цель управления, то есть желаемое положение тележки

— Определяем воздействия, которые приведут тележку куда нужно

— Производим воздействия

— Оцениваем фактическое положение тележки и, если надо, повторяем все сначала

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

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

Множество «тележек» — это не подарок, но есть более принципиальная сложность – в проекте не один, а множество «толкателей», усилия которых надо координировать, и усугубляется все множеством «не пущателей», усилия которых надо нейтрализовывать. Подарком можно считать то, что несмотря на эти сложности, управление проектом происходит полностью согласно классическому циклу, но с особенностями, характерными для любого сложного производства, в котором задействовано множество участников. А именно, в управлении проектами доминируют два элемента цикла: планирование — для координации действий участников и контроль – для отслеживания и корректировки любых отклонений или сбоев, основными источниками которых являются опять же участники.

С учетом этого мы можем говорить об управлении проектом достаточно конкретно. Мы видим, что:

Основа управления проектом – это управление работами проекта путем планирования и контроля.

1.11 ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТОМ

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

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

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

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

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

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

ЧТО ДАЛЬШЕ?

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