Point of Total Assumption - что это такое

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

Первая из таких заметок будет посвящена Point of Total Assumption – параметру, который в последние годы все чаще принято (а кое-где и требуется) указывать в контрактах типа Fixed Price plus Incentive Fee (FPIF). Поскольку русского наименования для этого термина я пока не нашел, то применяю самодельный перевод: Точка полного принятия ответственности.

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

Зачем менеджеру знать миссию проекта?

Значительная часть моих знакомых бизнесменов склонна относить понятие "миссия" к тем новомодным штучкам-дрючкам, которые годятся разве что для засорения мозгов слушателям школ МВА, и потому никакой практической пользы для реального дела не приносящим. Одним словом - "пальцы". Не желая распыляться на тему, что такое бизнес без понимания его миссии, остановлюсь на том, что вынес в заголовок.
Бесспорно, проект как временное предприятие во многом наследует особенности и потребности любого бизнеса. Если у проекта не определена оргструктура, то при достаточной величине проекта в нем начнется точно такой же бардак, как и в неструктурированной, к примеру, торгово-закупочной компании. Разница будет заключаться только в том, что проекты, как правило, быстрее прогорают. Аналогично дело обстоит и с миссией.
"Но то все относится к стратегиям" - заметят некоторые из моих коллег. "А мы-то - практики! Наше дело - двигать проект, поставлять результаты вовремя и за оговоренные деньги/трудозатраты". И вот тут они окажутся не правы…
В интересах менеджера проекта не просто представлять миссию того дела, которое он возглавляет, но и весьма желательно твердо ее знать. К чему может привести неведение в данной области, проиллюстрирую на двух примерах из личного опыта.
Пример первый.
Достаточно немалый машиностроительный завод (более 1000 сотрудников) нанимает меня для внедрения процессов управления проектами. Мои попытки выяснить назначение результатов проекта для бизнеса этого завода буквально обрезаются тезисом "Хозяин приказал - обсуждению не подлежит. Он дважды никогда не повторяет". Полагаюсь на свое ощущение миссии проекта, основанное на том, что производство на заводе носит типично проектный характер и может существенно прибавить в эффективности, и с энтузиазмом берусь за дело.
Результат оказался печальным. Через 4 месяца проект был прекращен без видимых на то причин. Не так уж трудно догадаться, что объяснение было то же самое: "Хозяин приказал - обсуждению не подлежит. Он дважды никогда не повторяет". Слабым утешением было лишь то, что материально я не пострадал. Но время-то и силы потрачены "в корзину". А чего стоит обманутое ожидание близкого успеха проекта?
Пример второй.
В качестве стороннего менеджера проекта, я руковожу внедрением информационной системы в одной из хорошо известных в Украине корпораций. Считаю себя умудренным давним опытом из предыдущего примера, поэтому прежде, чем дать согласие на участие в проекте, я настойчиво выясняю его назначение для бизнеса. Будущий спонсор проекта буквально излучает уверенность в огромной важности проекта, но никак не сформулирует, чем она определяется. Получив некоторое представление о бизнесе корпорации, его потребностях и текущих вызовах, я пытаюсь помочь спонсору и подсказываю свои варианты. В конце концов, мы сошлись на двух очень правдоподобных формулировках назначения проекта: повышение эффективности деловых процессов за счет их унификации по предприятиям корпорации, а также повышение качества исходной информации для принятия управленческих решений руководством предприятий и корпорации в целом. Как говорится, вот и ладненько, поехали…
Первый этап проекта "Техническое задание" был оперативно спланирован, опираясь на энтузиазм и поддержку спонсора хорошо и "правильно" стартовал, но по завершению этапа проект был остановлен. Неожиданно для многих, дальнейший подход к его выполнению и предполагаемый график категорически не устраивали руководство. И вот тогда, наконец, вскрылось назначение проекта, о котором до тех пор никто не решался сказать подрядчикам открыто. "Страшная тайна" заключалась в том, что корпорация готовилась к выходу на IPO. Автоматизация была одним из шагов на дороге к фондовому рынку. И у шага этого оказались критические сроки…
По большому счету, все закончилось без серьезных потерь. Проект был перепланирован таким образом, чтобы можно было "ставить птицу" в контрольном списке подготовки к IPO, не дожидаясь завершения проекта. Но значительная часть ранее проделанной работы все же ушла в корзину.
В качестве резюме приведу три вывода, которые я вынес из этих историй:
1. Если миссию (назначение) проекта никто не может сформулировать, этот проект - не для меня.
2. Если назначение проекта заказчиком видится не четко, не стоит спешить строить замок из песка, поскольку "в действительности все окажется не так, как на самом деле".
3. Додумывать за заказчика - занятие неблагодарное.

Кейс: управление ожиданиями заинтересованных сторон

"Управление ожиданиями заинтересованных сторон включает мероприятия по коммуникациям, ориентированные на заинтересованные стороны проекта для того, чтобы влиять на их ожидания, устранять беспокойство и решать проблемы, …"
PMBOK®Guide - Fourth Edition

Краткая характеристика проекта
Назначение (миссия) проекта: Сделать ребенку обещанный подарок
Цель проекта: Купить ребенку обещанный игрушечный автомобиль за сумму, не более ХХХ денежных единиц.
Главные заинтересованные стороны проекта: Папа (П), мама (М) и сын примерно 5 лет (С)
Ожидаемые результаты проекта:
- №1. Игрушечный электромобиль с радиоуправлением
- №2. Довольный ребенок
Спецификация требований к результату №1: "Хочу, как у дяди Жоры". Судя по готовности стороны "С" подкрепить требование ревом, приоритет требования "Критический".

Статус проекта на 11:20 31.01.10:
В результате осмотра выставленных на полках детского супермаркета "Антошка" игрушек, участники "П" и "М" обнаружили, что среди представленных моделей нет полностью соответствующей критическому требованию к результату №1. Есть подходящие модели с кузовом "седан" различных цветов за исключением белого (как у дяди Жоры). Участник "С" еще не понял всей глубины ожидающего разочарования и продолжает оживленно вертеть головой.

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

Статус проекта на 11:45 31.01.10:
Заинтересованные стороны в полном составе покинули магазин. Сторона "С", сияя от счастья, держала за руки стороны "М" и "П". Вторая рука стороны "П" держала коробку с купленной игрушкой...

Игра в "Угадай мелодию" как способ заранее угробить проект

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

Почему Освоенный объем не всегда работает?

Каждый, кто хотя бы пытался внедрить анализ освоенного объема в практику управления проектом, прекрасно знает, сколько усилий приходится истратить и менеджеру проекта, и руководству его организации, чтобы наладить сбор необходимых для этого данных. Тем болшее разочарование Вас может ожидать, если получив в свое распоряжение "вожделенные" BCWP, BCWS и ACWP, Вы обнаружите, что они говорят о Вашем проекте явно нелепые вещи.
Читать всю статью ...

Миф о сертификации PMP

Довольно часто сталкиваюсь с распространенным заблуждением: чтобы получить сертификат PMP (от PMI), необходимо и достаточно выучить Руководство PMBOK. По личному опыту сертификации могу утверждать, что основные положения PMBOK знать, в принципе, надо, но для сертификации этого крайне недостаточно.

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

Вопросов на знание PMBOK (процессы, входы, выходы) на моем экзамене оказалось не так уж много. Причем вопросы такого рода или отличались примитивностью, или же 2 - 3 варианта представленных ответов (из 4-х возможных!!!) были настолько очевидно бредовыми, что я их даже не пытался рассматривать всерьез. Достаточно сказать, что мои опасения насчет того, что я так и не нашел времени прочесть PMBOK "от корки до корки", не оправдались. Самыми трудными оказались вопросы "ситуационные", с PMBOK практически не связанные.

Когда-то, общаясь с ПМ-ом из Oracle, я с сомнением отнесся к его словам о том, что экзамен PMP для него был очень легким, поскольку он просто отвечал так, как это происходит у них в компании. Теперь верю.

Надо сказать, что 200 вопросов (иногда не слишком вразумительных) на 4 часа - это достаточно высокий темп. Долго раздумывать, анализировать и оценивать варианты здесь некогда. Поэтому вам вряд-ли помогут прочитанные книги. Реально поможет только опыт и "правильные" навыки, приобретенные в практической деятельности. Мне повезло, что я такой опыт имел ;-) На курсах подготовки к сертификационному экзамену (кстати, очень полезная вещь) учат вопросы классифицировать, ответы анализировать и т.п. Находясь в состоянии теплового удара в "аквариуме" для тестирования с неисправным кондиционером и с палящим июньским солнцем за окном, я просто физически был не в состоянии что-либо анализировать. Я не имел иного выхода, как отвечать без особых раздумий, выбирая более "симпатичный" ответ, опираясь на свой опыт и хорошее знание Процесса управления проектами ТенСтеп (я его применяю сам, ему обучаю, внедряю его клиентам). В результате, первый "проход" по 200 вопросам у меня занял 3 часа. Еще минут 20 я потратил на повторный просмотр помеченных вопросов, в которых я сомневался в первый час экзамена (пока еще были силы сомневаться). Кстати, из пары десятков вопросов ответ изменил только в одном. В общем, через 3,5 часа я уже любовался протоколом экзамена с печатью центра тестирования Прометрикс.

Подведу итог для готовящихся к экзамену:

1. Заучивание PMBOK - пустая трата времени. Конкретно, из него надо знать терминологию, основные определения и назначение процессов управления проектом (вводная часть в описании каждого процесса). Входы-выходы, как правило, легко угадываются по смыслу.

2. Чтобы быть готовым к особенностям экзамена, а также освоить некоторые "уловки", стоит пройти специализированный курс подготовки, хотя бы дистанционный, а также потренироваться отвечать на вопросы, аналогичные экзамену, на специальных сайтах в Интернет. Лично мне очень помогло то, что я, следуя совету с такого курса, еще до начала экзамена выписал на выданной мне бумаге все важнейшие формулы. К концу экзамена я бы уже не вспомнил и таблицу умножения.

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

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

5. Нужно иметь опыт "правильного" управления проектами. Кому не повезло работать в управленчески зрелой организации, чрезвычайно полезно будет пройти имитационный семинар с управлением проектом на симуляторе, например, SimulTrain, который проходил я сам. Полагаю, что в такие симуляторы (по крайней мере, могу поручиться за SimulTrain) заложены правильные принципы управления проектом, и результат ваших правильных или неправильных действий тут же становится виден "во всей красе".

6. Самое главное. К экзамену надо отнестись серьезно и приходить с настроем на успешную сдачу.

Мысли об управлении проектом в условиях функциональной организации

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

В действительности, у функциональной организации существует достаточно сильных сторон, которыми остается грамотно распорядиться, чтобы обратить их на пользу проекту. Читать далее →