Коллеги, привет!
Меня зовут Иван Селиховкин. Я руководитель проектов (а позднее — портфелей и программ) с 2005 года. Периодически пишу статьи.
Этой публикацией я начинаю курс по проектному управлению, вот полный список опубликованных материалов:
1. Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера
2. Три фундаментальных принципа проектного управления
3. Роли в проектном управлении
4. Управление заинтересованными сторонами
5. Устав проекта — это скорлупа яйца
6. Алгоритм управления содержанием проекта
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. Риски – количественный анализ
Продолжение следует…
Сегодня хочу в двух словах рассказать о критериях успешности проектов и проектных менеджеров.
Но сперва придется ответить на вопрос “что такое проект” 🙂
Что такое проект
Это первый вопрос, на который необходимо ответить любому менеджеру.
Неочевидно, но проектное управление сложнее, чем “обычный”, так называемый “регулярный менеджмент”. Управлять отделом или подчиненными — это одно. Руководить проектом — совсем другое.
Большинство методологий проектного управления объемные. Например, последняя редакция “библии менеджеров” 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 предложения (“что делаем и чего не делаем”). Эти грани символизирует треугольник на картинке.
Достигнуть их нужно так, чтобы ключевые (не все, но ключевые) заинтересованные стороны проекта (ключевые пользователи и представители заказчика, ваше руководство, ключевые регуляторы и некоторые другие) были удовлетворены. Эту удовлетворенность символизирует смайлик внутри треугольника.
Как стать хорошим менеджером
Хороший менеджер проектов отличается от плохого тем, что попадает в треугольник при завершении и ключевые заинтересованные лица при этом довольны.
Все методологии, по большому счету, ориентированы на то как сформировать треугольник на старте проекта с достаточной точностью и что делать по ходу, когда будут возникать отклонения (промахнулись с оценками, появились новые требования, сменился представитель заказчика и т.п.).
Менеджер не успешен, если не умеет удержать проект в треугольнике (который сам же при старте согласовал). Или если его проекты завершаются “в бюджет и в срок и строго по ТЗ”, но заказчик при этом остается глубоко несчастным и разочарованным (смайлик в треугольнике уголками губ вниз). Еще один пример неуспеха: проект завершен в рамках первоначально-означенного треугольника, заказчик доволен, но команда перенапряглась — люди в ней демотивированы, многие, получив проектный бонус, подали заявление об увольнении. Внутренняя репутация компании подпорчена, искать новых специалистов на рынке труда — трудно и дорого. В этом случае, вероятно, недовольны будут в высшем руководстве компании. А это тоже заинтересованные ключевые стороны (ведь проект делался на их деньги — именно они платили зарплату вам, как менеджеру и всем штатным сотрудникам).
Проектное управление — это балансирование: как определить и не провалить рамки треугольника (сроки-деньги-содержание) и добиться удовлетворенности ключевых заинтересованных сторон проекта. Это ключевое, что нужно помнить про критерии успеха проекта.
Статья написана на основании видео учебного курса по управлению проектами.
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Иван, спасибо за наглядную статью. Но, все-таки, для соблюдения истины позволю себе заметить, что «всё уже украдено до нас». Идея о том, что проект — это что-то уникальное, мягко выражаясь, не нова. Это в явном виде написано что в PMBOK («Проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата» (PMBOK 6(th), стр. 4), что в стандарте ISO («Проект состоит из уникального набора процессов» (ГОСТ-Р-ИСО-21500-2014).
Пример с яичницей не удачный. Где уникальный продукт?
(2) раскрывается ниже по тексту, в аналогии со страусиным яйцом. Далеко не каждый день простой обыватель готовит из него яичницу.
Здесь кажется двумя предложениями можно было обойтись и все бы всё поняли. Н-р: “Проект – это мероприятие для достижения какой-то цели, ограниченное во времени ресурсах и связанное с достижением уникального результата.”
Соответственно выход за ограничения — плохо, негативный результат — тоже плохо. У хорошего менеджера плохо бывает крайне редко.
А начали тут яичницы какие-то, пирамиды, грани, обыватели и т.п. ))))
(2)Нет уникального продукта. Не нужно добавлять эту фразу в определение, в реальных условиях она только путает.
Представьте себе стройку. Возведение дома это проект? Вроде, да.
Но если это дом по типовым чертежам (на языке строителей «по типовому проекту») — что в нем уникального? Местоположение?
Понятие уникальности — недоказумо и непроверямо.
(4)По процитированному вами определению — почти все в жизни является проектом. Попробуйте сами применить его к поездке на метро или в автобусе — например, на незнакомую станцию. Вот в том-то и проблема 😉
(6) по примеру с домом — если для застройщика это первый такой дом (например, раньше возводил только малоэтажки, а сейчас нужно построить МКД на 22 этажа) — то, думаю, это проект. Да, нашли тех. документация, готовые подобные дома других застройщиков изучили — но у конкретно этого застройщика нет опыта (ещё может быть и компетенций нет — только контракт с суммой и сроками) — то есть для него это уникальный дом. Может быть нужно взглянуть на термин «уникальность» немного под другим углом?
(7)
и в чём же проблема?
(9)
Без PMBOOKa боится не доехать.
(6) .
Батюшка, вы либо крестик снимите, либо трусы наденьте. Вас паяльником заставили в статью определение вставлять?
Я в ней работаю. Когда говорят «по типовому проекту» то речь идет не о проекте, а об объекте..
Надо физикам, да математикам рассказать, а то они бедолаги столько на этом базисе построили…
(8) Мне ход мысли нравится…
Статья — ведро воды, примерно на середине стало нудно читать. Автор пытается показать, что все определения проекта неверные, а вот его определение верное. И сразу видно насколько автор плавает в теме, когда пишет, что современный проектный менеджмент сформировался примерно 50-70 лет назад. Так 50 или 70 лет и кто его сформировал? Фраза о том, что имея неограниченные ресурсы можно любой проект довести до конца полнейшая чушь и это не работает. Во первых неограниченных ресурсов не бывает. В том же Древнем Египте пирамиды строили экономя ресурсы. Еще пример, M$ (или Microsoft) имела очень громадные ресурсы, но где ее мобильная операционная система? Nokia имела громаднейшие финансовые ресурсы и научный потенциал, но где делась Nokia с ее ресурсами и с ее проектами? Поэтому статья вышла неинтересная. Рассказы про яичницу смешат. Порадовать ребенка яичницей из страусиного яйца на День рождение, Вы это серьезно рассматриваете как пример проекта?
(13)
А что ещё ждать от «проповедников с горящими глазами». Каждый считает что его понимание «проектов» правильнее, его Scrum самый толстый и длинный и только он познал истинный дзен Agile, о чём нужно срочно всем в интернете рассказать.
(10)Наоборот. Боюсь, вы пойдете с PMBoK в метро (а он там не нужен).
(15)
Почему не нужен?
(17)Может я чего не знаю.
Расскажите, как обычно используете PMBoK в общественном транспорте и почему (без него совсем не можете)?
(11)
Вы спорите с воображемыми моими аргументами.
Определение в статье приведено для того, чтобы было видно:
— есть классическое определение
— оно неудачное (не применимо на практике управленцем)
— отличать проект от не-проекта можно (критерии даны)
Ну что же, отвечу любителю анекдотов:
«- Ты где работаешь?
— Да в аэропорту, туалеты мою.
— Так зачем тебе такая работа, брось ее!
— Да? И уйти из авиации?»
Вы не работаете руководителем проектов в стройке (судя по профилю — даже не близко). Автоматизировать процессы и отвечать за ввод объектов эксплуатации в срок и в рамках бюджета — разные вещи чутка. Давайте посоветую вам у кого из реальных боевых строительных менеджеров про уникальность домов спросить 😉
(8)
Это, кстати, вполне возможный и распространенный подход. Его некоторые управленцы применяют. Грубо говоря, пока вы плохо умеете делать нечто, многое в этой области для вас — проекты. Обратное верно (научились очень хорошо — теперь это не проекты, а «операционная деятельность»).
Грубо говоря, разворачивается на своем автозаводе новую сборочную линию (и это для вас в новинку) — проект. И наоборот, если вы компания, которая в месяц запускает по 3-4 таких линии под заказ на разных заводах — это вполне повседневная рутина.
Однако его придерживаются не все.
У многих застройщиков (использующих наработки еще советских проектных бюро для чертежей и штампующих одинаковые дома целыми микрорайонами) — каждый дом это отдельный проект. В ИТ и в прикладной науке — аналогично. И дело не в уникальности. Просто стройка это всегда очень высокая неопределенность (софтверная разработка, научные изыскания — тоже, хоть и по другим причинам).
Так что если неконкретную «уникальность» заменить на более понятную (на практике для конкретного менеджера и команды) «высокую неопределенность» — отличать проекты от не проектов гораздо проще. 🙂
(19) Еще раз. Определение работает. Яичница при его использовании не подходит. Так что либо не то определение, либо пример. Закон исключения третьего.
В чём сложность отличать «проекты» от «не проектов» ?
Не важно едем мы на метро, жарим яичницу, строим многоквартирный дом или целый микрорайон. Если мы это делаем с применением проектных технологий то это проект, если нет то это не проект. Разве нет?
Не деятельность, не результат этой деятельности не определяют «проект» или «не проект», а именно сам проектный подход к деятельности говорит нам о том проект у нас или нет.
Исследовательская деятельность не совсем проектная.
Если мы первую линию делаем не по проектным технологиям это проект? А если последующие делаем по «проектным» это не проект ?
Любой проект — это прежде всего управление деятельностью проектной группы с целью устранения рисков негативного результата проекта.
А уж к чему вы это управление прикрутите и как будете управлять это ваше решение ;).
Все PMBoKи и другие стандарты прежде всего об этом.
(22)
Не важно едем мы на метро, жарим яичницу, строим многоквартирный дом или целый микрорайон. Если мы это делаем с применением проектных технологий то это проект, если нет то это не проект. Разве нет?
Не деятельность, не результат этой деятельности не определяют «проект» или «не проект», а именно сам проектный подход к деятельности говорит нам о том проект у нас или нет.
Делать операцию пациенту или не делать?
Не симптомы и не диагноз определяют «оперировать ли». Важно ли то, разрезали ли мы ему живот.
Аналогично с проектами.
1000 страниц PMBoK написана не на все случаи жизни, а только для тех, которые требуют проектного подхода.
Какие это случаи? Пытаюсь ответить в статье.
(23)
Ага. Любое управление вообще об этом. Можно даже слово «проекты» не употреблять.
(25)
Решает врач, а не «проектный подход», так же как строить дом или нет решает инвестор который на это строительство выделяет деньги. Сама операция может быть проектом, может не быть, зависит от подхода к её проведению. С применением проектных подходов или без.
«Операция» это процесс которым нужно управлять, а не методика управления.
«Операция» в данном случае это процесс как и «строительство дома», а вот как вы к этому процессу подойдёте с применением «проектных технологий» или нет будет определять проект это или нет.
Вы ввели ложную аналогию.
«Проектный подход» это универсальная методика которая может применяться, может не применяться. Где то она лучше применима, где то хуже, возможно где то не применима.
Так вот:
и
В приведённом выше примере что проект, а что не проект по вашей классификации?
З.Ы. С радостью бы с вами на эту тему по дискутировал, но за дискуссии с вами выдают баны. А новые аккаунты мне лень регить. Хорошего вам настроения, держитесь здесь!
В медицине есть понятие прогноз. Имхо, если прогноз после окончания проекта благоприятный — проект можно считать успешным.
Хотя мысль о том, что если хотя бы одна из сторон проекта (заказчик или исполнитель) не была полностью удовлетворена — проект можно считать провальным, тоже очень интересна. Если в состав целей проекта включено подготовка и повышение квалификации команды — то разумеется, использование профессионалов, которые оперирует исключительно своим багажом знаний — означает всего лишь сокращение сроков и демпинг. В принципе можно найти и таких специалистов. Но в этом случае проект не может быть успешным по определению. Именно потому что для исполнителя это путь вниз и этот прогноз неблагоприятный.
Вопрос в том, можно ли считать проект успешным когда результата нет, но прогноз благоприятный.
Или когда результат есть, но с неблагоприятными перспективами.
(28)
Медицина, как и управление проектами — очень многообразна.
Некоторые врачебные вмешательства можно и нужно мерить по быстрому результату в большей степени, чем по отдаленному прогнозу. Например, значительную часть ургентных (например травматологических) хирургических вмешательств. Привезли пациента с открытым переломом — и внутренним кровотечением — операция должна сразу дать конкретный результат.
Другие, наоборот, часто не могут дать быстрого эффекта (часто — работа дерматолога или ортопеда оперирует не «результатом через пол часа», долгосрочными прогнозами).
Иногда работа врача вообще не предполагает хорошего прогноза, к сожалению (в хосписах тоже работают врачи — не их вина, что пациента невозможно вылечить).
С менеджерами проектов похоже. Нужно обязательно смотреть на цель (чего хотели те, кто проект запускал). В некоторых случаях нужен внятный результат сразу по завершении, в других — положительная динамика, а третьи проекты, например, планово-убыточные и сейчас и в перспективы и призваны, например, законсервировать некую бизнес-ситуацию или притормозить падение.
(27)
(27)
«Операция» это процесс которым нужно управлять, а не методика управления…
…Аналогично с проектами.
Вы ввели ложную аналогию.
Врач смотрит на пациента и принимает решение «как его лечить» — операция ли (какая?) или консервативное лечение (какое?) или смесь.
Менеджер смотрит на порученную ему задачу и решает как выполнить — применить ли проектное управление (и какую методику), применить регулярный менеджмент (что на много проще) или смесь.
Инвестор, конечно, не имеет никакого понятия какие управленческие подходы нужны для строительства дома — он не менеджер. Управленец должен сам уметь подбирать набор методик и инструментов под ситуацию. К тому и статья.
(27)
Спасибо!
А вот слово «проект» и определяет ту радужную , уникальную цель к которой и несется проектная группа, преодолевая и превозмогая… Под чутким руководством…
Перечитал 2 раза, но так и не увидел конкретного ответа на вопрос — что такое проект. Наверное я очень глуп или… автор призывает к субъективной оценке проекта и банальному словоблудию. Главу «Что такое проект» перечитал раз пять (!!!!), но там только говорится про «что такое не проект» и как все вокруг ошибаются.
Поправьте меня, если не прав. А то как-то чувствую себя неуютно.
Ок, я не совсем понимаю, вот есть небольшое предприятие с комплексной конфигурацией. Функциональность почти вся отключена. Предположим с начала года меняется учетная политика, какое-то время ведется работа в предыдущем периоде. Как совмещать к примеру оции наличие статуса у перемещений или соглашения, или и изменение реквизитов организации. все это требуется.зафиксировать в проекте. Единственное, что допускается включать в процессе работы это ордерный склад. Что отличает решение регулярного менеджмента от проектного? Фраза а почему вы не сказали этого раньше? Теперь уже поздно что то менять..
Иван, довольно необычно читать про неопределенность как обязательный атрибут проекта, как одну из граней, по которой можно отличить проект от не-проекта.
Ваши идеи читать интересно, но гугл как-то мало помогает, разве что кроме прикладной части вроде управления рисками в условиях неопределенности. Но чтобы неопределенность была отличительной чертой проектов …
Есть ли в в документах от PMI или в руководствах PRINCE 2 упоминание о неопределенности в такой роли?
Какой англоязычный термин можно употреблять?
(34) Я не Иван, но рискну изложить свою версию.
Предположу, что Иван говорит о неопределенности как о непременном свойстве уникальности.
Уникальность — действительно непременное свойство проекта.
Когда нет уникальности, мы говорим не о проектах, а об операционной деятельности. Нет никакой необходимости городить ни PMBOK ни Agile — один раз выстраиваем бизнес-процессы, и идём по ним. Но проект, из-за того, что он уникален, никогда до конца не понятен, не определен. В нём сидит где-нибудь чертик из табакерки под лозунгом «ни один план сражения не выдерживал столкновения с противником»…
То есть из-за уникальности мы никогда не можем в точности быть уверенными, что и как нужно делать. Риски всегда выше, чем в операционной деятельности. Как-то так.
(35) Марина, перечитал комментарии, Иван говорит возможно о замене уникальности на неопределенность.
Выглядит как reframing, ррраз и уже контекст другой.
Возможно существуют дискуссии и в англоязычной среде менеджеров проектов.
Интересно, как там звучит или звучало бы использование неопределенности как отличительного атрибута проектов.
(36) Вообще, по моим представлениям о прекрасном, как раз Agile говорит об управлении проектами в условиях неопределенности. Что про это говорит PMBOK, если честно, не помню, последний раз его читала год назад ))).
Проект дома — это проект?
Проектный институт занимается проектами?
Та или иная степень неопределенности присуща любой последовательности действий для достижения определенного результата за определенное время. Даже для яичницы.
С тем же успехом можно дискутировать о терминах Задача и Дело. Впрочем, тут проще. Задачи надо решать, дела — делать.
В любом случае, Термин Проект, можно применять к связанной последовательности действий по-разному. Непременные атрибуты проекта:
— планируемое время
— наличие участников
— наличие этапов (стадий, промежуточных результатов и т.д.)
— ожидаемый результат.
Тема я бы сказал жизненная. Спасибо автору за лаконичное и содержательное вступление в тему проектов.