Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1

30.07.18

Управление проектом - Компетенции и навыки РП

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

Коллеги, привет!

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

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

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

 

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

1. Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера 

2. Три фундаментальных принципа проектного управления

3. Роли в проектном управлении

4. Управление заинтересованными сторонами 

5. Устав проекта - это скорлупа яйца

6. Алгоритм управления содержанием проекта

7. Сбор требований

8. Создание концепции проекта (project scope statement)

9. Иерархическая структура работ (ИСР)

10. Управление качеством – ключевые термины

11. Управление качеством – диаграмма Ишикавы (Ishikawa diagram)

12. Управление качеством: блок-схемы, чек-листы и контрольные карты Шухарта

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

14. Алгоритм управления сроками

15. Алгоритм управления сроками с использованием специального софта

16. Управление сроками – определение продолжительности

17. Управление сроками – пэддинг и кривая обучения

18. Критический путь в расписании, продолжаем тему управления сроками

19. Методы сжатия расписания и вехи в проекте

20. Методы определения себестоимости и способы отслеживания прогресса проекта

21. Контроль прогресса – метод освоенного объема (earned value management – EVA)

22. Закупки на проекте: алгоритм, планирование и осуществление закупок

23. Закупки по контрактам Fixed Price - с фиксированной ценой

24. Закупки по контрактам "Время и материалы" и "С возмещением затрат". Закрытие закупок

25. Управление рисками – алгоритм

26. Риски – идентификация и качественный анализ

27. Риски – количественный анализ

28. Планирование реагирования на риски

29. Коммуникации в проекте: шумы и подсчет количества каналов

30. Матрица RACI

31. Развитие команды проекта и командообразование (тимбилдинг)

32. Теория мотивации МакГрегора

33. Теория мотивации – пирамида Маслоу

34. Теория мотивации Дэвида Макклелланда

35. Управление интеграцией

36. Закрытие проекта или фазы

 

 

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

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


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

 

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

 

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

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


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

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

 

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

управление проектами PMI PMBoK

См. также

Коммуникации Лидерство Компетенции и навыки РП Бесплатно (free)

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

11.11.2024    408    6    dklimchuk    3    

4

Компетенции и навыки РП Коммуникации Бесплатно (free)

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

06.11.2024    776    0    Kukabarra    2    

7

Компетенции и навыки РП Руководитель проекта

Есть занятный психологический эффект, когда мы игнорируем проблемы, с которыми мы не понимаем что делать. В своей книге “Вальсируя с медведями” авторы назвали этот эффект “А, вы имеете в виду этот приближающийся поезд…”

05.11.2024    1147    0    MariaTemchina    1    

27

Компетенции и навыки РП Бесплатно (free)

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

22.05.2024    2536    0    user1669221    0    

8

Компетенции и навыки РП Бесплатно (free)

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

20.05.2024    3184    0    TanyaRi    1    

8

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

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

02.05.2024    3705    0    biimmap    39    

39

Компетенции и навыки РП Руководитель проекта Бесплатно (free)

Статья о том, как быть эффективным руководителем проектов. Кто такой руководитель проектов, что подразумевает эта роль в проекте, и зачем она нужна?

22.03.2024    1308    0    PChizhov    0    

6

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

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

26.02.2024    3034    0    user1270271    0    

13
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. MariaTemchina 1646 30.07.18 16:44 Сейчас в теме
Иван, спасибо за наглядную статью. Но, все-таки, для соблюдения истины позволю себе заметить, что "всё уже украдено до нас". Идея о том, что проект - это что-то уникальное, мягко выражаясь, не нова. Это в явном виде написано что в PMBOK ("Проект - это временное предприятие, направленное на создание уникального продукта, услуги или результата" (PMBOK 6(th), стр. 4), что в стандарте ISO ("Проект состоит из уникального набора процессов" (ГОСТ-Р-ИСО-21500-2014).
Irwin; serge_focus; Kochergov; +3 Ответить
5. Selikhovkin 570 31.07.18 00:19 Сейчас в теме
Мария, спасибо.
Я как раз не говорю, что проект это что-то уникальное.
А подчеркиваю, что пользуясь такой характеристикой (или определениями из PMBoK или ISO 21500) вы, как раз, скорее всего не сможете отделить проект от не проекта в реальной жизни.
theelectric; leongl; itriot11; LordKim; +4 3 Ответить
2. awk 744 30.07.18 17:39 Сейчас в теме
Пример с яичницей не удачный. Где уникальный продукт?
wowik; Irwin; Kochergov; +3 Ответить
3. jenky_pro 30.07.18 18:09 Сейчас в теме
(2) раскрывается ниже по тексту, в аналогии со страусиным яйцом. Далеко не каждый день простой обыватель готовит из него яичницу.
6. Selikhovkin 570 31.07.18 00:21 Сейчас в теме
(2)Нет уникального продукта. Не нужно добавлять эту фразу в определение, в реальных условиях она только путает.

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

Понятие уникальности - недоказумо и непроверямо.
theelectric; mr_tuzlukov; itriot11; LordKim; user764938; +5 3 Ответить
8. CSiER 36 31.07.18 08:06 Сейчас в теме
(6) по примеру с домом - если для застройщика это первый такой дом (например, раньше возводил только малоэтажки, а сейчас нужно построить МКД на 22 этажа) - то, думаю, это проект. Да, нашли тех. документация, готовые подобные дома других застройщиков изучили - но у конкретно этого застройщика нет опыта (ещё может быть и компетенций нет - только контракт с суммой и сроками) - то есть для него это уникальный дом. Может быть нужно взглянуть на термин "уникальность" немного под другим углом?
Irwin; serge_focus; Selikhovkin; awk; +4 Ответить
12. awk 744 31.07.18 09:22 Сейчас в теме
(8) Мне ход мысли нравится...
20. Selikhovkin 570 31.07.18 20:12 Сейчас в теме
(8)
по примеру с домом - если для застройщика это первый такой дом (например, раньше возводил только малоэтажки, а сейчас нужно построить МКД на 22 этажа) - то, думаю, это проект. Да, нашли тех. документация, готовые подобные дома других застройщиков изучили - но у конкретно этого застройщика нет опыта (ещё может быть и компетенций нет - только контракт с суммой и сроками) - то есть для него это уникальный дом. Может быть нужно взглянуть на термин "уникальность" немного под другим углом?

Это, кстати, вполне возможный и распространенный подход. Его некоторые управленцы применяют. Грубо говоря, пока вы плохо умеете делать нечто, многое в этой области для вас - проекты. Обратное верно (научились очень хорошо - теперь это не проекты, а "операционная деятельность").
Грубо говоря, разворачивается на своем автозаводе новую сборочную линию (и это для вас в новинку) - проект. И наоборот, если вы компания, которая в месяц запускает по 3-4 таких линии под заказ на разных заводах - это вполне повседневная рутина.

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

Так что если неконкретную "уникальность" заменить на более понятную (на практике для конкретного менеджера и команды) "высокую неопределенность" - отличать проекты от не проектов гораздо проще. :)
mr_tuzlukov; LordKim; +2 Ответить
11. awk 744 31.07.18 09:20 Сейчас в теме
(6) .
Не нужно добавлять эту фразу в определение.
Батюшка, вы либо крестик снимите, либо трусы наденьте. Вас паяльником заставили в статью определение вставлять?

Представьте себе стройку.
Я в ней работаю. Когда говорят "по типовому проекту" то речь идет не о проекте, а об объекте..

Понятие уникальности - недоказумо и непроверямо.
Надо физикам, да математикам рассказать, а то они бедолаги столько на этом базисе построили...
19. Selikhovkin 570 31.07.18 20:03 Сейчас в теме
(11)
Батюшка, вы либо крестик снимите, либо трусы наденьте. Вас паяльником заставили в статью определение вставлять?

Вы спорите с воображемыми моими аргументами.

Определение в статье приведено для того, чтобы было видно:
- есть классическое определение
- оно неудачное (не применимо на практике управленцем)
- отличать проект от не-проекта можно (критерии даны)

Я в ней работаю.

Ну что же, отвечу любителю анекдотов:
"- Ты где работаешь?
- Да в аэропорту, туалеты мою.
- Так зачем тебе такая работа, брось ее!
- Да? И уйти из авиации?"

Вы не работаете руководителем проектов в стройке (судя по профилю - даже не близко). Автоматизировать процессы и отвечать за ввод объектов эксплуатации в срок и в рамках бюджета - разные вещи чутка. Давайте посоветую вам у кого из реальных боевых строительных менеджеров про уникальность домов спросить ;)
theelectric; artyr; LordKim; +3 Ответить
21. awk 744 01.08.18 09:18 Сейчас в теме
(19) Еще раз. Определение работает. Яичница при его использовании не подходит. Так что либо не то определение, либо пример. Закон исключения третьего.
AK_1064; Irwin; +2 Ответить
4. Идальго 235 30.07.18 21:52 Сейчас в теме
Здесь кажется двумя предложениями можно было обойтись и все бы всё поняли. Н-р: “Проект – это мероприятие для достижения какой-то цели, ограниченное во времени ресурсах и связанное с достижением уникального результата.”
Соответственно выход за ограничения - плохо, негативный результат - тоже плохо. У хорошего менеджера плохо бывает крайне редко.
А начали тут яичницы какие-то, пирамиды, грани, обыватели и т.п. ))))
7. Selikhovkin 570 31.07.18 00:22 Сейчас в теме
(4)По процитированному вами определению - почти все в жизни является проектом. Попробуйте сами применить его к поездке на метро или в автобусе - например, на незнакомую станцию. Вот в том-то и проблема ;)
9. Идальго 235 31.07.18 08:47 Сейчас в теме
(7)
метро или в автобусе - например, на незнакомую станцию. Вот в том-то и проблема ;)
и в чём же проблема?
10. TODD22 19 31.07.18 08:56 Сейчас в теме
(9)
и в чём же проблема?

Без PMBOOKa боится не доехать.
15. Selikhovkin 570 31.07.18 13:21 Сейчас в теме
(10)Наоборот. Боюсь, вы пойдете с PMBoK в метро (а он там не нужен).
17. TODD22 19 31.07.18 13:24 Сейчас в теме
(15)
Боюсь, вы пойдете с PMBoK в метро (а он там не нужен)

Почему не нужен?
18. Selikhovkin 570 31.07.18 13:35 Сейчас в теме
(17)Может я чего не знаю.
Расскажите, как обычно используете PMBoK в общественном транспорте и почему (без него совсем не можете)?
13. profiprog1c 250 31.07.18 12:19 Сейчас в теме
Статья - ведро воды, примерно на середине стало нудно читать. Автор пытается показать, что все определения проекта неверные, а вот его определение верное. И сразу видно насколько автор плавает в теме, когда пишет, что современный проектный менеджмент сформировался примерно 50-70 лет назад. Так 50 или 70 лет и кто его сформировал? Фраза о том, что имея неограниченные ресурсы можно любой проект довести до конца полнейшая чушь и это не работает. Во первых неограниченных ресурсов не бывает. В том же Древнем Египте пирамиды строили экономя ресурсы. Еще пример, M$ (или Microsoft) имела очень громадные ресурсы, но где ее мобильная операционная система? Nokia имела громаднейшие финансовые ресурсы и научный потенциал, но где делась Nokia с ее ресурсами и с ее проектами? Поэтому статья вышла неинтересная. Рассказы про яичницу смешат. Порадовать ребенка яичницей из страусиного яйца на День рождение, Вы это серьезно рассматриваете как пример проекта?
rpgshnik; Irwin; CodeNull; acanta; serge_focus; Man4kin; Kochergov; +7 Ответить
14. TODD22 19 31.07.18 12:41 Сейчас в теме
(13)
Автор пытается показать, что все определения проекта неверные, а вот его определение верное.

А что ещё ждать от "проповедников с горящими глазами". Каждый считает что его понимание "проектов" правильнее, его Scrum самый толстый и длинный и только он познал истинный дзен Agile, о чём нужно срочно всем в интернете рассказать.
16. Selikhovkin 570 31.07.18 13:23 Сейчас в теме
(14)Молодцы. Придумали за автора свои тезисы и теперь с ними спорят ;)
22. user1025004 01.08.18 10:26 Сейчас в теме
Так что если неконкретную "уникальность" заменить на более понятную (на практике для конкретного менеджера и команды) "высокую неопределенность" - отличать проекты от не проектов гораздо проще. :)

В чём сложность отличать "проекты" от "не проектов" ?
Не важно едем мы на метро, жарим яичницу, строим многоквартирный дом или целый микрорайон. Если мы это делаем с применением проектных технологий то это проект, если нет то это не проект. Разве нет?
Не деятельность, не результат этой деятельности не определяют "проект" или "не проект", а именно сам проектный подход к деятельности говорит нам о том проект у нас или нет.
прикладной науке - аналогично

Исследовательская деятельность не совсем проектная.

И наоборот, если вы компания, которая в месяц запускает по 3-4 таких линии под заказ на разных заводах - это вполне повседневная рутина.

Если мы первую линию делаем не по проектным технологиям это проект? А если последующие делаем по "проектным" это не проект ?
25. Selikhovkin 570 01.08.18 12:09 Сейчас в теме
(22)
В чём сложность отличать "проекты" от "не проектов" ?
Не важно едем мы на метро, жарим яичницу, строим многоквартирный дом или целый микрорайон. Если мы это делаем с применением проектных технологий то это проект, если нет то это не проект. Разве нет?
Не деятельность, не результат этой деятельности не определяют "проект" или "не проект", а именно сам проектный подход к деятельности говорит нам о том проект у нас или нет.


Делать операцию пациенту или не делать?
Не симптомы и не диагноз определяют "оперировать ли". Важно ли то, разрезали ли мы ему живот.

Аналогично с проектами.
1000 страниц PMBoK написана не на все случаи жизни, а только для тех, которые требуют проектного подхода.
Какие это случаи? Пытаюсь ответить в статье.
27. user1025103 01.08.18 12:57 Сейчас в теме
(25)
Делать операцию пациенту или не делать?

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

Не симптомы и не диагноз определяют "оперировать ли". Важно ли то, разрезали ли мы ему живот.

"Операция" в данном случае это процесс как и "строительство дома", а вот как вы к этому процессу подойдёте с применением "проектных технологий" или нет будет определять проект это или нет.

Аналогично с проектами.

Вы ввели ложную аналогию.

1000 страниц PMBoK написана не на все случаи жизни, а только для тех, которые требуют проектного подхода.

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

Так вот:
Если мы первую линию делаем не по проектным технологиям это проект? А если последующие делаем по "проектным" это не проект ?

и
Какие это случаи? Пытаюсь ответить в статье.

В приведённом выше примере что проект, а что не проект по вашей классификации?


З.Ы. С радостью бы с вами на эту тему по дискутировал, но за дискуссии с вами выдают баны. А новые аккаунты мне лень регить. Хорошего вам настроения, держитесь здесь!
30. Selikhovkin 570 02.08.18 10:50 Сейчас в теме
(27)
(27)
Решает врач, а не "проектный подход", так же как строить дом или нет решает инвестор который на это строительство выделяет деньги. Сама операция может быть проектом, может не быть, зависит от подхода к её проведению. С применением проектных подходов или без.
"Операция" это процесс которым нужно управлять, а не методика управления...

...Аналогично с проектами.
Вы ввели ложную аналогию.

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

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

(27)
Хорошего вам настроения, держитесь здесь!
Спасибо!
user685982_ozamota; +1 Ответить
23. serge_focus 4 01.08.18 11:10 Сейчас в теме
Любой проект - это прежде всего управление деятельностью проектной группы с целью устранения рисков негативного результата проекта.

А уж к чему вы это управление прикрутите и как будете управлять это ваше решение ;).
26. Selikhovkin 570 01.08.18 12:10 Сейчас в теме
(23)
Любой проект - это прежде всего управление деятельностью проектной группы с целью устранения рисков негативного результата проекта.

Ага. Любое управление вообще об этом. Можно даже слово "проекты" не употреблять.
24. serge_focus 4 01.08.18 11:13 Сейчас в теме
Все PMBoKи и другие стандарты прежде всего об этом.
28. acanta 01.08.18 16:12 Сейчас в теме
В медицине есть понятие прогноз. Имхо, если прогноз после окончания проекта благоприятный - проект можно считать успешным.
Хотя мысль о том, что если хотя бы одна из сторон проекта (заказчик или исполнитель) не была полностью удовлетворена - проект можно считать провальным, тоже очень интересна. Если в состав целей проекта включено подготовка и повышение квалификации команды - то разумеется, использование профессионалов, которые оперирует исключительно своим багажом знаний - означает всего лишь сокращение сроков и демпинг. В принципе можно найти и таких специалистов. Но в этом случае проект не может быть успешным по определению. Именно потому что для исполнителя это путь вниз и этот прогноз неблагоприятный.
Вопрос в том, можно ли считать проект успешным когда результата нет, но прогноз благоприятный.
Или когда результат есть, но с неблагоприятными перспективами.
29. Selikhovkin 570 02.08.18 10:33 Сейчас в теме
(28)
Вопрос в том, можно ли считать проект успешным когда результата нет, но прогноз благоприятный.

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

Другие, наоборот, часто не могут дать быстрого эффекта (часто - работа дерматолога или ортопеда оперирует не "результатом через пол часа", долгосрочными прогнозами).

Иногда работа врача вообще не предполагает хорошего прогноза, к сожалению (в хосписах тоже работают врачи - не их вина, что пациента невозможно вылечить).

С менеджерами проектов похоже. Нужно обязательно смотреть на цель (чего хотели те, кто проект запускал). В некоторых случаях нужен внятный результат сразу по завершении, в других - положительная динамика, а третьи проекты, например, планово-убыточные и сейчас и в перспективы и призваны, например, законсервировать некую бизнес-ситуацию или притормозить падение.
31. serge_focus 4 03.08.18 11:42 Сейчас в теме
А вот слово "проект" и определяет ту радужную , уникальную цель к которой и несется проектная группа, преодолевая и превозмогая... Под чутким руководством...
32. strange2007 144 21.09.18 08:59 Сейчас в теме
Перечитал 2 раза, но так и не увидел конкретного ответа на вопрос - что такое проект. Наверное я очень глуп или... автор призывает к субъективной оценке проекта и банальному словоблудию. Главу "Что такое проект" перечитал раз пять (!!!!), но там только говорится про "что такое не проект" и как все вокруг ошибаются.
Поправьте меня, если не прав. А то как-то чувствую себя неуютно.
33. acanta 21.09.18 09:31 Сейчас в теме
Ок, я не совсем понимаю, вот есть небольшое предприятие с комплексной конфигурацией. Функциональность почти вся отключена. Предположим с начала года меняется учетная политика, какое-то время ведется работа в предыдущем периоде. Как совмещать к примеру оции наличие статуса у перемещений или соглашения, или и изменение реквизитов организации. все это требуется.зафиксировать в проекте. Единственное, что допускается включать в процессе работы это ордерный склад. Что отличает решение регулярного менеджмента от проектного? Фраза а почему вы не сказали этого раньше? Теперь уже поздно что то менять..
34. Valerych 03.12.18 18:25 Сейчас в теме
Иван, довольно необычно читать про неопределенность как обязательный атрибут проекта, как одну из граней, по которой можно отличить проект от не-проекта.

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

Есть ли в в документах от PMI или в руководствах PRINCE 2 упоминание о неопределенности в такой роли?
Какой англоязычный термин можно употреблять?
35. MariaTemchina 1646 03.12.18 18:43 Сейчас в теме
(34) Я не Иван, но рискну изложить свою версию.
Предположу, что Иван говорит о неопределенности как о непременном свойстве уникальности.
Уникальность - действительно непременное свойство проекта.
Когда нет уникальности, мы говорим не о проектах, а об операционной деятельности. Нет никакой необходимости городить ни PMBOK ни Agile - один раз выстраиваем бизнес-процессы, и идём по ним. Но проект, из-за того, что он уникален, никогда до конца не понятен, не определен. В нём сидит где-нибудь чертик из табакерки под лозунгом "ни один план сражения не выдерживал столкновения с противником"...
То есть из-за уникальности мы никогда не можем в точности быть уверенными, что и как нужно делать. Риски всегда выше, чем в операционной деятельности. Как-то так.
36. Valerych 03.12.18 19:09 Сейчас в теме
(35) Марина, перечитал комментарии, Иван говорит возможно о замене уникальности на неопределенность.
Выглядит как reframing, ррраз и уже контекст другой.

Возможно существуют дискуссии и в англоязычной среде менеджеров проектов.
Интересно, как там звучит или звучало бы использование неопределенности как отличительного атрибута проектов.
37. MariaTemchina 1646 04.12.18 10:03 Сейчас в теме
(36) Вообще, по моим представлениям о прекрасном, как раз Agile говорит об управлении проектами в условиях неопределенности. Что про это говорит PMBOK, если честно, не помню, последний раз его читала год назад ))).
38. Вurenkov 12.12.18 14:58 Сейчас в теме
Проект дома - это проект?
Проектный институт занимается проектами?
Та или иная степень неопределенности присуща любой последовательности действий для достижения определенного результата за определенное время. Даже для яичницы.
С тем же успехом можно дискутировать о терминах Задача и Дело. Впрочем, тут проще. Задачи надо решать, дела - делать.
В любом случае, Термин Проект, можно применять к связанной последовательности действий по-разному. Непременные атрибуты проекта:
- планируемое время
- наличие участников
- наличие этапов (стадий, промежуточных результатов и т.д.)
- ожидаемый результат.
39. k.dm.v@mail.ru 15.05.19 23:16 Сейчас в теме
Тема я бы сказал жизненная. Спасибо автору за лаконичное и содержательное вступление в тему проектов.
user685982_ozamota; +1 Ответить
40. sournk 27 07.07.20 23:00 Сейчас в теме
По крайней мере, пока речь не заходит и масштабных перестройках системы. В таких условиях проектное управление тоже бесполезно.


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