Глава 1. Общий взгляд на управление проектами
Со времени выхода первого издания этой книги в 1997 году количество членов международного Института по управлению проектами (Project Management Institute, PMI) возросло с нескольких тысяч до 462 000 в 2015 году. Для тех, кто не в курсе, поясним, что PMI – это профессиональная организация людей, управляющих проектами (менеджеров проектов)[1]. Она обеспечивает своих членов целым набором услуг; однако главная ее задача – развитие области управления проектами как отдельной профессии. Для этого разработаны специальные программы сертификации, благодаря которым отдельные физические лица могут получить квалификацию «профессионал в управлении проектами» (РМР) при наличии профессионального опыта (примерно 5000 часов работы по специальности) и условии прохождения серии онлайновых тестов и экзаменов, построенных на основе информационного пакета Руководства к Своду знаний по управлению проектами (PMBOK® Guide).
Профессиональная организация? Только для управления проектами? Разве управление проектами не является всего лишь одной из разновидностей общего управления, или менеджмента?
И да и нет. Между ними много сходства, но существуют и различия, которые требуют выделить управление проектами в качестве области знаний, отличной от общего менеджмента. Проекты обычно в большей мере привязаны к срокам, нежели большая часть того, чем занимаются общие управленцы. Кроме того, именно им, а не менеджерам проекта обычно напрямую подчиняется команда проекта.
И все же, что такое управление проектами и что такое проект? Институт по управлению проектами определяет проект как «временное предприятие, направленное на создание уникального продукта, услуги или результата» (PMBOK® Guide, PMI, 2015, с. 5). Это означает, что проект осуществляется только единожды. Если мероприятие повторяется, то это уже не проект. Проект должен иметь определенные точки начала и завершения (время), бюджет (стоимость) и четко определенные объемы или величину работы, которую надлежит выполнить, а также специфические требования к результатам. Я говорю «должен», потому что редко какой проект соответствует всем этим определениям. В книге данные условия проектов определяются как «цели РССС» (результат, стоимость, сроки, содержание).
Д-р Дж. М. Джуран, видный эксперт по вопросам управления качеством, определяет проект как некую проблему, запланированную к решению. Это определение мне нравится, поскольку напоминает о том, что любой проект осуществляется в целях решения той или иной проблемы компании. Однако должен предупредить, что слово «проблема» часто несет в себе негативный смысл. Проекты же имеют дело как с позитивными, так и с негативными проблемами. Так, разработка нового продукта или товара является позитивной проблемой, а проект по очистке окружающей среды, как правило, – проблемой негативного плана.
Проект – это некая проблема, запланированная к решению.
Неудачи проектов
Современные исследования указывают на неоднозначные результаты управления проектами. Последний доклад транснациональной консалтинговой корпорации Standish Group[2], который, как обычно, в основном сконцентрирован на проектах IT, в частности в области разработки новых программ компьютерного обеспечения, показывает, что из общего числа новых проектов 29 % оказались успешными, 52 % столкнулись с трудностями, а 19 % закончились неудачей. Следует отметить, что факторы успеха были «актуализированы», то есть проекты были завершены вовремя, в пределах выделенного бюджета и с удовлетворительными результатами. Этот показатель успешности проектов практически не изменился с предыдущего доклада от 2011 года. Standish Group особо выделяет то обстоятельство, что меньшие по размерам проекты имеют значительно большие шансы на успех, чем более крупные. Gartner, консалтинговая компания в области высоких технологий, в своих последних отчетах дает аналогичные данные, отмечая, что большие по размерам проекты (с бюджетами, превышающими $1 млн) чаще терпят неудачу. Это происходит примерно в 28 % случаев.
Наиболее убедительными оказались данные, опубликованные недавно Институтом по управлению проектами (Project Management Institute). PMI осуществляет постоянный мониторинг состояния управления проектами, программами и портфелями проектов. Исследование института под названием «Пульс профессии», обнародованное в 2015 году, отмечает появление позитивных трендов, однако при этом подчеркивает, что доля проектов, достигших своих целей, осталась практически неизменной по сравнению с 2012 годом: 64 %. Для исправления ситуации PMI предлагает организациям вернуться к фундаментальным основам проектного менеджмента, а именно трем составляющим.
1. Корпоративная культура. Необходимо создавать специфический психологический настрой у работников.
Профессионализм. Следует сконцентрировать внимание на работе по подбору и подготовке адекватных кадров, их постоянном обучении и стимулировании к обмену знаниями и навыками.
Организация процесса управления проектами. Сферу управления проектами необходимо поддерживать путем разработки и принятия в компании стандартизированной практики и требований к организации процесса управления проектами.
Мой личный опыт – 28 лет управления проектами, изучения практики, консультационной деятельности и организации профессионального обучения – убеждает меня в том, что чем больше меняются вещи, тем больше все остается по-старому. Давно ясно, что во многих наших бедах виновато плохое планирование. Успешные проекты – крупные и небольшие, будь то в области IT, исследований и развития или организационной практики – все основаны на хорошем планировании. Однако слишком многие менеджеры проектов с самого начала работы с ходу занимают «позиции на огневом рубеже» в попытке завершить проект как можно быстрее. Во многих организациях им не отпускают достаточного времени на планирование работы, если отпускают вообще. В результате много времени и усилий уходит на исправление ошибок, успокоение недовольных заказчиков и партнеров и выход из блуждания по тупикам. Короче говоря, именно недостаток адекватного планирования приводит проект к неудаче.
Исследование PMI констатирует, что «для компаний и организаций настало время вновь обратиться к основам науки управления проектами, по существу, к ее базовым принципам». Я всецело за такой подход. Вы, читатель, должны создать собственный фундамент знаний и освоить изложенные здесь базовые принципы, чтобы обеспечить свое совершенствование и успех в движении вперед и в работе над новыми проектами.
Что такое управление проектами?
Руководство к Своду знаний по управлению проектами (PMBOK® Guide) определяет управление проектами как «приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Управление проектом осуществляется посредством надлежащего применения и интеграции логически сгруппированных 47 процессов управления проектом, объединенных в пять групп:
• инициация;
• планирование;
• исполнение;
• мониторинг и контроль;
• закрытие.
(PMBOK® Guide, PMI, 2015, с. 6).
Управление проектами – это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Управление проектом осуществляется посредством надлежащего применения и интеграции логически сгруппированных 47 процессов управления проектом, объединенных в пять групп: инициация, планирование, исполнение, мониторинг и контроль, закрытие.
Новый PMBOK® Guide вводит пять новых процессов в управлении проектами.
1. Процесс управления содержанием проекта.
2. Процесс управления расписанием проекта.
3. Процесс управления стоимостью проекта.
4. Процесс управления заинтересованными сторонами проекта.
5. Процесс контроля вовлечения заинтересованных сторон проекта.
Это новое изменение подчеркивает, что команда проекта должна осуществлять его планирование до начала собственно работы по управлению проектом. Функции 4 и 5 (функции управления заинтересованными сторонами проекта и контроля вовлечения заинтересованных сторон проекта) были добавлены для соответствия позиции об «Управлении заинтересованными сторонами проекта» как новой, десятой сфере знаний в управлении проектами, которая подчеркивает важность правильного вовлечения заинтересованных сторон в принятие ключевых решений и действий по проекту.
Требования к проектам включают в себя целевые параметры РССС (результат, стоимость, сроки и содержание). Различные этапы проекта: его инициация, планирование и т. п. – подробнее рассмотрены далее в этой главе. Вообще большая часть книги посвящена тому, как практически осуществляются функции управления проектами на каждом из этих этапов.
Было бы лучше, если бы в Руководстве к Своду знаний по управлению проектами (PMBOK® Guide) было четко указано, что менеджер проекта должен всячески содействовать его планированию. Одна из частых ошибок молодых профессионалов по управлению проектами состоит в том, что они пытаются все спланировать за свою команду. По этой причине их планы не воспринимаются членами команды, к тому же они полны пустот. Менеджеры не могут продумать все за всех; их оценки временных затрат на решение тех или иных задач, как правило, ошибочны, и уже на старте проекта все их планы разваливаются. Первое важнейшее правило в управлении проектами состоит в том, что люди, выполняющие в них ту или иную работу, должны помогать в ее планировании.
Задача менеджера проекта – помогать своей команде в том, чтобы работа была выполнена; в том, чтобы команда не отвлекалась; в том, чтобы «выбивать» не всегда доступные ресурсы, в которых нуждается команда, и в том, чтобы отклонять возможное вмешательство внешних сил, которые могут помешать работе команды. Менеджер проекта не является его царем. Он должен быть прежде всего подлинным лидером проекта, в самом глубоком значении этого слова.
Лучшее определение лидерства, которое я нашел до сих пор, – это определение Вэнса Паккарда[3], данное им в книге «Покорители пирамид» (The Pyramid Climbers, Crest Books, 1962). Он говорит: «Лидерство – это искусство заставлять других хотеть сделать то, что, как вы считаете, должно быть сделано». Главное слово здесь – «хотеть». Диктаторы заставляют других делать то, чего хотят сами диктаторы. То же самое с тюремщиками, которые выступают в качестве надсмотрщиков за трудом заключенных. Однако лидер заставляет людей хотеть выполнить работу, и в этом состоит принципиальное различие в этих ситуациях.
Лидерство – это искусство заставлять других хотеть сделать то, что, как вы считаете, должно быть сделано.
Планирование, точный расчет сроков исполнения и контроль представляют собой управляющую, или административную, часть работы менеджера проекта. Без лидерства проекты часто сводятся к удовлетворению лишь минимальных формальных требований. А вот при наличии лидерства они могут выходить за пределы голого минимума. Я предлагаю комплексный взгляд на приложение к проекту методик лидерства в главе 14.
Распространенной ошибкой является представление о проекте исключительно как о расписании действий. Судя по последнему отчету, корпорация Microsoft продала огромное количество копий программы Microsoft Project®, однако процент неудачных проектов по-прежнему высок. Важными инструментами осуществления проекта являются составление и контроль сроков его реализации. Однако по своей важности они все же уступают таким аспектам, как достижение общего понимания командой целей проекта, а также формирование действенной системы распределения работ, которая покрыла бы все действия команды. (Об этой системе я подробнее расскажу в главе 7.) Если не удастся осуществить другие звенья в управлении проектом, то его детальное расписание позволит лишь с большой точностью задокументировать свои неудачи!
Хочу особо выделить пункт, касающийся программного обеспечения проекта. В конце концов, не так уж важно, какой пакет программ вы выберете: все они имеют и сильные, и слабые стороны. Однако предпочтительнее подбирать для команды такое программное обеспечение, которое она освоит быстро и без дополнительной подготовки. Иначе оно не сработает. Большинство людей не вникают в детали программ, составляющих рабочие и другие графики. Обычно сотрудникам не хватает на это времени, поскольку они заняты выполнением своих непосредственных обязанностей. Кроме того, не все имеют склонность к самообразованию. Вы ведь не станете нанимать новичка для управления сложными машинами на производстве без соответствующего профессионального обучения, потому что знаете, что он может сломать технику и покалечить себя. Зачем же тогда поступать практически таким образом с программным обеспечением проекта?
Случалось ли вам неожиданно оказаться в роли управляющего проектом без соответствующего должностного обозначения «менеджер проекта» или без особенной поддержки? И не приходилось ли тогда считать себя одновременно и менеджером проекта, и рядовым работником? Если да, то вы не одиноки. Все чаще и чаще работа попадает под определение проекта, данного Руководством к Своду знаний по управлению проектами (PMBOK® Guide) в 2013 году (PMI 3, 2013): «временное предприятие, направленное на создание уникального продукта, услуги или результата». Есть сроки выполнения работы, ее содержание, ограниченные ресурсы и зачастую строго ограниченный бюджет. Такие проекты или программы менее формализованы и не имеют отдельной команды, однако их тоже необходимо планировать, четко рассчитывать по времени и контролировать. Уникальный или просто приемлемый продукт следует произвести и доставить заказчику, а тот должен быть восхищен или как минимум удовлетворен.
Я веду семинар «Основы управления проектами для НЕ менеджеров проектов» в некоммерческой образовательной и консультационной организации American Management Association International в Нью-Йорке. Он стал весьма популярным и обратил на себя внимание управляющих проектами с нестандартными подходами, экспертов в различных сферах бизнеса, спонсоров и филантропов. Типичные слушатели – менеджеры по продажам, администраторы, менеджеры по маркетингу, менеджеры по снабжению и другие. У меня создалось впечатление, что большинство из них в той или иной степени связаны с управлением проектами. Они не являются менеджерами проектов в традиционном смысле этого слова, однако в какой-то мере им приходится заниматься этой работой. Методики и инструментарий, которыми оперируют менеджеры проектов, могут им быть полезны. Я люблю говорить моим слушателям о том, что инструменты в управлении проектами применимы везде, но их ценность зависит от того, каким именно образом они применяются.
Первое: оцените работу. Ограничены ли вы ее содержанием, стоимостью и ресурсами? Существует ли конкретный срок завершения? И тогда переходите к организации этой работы как проекта. Определите, какие инструменты управления проектами наиболее подходят в этом случае. Например, проект со сроком завершения через две недели потребует значительно меньшего объема инструментов управления, чем проект со сроком исполнения в 50 недель. Ужмите или, наоборот, увеличьте «широту охвата» вашего менеджмента в соответствии с продолжительностью, глубиной и масштабами проекта.
В бизнесе нередко менеджеров проектов пытаются задействовать как исполнителей в тех же проектах. Это однозначный рецепт создания проблем. Если это настоящая команда проекта из нескольких человек, то ее руководитель неизбежно окажется зажатым между интересами управления проектом и необходимостью выполнять свою часть работы в группе. Естественно, приоритет отдается последнему, иначе начнут срываться графики, так что управление проектом не осуществляется. Руководитель думает, что это произойдет как-нибудь само собой, но так не получится. В конце концов, если бы команда могла управлять сама собой, то необходимость в руководителе проекта отпала бы. (Помните вопрос о том, зачем вообще нужно управление проектами?)
К сожалению, когда подойдет время оценки работы управляющего проектом, ему будет заявлено, что качество его управления требует улучшения. А на самом деле все, что требовалось сделать с самого начала, это разрешить ему заниматься именно управлением проектом.
В очень маленьких проектных командах, например из трех-четырех человек, менеджер проекта может и лично осуществлять какие-то сугубо рабочие функции. Однако по мере увеличения численности проектных групп выполнять одновременно два круга обязанностей – собственную работу и организацию управления проектом – становится невозможно, потому что потребности членов команды отрывают руководителя от выполнения собственной работы.
Иногда так происходит потому, что в некоторых организациях не до конца понимают, что такое управление проектами, и считают, что человек вполне может совмещать две функции. В результате заниматься управлением проектами там пытаются почти все сотрудники. Однако, как и в любом другом деле, одним это вполне удается, а другие не проявляют способностей к проектному менеджменту. Поэтому целесообразно выделить группу работников, имеющих склонность и желание исполнять обязанности управляющих проектами, и позволить им проявить себя на небольших заданиях. Это позволит «техникам» (в широком смысле этого слова) выполнять техническую работу, не касаясь административных вопросов, и, с другой стороны, даст возможность управляющим проектов совершенствоваться в профессиональном мастерстве.
Вопрос о том, как отбирать управляющих проектами, выходит за пределы этой книги. Но для заинтересованного читателя могу подсказать, что эта тема хорошо раскрыта в книге Роберта Высоцки и Джеймса Льюиса «Менеджеры проектов мирового уровня» (Pobert K. Wysocki and James P. Lewis “The World-Class Project Manager”, Perseus, 2001).
Нельзя получить все и сразу!
Часто бывает, что спонсор (заказчик) проекта требует, чтобы его управляющий завершил работу к определенному сроку, в рамках отведенного бюджета, с определенным содержанием или объемом и при условии достижения заранее обозначенных результатов. Одним словом, диктует все целевые параметры РССС (результат, стоимость, срок и содержание). Но это редко срабатывает.
Взаимозависимость между результатом, стоимостью, сроками и содержанием проекта может быть выражена формулой
Стоимость = f(x) (Результат, Сроки, Содержание),
то есть стоимость проекта является функцией его результата, сроков и содержания. Графически это можно выразить в виде треугольника, в котором результат, стоимость и сроки являются тремя сторонами, а содержание – его площадью (рис. 1.1).
Рис. 1.1. Зависимость между результатом, сроками, стоимостью и содержанием проекта
По законам геометрии, если нам известны три стороны треугольника, мы вычислим его площадь. Или, если известна площадь треугольника и длина двух его сторон, определим длину оставшейся третьей. Это переводится в одно практическое правило, действующее в любом управлении проектом: спонсор (заказчик) может задать любую или все из трех переменных величин, но руководитель проекта будет определять оставшуюся.
Предположим, заказчик выдвигает требования по трем параметрам проекта: результатам, срокам и содержанию. Значит, руководитель проекта должен определить стоимость достижения указанных результатов. Однако я всегда предупреждаю управляющих проектами, что при озвучивании стоимости проекта неплохо бы иметь рядом фельдшера: у спонсора может случиться сердечный приступ.
Он обязательно воскликнет: «Почему так дорого?» У него в голове была своя цифра, а ваша ее явно превосходит. Он может сказать: «Если это столько стоит, мы не оправдаем свои расходы». Вот именно! Это именно то решение, которое заказчик должен принять. Однако он уверен, что ему удастся склонить руководителя проекта на снижение стоимости. И если вы согласитесь, то только ввяжете и заказчика, и себя в гораздо более серьезные проблемы, которые возникнут позднее.
Назвать спонсору настоящую цену – ваша обязанность. Это нужно, чтобы он принял правильное решение относительно данного проекта. Если поддаться давлению и подписаться на более низкую сумму, позже случится катастрофа. Поэтому для вас гораздо лучше понести возможное наказание сейчас, чем быть повешенным позднее.
Разумеется, есть и другая возможность. Если визави говорит, что может позволить себе заплатить только такую-то ограниченную сумму за проект, вы можете предложить ограничить его содержание или объем. Если проект годится и с таким объемом, он может быть осуществлен. Иначе разумнее и экономнее вообще забыть о нем и взяться за что-то другое, более прибыльное. Кто-то сказал, что скорее в проекте случайно что-то пойдет не так, чем все пройдет идеально. Что касается стоимости проекта, бюджет наверняка будет превышен. Это просто другой вариант изложения закона Мёрфи: «Если какая-нибудь неприятность может случиться, то она обязательно произойдет».
Фазы проекта
Существует множество моделей деления проекта на фазы его жизненного цикла. Одна из таких моделей, которая отражает весьма распространенный тип проблемных проектов, представлена на рис. 1.2.
Рис. 1.2. Жизненный цикл проблемного проекта
Я показывал этот рисунок разным людям по всему миру, и все они улыбались и говорили: «Да, именно так все и происходит». Меня в этой ситуации успокаивает лишь то, что не только американцы сталкиваются с подобными проблемами. Плохо то, что если все признают эту модель, то многие проекты обречены на неудачу.
На простейшем уровне проект имеет свое начало, середину и конец. Я предпочитаю модель жизненного цикла проекта, изображенную на рис. 1.3, но и другие варианты имеют право на существование. В моей модели вы увидите, что любой проект начинается с расплывчатой концепции и команда должна сформулировать содержание работ до того, как к ним приступать. Однако нередко мы начинаем работать над проектом исходя из того, что имеем его правильное определение или что участники разделяют его цели и понимание необходимой работы. Это неизменно создает трудности по мере продвижения проекта (рис. 1.3).
Рис. 1.3. Правильный жизненный цикл проекта
Несколько лет назад управляющий проектом одной компании, которая тогда была моим клиентом, пригласил меня к себе и сказал: «Я только что провел онлайн-конференцию с ключевыми сотрудниками моей команды и понял, что мы не можем прийти к единому мнению о том, чего должен достичь наш проект».
Я ответил, что такая ситуация складывается довольно часто.
«И что же мне делать?» – спросил он.
Я ответил, что ему придется заставить членов своей команды двигаться в одном направлении, объяснив им, какая высокая цель или миссия стоят перед проектом. Он попросил меня помочь провести такую встречу.
На встрече я подошел к доске и сказал: «Давайте запишем, какая проблема стоит перед нами». Кто-то сразу же возразил: «Не нужно, мы и так знаем, в чем проблема».
Я, не смутившись, ответил: «Ну что ж, если так, то записать ее – пустая формальность, на это потребуется всего несколько минут. Мне удобнее, если она будет изложена письменно. Поэтому прошу вас помочь нам начать».
Далее можно было позабавиться. Кто-то сказал: «Но…» Я записал это на доске. Кто-то воскликнул: «Я с этим не согласен!»
Через три часа мы, наконец, завершили письменное формулирование проблемы.
Руководитель проекта оказался прав. В его команде не было единого мнения ни о том, в чем состояла проблема, ни о способах ее решения. Я с этим сталкиваюсь настолько часто, что начинаю думать, что у всех нас есть некий дефектный ген, который мешает правильно сформулировать проблему, прежде чем приступать к работе над ней. Помните: руководитель проекта решает проблему в большом масштабе. И от того, как вы ее сформулируете, зависит, как вы будете ее решать. Если проблема определена неправильно, то вы можете найти правильное решение, но не для данной конкретной проблемы!
Я убедился, что проекты редко терпят неудачу под конец. Как правило, они проваливаются на этапе определения проекта. Как подсказывает само это слово, определительная фаза наступает очень рано: когда формулируется проблема, определяется цель и проясняется миссия проекта. Я называю проекты без правильного определения «курицами без головы», потому что они похожи на кур с только что отрубленными головами, которые мечутся по двору, заливая все кровью, и только через несколько минут падают замертво. С проектами происходит то же самое. Они «разбрызгивают кровь» повсюду, пока кто-нибудь не скажет: «Думаю, этот проект мертв». Так оно и есть на самом деле. Но мертвым-то он стал тогда, когда мы отрубили ему голову в самом начале. Просто потребовалось некоторое время для того, чтобы все это осознали.
Только определив проект, можно планировать работу. В таком плане три составляющие: стратегия, тактика и логистика. Стратегия – это общий подход, или «план на игру», которому вы будете следовать на всем протяжении работы. Приведенный в следующем разделе пример стратегии рассказал мне мой друг, который специализируется на военной истории.
Стратегическая фаза проекта определяет максималистский подход, который закладывается в ваш проект, чтобы он достиг предъявляемых к нему требований. Хороший пример – история судоверфей Avondale. Во время Второй мировой войны производители вооружений столкнулись с жесткой необходимостью производства военной техники максимальными темпами. В то время были изобретены многие новые методы сборки, особенно в военном судостроении и авиастроении. Судоверфи Avondale на реке Миссисипи к северу от Нового Орлеана тоже взяли на вооружение новые судостроительные технологии. Традиционно суда строились в положении днищем книзу. Однако стальные корабли требовали сварки именно по днищу, в области киля. А сделать это чрезвычайно трудно. Тогда на верфях Avondale решили строить суда в положении днищем кверху, что оказалось гораздо проще, а потом переворачивать их в традиционное положение для строительства внутренних механизмов и палубных надстроек. Эта стратегия оказалась настолько успешной, что судоверфи Avondale смогли строить военные корабли быстрее, дешевле и с более высоким качеством, чем их конкуренты. И что примечательно: эта же технология используется и сегодня, 70 лет спустя.
Фаза имплементационного планирования проекта включает в себя разработку тактики и логистики. Если вы собираетесь строить корабли днищем кверху, то должны проработать в деталях, как это будет осуществляться. Необходима система крепежей, которые удерживают корпус корабля в перевернутом состоянии, а затем позволят перевернуть его в нормальное положение без ущерба для судна. Это называется разработкой тактики. Она включает в себя последовательность предстоящих работ, описание того, кто и что будет делать, а также расчет времени, которое займет каждый технологический шаг.
Логистика обеспечивает команду проекта необходимыми ресурсами для выполнения работы. Обычно мы представляем это как снабжение команды сырьем и другими производственными материалами. Но если она будет работать в местности, лишенной продовольствия, и никто об этом не подумает, то работа вскоре встанет. Поэтому в том, что касается команды, все должно быть продумано до мелочей: и чем ей питаться, и, возможно, где ей жить.
Когда планы разработаны и утверждены, команда может приступать к работе. Это исполнительская фаза проекта, но она включает в себя и контроль: по мере имплементации проекта осуществляется мониторинг за его продвижением в соответствии с планом. При отклонениях от плана предпринимаются корректирующие действия, которые возвращают проект на заранее определенные позиции. Если это оказывается невозможным, планы изменяются и утверждаются заново. Ревизованный исправленный план становится той основой, по которой проект движется вперед.
Когда все работы по проекту завершены, на фазе закрытия требуется произвести анализ всего проекта. Цель – вынести из проведенной работы все необходимые уроки, которые могут быть применены в дальнейшем. При этом ставятся два вопроса: «Что мы сделали хорошо?» и «Что мы хотели бы улучшить в следующий раз?»
Обратите внимание: вопрос о том, что было сделано неправильно, не задается. Он заставляет людей занимать оборонительную позицию, и они постараются скрыть те вещи, за которые их могут наказать. Поэтому анализ уроков, выносимых из работы над проектом, никогда не стоит проводить в атмосфере обвинений и наказаний. Если вы хотите заняться инквизицией, это ваше дело. Цель инквизиции – найти ответственного за все катастрофы и горести мира и наказать его. Цель анализа уроков, полученных в ходе реализации проекта, должна точно соответствовать тому, что обозначают эти слова.
За последние несколько лет я открыл для себя, что в очень немногих организациях регулярно проводится анализ уроков, вынесенных из реализованных проектов. Есть в этом какой-то страх открыть «коробку с тараканами». При этом демонстрируется желание переключиться на новые проекты. При таком подходе вы почти наверняка повторите совершенные ранее ошибки, если никто не знает о них и не имеет представления, как они произошли и как предотвратить их в дальнейшем. Однако, пожалуй, главное – вы не можете воспользоваться опытом удачных решений и действий.
Неоднократно звучали утверждения о том, что выживут и будут процветать те организации, которые учатся быстрее конкурентов. Это особенно верно в отношении проектов.
Шаги в управлении проектами
Реальные шаги в управлении проектами достаточно понятны. А вот их выполнение – не совсем. Рисунок 1.4 иллюстрирует эти шаги. В следующих главах подробно описывается каждый шаг. Сейчас приведем только краткое описание соответствующих процессов.
Рис. 1.4. Шаги в управлении проектом
Итак, прежде всего следует определить проблему, которую должен решить проект. Это помогает визуализировать желаемое и результат. Что изменится? Что нового вы увидите, услышите, почувствуете, ощутите на вкус или на запах? (Используйте сенсорное восприятие, если не можете дать количественное определение.) Какая потребность вашего клиента будет удовлетворена?
Сколько существует различных путей для решения данной проблемы? Проанализируйте альтернативные варианты (можете сделать это в одиночку или в составе группы). Какой из них, по вашему мнению, наилучший? Он дороже или дешевле других? Даст ли он полный или только частичный результат?
Конец ознакомительного фрагмента.