1. Насколько важны для Менеджера Проекта знание и навыки отраслевой экспертизы - для осуществления своей деятельности эффективно - в случае смены отрасли?
Например, Менеджер Проектов в IT-среде, дистрибуции ПО - насколько ему будет легко перейти в корпорацию в производственной сфере?
или Менеджер в сфере Строительства - насколько он будет уместен:
*как при смене традиционной сферы - например, управление в отрасли здравоохранения,
*так и при смене специализации - человек, занимающийся вопросами реализации проектов в сфере гражданского строительства, резкий уход в сферу проектов индустриальной электроэнергетики или автоматизации?
1.1 Следует ли менеджеру проектов посвятить множество времени на изучение отраслевой специфики, или отдавать все на откуп техническим департаментам?
Какой критерий достаточности технической экспертизы для Менеджера - для успешных переговоров с Заказчиком?
Условно, глава проектного отдела знает тех. часть на 8-9/10, а менеджер - на 4-5/10?
Достаточно ли этого и когда стоит остановиться?
2. Если это не имеет значения, то почему случаи успешного перехода из отрасли в отрасль так редки?
Либо отрасли и имеющаяся экспертиза лиц схожи по своей сути .
Например переход Льва Хасиса из X5 RG в Сбер в 2012.
Основная экспертиза - e-commerce, чем он успешно в Сбере и занимался.
3. Большая просьба, примеры типа перехода С. Джобса из киностудию Pixar в Apple, или Джона Скалли из PepsiCo туда же - прошу не указывать,
Желательны кейсы из российской действительности.
4. В качестве затравки, могу заметить что в своей практике не могу привести реализованных кейсов радикальной смены индустрии топ-менеджерами.
Коллеги, меняя компании и географию работ, зачастую оставались в рамках одной индустрии и зачастую специализации.
Незначительные изменения специализации - Например, переход из проектного менеджмента гражданского строительства - в дорожное - не в счет.
5. В случае если тема поднималась ранее - прошу указать ссылку.
Компания планирует привлечь во время размещения 15-20 млрд руб.
Зарплатные предложения в этой сфере также выросли на 32%.
Для юридических лиц планируют ввести штраф в размере от 50 тыс. до 100 тыс. руб.
У каждого третьего опрошенного увеличился бюджет на летний отпуск по сравнению с 2023 годом.
Абсолютно верно, надо обьяснить, но сделать это крайне не просто. По следующим причинам:
- собственник не является специалистом и много чего не знает;
- незнание и невозможность осуществить личную экспертизу решений специалистов заставляет интегрировать в управленческую вертикаль своих проверенных людей, а они начинают устраивать препоны к доступу к ЛПР для специалистов более высокого уровня чем они, что бы не сложилось доверительных отношений;
- языковой и ценностный барьер - ресурсособирательная стратегия присущая собственникам немного отличается от опытособирательной стратегии специалиста - понятия и ценности отличаются и понимание высказанное в одной парадигме в другой понимается иначе с искажениями;
- животные (примативные) влияния - находясь на разном уровне иерархии людям свойственно искажать сказанное визави - слова более статусного члена обретают отсутствующую там мудрость, а слова менее статусного могут восприниматься как заведомо глупые. Этот фактор тоже вносит вклад.
Коммуникация затруднена. Но работать в этом направлении нужно.
А почему нужен единый МП, почему нельзя назначить МП (менеджером проекта) Васю или кого другого и одновременно ГИП (главным инженером проекта) Петю?
То что Петя годится на ГИП сомнений нет.
Распределите их обязанности, и пускай работают оба.
Поскольку Петя работал ГИП-ом в институте, то он умеет взаимодействовать с вышестоящими, смежниками и подчиненными.
Если дело в экономии на зарплате, то убытков может быть гораздо больше и если назначить одного Васю МП или одного Петю.
Кстати, помните был сериал "Богатые тоже плачут", так там в какой-то момент два героя, которые увивались за главной героиней, были руководителями строительного проекта, один, архитектор - технической частью, другой - административной частью.
В связи с личным соперничеством они плохо друг с другом работали, но это же не Ваш случай.
Кстати, есть еще один вариант, Вы можете назначить Петю МП и дать ему помощника по административно-коммерческим вопросам, в общем по тем вопросам, в которых он плохо разбирается.
Мне кажется, что лет 30-40 назад произошло переосмысление слова "проект". В старину значение слова было что-то близкое к мечте.
Помните: - у вас есть дети? - в проекте.
А сейчас они имеет именно тот смысл, о котором Вы пишете.
Кстати, много лет назад я, айтишник, стал главным инженером одного из больших технологических комплексов. У меня не было трудностей с повседневней работой - электорпитание, большое количество аппаратуры и приборов, кондиционирование, водоподготовка, вычислительный центр, связь, включая линейные-аппаратные залы. Но шла стройка и я отвечал со стороны заказчика за результат её выполнения. И там для меня возникли серьёзные трудности. Решал их дипломатическим путём вместе с прорабом. Нашли общий язык и в принципе проколов не было. Но это была очень непростая для меня работа. Особенно сложно было разговаривать со строителями-специалистами. Они двумя словами могли меня вывести за линию.
Сейчас мы это поправим ...
Затесалось - так затесалось, в голову - так в голову. Достанем и оттуда.
Берем любой стандарт на понятных нам языках. Например, ГОСТ Р 54869-2011 Вас устроит? Принят довольно давно.
Для Вашего удобства - самое короткое из того, что я видел. См. Раздел 3 - "Термины и определения":
3.12 проект: Комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.
https://docs.cntd.ru/document/1200089604
Если интересуют детали и нюансы, то можно посмотреть ISO 21500, PMBoK, PRINCE2 и другие важнейшие источники на эту тему. Смысл будет тот же, а деталей гораздо больше. Зависит также от года и версии.
Вы говорите о том, о чём считаете нужным - у Вас полная свобода. Вы упомянули некое общеупотребительное применение + дополнительно дали собственные определения. Отлично.
Отвечая на Ваш вопрос: приведенное мной выше достаточно конкретно? Нужны ли дополнительные пояснения?
И мы с Вами вовсе не спорим - обычная дружеская беседа о словах, как принято между джентльменами.
Это важный вопрос об организационной структуре проекта. Готовится и решается (обычно) менеджером проекта, результаты затем отражаются в проектной документации.
Распределение обязанностей, зоны ответственности и смежные вопросы должны быть глубоко продуманы с учетом и хорошим пониманием деталей и сложности проекта. Человек без соответствующего опыта вряд ли сделает это правильно с первого раза.
Помните слово "прожектёр"? Пришло, скорее всего, из французского - и с негативным оттенком. Хорошего человека так не называли.
Думаю, что это зависит от места и контекста. Скажем, слова design и project в оригинале имеют понятные различия, хотя у нас они могут употребляться как угодно, по какому угодно поводу, по одиночке и вместе, и одно вместо другого.
Именно. Нет, чтобы сказать "в планах" или "да, пока думаем об этом". Но "дети - в проекте" звучит совсем иначе.
Хотелось бы - лучше бы друг друга понимали. Но увы ...
Плохой (анти-) пример: нечто под названием "либеральный проект для России". Слышал много раз, потом поутихло. Но не разу не видел хотя бы двоих, чьи представления по этому поводу совпадали. Почему "проект" - да кто ж его знает, просто кому-то понравилась фонетика. Понятно, что никаких проектов эти люди никогда не вели.
Просто пример: финансисты, говоря о проектном финансировании, обычно склеивают собственно проект и некий связанный с ним бизнес. Например, предполагается построить мост, поставить шлагбаум и собирать деньги за проезд.
Работа менеджера проекта заканчивается, когда мост построен, шлагбаум установлен, всё передано заказчику, а проект закрыт. Тут просыпаются финансисты, для которых сам по себе проект строительства моста - только расходы и рутина, и начинают смотреть, соответствует ли календарный приход и поток денег их расчетам, не слишком ли они ошиблись со сроками окупаемости (скажем, 10 лет), как этот бизнес себя чувствует и пр..
И таких примеров сколько угодно.
А ну теперь понятно. Давайте проверим на простом примере. Организация строит жилое здание. Жилое здание не относиться к уникальным объектам. Значит это не проект согласно пмбоку? И в каждом учебном курсе по пмбоку обьясняется что это все таки проект, и уникальность состоит в том что все начинается с начала. Это пример как крайне не удачно выбранное определение понятия сбивает с толку не способную к критическому мышлению публику.
Блестящие примеры! Именно так!
Строительство любого здания является уникальным. Хотя бы только из-за того, что оно начинается, как минимум, с изучения условий строительства.
Лет 10 назад мы делали некоторый памятник в одном из городов страны. Сами подготовили дизайн, картинки-рисунки, нашли деньги. Но всё затормозилось из-за того, что нужны было проводить инженероно-изыскательсткие работы на местности. и проект встал. А у нас был такой красивый образ!
Евгений как раз об этом пишет - от определения проекта зависит и точка отсчёта его начала и окончания. Собственно уровень компетенции проявляет и менеджер проекта, которые способен правильно и оптимально определить начальную точку, то есть входы и выходы проекта.
Евгений не хочет думать, но хочет спорить. Градостроительный кодекс РФ содержит перечень обьектов считающимися уникальными, а также указания к подготовке проектов считающимися уникальными, список работ делающих объект уникальным и тд. Памятник будет уникальным если у него чего то будет торчать на 20м.
Слово уникальный в стандарте пмбок введено для характеризации отличий проекта от процесса. Процесс это повторяющаяся совокупность мероприятий, а проект это уникальная совокупность. Собственно оттуда эта дефиниция. Правильный контекстный перевод стандарта это не "уникальный" а "неповторяемый" расставил бы все на свои места.
Мы начинаем заниматься казуистикой. Сначала обсуждали уникальный проект, потом уникальный продукт. а теперь уникальный объект. Я в град. кодексе не специалист, посмотрел - да, там указаны признаки уникальности объекта. Согласитесь, что эти изменения в ГК сделаны после ряда аварий на строительных объектах и служат целям обеспечения безопасности. Не вижу противоречия между ГОСТом и ГК.
В моём случае всё гораздо проще:
- с точки зрения ГК мой памятник не является уникальным объектом строительства.
- с точки зрения пректного менеджера он является уникальным и неповторим (как угодно) проектом, даже если он не заглублён сильнее 15 метров.
Тут еще стоит один вопрос, а что под памятником находится? Какие коммуникации проходят, какие объекты расположены, с учетом этого он может быть очень уникален.
Отлично.
Давайте. Всегда полезно. Это имеет прямое отношение к теме дискуссии.
Здание - нет. Это часть требований заказчика и возможный результат выполнения проекта - или один из результатов. Уникальность проекта состоит не в том, что Вы каждый раз строите уникальное здание. Это никак не связано.
А проект - все действия (!), нужные, чтобы это или любое другое здание действительно построить в этом месте, в это время, вот этими ресурсами, в соответствии с вот такими требованиями, целями проекта, критериями успеха и т.д.. См. также ниже.
Два одинаковых проекта мне пока не встречались. Детали можно найти в комплекте документов на момент закрытия проекта.
Не знаю, на что конкретно Вы ссылаетесь. Звучит удивительно.
Но работу можно выполнить в формате проекта в соответствии с критериями PMBoK или других методологий и концепций PM, а можно и как угодно еще.
Проект начинается, естественно, с начала. А как иначе?
Жаль, если Вы сбиты с толку - если это так. С определением всё нормально - смело пользуйтесь.
Вспомним то, что уже неоднократно обсуждалось на этом ресурсе.
Проект для менеджера обычно определяется триадой Scope/Sсhedule/Budget, к этому я бы добавил Constraints, Resources и Risks. Список можно расширить, это самое важное для начала. Присутствует всегда.
В Вашем примере будущее здание относится к Scope. Там же будет и многое другое, нужное для строительства. Определяется заказчиком, но не только им.
Менеджер проекта, готовя и обновляя проектную документацию, планируя работы, работая с заказчиком, исполнителями, субподрячиками, поставщиками и пр., принимая решения и, в целом, управляя проектом в течение его жизненного цикла, постоянно проверяет на практике всё вышеперечисленное с точки зрения правильности, возможных изменений, факта выполнения и прочего. В случае необходимости в проектную документацию вносятся изменения согласно процедурам проекта.
И так до тех пор, пока проект не будет закрыт.
Конечно. Это очевидно.
Никто не построит два совершенно одинаковых здания в одном и том же месте одними и теми же руками в одно и то же время за одни и те же деньги на основании одних и тех же требований и подключенные к одним и тем же коммуникациям. И так далее.
А дальше возможны любые различия, иногда очень важные.
Хороший пример на тему дискуссии. Опытный PM включил бы все предварительные работы и изыскания в план. Неопытный - в лучшем случае спросил бы старших товарищей, что всё это значит.
И их тоже, естественно. Относится к Schedule. Аналитического решения не существует - а жаль, не было бы большинства проблем. Опытному PM планировать, конечно, гораздо проще. Он уже на многие грабли наступал.
Но в определении проекта главное - что это о реальных работах, людях и их потных спинах, а не о пачке бумаги с картинками, на которой кто-то написал слово "Проект". Единственный риск для пачки бумаги - что её выбросят. А в каждом реальном проекте рисков могут быть десятки, если не сотни.