Цитата о завершении проекта судят не по тому в какие сроки он реализован

Обновлено: 06.11.2024

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

Следующая цитата

Крупные проекты часто дробят на фазы. Фаза с точки зрения проектного управления – это часть проекта. Таких частей может быть несколько, и они стоят друг за другом. Обычно они стоят именно друг за другом, хотя бывают исключения, и они идут параллельно.

Фазы – это части проекта, над которыми обязательно работают разные команды.

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

В рамках проекта каждую фазу надо закрывать отдельно.

Закрытие проекта

Но вернемся к закрытию проекта. На протяжении всего проекта у менеджера следующая загрузка:

  • на уровне планирования – 100%;
  • большую часть проекта – 30% с возможными всплесками;
  • к закрытию загрузка прыгает примерно до 70%, а потом опадает в три этапа.



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

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

Ключевое, на что обращаю внимание: сдача-приемка – это формальное мероприятие. Это не место для выяснения отношений, не место для знакомства с приемной комиссией. Если вы нормально управляли ожиданиями заинтересованных сторон, вы идете, как студент-отличник подписать зачетку, а не сдавать экзамен. Потому что все, что нужно было заказчику знать, до него доносится раньше. Для этого есть управление заинтересованными сторонами. Но если вы заказчика долгое время держали в неведении, то сдача-приемка будет похож на взрыв, на ад. Это история о том, что не так страшны первые 70% проекта, как вторые 70%.

Следующий момент в закрытии – высвобождение команды. Это важный шаг. Когда проект закрыт, сдача-приемка прошла, я рекомендую провести kick-off meeting (первая общая встреча с командой) наоборот. Снова всех соберите и скажите, условно, «всем спасибо, все свободны». Почему это надо сделать? Для вас, как для менеджера, может, она не сильно важна. Но она важна для компании. Так вы дадите понять, что проект окончен, что вы благодарны людям, что им больше не надо работать на проекте. А если прилетит какая-то задача, связанная с ним, человек должен сказать, что больше не работает в этом проекте.

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

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

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

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

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

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

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

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

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

Можно сказать, что с «удавом» мы завершили. Мы прошли все инструменты, все алгоритмы, которые дает PMBoK менеджерам проектов.


Закрытие курса

Подведем короткий итог, что мы пытались сделать. У меня было три задачи:

  • представить алгоритм работы менеджера проекта, конкретную последовательность шагов (заинтересованные стороны, разработка устава, уточнение бюджета и работа с рисками);
  • рассказать про инструменты – с помощью чего работает менеджер (иерархическая структура, продолжительность и методы ее оценки, способы оценки рисков, пр.);
  • поведать про PMBok, чтобы можно было свободно читать стандарт управления проектами.


Напомню, что проектное управление работает, когда у вас есть задачи, ограниченные конечностью и неопределённостью. После этого курса вы сможете применить все, что слышали и узнали. Подчеркиваю: никаких других инструментов и алгоритмов нет.

Что касается PMBok, уверяю, что если вы откроете его, вы увидите, что целые его пласты вам понятны. Там есть узкие моменты, которые на курсе не освещались, но это нюансы. Ничего такого, о чем знают все менеджеры в мире, а вы после этого курса не слышали, не осталось: ключевые моменты мы разобрали.


Причина №4. Перескакивание между заданиями

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

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

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


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

Операционная деятельность - это что

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

Для операционной деятельности характерно нарушение обоих принципов: (бес-) конечность и (отсутствие) неопределенности.

Пример - работа автосборочного предприятия. Завод, на котором работает конвейер. По нему двигаются автомобили. Кто-то занимается покраской кузова, установкой колес, фар, сидений и так далее. Эта деятельность условно-бесконечна (она будет повторяться изо-дня в день, пока не закроют завод или не свернут производство этой марки машин). Она крайне предсказуема (хорошо известно сколько авто можно произвести за смену, какой будет “выхлоп” в конце дня, недели, месяца, года). Никакой пользы применение принципов проектного управления в таких условиях не даст (только все усложнит и запутает).

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

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

Важная информация!


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

Запрещено переиспользовать только тренерам-консультантам. Им нельзя продавать этот курс и встраивать его в свои программы.

Что изменилось

Позвольте предложить свое определение.

Проектом мы назовем работу над задачей, которой свойственны одновременно:

  • конечность,
  • высокая неопределенность.

Конечность - это “рамки”, ограниченность в сроках и ресурсах.

Высокая неопределенность - говорит о том, что поставленную задачу до конца непонятно, как решить. Только когда ОБА условия соблюдаются - применяйте проектное управлении.

Вспомните основные индустрии и отрасли, в которых распространено проектное управление: например, ИТ или прикладная наука. Когда запускается проект по разработке и внедрению программного продукта или по выводу на рынок нового фарм. препарата - у них, как правило, есть рамки. Компания располагает определенным бюджетом и может позволить себе инвестировать в разработку на определенное время. Но затем деньги должны вернуться. При этом задача, которую будут решать софтверные инженеры, технологи и ученые - зачастую не имеет понятного алгоритма, она плохо предсказуема, может сработать множество рисков (приходится отчасти брать на вооружение принцип “ввяжемся в бой, там посмотрим”).

Вот на таком “стыке” очень плохо работают подходы из регулярного менеджмента. Когда одновременно имеются и очень жесткие рамки (конечность), и высокая неопределенность.

Вот почему (на мой взгляд) строительство египетских пирамид древними египтянами - не проект. Как минимум один из параметров отсутствует. И это - конечность.

Следующая цитата

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

В то же время, каждая компания, работающая с ИТ-проектами постоянно предпринимает серьезные попытки снизить уровень неопределённости и повысить тем самым точность оценок длительности заданий. И все же, если бы мы спросили руководителей проектов 40 лет назад, что бы они сказали о своих проблемах? Были бы их жалобы другими? Думаю, нет. Даже если проекты отличаются друг от друга, жалобы практически не меняются.

Это отражает очевидный факт – проектная среда имеет две доминирующие характеристики:

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

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


Причина №3. Опоздания передаются, выигрыш — нет

На рисунке схема проекта зависимых заданий:


  • По плану на проект должно уйти 17 дней
  • Первое задание закончилось на 5 дней раньше.
  • Четвертое задание закончилось на 5 дней позже.

Сколько времени уйдет на выполнение проекта? Хотелось бы, как и планировали - 17, но для указанного типа проектов правильный ответ - 22 (12+5+5=22).

Вывод: Опоздания передаются следующему заданию, выигрыш – нет.

Кто автор курса?


Иван Селиховкин – профессионал управления проектами «со стажем» почти 13 лет. За это время он успел поработать и в маленьких организациях (например, в стартапе, где трудилось 3 человека), и в крупных, где в штат принято 6 тысяч человек. Соответственно, опыт проектного управления у Селиховкина с 2005 года. При этом примерно 40% своей карьеры он проработал в государственном секторе, а остальное время – в коммерческом. Поэтому четко себе представляет, какие нюансы проектного управления нужно учитывать при работе в государственных компаниях, а что лучше оставить для коммерческих структур, и наоборот.

Этой публикацией начинается курс по проектному управлению, вот полный список опубликованных материалов:

Как родилась идея сделать бесплатный курс?

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

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

Никакого смысла держать эту информацию или прятать её нет. Поэтому курс был сделан бесплатным и доступным для всех желающих.

Резервы времени

Вопрос: Достаточно лишь одних резервов времени, так называемой подстраховки, заложенной в оценке длительности каждого задания, для того, чтобы поглотить все отклонения от графика проекта?

Взгляните на рассуждение:

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

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

Критерии успеха проекта

Говоря об определении проекта важно упомянуть и критерии успеха. Кто такой “успешный менеджер”? Что такое “успешный проект”? И что считать провалом?

Ответ давно выработан методологами.

Успешный проект тот, который уложился в заранее определенные сроки, стоимость (и прочие ресурсы), предоставил заказчику то что тот просил и при этом ключевые заинтересованные стороны - удовлетворены.

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


Это критерии вашего успешного проекта.

Грани - то что согласовано с заказчиком до старта проекта. Обычно - такие договоренности высокоуровневые, в общих чертах, но они же - нерушимые. Пообещали построить дом из кирпича, 9-и этажный, в срок 12 месяцев и с бюджетом в 1 млн. долларов? Делайте!

Каким будет этот дом, как будут выглядеть балконы, лифты какой фирмы в него установить - второй вопрос. Об этом еще предстоит договориться, возможно - по ходу проекта. Но рамочные договоренности - сразу. До запуска проекта. Обычно их фиксируют в гипер-лаконичном документа под названием “устав проекта” (о нем как-нибудь в другой раз).

Итак, три грани проекта вы должны определить ДО того, как начнете работать. Сроки (“закончим не позднее, чем”), деньги (“бюджет проекта не больше, чем…”) и содержание в 2-3 предложения (“что делаем и чего не делаем”). Эти грани символизирует треугольник на картинке.

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


Чему научит курс?

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

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

Использование PMBoK. Многие слышали о таких подходах, как стандарты от PMI (Project Management Institute – Институт управления проектами). Институт собирает лучшие практики и ведет PMBok – свод знаний, который регулярно обновляется и дополняется. В версии 6, выпущенной в 2017 году, PMBok насчитывает почти 1000 страниц суммарно со всеми приложениями. Но читать его очень сложно, в нем много сложных терминов, и они поданы так, что PMBok становится хорошим справочником, если вы уже разобрались в проектном управлении. Но если вы только разбираетесь в этой теме, то как учебник он не сгодится: разобраться, как управлять проектами, читая PMBok с нуля, практически невозможно. Бонусная опция этого курса для тех, кто проходит его до конца и начинается разбираться в алгоритме и в инструментах проектного управления, – возможность использовать PMBok как справочник. После обучения свод знаний превращается из холодной бюрократичной и непонятной книжки в очень удобный справочник, где все знакомо и есть все, что ищешь.

А как вы даете оценку?

Давайте проверим себя: а как вы даете оценку?

Представьте, вас попросили оценить, сколько времени уйдет на выполнение определенного задания.

  • Вы делали нечто подобное 1 или 2 раза, то есть статистики мало и придется давать оценку скорее интуитивно, чем объективно.
  • Вы знаете, что ваша оценка будет переведена в разряд обязательства, то есть возможны взыскания.
  • Вас попросили дать только одно число. И ни каких плюс/минус километр!


Какую оценку вы дадите? Варианты:

  • Гарантирующую 50% вероятности выполнения в срок.
  • Гарантирующую 80% вероятности в срок.
  • Гарантирующую боле 80% вероятности завершения работ вовремя.

Дайте угадаю… большинство из вас дали оценку, гарантирующую 80% или 80%+ вероятность завершения в срок. Верно?

Почему мы даем такие оценки? Все просто:

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

Но сколько же подстраховки заложено в наших оценках? Очевидно, что любая оценка с более чем с 50%-ной вероятностью завершения в срок содержит какую-то подстраховку. Обычно, более или менее качественной оценку можно считать, если она обеспечивает не менее 80 процентов вероятность завершения задания в срок.


Судя по графику + 30% к вероятности добавляет относительно немного подстраховки времени. Это рассуждение верно для нормального распределения вероятностей. Однако, в реальности из-за высокой неопределенности вероятность завершения в срок НЕ симметрична – она имеет длинный хвост.


Незначительное увеличение ВЕРОЯТНОСТИ приводит к ЗНАЧИТЕЛЬНОМУ увеличению ВРЕМЕНИ. Чем выше степень неопределенности, тем длиннее хвост! В конце концов, ни что не может быть сделано со 100% вероятностью! Так ведь? Наша практика показывает, что для большинства ИТ-проектов по меньшей мере половина времени в предварительных оценках – это подстраховка.

Позвольте тогда задать один вопрос… Если все дают оценку с высокой вероятностью завершения в срок, закладывают туда изрядное количество подстраховки, как же так получается, что большинство заданий в проектах не завершаются НАМНОГО раньше срока? Что происходит со всей этой подстраховкой, которую мы так щедро закладываем в оценки?


Кому будет полезен курс?

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

Причины потери подстраховки

Моделирование условного проекта

Давайте посмотрим на математической модели, как названные три причины влияют на выполнение обязательств по срокам проекта.

  • Проект содержит 7 в разной степени зависимых друг от друга этапов.
  • В проекте заняты 10 различных спецов и каждый может выполнять задания только своего типа.
  • Каждое задание длится 20 дней и вероятность выполнения его в срок 80%.
  • В каждом задании 10 дней подстраховки.
  • Плановое время выполнения проекта 140 дней.



Какова вероятность, что проект будет завершен через 140 дней? Запустим симулятор проекта используя генератор случайных чисел и выполним 1000 прогонов.

Несмотря на то, что каждое задание содержит в себе большую подстраховку и высокую вероятность завершения в срок, результаты таковы:

  • Вероятность успеть в срок – чуть более 10%

Почему так? Может быть, мы недостаточно заложили подстраховки? Решит ли проблему увеличение подстраховки в каждом задании?

  • Мы считаем, что всему виной отдельные задания, которые не завершились в срок.
  • В следующем проекте в аналогичные задания, которые «обвиняются» сейчас, будет заложено больше подстраховки.
  • При планировании проекта его время исполнения будет еще больше увеличено.
  • Мы продолжаем работать по-старому. Т.е. все те же явления - Студенческий синдром, Закон Паркинсона, Опоздания в цепи и потеря выигрыша- продолжают расходовать нашу подстраховку.
  • Проект все равно не завершается в срок.
  • Мы снова ищем виновные задания и снова добавляем резервы по времени.

Получаем замкнутый круг! В конце концов рынок ставит предел увеличению времени наших проектов.

Похожие цитаты:

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

Я не доживу до осуществления своей мечты; твоим делом будет её закончить.

Определение термина

Давайте вспомним или нагуглим более-менее классическое определение. Нам попадется что-то вроде: “Проект – это мероприятие для достижения какой-то цели, ограниченное во времени ресурсах и связанное с достижением уникального результата.”

Подобные формулировки встречаются часто. В том числе, в самом PMBoK. Проблема: они неудачные. Из них непонятно главное - чем проект отличается от “не проекта”.

Не верите? Попробуйте подобрать хотя бы один пример любой деятельности, который не подпадает под это определение?

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

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

Но сперва придется ответить на вопрос “что такое проект” :)

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

Неочевидно, но проектное управление сложнее, чем “обычный”, так называемый “регулярный менеджмент”. Управлять отделом или подчиненными - это одно. Руководить проектом - совсем другое.

Большинство методологий проектного управления объемные. Например, последняя редакция “библии менеджеров” PMBoK составляет почти 1000 страниц, руководства Prince2, IPMA и другие (о них - как-нибудь в другой раз) - тоже не маленькие.

В жизни руководителя важно научиться быстро понимать “проект перед вами или нет”, чтобы не тратить силы (и попытки подтянуть 1.000-страничные методологии туда, где можно обойтись малой кровью).

Одно из первых открытий, которое предстоит сделать - высшее руководство само, как правило, плохо понимает где проекты, а где нет. Т.е. надеяться на то, что вам поручили нечто, назвали это проектом и уже хорошо подумали - не приходится. На практике проектами называют что попало, именно вам (проектному менеджеру) нужно проверить сказанное на адекватность.

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

О пафосе тренеров

Многие тренеры по управлению проектами любят пафос и склонны преувеличивать. Иногда они говорят “все на свете - это проекты”. Или “проектное управление - очень древнее умение, первым проектам тысячи лет - вот, египетские пирамиды. ”.

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

Однако, вернемся к яичнице.

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

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

И вот в такой ситуации, ваша деятельность начинает все больше напоминать проект. Вы начинаете более тщательно (по сравнению с привычным завтраком) планировать - лезете в интернет, выясняете “как жарить”, “как разбивать”, подбираете специальную сковородку (или даже покупаете в магазине подходящую, рассчитываете время. Не обязательно вся 1000 страниц PMBoK найдет применение в таком подходе. Но очень многие элементы, которые вам не пришло бы и в голову использовать для обычного завтрака или путешествия до офиса вы примените тут.

Строительство египетских пирамид - не проект

Строительство пирамиды начинали, когда рождался фараон. Закончить нужно было к моменту его смерти. Если не случалось гибели во младенчестве, то, скорее всего, на постройку отводилось лет 20-30 как минимум. Ресурсы (люди, материалы) также не были дефицитными. Мнения расходятся - строили ли пирамиду рабы или свободные наемники, но, в любом случае, работал принцип - “что-то пошло не так? Давайте пригоним еще людей”. Если у вас не ограниченные сроки и / или бюджеты, то рано или поздно вы справитесь с любой задачей. Даже с очень сложной. И очень непонятной вам. С пятого-десятого-двадцатого раза, после огромных расходов - все у вас получится.

Пример “египетских пирамид” в современном мире - некоторые гос. проекты. Или работа некоторых продуктовых компаний (чаще в сфере ИТ). Когда фирма сделала некий ИТ-продукт и потом годами дорабатывает и совершенствует его, продавая все новым и новым клиентам, расширяя количество сервисов. Пока такая компания не выходит на новый уровень развития, но уже является очень богатой - она не нуждается в проектном управлении (представьте Google или Facebook). Сейчас это гигантские корпорации, занимающиеся множеством проектов от создания автомобилей и спутников до медицинских и финансовых стартапов. Но когда-то они имели 1 очень успешный продукт (поисковик или социальную сеть), и могли единственной своей задачей поставить его развитие (на что могли тратить, как минимум, неограниченное количество денег). Такому Google и такому Facebook управление проектами было бы не нужно.

Выводы

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

И так, есть, как минимум, 4 основных причины из-за которых мы теряем резервы времени в проектах:

  • Закон Паркинсона.
  • Студенческий синдром.
  • Потеря выигрыша и передача опозданий в цепи зависимых заданий.
  • Перепрыгивание от задания к заданию в мульти-проектных средах.

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

Решение должно обеспечить, чтобы:

  • Оценка длительности заданий не переводилась в разряд ОБЯЗАТЕЛЬСТВ - это должно значительно сократить количество подстраховки.
  • Выигрыш по времени и опоздания компенсировали друг друга.
  • Перепрыгивания от задания к заданию резко сократились.

И так, что собой представляет решение?

Читайте об этом в моей следующей статье: "Как завершать проекты в срок".

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Krasnodar. Больше статей можно прочитать здесь.

Моделирование мульти-проектной среды



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

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

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

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

Результат на рисунке:


Симулятор провел оптимизацию и рассчитал, что реально успеть все три проекта завершить за 420-430 дней. Будем считать это отправной точкой.

Объясняем на примере

Вы отправляетесь на работу или готовите себе утром яичницу на завтрак.

Это мероприятия для достижения цели? Конечно, цель вполне конкретная (прибыть в пункт назначения, насытиться).

Ограниченные во времени? Безусловно! Нельзя завтракать пол дня или потратить сутки на дорогу.

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

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

Следующая цитата

Две возможности: делать себя бесконечно малым или быть им. Второе — завершение, значит, бездеятельность, первое — начало, значит, действие.

«Творчество есть продолжение миротворения. Продолжение и завершение миротворения есть дело богочеловеческое. Божье творчество с человеком, человеческое творчество с Богом. Но я изначально сознал глубокую трагедию человеческого творчества и его роковую неудачу в условиях мира. Это сознание есть очень существенная сторона моей книги „Смысл творчества“. Творческий акт в своей первоначальной чистоте направлен на новую жизнь, новое бытие, новое небо и новую землю, на преображение мира. Но в условиях падшего мира он отяжелевает, притягивается вниз, подчиняется необходимому заказу, он создает не новую жизнь, а культурные продукты большего или меньшего совершенства. Результаты творчества носят не реалистический, а символический характер. Создается книга, симфония, картина, стихотворение, социальное учреждение. Есть несоответствие между творческим взлетом и творческим продуктом. Не буду повторять того, о чем я уже много раз писал. Но хотелось бы предотвратить ложное понимание моей мысли. Я совсем не отрицаю творчества культуры, совсем не отрицаю смысла продуктов творчества в этом мире. Это есть путь человека, человек должен пройти через творчество культуры и цивилизации. Но это есть творчество символическое, дающее лишь знаки реального преображения. Реалистическое творчество было бы преображением мира, концом этого мира, возникновением нового неба и новой земли. Творческий акт есть акт эсхатологический, он обращен к концу мира.»

Хряк иногда моется — он не так грязен, как гласит молва, а когда становится по-настоящему толстой свиньёй, председательствует на языческих церемониях, называемых свиноводческими конкурсами, по завершении которых, после того как его вконец затискают, обласкают, наградят орденом Почётного легиона и провозгласят наитолстейшим и наикрупнейшим, его коварно умерщвляют шпиговальным ножом и в тот же день разделывают на закуску. Кабану тоже случается оканчивать свои дни на мясном прилавке, однако он до последнего момента сопротивляется. К тому же ему иногда выпадает посмертная радость быть выставленным во всей своей красе, вплоть до последней щетинки, в «Шатрио» или другом роскошном заведении: кабан никогда не покидает эмпиреев. У него всегда, вплоть до последней минуты, остаётся возможность покончить жизнь самоубийством, бросившись под колёса автомобиля па какой-нибудь автостраде; а если заблагорассудится, он даже может выбрать для этого мост, который послужит величественной декорацией к акту самоутопления. Наконец, как эго ни странно, кабан пользуется той же доброй славой, что и медведь, и гордо красуется на гербах знаменитых родов — тогда как его розовый собрат может украсить своим изображением разве что витрину какого-нибудь колбасника, такого же жирного, как он сам.

Генезис мужской гомосексуальности в целом ряде случаев следующий: молодой человек необыкновенно долго и интенсивно, в духе Эдипова комплекса, сосредоточен на своей матери. Но, наконец, по завершении полового созревания все же настает время заменить мать другим сексуальным объектом. И тут происходит внезапный поворот: юноша не покидает мать, но идентифицирует себя с ней, он в нее превращается и ищет теперь объекты, которые могут заменить ему его собственное «Я», которых он может любить и лелеять так, как его самого любила и лелеяла мать. Этот часто наблюдающийся процесс может быть подтвержден любым количеством случаев; он, конечно, совершенно независим от всяких предположений, которые делаются относительно движущей силы и мотивов этого внезапного превращения. Примечательна в этой идентификации ее обширность, она меняет «Я» в чрезвычайно важной области – а именно в сексуальном характере – по образцу прежнего объекта. При этом сам объект покидается; покидается ли он совсем или только в том смысле, что он остается в бессознательном, не подлежит здесь дискуссии. Идентификация с потерянным или покинутым объектом для замены последнего, интроекция это объекта я «Я» для нас, конечно, не является новостью. Такой процесс можно непосредственно наблюдать на маленьком ребенке. Недавно в «Международном психологическом журнале» было опубликовано такое наблюдение. Ребенок, горевавший о потере котенка, без всяких обиняков заявил, что сам он теперь котенок, и стал поэтому ползать на четвереньках, не хотел есть за столом и т.д. («Психология масс и анализ человеческого "Я"», 1921г.)

Как стать хорошим менеджером

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

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

Менеджер не успешен, если не умеет удержать проект в треугольнике (который сам же при старте согласовал). Или если его проекты завершаются “в бюджет и в срок и строго по ТЗ”, но заказчик при этом остается глубоко несчастным и разочарованным (смайлик в треугольнике уголками губ вниз). Еще один пример неуспеха: проект завершен в рамках первоначально-означенного треугольника, заказчик доволен, но команда перенапряглась - люди в ней демотивированы, многие, получив проектный бонус, подали заявление об увольнении. Внутренняя репутация компании подпорчена, искать новых специалистов на рынке труда - трудно и дорого. В этом случае, вероятно, недовольны будут в высшем руководстве компании. А это тоже заинтересованные ключевые стороны (ведь проект делался на их деньги - именно они платили зарплату вам, как менеджеру и всем штатным сотрудникам).

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

Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"

Причина №1. Закон Паркинсона.

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

Первый Закон Паркинсона гласит: «Работа заполняет все время, отпущенное на неё».

Следствие: Перевод оценки в разряд обязательства приводит к реализации именно данной оценки (но никак не меньшей!)

Причина №2. Студенческий синдром

Нам хорошо известна модель поведения исполнителя, когда всё делается в последний момент. Так называемый «Студенческий синдром». Мы тянем время до последнего, каждый раз находя все более важные или более интересные дела. Да и к чему спешить, ведь до срока еще столько времени! В результате все резервы беспечно теряются.

Как подается информация?


На Инфостарте опубликованы транскрибации онлайн курса, записанного в рамках очных программ, которые Иван Селиховкин проводил для менеджеров. Это не видео-доклад, где выступает лектор. Это информация с интересными практическими примерами.

Читайте также: