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

Самоучители ♦ Справочники по стандартам УП ♦ Имитатор экзамена PMP ♦ Обучение

Разработка календарного плана проекта: 2
Сергей Вратенков. Планирование работ проекта
First Prev 1 2 3 4 5 6 7 Next Last

1 Проекты и их окружение

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

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

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

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

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

 

1.1 Что такое проект?

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

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

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

Наше определение проекта выглядит пока простенько, но кое-что мы уже имеем! А имеем мы вот что.

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

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

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

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

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

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

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

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

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

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

 

1.2 Определение проекта в стандартах ISO 21500 и PMBOK Guide

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

ISO 21500:

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-й включительно) дает такое определение проекта:

PMBOK Guide:

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.1. Жизненный цикл продукта (Стандарт EIA649)

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

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

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

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

 

1.8 Заинтересованные стороны

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

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

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

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

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

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

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

Вот наше рабочее определение проекта:

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

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

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

 

1.9 Рабочая модель проекта

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

Модель проекта

Рисунок 1.2. Модель проекта

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

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

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

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

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

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

 

1.10 Что такое управление проектом?

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

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

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

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

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

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

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

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

 

1.11 Процессы управления проектом

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

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

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

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

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

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

 

1.11 Что дальше?

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

 

First Prev 1 2 3 4 5 6 7 Next Last