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

Термин "количество заказов" как бы намекает нам, что речь идёт о заказной разработке.

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

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

У Гугла и у Яндекса и у другой интернет-компании описаны эти все процессы. Я так думаю.
Уж точно они подсчитывают количество обращений к своим сервисам таким, как gmail и mail.yandex.ru и как бы невзначай подсовывают свою рекламу. Так и живут.

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

Какой бы неформальный процесс не был - все равно есть техника создания документации без шаблона - как самая простая техника формализации знаний.

Моя оценка по результатам внедрений наводит на размышления о 80%... то есть успех внедрения зависит на 80% от человеческого фактора и только на 20% от технологий и инструментов  
Проиллюстрировать ЭТО хочу своей статьей (вернее зарисовками).

Вообще, из текста статьи мне, например, непонятно, откуда взялось такое соотношение "80 на 20"? Оно, конечно, считается стандартным и много где оправдывает себя, но здесь возникает резонный вопрос: только ли оказал негативное влияние человеческий фактор? Может, все-таки в приведенном примере не меньшую роль сыграла (как уже писали здесь выше) общая корпоративная культура? Может в предлагаемом уравнении все-таки не хватает переменных?

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

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

Хотел бы развеять такое расхожее мнение очень уверенных в себе консультантов и внедренцев.

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

Более того процессы есть всегда!
Вопрос какие? с точки зрения оптимальности, с точки зрения эффективности и т.п.

Ну, я думаю (и, наверное, многие со мной согласятся), что когда мы говорим о наличии/отсутствии процессов, то имеем в виду, что они описаны (задокументированы) / не описаны (не задокументированы). Далее... под процессом все-таки как-то принято понимать некую утвержденную последовательность действий в той или иной ситуации (конечно, есть и более точные определения, но здесь этого будет достаточно для иллюстрации). Во всех ли организациях, с которыми приходится иметь дело при внедрении инструментов или программных систем, мы можем обнаружить процессы в виде задокументированной процедуры? Я такое встречала только в одной организации и это была крупная западная компания.

Ой сколько всего написано 

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

Слава Богу, что что в сообществе аналитиков таких людей почти нет 

Коллеги, хочу обратить еще раз внимание на мой первый пест в теме. История, поведанная в зарисовке не есть пример одного внедрения,  а есть попытка обобщить, накопленный за 10 лет внедрений, опыт общения с __человеческим фактором__

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

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

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

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

По результатам данного форума мне бы хотелось выпустить уже не эссе, а статью (расширенную и дополненную), которая бы строилась по шаблону:
1. Описание фактора
1.1 Рациональное объяснение как избежать подобного риска, как его снизить
1.1.1 Контр пример (из реальной же практики). Как это было успешно решено, или описание ситуации, когда этот фактор не оказал влияния

Товарищ Boatman почти раскусил мою идею 

Теперь попробую дать ответы на некоторые сообщения:

Ситуация очень сильно перекликается с проблемами в моих проектах.

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

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

Выше уже все сказано.
А задеть автора очень сложно. Хотя, скажу по-другому: автора можно попытаться задеть и даже скомпромитировать, но только во благо дискуссии 

Какие этапы необходимо пройти, чтобы было все ОК:
1. - определить ЗС (заинтересованные строны, их потребности и интересы, включая иррациональные)
2. - определить решаемую проблему (что хотят купить)
2а - определить целевое назначение системы (цели и показатели).
3. - определить решение, включая плетки и пряники, согласующие интересы ЗС
4. - определить цену вопроса: во что это все выльется не только по деньгам, но и по организационно-технической подготовке
5. - подписать заказчика на цену вопроса, включая его обязанности касательно каждой работы по плану
6. - работать по плану, в том числе:
6.1. -- настроить и пуско-наладить ПО
6.2. -- написать и утвердить инструкции и регламенты (второе очень важно)
6.3. -- обучить людей
6.4. -- прогнать их через опытную эксплуатацию
6.5. -- перевестись в промышленную, включая официальный ввод регламентов, при этом, если одна система заменяет другую сломать старую систему напрочь (стереть, отформатировать ), чтобы ее нельзя было никак использовать.

Согласен с логикой на все 100%. Имея за плечами не один десяток проектов по внедрению могу сказать, что данный набор шагов верный и правильный. Только есть одно "но" - для достижения цели можно пользоваться  разными методами и подходы будут разными.
В реальной практике внедрения человеческий фактор играет ключевую роль при выборе стратегии внедрения. А если посмотреть вглубь, то оказывается, что человеческий фактор (он же менталитет) складывается из:
1. сектора рынка (банкинг, софтверная компания, телеком, отраслевая компания (нефтянка, металлургия), ОБОРОНКА)
каждый из факторов влияет на план (так как менталитет в разных секторах разный)
2. размер компании
чем меньше размер компании, тем менее формализованные методы в ней используются
3. РЕГИОН внедрения (или, если хотите, национальный менталитет)
Например, есть регионы, где очень большое уважение к старшим, даже если этот старший и старше-то на 2 дня 
Если в такой проект с нашей стороны пойдет молодой специалист, то его просто не будут слушать (мальчишка, что с него взять)
И так далее и тому подобное. То есть, выбирая план работ (еще до подписания контракта) выбирается некая стратегия действий исходя из вышесказанного.

Теперь посмотрим, что сбойнуло и на каких этапах:

1. Вроде, ЗС определили, точнее по тексту статьи не скажешь, но думаю там проблем нет.

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

2а. О целевом назначении не сказано - это настораживает. Один из основных рисков данного проекта.

3. Решение определили не очень... Ни плеток ни пряников и, в первую очередь для ЛПР. И это видно на седующем этапе.

4. Я думаю, смету посчитали - это не проблема, а вот требования к заказчику определили не до конца.

5. Здесь стали видны проблемы предыдущих 2х этапов:
- "Заказчик мягко намекнул, что процессы ему выстраивать не надо." - в чем проблема, денег пожалели?
- "Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать" - надеюсь, его заставили положить эти процессы на стол в виде диаграмм, утвержденных регламенов и инструкций и доказательств того, что эти регламенты исполняются?
- "Нас продавили только двумя железными аргументами “клиент всегда прав” и “кто платит деньги?”." - иными словами очень хотелось заработать (не до жиру), по этому пришлось идти в проект на условиях заказчика (сам так попадал).
- "Пришлось взять расписку об ответственности за неуспех и приступить" - это хороший вариант для зарабатывания деннег. Для пользы дальнейшего процесса можно было грузить обязательствами "обязательно есть то, что заказывали, что заказывали четко задокументировать в спецификации".
И здесь же всплыло отсутствие целевого наначения системы (риск реализован): основных достигаемых показателей. Неквязка между целевым назначением и более низкоуровневыми требованиями могла бы стать аргументом для заказчика.

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

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

3,4 ну история так и показана 
ок

5. Тут интереснее
- "Заказчик мягко намекнул, что процессы ему выстраивать не надо." - в чем проблема, денег пожалели?
Возвращаемся к рыночному разделению компаний. Если проект относится к оборонке, то, в 99% случаев есть все нормативные документы... и общие положения, и положения о ролях, и регламенты. И в таких проектах нужно взять и сделать как написано.
Такой заказчик не всегде хочет платить денег за глубокое предобследование и выстраивание процессов.
Да, может и денег пожалеть.
Если провести аналогию с корпоративной культурой, то она есть в любой компании. Отсутсвие культуры - тоже культура   

- "Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать" - надеюсь, его заставили положить эти процессы на стол в виде диаграмм, утвержденных регламенов и инструкций и доказательств того, что эти регламенты исполняются?
Что называется, не будем переходить грани светского разговора 
В большинстве случаев, если заказчик говорит, что у него есть ФОРМАЛИЗОВАННЫЙ процесс, то мы просим его показать.

- "Нас продавили только двумя железными аргументами “клиент всегда прав” и “кто платит деньги?”." - иными словами очень хотелось заработать (не до жиру), по этому пришлось идти в проект на условиях заказчика (сам так попадал).
Даже не знаю, что написать...
Наверное, кому-то и не нужны. А так, вообще, это очень сильный аргумент со стороны заказчика.
Лично для себя я готов сделать многое для заказчика, если это не противоречит в дальней перспективе _ЕГО_ же интересам. Классический вопрос: если человек стоит с завязанными глазами перед пропастью и хочет сделать шаг вперед... разрешу я ему это или нет? 

- "Пришлось взять расписку об ответственности за неуспех и приступить" - это хороший вариант для зарабатывания деннег. Для пользы дальнейшего процесса можно было грузить обязательствами "обязательно есть то, что заказывали, что заказывали четко задокументировать в спецификации".
И здесь же всплыло отсутствие целевого наначения системы (риск реализован): основных достигаемых показателей. Неквязка между целевым назначением и более низкоуровневыми требованиями могла бы стать аргументом для заказчика.
Ой! А как можно по-другому?
Роль расписки вполне играет _ПИЛОТНЫЙ_ проект

6-6.4
Золотые слова. Всем бы заказчикам в уши. На практике, внедрение новой системы взамен существующей (тем более если разработчики, ее поддерживающие являются сотрудниками компании), всегда сопровождается сложностями. Договор в этом случае прикрывает нас, но не гарантирует отсутствие человеческого фактора

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

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

Может на стадии подписания договора экстрасенсов приглашать? Не знаю... 

Какие сделаны выводы мной:
Опять бюджет 
Хочу чтоб был учтен фактор неформальных связей. И фактор выполнения проекта на подряде.
В остальном вопросов нет. Такая точка зрения имеет место быть и бывает.


Уф...

Дальше отвечу телеграфно. Цитировать очень неудобно

"идти ли в проект, если видишь, что он закончится не очень успешно, но деньги заплятят" - это тема отдельного разговора и на этот вопрос статья не отвечает (расклад по вопросу не ясен).
Иногда бывают непопильные проекты.
Всегда неясно будет проект успешным или нет.
Никто заранее не знает что и как будет....

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

В развитие темы и для подолжения данной темы дам ссылки (на дополнительную критику):

1. Презентация с конференции Training Labs 2008 http://cmcons.com/presentation/tl_cc_cq/
Там как раз есть тема про типы внедрения

2. Человеческий фактор в обучении при внедрении http://cmcons.com/articles/course/trainings_strategy/

3. Тоже эссе на тему как правильно внедрить http://cmcons.com/articles/analitika/cool_deploy/

Вроде все.
Спасибо за пост. Готов при доработке данной статьи взять в соавторы 

Ладно, еще секрет открою 
Это все (включая ссылки) были рабочие материалы для книги. Я еще собираюсь сделать несколько эссе (выдрать материалов из книжки), но вот я пока не уверен, что она будет пользоваться спросом... Хотя, опять же, дискуссия говорит об обратном.
Возможно тема и верная 

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

Думаю, что это не PMBOK'у не хватает техники (его-то как раз практики пишут, см. список авторов), а его имплементаторам. Сами же пишете про умелые руки. Так что руки (да и голову) пока никто не отменял, собственно, это ключевой тезис в разговорах о человеческом факторе. Как пишут в книжках "Хорошее программное обеспечение создается людьми. Так же как и плохое. "

Или может быть книгу?...
Хорошо будет продаваться...

не факт, к сожалению. хотя хороших книг у нас катастрофически мало.

По результатам данного форума мне бы хотелось выпустить уже не эссе, а статью (расширенную и дополненную), которая бы строилась по шаблону:
1. Описание фактора
1.1 Рациональное объяснение как избежать подобного риска, как его снизить
1.1.1 Контр пример (из реальной же практики). Как это было успешно решено, или описание ситуации, когда этот фактор не оказал влияния

Почему только форума? Непонятно желание ограничить себя в каком-то мирке, пусть довольно амбициозном, но тем не менее узком.
Между прочим, всё уже придумано до нас. Про влияние человеческого фактора (который, кстати, может иметь не только отрицательное влияние, но и положительное) написано несколько довольно известных даже у нас книг, навскидку приходят на ум: Peopleware Демарко и Листера, книга с подобным названием (The Peopleware Papers) Ларри Константина.
Если есть, что сказать нового - было бы очень полезно иметь такую книжку. Впрочем, для самовыражения и сам факт неплох.

По классификации рисков посмотрите Рассела Арчибальда, правда у него приведены риски, связанные не только с человеческим фактором.
Да и с примерами придётся непросто.

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

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

Между прочим, всё уже придумано до нас. Про влияние человеческого фактора (который, кстати, может иметь не только отрицательное влияние, но и положительное) написано несколько довольно известных даже у нас книг, навскидку приходят на ум: Peopleware Демарко и Листера, книга с подобным названием (The Peopleware Papers) Ларри Константина.
Если есть, что сказать нового - было бы очень полезно иметь такую книжку.

Мне тоже долгое время казалось, что нужно стремиться перечитать все книжки, которые есть, прежде чем что-то пытаться изобрести... но жизнь оказалась такова, что всех книг не перечитаешь, а действовать как-то надо... Это я к тому, что само по себе утверждение о том, что "всё уже придумано до нас" несколько спорно, хотя и не ошибочно. Это раз. А два - хорошо, книг написано много, но ситуация от этого коренным образом не меняется... Почему? Может, потому что кричать нужно громче - чтоб услышали? Это я к тому, что лишнее упоминание в прессе о влиянии в том числе и человеческого фактора при внедрении, будет вовсе не лишним. И три - все перечисленные вами книги - книги зарубежных авторов... Лично у меня сложилось такое впечатление, что не все западные методы применимы для российской действительности, и часто в западной литературе просто не возможно найти рецепты для различного рода специфических проблем, свойственных многим именно отечественным предприятиям.

Они позволяют... не брать на себя ответственность. Фиг ли. В книжке прочитал. Умные люди написали. Я не виноват, что не сработало...

А знаете, к сожалению, действительно бывают ситуации, когда лучше не брать на себя ответственность. (Я искренне завидую тем, кому не доводилось с ними сталкиваться!) И дело даже не в том, что лень, а в том, что тем, кто такую ситуацию создал, им-то хорошо, они так и так сухими из воды выйдут, а вот отвечать-то тебе придется... Реальный пример: у софтверной организации 2 активных проекта, по одному имеется четкий план, согласованный с заказчиком, по второму - лишь смутное представление о том, что вот эти вещи по-любому должны быть сделаны. Куратором второго проекта является начальник подразделения анализа, куратором первого - ведущий аналитик. В итоге начальник, будучии извещенным о наличии согласованного с заказчиком плана по 1-ому проекту и предупрежденный куратором этого проекта, перебрасывает запланированных на него людей на 2-ой проект... В итоге: летят сроки по 1-ому проекту, из-за отсутствия четкого плана срывается также и 2-ой проект, но вся ответственность за проблемы  1-ого проекта перекладывается этим же самым начальником на куратора, который находится в его подчинении и в общем-то и сделать-то ничего не может... Вот так вот

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

По поводу неизменения ситуации у меня есть своё личное мнение. Заключается оно в отсутствии критической массы, знакомой (хотя бы просто знакомой) с литературой. ЛюдЯм кажется, что проще и дешевле будет сначала самому попробовать наступить на грабли. Но как говорит один мой знакомый: Опыт хорошая школа, но только дураки не учатся ни в какой другой.

Конечно же очередное упоминание о роли человеческого фактора лишним не будет (что мы и имеем в рамках этого обсуждения). Так что, наверное, да, нужно и кричать тоже. Вопрос: о чём? От прописных истин люди быстро устают, всем обычно нужны конкретные советы, но советы без соответствующего контекста тоже бессмысленны.

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

А знаете, к сожалению, действительно бывают ситуации, когда лучше не брать на себя ответственность. (Я искренне завидую тем, кому не доводилось с ними сталкиваться!) И дело даже не в том, что лень, а в том, что тем, кто такую ситуацию создал, им-то хорошо, они так и так сухими из воды выйдут, а вот отвечать-то тебе придется... Реальный пример: у софтверной организации 2 активных проекта, по одному имеется четкий план, согласованный с заказчиком, по второму - лишь смутное представление о том, что вот эти вещи по-любому должны быть сделаны. Куратором второго проекта является начальник подразделения анализа, куратором первого - ведущий аналитик. В итоге начальник, будучии извещенным о наличии согласованного с заказчиком плана по 1-ому проекту и предупрежденный куратором этого проекта, перебрасывает запланированных на него людей на 2-ой проект... В итоге: летят сроки по 1-ому проекту, из-за отсутствия четкого плана срывается также и 2-ой проект, но вся ответственность за проблемы  1-ого проекта перекладывается этим же самым начальником на куратора, который находится в его подчинении и в общем-то и сделать-то ничего не может... Вот так вот

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

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

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

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

Думаю, это тема отдельного разговора. Подозреваю, что мы говорим о разных вещах относительно западных методов и отечественной специфики.

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

Подозреваю, что мы говорим о разных вещах относительно западных методов и отечественной специфики.

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