воскресенье, 30 октября 2016 г.

Прием для сбора требований - джинн реального мира

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


Вы говорите пользователям: "Представьте, что есть джинн, который может сделать все что угодно. Чем больше вам от него надо, тем меньше желаний он выполнит. Какой минимум он для вас должен сделать?" Т.к. это джинн, то никто не пытается дать ограничения вместо требований, а т.к. он реальный и его услуги стоят денег-времени, то люди начинают думать об оптимальном наборе желаний.

суббота, 29 октября 2016 г.

Почему сложно продавать системный менеджмент?


Для начала я хотел бы развести понятия системного менеджмента (СМ) и системного управления проектами (СУП). Под СМ я подразумеваю использование системного мышления применительно к предприятию, см. курс Техинвестлаб по системноменеджерскому мышлению. Под СУП я подразумеваю один из подходов – Акселос, ПиЭмАй фаундешенел стэндардз, АйСиБи и П2М. При этом, Основные стандарты (условный ОПМ3) в части ПМБОК берет на себя роль метатекста, давая онтологию для проектного управления (ПУ), а вместе с остальными основными стандартами ПиЭмАй является описанием жизненного цикла (ЖЦ), который описывает 5 практик – инициация, планирование, исполнение, контроль, закрытие ко всему холону плановой деятельности предприятия, с разбивкой этих практик на подпрактики для проектов, программ и портфтелей. Примерное похожая ситуация с подходом Акселос, но там, насколько помню, нет метатекста, онтология вшита в тексты стандартов.
В моем мире все основные СУПы системные и по ОМГ Эссенс покрывают альфы «Стейкхолдеры» и «Возможности» (Ст. ПгМ и ПфМ это как раз по большей части про это, как с точки зрения распределения и привлечения ресурсов, так и с точки зрения управления пользой и рисками, ПгМ и ПфМ явно указывают на подотчетность), «Требования» (покрыты слабо, но в части управления качеством и конфигурацией кое-что есть), «Работы» - комментировать даже не стоит, «Команда» (Ст. ПгМ, ПМБОК явно указывают практики развития команды), «Технологии» (Ст. ПгМ, см. Програм Сет-ап и Транзишен плэннинг). Здесь есть ключевой момент, важный для дальнейшего понимания, ПМБОК является метатекстом, основные знания по управлению проектами лежат в других текстах, и это явно указано в тексте документа, и именно знание реальных практик проектного управления, а не знание и понимание онтологии ПУ проверяется на экзамене ПМП. Чаще всего базовыми текстами по ПУ являются Керцнер и Малкахи.
Разработчики ПиЭмАй осознанно оставили в стороне практики управления системой – альфы «Требования» и «Воплощение системы», т.к. это как раз вотчина системной инженерии и создавать новую онтологию смысла никакого нет. Так что и получается та самая смычка между системными инженерами и инженерными менеджерами, у которых совпадает мотивация – сделать проект с нужным качеством, в срок и бюджет, но у каждого из них свой объект управления и свое пространство выбора. Одни сосредоточены на слое Система, другие на Возможностях и Предпринятии. И есть у меня подозрение, что если расписать Эссенс по подальфами, то граница между СИ и ИМ пройдет достаточно четкая, так что можно будет навести интерфейсы с достаточно жесткими контрактами. И к решению этой задачи, на мой взгляд, военные ИМ и СМ США подошли ближе всех.
Возвращаясь к основному вопросу – почему же тяжело продавать СМ, равно как и СУП? Взгляните на ситуацию глазами предпринимателя. Приходят к нему внедренцы СУП, пусть даже вся святая троица – логисты, вендоры ИТ решения и организаторы, см. обсуждение https://www.facebook.com/alex.turkhanov/posts/10210400088615611
Что могут показать команды СУП? Огромный многолетний пласт решений, сотни тысяч кейсов, миллионы специалистов, выбор всего и вся во всех отраслях. Взять одни только отраслевые журналы, выпускаемые ПиЭмАй, и того хватит за глаза, чтобы объективно доказать полезность внедрения СУП. Но не хватает, т.к. внедрение ПУ – это внедрение менеджмента вообще, много раз об этом писал и не только я. Начинать внедрение ПУ надо с Get Things Done и трекеров,  А в части СМ пространство решений и данных об их эффективности настолько мало, что просто незаметная величина. И ставить СМ будут только венчурные капиталисты, да и то, если команда сможет показать, что СМ дает 50% роста эффективности по сравнению с СУП. А мы тут сами еще не разобрались, что от чего чем отличается, как же мы продадим другим?
 
Что еще было по теме?

пятница, 28 октября 2016 г.

Как все начиналось



Коучи


Снится ли Microsoft Project критические цепи?

"Жора, побывавший там под самый Новый год, возразил, что никакой машины там не было, а были там какие-то серые шкафы, тунеядец был не в черном халате, а в белом, и пахло там печеной картошкой. В общем, мура, обман трудящихся. Если хотите знать мое мнение, сказал Жора Наумов, он же Гирш Наумови...ч, то все очень просто: какой-то еврей из Академии наук охмурил нашего Теодор Михеича и гонит себе сейчас докторскую из нашего трудового пота."

Кейс - небольшой проект по запуску нового сервиса, 10 месяцев, менее 1 млн. Евро бюджета, около 100 человек в проекте, несколько подразделений российского филиала, несколько подрядчиков, географическая распределенность. Уровень зрелости ПУ - между 2-с и 3-м, для отрасли высокий, РП выделенный, специалист в предметной области, без серьезных знаний ПУ, планирование и контроль хода реализации осуществлялся при поддержке офиса управления проектами. Команда планирования имела аналогичный опыт, задачи типовые, на многие задачи были доступны исторические данные. Инструментом составления расписания по МКЦ был MSP2010 со специализированным шаблоном. В компании очень высокий уровень личной ответственности, обязательности и ориентированности на общий результат, низкий уровень бюрократии. Размер плана - порядка 1,000 задач.

Проблемы на инициации проекта
Расписание контрольных точек (КТ) - пришлось в устав писать дедлайны КТ, а не их плановые даты, в результате полученное на этапе планирования агрессивное расписание КТ не совпало с датами из устава, пришлось объяснять спонсору и владельцам ресурсов причину расхождения. Сразу возник вопрос - какие КТ ставить в календари Outlook участникам проекта - из устава или из сжатого расписания? Постоянный перенос дат КТ по мере расходования буфера проекта крайне расхолаживающе действует на исполнителей, а сделать мотивацию по достижению агрессивных сроков не всегда осмысленно, т.к. даты открытия сервиса по точкам привязаны к промо-периодам и раннее завершение проекта бизнес-кейса не улучшит.
Проблемы при планировании проекта
Длительности работ ставились исполнителям директивно командой планирования и РП. Несмотря на наличие исторических данных определение 50% длительности и 95% длительности все равно напоминало гадание на кофейной гуще, т.к. статистически значимых массивов для определения нормативов не было. Какая ситуация сложилась бы на сколько-нибудь уникальном проекте, догадаться несложно, т.к. в таких проектах типична ситуация "два оценщика, четыре мнения". Аналогично, даже если проект типовой, но технология позволяет реализовать решение ста тысячами разных способов, как это часто случается в ИТ проектах, исторические данные теряют свою ценность по сравнению с оценками исполнителей/планировщиков.
"Узкие места" были заранее известны, их было три, планирование только подтвердило предположения.
Итоговый план исполнителями был воспринят как малореалистичный, мотивация участников и так была близка к сдельной работе и замотивирована на завершение проекта к заданной дате (нет сервиса к промо-периоду и высокому сезоны - продажи меньше плана).
Плановая стоимость проекта - один большой вопрос. Должен ли буфер содержать стоимости или это пустая задача? Если пустая задача, то надо пересчитывать нормативы стоимости ресурсов, т.е., вести два справочника, если буфер содержит стоимости, то как все это учитывать? Забегая вперед - а как считать освоенный объем, по физобъему, т.к. по длительностям, при искаженных стоимостях ресурсов, будет полная ерунда?
Метод освоенного объема (EVM) - вообще один большой вопрос. Бюджетная кривая, изначально рассчитанная на то, что проект будет от нее отклоняться, вопрос, насколько - это не та идея, которую вы сможете продать топ-менеджменту и финансам? Внятных ответов в Сети по тому, как обойти этот вопрос, я не нашел, есть только статьи типа такой 'Theory of Constraints Project Management in Aircraft Assembly David K. Christ The Boeing Company September 10, 2001'. Т.е., при переходе на МКЦ выбор стоит еще в отказе от EVM?
Со стороны программного и портфельного менеджмента тоже совсем все не ясно. Вот есть программа из трех проектов - маркетинговое изучение нового сервиса (продукта), разработка и производство сервиса (продукта), модернизация системы отчетности для контроля и управления этим новым сервисом (продуктом). Я могу на одном слайде показать три колбаски с КТ, на котором объяснить, что происходит - вот тут готовы результаты исследований, вот тут мы по этим результатам дорабатываем новую версию сервиса, вот тут должна появиться новая отчетность. Руководство запоминает эти даты, а далее в проекте все эти КТ запланированы на первую половину отведенной длительности проекта, и когда спонсор смотрит в план управления проекта, он вспоминает, что в презентации дорожной карты даты КТ были другие. Ну что, удачи офису управления проектами и РП объяснять причины расхождений, до тех пор, пока все руководство не поймет простой истины - КТ больше верить нельзя, в этом методе есть только одна дата, которая "гарантируется" - дата завершения проекта или фазы. А в промежутке спонсор увидит "агрессивную дату", которая никогда не будет выполнена, и "здоровье буфера". Такой подход не способствует повышению уверенности спонсора и требует более длительных собраний, больше бюрократии, отчетности и т.п. Как это все должно работать на уровне портфельного менеджмента, мне сейчас тоже не ясно, т.к. вместе с расписанием КТ уходит и инструмент дорожной карты портфеля и EVM.
Итог - менять надо гораздо больше, чем говорят в красивых презах, и менять не только в методологии и программном обеспечении, но и в головах исполнителей, функциональных руководителей, менеджеров проектов и руководства предприятия.
Контроль - как и куда списываться? Если агрессивная плановая длительность задачи завершилась, списываться ресурсы должны в буфер или на эту задачу? Сколько еще ресурсов можно списать в задачу после завершения ее плановой длительности? Или списываться ресурсы могут только в пакет работ или даже в контрольный счет и до тех пор, пока он не закрыт? Это, на мой взгляд, единственный способ объединить МКЦ и EVM хоть в каком-то виде, но применимо ли это в проектах менее 1 млн.? На мой взгляд, нет.
Вообще, есть множество очень практических вопросов, которые давно надежно решены в классических методологиях, но ответы на которые доступные ресурсы по МКЦ не дают, везде ответ по типу "платите 1,500 фунтов, и мы расскажем". И что-то у меня сомнения, что расскажут, из моего опыта общения на форумах, посвященных МКЦ.
Итого, потенциальные выгоды (уменьшить использование техник padding) не больше, чем при обычном и отработанном management by exceptions, а проблем на порядок больше. Причем, наличие буфера на мой взгляд, отвращает исполнителей и планироващиков от техники padding, чем наличие контролируемого спонсором бизнес-кейса и management by exceptions на всех уровнях. Пока чистый проигрыш PRINCE2.
Еще одна дилемма - показывать исполнителям буфер или нет? Ответов нет, и за и против список длинный.
Закрытие. Самые главные вопросы - кого вознаграждать и за что; как обновлять историческую информацию по исполнению и планам; какие lessons learned?
Заключение. Использование МКЦ для непроизводственных проектов, где расписание не упирается в статистически управляемые производственные процессы, вызывает серьезные вопросы в целесообразности использования, которые возникают на всех этапах проекта. В дополнение к возникающим проблемам, внедрение МКЦ требует устранения некоторых очень важных и распространенных инструментов планирования и контроля, используемых в т.ч. и для портфельного управления. Другими словами, пока это выглядит как http://www.youtube.com/watch?v=2rfc0o1k_HM

Update. Сейчас понятно, что EVM прекрасно стыкуется с МКЦ.

Работа - это не игрушки?

Как сохранить мотивацию
Мотивация — топливо любой интеллектуальной работы. При наличии мотивации можно за день сделать больше, чем за неделю. При отсутствии мотивации можно потерять неделю на выполнение дневной работы.
Но как руководителю убедиться в том, что все члены его удаленной команды высокомотивированы? Угрожать им кнутом или заманивать пряником?
В замечательной книге "Наказание наградой" Э...лфи Коэн отвечает на последний вопрос: ни то ни другое. Попытки подстегнуть мотивацию угрозами или наградами абсолютно неэффективны. На самом деле они приводят к обратному результату. Можете посмотреть ролик "Загадка мотивации" Дэна Пинка на TEDx, там есть взгляд на эту проблему с другой стороны.
Есть только один надежный способ поднять мотивацию — поощрять людей работать над тем, что им нравится, и только с теми людьми, которые не оставляют их равнодушными. И никаких других вариантов.
Поначалу это не укладывается в голове. Особенно у руководителей. Обычное возражение «работа — это не игрушки». Может, и так. Но почему она не может быть сложной, интересной и захватывающей? Называя удовольствие от работы «игрушками», такие боссы принижают силу интеллектуальной стимуляции, которую обеспечивает хорошо сделанное дело.
Мотивацию нельзя искусственно увеличить при помощи правильных трюков. Считайте ее барометром качества работы и рабочей среды. Если мотивация сотрудников снижается, возможно, работа плохо определена, или кажется им бессмысленной, или остальные члены команды используются в качестве инструментов.
Если вы работаете удаленно и вдруг заметили, что на выполнение дневного объема работы уходит неделя, у вас должна «загораться красная лампочка»: с этим нужно что-то делать. И чем быстрее вы отреагируете, тем лучше.
Но так бывает нечасто. Большинство страдающих от низкой мотивации людей в первую очередь обвинят себя: «Эх, что же я такой размазня? Почему я не могу просто собраться?» Но чаще всего истина заключается в том, что проблема — не в вас, а в обстановке на работе.
Если это так, остается самое трудное: не заставлять себя трудиться, а набраться смелости, громко заявить о проблеме, изменить обстановку и добиться того, чтобы работа снова начала вас мотивировать.
Предположим, что вы как руководитель обратили внимание на одного из подчиненных, который утратил интерес к работе. Срочно планируйте разговор один на один и выясняйте, в чем дело. Может, ему наскучил слишком простой для него проект? Или, наоборот, он чувствует, что уперся в стену, и тянет время, поскольку ситуация кажется ему неразрешимой? Подумайте, что можно сделать для возвращения сотрудника на путь истинный. Проблемы могут быть как организационными, так и личными. Определить это нелегко, особенно если не работаешь с человеком в одном офисе. Иногда для того, чтобы вернуть сотруднику былую эффективность, достаточно отправить его в отпуск на пару недель.
Мотивация — ключевой фактор здоровой жизни и здорового бизнеса. Никогда не забывайте об этом.

Про стратегическое угадывание. Стратегируй и выкидывай на помойку!

Планирование — это не более чем догадки
Если вы не предсказатель, то долгосрочное бизнес-планирование будет для вас не более чем фантазией. Существует слишком много факторов, на которые вы не можете влиять: рыночные условия, конкуренты, клиенты, состояние экономики и т.д. Написание плана позволяет вам якобы ощутить контроль над вещами, над которыми вы на самом деле не властны.
Почему бы нам тогда ...не назвать планы тем, чем они на самом деле являются, а именно догадками? Переименуйте ваши бизнес-планы в бизнес-догадки, финансовые планы в финансовые догадки, а стратегическое планирование — в стратегическое угадывание. Теперь вы можете перестать так о них волноваться. Они просто не стоят этого стресса.
Превращая догадки в планы, вы вступаете на опасную территорию. Планы позволяют прошлому управлять будущим. Они надевают на вас шоры. «Мы идем этим путем, потому что мы сказали, что пойдем этим путем». И в этом заключается проблема: планы несовместимы с импровизацией.
А у вас должна быть возможность импровизировать. У вас должна быть возможность воспользоваться шансами, которые выпадут на вашу долю. Иногда вам нужно сказать: «Мы пойдем в новом направлении, потому что сегодня это имеет смысл».
Установка сроков в долгосрочных планах — тоже полная ерунда. Вы обладаете наиболее полной информацией, когда вы уже что-то делаете, а не до того, как вы начали это делать. Однако планы вы составляете обычно до того, как начинаете дело. Это худшее время для принятия глобальных решений.
Мы говорим это не для того, чтобы вы вообще не думали о будущем и о том, как намерены преодолевать препятствия, которые встретятся вам на пути. Это полезное занятие. Просто не надо зацикливаться на этих мыслях. Велика вероятность, что, составив более чем 20-страничный план, вы им так и не воспользуетесь, и он в итоге осядет древним ископаемым в вашем архиве.
Перестаньте тратить время на построение догадок. Решите, что вы собираетесь делать на этой неделе, а не в этом году. Определите очередную наиболее важную задачу и займитесь ею. Принимайте решения непосредственно перед тем, как начать действовать, а не задолго до этого.
Действовать по обстоятельствам — это нормально. Просто сядьте в самолет и взлетайте. Симпатичную рубашку, крем для бритья и зубную щетку можно купить, уже добравшись до места.
Перспектива работать без плана может показаться пугающей. Но слепое следование плану, не имеющему ничего общего с реальностью, должно пугать еще больше.
Rework

Про мифы достигательства и больших целей (мельчите, мельчите во всем)

Ничего не записывайте
Как лучше следить за тем, чего хотят ваши клиенты? Никак. Слушайте их, но затем забудьте то, что услышали. Мы не шутим, а говорим вполне серьезно.
Вам нет необходимости вести таблицы, базы данных или системы учета. Запросы, которые действительно важны, будут повторяться снова и снова. Через какое-то время вы просто не сможете забыть про них. Ваши клиенты станут вашей памятью. Они ясно дадут вам понять, о каких вещах действительно стоит волноваться.
Вы забыли про какую-то просьбу? Это значит, что она не так важна. Действительно важное просто так не исчезает.

Принимайте маленькие решения
Большие решения трудно принимать и изменять. Однажды приняв такое решение, вы, вероятно, будете продолжать верить в его правильность, даже если это не так. Вы перестанете быть объективным.
Вы не можете передумать, не поступившись своим эго и гордыней. Желание сохранить лицо преобладает над желанием сделать правильный выбор. А затем в дело вступает инерция: чем больше усилий вы вкладываете в одно направление, тем тяжелее затем будет сменить курс. Вместо этого принимайте решение за решением, но пусть они будут небольшими и, по сути, временными. Принимая крошечные решения, невозможно совершить большие ошибки. В небольшие решения легче внести изменения. Не будет большого вреда, если вы и ошибетесь. Вы просто все исправите.
Небольшие решения не означают невозможности вынашивать большие идеи и строить большие планы. Они просто означают вашу веру в то, что лучший путь достичь больших целей — принимать за раз по одному крошечному решению. Главная проблема амбициозных целей и великих свершений в том, что они убивают мотивацию. Они закладывают в вас установку на провал.
Полярный исследователь Бен Сондерс рассказывал, что во время его одиночной экспедиции к Северному полюсу (31 марафонская дистанция, 72 дня в одиночестве) гнет «огромной задачи» был настолько невыносим, что повседневные цели редко выходили за рамки «добраться до глыбы льда в нескольких ярдах впереди».
Лучше всего иметь как раз такие достижимые цели. Те, которых вы в состоянии достичь, и затем полагаться на их результаты. Вы должны сказать: «Мы закончили это. Сделано!», а затем продолжить движение к следующей цели. Такая тактика дает гораздо больше удовлетворения, чем несбыточная воображаемая цель, которой вы никогда не достигнете.

Не буду больше цитировать, читайте Rework и Remote, они прекрасны.

Тексты - ключ к победе

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

Для любителей переработок

Отправляйте людей домой в 17 часов
Сотрудник мечты для многих компаний — это кто-то двадцати с лишним лет от роду, проводящий как можно меньше времени вне работы, кто-то, кто чувствует себя прекрасно, работая по 14 часов в сутки и засыпая под рабочим столом.
Набивать комнату ребятами, склонными к работе за полночь, не такой уж удачный ход, как кажется на первый взгляд. Это всего лишь попытка как-т...о оправдать в своих глазах отвратительное качество исполнения. Не верьте тем, кто увековечил миф: «Такие сотрудники для нас — единственный способ тягаться с большими компаниями». Дело не в количестве часов, проведенных за рабочим столом, а в продуктивности этих часов.
Сотрудники, которым надо побыстрее освободиться (допустим, им нужно забрать детей или присутствовать на репетиции хора), вынуждены искать способы быть более эффективными, поэтому они мудро используют свое время.
Есть такая поговорка: «Если вы хотите, чтобы что-то было сделано, поручите выполнение самому занятому человеку». Вам нужны занятые люди. Люди, у которых достаточно других забот после работы. Если вы хотите работать с человеком долгое время, не нужно рассчитывать на то, что работа будет полностью занимать его жизнь.

Разное

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

Описка по Фрейду - жрунал проекта. Прямо-таки псевдоним статьи расходов на персонал

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

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

Нужно по капле выдавливать из себя лайк

Табурет (ж. табуретка) - высокопоставленный чиновник, выступающий за всевозможные запреты.
Напр., "Известная табуретка Елена Мизулина выступила против таблицы умножения и шелковых носков".

It’s hard to explain puns to kleptomaniacs because they always take things literally.

Тщательно подбирал слова, кем-то брошенные на ветер.
...
Диалог в австралийском аэропорту. Таможенник, проверяя документы:
- Судимости есть?
Гражданин Великобритании:
- Это все еще необходимо для въезда в страну?

В этом году, в отличие от всех предыдущих новых годов, начну жить по-старому. Пора что-то менять.

"Как говорил мой двоюродный брат из Тбилиси, у узбекского плова только один, но существенный недостаток — он не блюдо грузинской кухни".

Нужно по капле выдавливать из себя лайк.

В человеке всё должно быть прекрасно: и селфи, и френды, и статус, и комменты.

В СССР, помнится, смотрели мы трофейный фильм С. Кубрика "The Shining". Озвучивал незабываемый гнусавый голос, часто улучшающий оригинал. По сюжету мальчик Дэнни в состоянии транса ходит с кухонным ножом и много раз произносит слово REDRUM, т.е. murder (т.е. "убийство") наоборот, а потом губной помадой пишет это страшное слово на зеркале. Переводчик аккуратно перевел, и мальчик неустанно повторял: "Овц йибу, овц йибу...". И нам было куда жутчее, чем англоязычным зрителям.

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

Заказали свадебный тост. Решил начать с притчи.
«Одна супружеская пара дожила до бриллиантовой свадьбы. И все прожитые годы супруги были счастливы. И когда у них спросили, в чем секрет такого долгого счастья, они в один голос ответили: «Так и не удалось найти никого поприличнее".

Any competent copy editor can turn a passage that is turgid, opaque, and filled with grammatical errors into a passage that is turgid, opaque, and free of grammatical errors.

"На комете Чурюмова-Герасименко обнаружен кислород".
А вы говорите Урюпинск. Всюду люди живут.

"Так и прожил всю жизнь с ощущением, что она вот-вот начнется".

Хотел расписаться в собственном бессилии, и не сумел.

Рано или поздно человек понимает, что роскоши терять время у него больше нет, и пора его тратить.

Коты подобны Паганини. Если бы звуки вашей речи были ограничены одним словом, какое бы выбрали? Многие, вне сомнений, возьмут "дискурс". Сам пока в затруднении. При наличии возлюбленной можно ограничиться ее именем. Но все равно будешь на нервы действовать. Лена да Лена.

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

Читаю RFP от вендоров по одному проекту. Есть решения on premise, есть Cloud/SaaS. И пришла в голову аналогия, что если on premise соответствуют банковскому депозиту с хеджирующим фьючерсом (что-то есть сейчас - депозит, возможность масштабирования - фьючерс), то Cloud - это опцион, а может даже и CDS. Нельзя же проверить, что всем клиентам хватит серверных мощностей дата-центра облачного решения, это какая-то матмодель, обеспечивающая расчетный уровень SLA с заданной вероятностью на доверительном интервале (т.е., вероятность дефолта, и чем ниже вероятность дефолта/downtime хочет клиент, тем больше он платит за облачное решение).

ТОС за 90 секунд

Менеджер с трекером наперевес

Я знаю, вы любите эту книгу. Я - нет.

Прочел
http://www.mann-ivanov-ferber.ru/books/paperbook/tattoos/
Что могу сказать - на самом деле, в этой книге выражена суть идеального российского менеджмента в вакууме. Тут тебе и увольнение отдела как способ управления организационными изменениями, и идея "подчиненные ведут себя так, как себя ведет руководитель" (теория мотивации Y), и использование авторитарного стиля менеджмента (6 стилей -... слишком много, понимаю). Вспоминая классическую американскую модель организации "ствол-ветки-листья", и сравнивая ее с 45 lessons learned этого культового российского топ-менеджера, я понимаю, что в классическом российском бизнесе стволом является только основатель, ветками - топ-менеджмент и среднее звено, а все что ниже, автоматом является только листьями. Для РП, обдумывающего житие, книга является великолепным пособием по пониманию внутреннего мира спонсора его проекта.

Про мои впечатления от постановки практики ПУ в госорганах РФ

Происходящее в бизнес-мире и в правительстве России вообще напоминает криптоисторический роман о том, как современная бизнес-библиотека попала в петровскую империю. Прочел, значит, Меньшиков Друкера и пошел применять его на строительстве линий на ВО. Коммерц-коллегия проектный офис запускает по Керцнеру с учетом рекомендаций PMI, для строительства Санкт-Петербурга.
А большинство помещиков порют крепостных на заднем дворе, хотя по-французски и разговаривают (т.е. читают и даже разговор могут поддержать об Адизесе, Голдратте и т.д.) Но "у России особый путь", и никакой Могун-Панеях-Рогов-Шульман со всеми исследованиями никого из боссов ни в чем не переубедит.

На вопрос "что ты куришь?" надо отвечать "на так важно, что, главное - сколько".


Управление жизненным циклом в CDC. Задача по переводу и адаптации стоит в плане работ.


Хороший образец оформления методологии:
http://www2a.cdc.gov/cdcup/library/matrix/default.htm
http://www2a.cdc.gov/cdcup/library/templates/default.htm
http://www2.cdc.gov/cdcup/library/checklists/default.htm

Очень компактно и понятно.

Основы невозможно перерасти

http://www.mann-ivanov-ferber.ru/books/paperbook/theeffectiveexecutive/

Классика не случайно стала классикой. Эту книгу можно растаскивать на цитаты:
"... эффективность в работе – это привычка. Комплекс определенных практических методик. И эти методики можно изучить и усвоить. Они просты, но просты обманчиво; даже семилетний ребенок без труда поймет, что он него требуется. Но выполнять эти правила довольно сложно. Им нужно учиться, как мы заучиваем таблицу умножения, – то есть повторять, что называется, до отвращения, до тех пор, пока они не превратятся в условный рефлекс, в глубоко укоренившуюся привычку. А чтобы они вошли в привычку, необходима практика, практика и еще раз практика."
"1. Эффективные руководители знают, на что расходуется их время. Они систематически трудятся над управлением той малой долей своего времени, которую они действительно могут контролировать.
2. Эффективные руководители концентрируются на достижениях, выходящих за рамки их организаций. Они нацелены не на выполнение работы как таковой, а на конечный результат. Прежде чем приступить к выполнению того или иного задания, эффективный руководитель задает себе вопрос: «Каких результатов от меня ожидают?» Сам процесс работы, не говоря уже о конкретных методах ее выполнения, отходит для него на второй план.
3. Эффективные руководители развивают сильные стороны – свои собственные, своих начальников, коллег, подчиненных. В сложных ситуациях они полагаются именно на сильные стороны и не зацикливаются на слабых. Они не начинают с задач, которые не в состоянии решить.
4. Эффективные руководители сосредотачиваются на нескольких крупнейших областях, где отличная работа приведет к выдающимся результатам. Они заставляют себя определять приоритеты и не отступать от принятых решений. Они знают, что у них нет иного выбора, кроме как вначале заняться делами первостепенной важности, второстепенными же не заниматься никогда. Иначе не будет сделано ничего.
5. Наконец, эффективно работающие руководители принимают эффективные решения. Они знают, что правильные решения – это не что иное, как система, – ряд правильных шагов в правильной последовательности. Они знают, что эффективное решение – это всегда суждение, основанное на «несовпадении мнений», а не на «консенсусе в отношении фактов». И им известно, что быстро принятое решение – это ошибочное решение. Решений должно быть немного, но фундаментальных. Необходима правильная стратегия, а не изобретательные приемы."

Опыт - это не то, что происходит с вами, это то, что вы делаете с тем, что происходит с вами.


Поэтому я позвонил Одноминутному Менеджеру. Когда он снял трубку, я сказал:
- Сэр, у меня проблема.
Прежде чем я успел произнести еще хоть одно слово, он произнес:
- Это хорошо! Ведь для решения проблем вас и наняли. – И на другом конце провода наступила гробовая тишина.
Я не знал, что делать. Молчание казалось мне оглушительным. Наконец, я выдавил из себя:
- Но, сэр, я не знаю, как решить проблем...у.
- Тренель, - сказал он, - одна из ваших задач – самому определять и решать свои проблемы. Но поскольку вы новичок, зайдите – поговорим. Когда я зашел к нему, он сказал:
- Расскажите, в чем ваша проблема, - но только в поведенческих терминах.
- В поведенческих терминах? – переспросил я. – Что вы имеете в виду?
- Я имею в виду, - пояснил менеджер, - что я не хочу слушать об одних только установках и чувствах. Изложите происходящее в осязаемых, измеримых терминах.
Я постарался описать проблему наилучшим образом.
Он сказал:
- Отлично, Тренель! Теперь расскажите мне, что вы хотите, чтобы произошло – опять же в поведенческих терминах.
- Я не знаю, - сказал я.
- Тогда не отнимайте у меня времени, - отрезал он.
Я в изумлении застыл, не зная, что предпринять. Он милостиво нарушил молчание.
- Если вы не можете сказать, что вы хотите, чтобы произошло, - сказал он, - у вас еще нет проблемы. Вы просто жалуетесь. Проблема существует только тогда, когда есть разница между тем, что фактически происходит, и тем, что вы хотите, чтобы происходило.

Хочешь делигировать и спать спокойно - учи и развивай персонал

Есть такие классные проекты, когда дела идут правильно (почти) безо всякого вмешательства со стороны руководителя. Ситуация похожа на самолет, который набрал плановую высоту и на крейсерской скорости идет по курсу на автопилоте. Но для того, чтобы он так летел, нужно:
а) Вывести его из ангара
б) Заправить, проверить состояние и т.п.
в) Загрузить пассажирами, вырулить на ВПП
г) Взлететь, набрать в...ысоту
Другими словами, правильно запустить проект и потом уже наслаждаться полетом. А то у многих пилотов посредине полета ситуация "капитан вбегает в салон самолета и кричит "нет ли у кого 30 тонн керосина".
Как стать капитаном такого самолета? Нужно начать делегировать полномочия. Но вы ведь не в кокпит стюарда не посадишь (разве что вас зовут Ричард Бренсон)? Значит надо научить персонал работать самостоятельно. Цель любого бизнес-обучения - достижение возможности делегировать полномочия. Остальное все шелуха, что бы не было написано в положении о подразделении отдел обучения и развития персонала.
Что же конкретно должно произойти, прежде чем появится возможность для делегирования полномочий? Менеджеры не должны, да и не могут делегировать полномочия, пока не будут достаточно уверены, что, во-первых, проект развивается в правильном направлении и, во-вторых, их подчиненные вполне могут справиться с проектом самостоятельно. Менеджеры, которые передают своим подчиненным полную ответственность за проект без такой уверенности, не делегируют полномочия - они просто уклоняются от ответственности.
Ясно, что некоторые проекты могут быть делегированы изначально, когда менеджеру с самого начала понятно, как они должны вестись, и что его подчиненные способны успешно справиться с этим проектом.
Однако, в большинстве случаев проект оказывается настолько сложным, что осуществление нельзя сразу передоверить подчиненным, поскольку зачастую ни сам менеджер, ни его подчиненные поначалу не обладают достаточным пониманием проблем, целей и возможных осложнений, не знают порой даже, как подступиться к проекту, не говоря уже о том, чтобы предугадать, что тот или иной человек успешно справиться с работой.
Таким образом, большинство проектов требует некоторого периода обучения, пока начальник не убедится, что он может делегировать свою ответственность.
Ясно, что сотрудники должны играть важную роль в процессе обретения начальником уверенности в возможности делегирования. Менеджер вообще не вправе делегировать свои полномочия, пока его сотрудники не продемонстрируют каким-то образом, что они способны управлять проектом самостоятельно.
Кроме того, поскольку специалисты о своей работе обычно знают больше, чем их начальство, во многих случаях они должны убедить своего босса в том, как следует вести данный проект. Это заставляет сотрудников проявлять ответственность за обучение и делегирование наравне с начальством!

Если вы всегда согласны со своим начальником, один из вас лишний.

I Know You Know!
coub.com


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

Управление кризисными проектами, пошаговое руководство для профессионалов


Rescuing a project in crisis
projectperfect.com.au

Часть 1. Стоит оно того?

На определенном этапе большинство руководителей проектов получают предложение войти в кризисный проект. Вас попросят спасти провальный проект или восстановить проект, столкнувшийся с серьезными проблемами. Ваша роль может заключаться в диагностике здоровья проекта, но вы можете и возглавить попытку спасения. Эта статья состоит из трех част...ей и в ней обсуждаются некоторые вопросы, подлежащие рассмотрению перед стартом, порядок проведения диагностики и мероприятия по восстановлению.
Перед началом необходимо выяснить, какие у вас полномочия. Они могут варьироваться от ревизии и отчета до "разобраться с проблемой, пленных не брать".
Множество попыток спасения оканчивается неудачей из-за того, что в начале нет четкого понимания ожиданий. И даже хуже того - ожидания смешаны. Чтобы проиллюстрировать данный пункт, давайте рассмотрим более конкретный пример. Помощь при стихийных бедствиях может быть совершенно неэффективна, когда несколько организаций и служб пытаются делать оди и те же вещи, либо не четко определены зоны ответственности. Образцом для организации помощи при стихийных бедствиях является центральная европейская служба, объединяющая различные агентства, в обязанности которой входит определение плана действий и назначения ответственных агентств, наилучшим образом оснащенных для выполнения поставленных задач.
Если вас попросили войти в проект, вам должно быть понятно, чего от вас ждут. Эти ожидания должны быть документированы и согласованы со спонсором или другим ответственным лицом. Этот документ должен быть доступен всем заинтересованным лицам, чтобы все понимали вашу роль и что вы собираетесь делать.

Содержание мандата (документа описывающего полномочия)

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

Следующие шаги

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

Влияние на карьеру

Проведение такой ревизии может иметь цену - как эмоциональную, так и для карьеры. Несколько дет назад ко мне обратился клиент, с которым у меня был бизнес ранее, меня попросили провести ревизию одного проекта. Вскрывшиеся факты были были очень критичными по многим аспектам деятельности компании, включая руководителя проекта и поддержки, которую он получал от топ-менеджмента. Результаты ревизии никто не оспаривал, но они, тем не менее, были болезненными для множества людей, которые надеялись на то, что факты будут заметены под ковер. К их сожалению, я не прислушался. Результат - они ко мне больше не звонили.
Сожалею ли я об этом? Не особо. Я начинал ревизию с пониманием того, что результат может быть нелицеприятным и что есть риск быть гонцом с плохими новостями с очевидными последствиями. По крайней мере я могу сказать, что этот отчет - это мое честное мнение о данной организации. В частности, я не хочу писать отчет, перемещающий вину с неспособности участников управлять проектом на мою неспособность анализировать ситуацию. Подлоги имеют тенденцию возвращаться к вам бумерангом по прошествии времени.
Часто организации ищут козла отпущения. Минимум. на который они рассчитывают, это найти человека, которого можно обвинить в текущих проблемах и зачастую это стрелочник, а не истинный виновник.

Эмоциональный ущерб

Я упоминул эмоциональный ущерб. Если ваши близкие друзья связаны с проектом, и окажется, что они виноваты в какой-либо оплошности? Готовы ли вы рискнуть вашей дружбой ради правды? В самом начале моей карьеры я работал в одной организации, и там проходила ревизия работы подразделения. В отчете на десятки страниц была одна строка, которая стала точкой в карьере одного руководителя. Проводивший ревизию человек был близким другом руководитея подразделения. Он, наверное, боролся с собой оставить или нет эту строку в отчете на протяжении нескольких дней. Фраза была примерно такой: "Реализованные мероприятия не соответствовали утвежденному годовому плану из-за недостаточного управленческого надзора за деятельностью отдела".
Руководитель подразделения был перемещен на должность с примерно таким же названием, но по значимости даже близко не стоящей к предыдущей. Это было во времена, когда увольнения по сокращению штатов было последней мерой, а не частью нормального бизнес-цикла. С точки зрения корпорации это, возможно, было правильным решением, но эти двое никогда больше не разговаривали.

Стиль управления

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

Необходимые навыки

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

Навыки управления проектами

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

Навыки проведения интервью

Если что-то пошло не так, то скорее всего, кто-то захочет это скрыть. Еще более вероятно, что некоторые вопросы люди захотят пропустить мимо ушей и уж тем более не захотят на них отвечать. Ревизор должен быть искусен в извлечении информации и уметь проводить перекрестные проверки. Вот некоторые примеры вопросов, которые вы, возможно, захотите добавить в свой репертуар.
Это мнение или факт?
Как это можно подтвердить?
Какая документация необходима для понимания проекта?
Кто хорошо работал в проекте? Вы ничего не сказали про...
Когда вы впервые подумали, что проект срывается?
Какие значительные трудности были между проектом и бизнесом?
Насколько заинтересован был ... в проекте в самом его начале?
Сильно ли менялся результат/содержание/сроки?
Что надо было бы делать по другому?
Что нужно сделать для воскрешения проекта?
Уверен ли спонсор/управляющий комитет/руководитель проекта в большинстве людей?
Что изменилось в окружении с начала проекта?
Нужно ли прекратить проект?

Навыки ведения бизнеса

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

Навыки письма

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

Смелость

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

Заключение

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

Часть 2. Подготовка

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

Содержание было хорошо определено на старте проекта?
Есть ли процесс по изменению содержания? Is there a scope variation process in place?
Есть ли отклонения, не прошедшие через этот процесс?
Может ли команда определить суммарное влияние на сроки и стоимость по всем таким отклонениям?
Отслеживается ли факт против плана/оценок для отклонений?
Был ли план проекта изменен, чтобы снабдить проект необходимыми ресурсами для реализации изменений?

Стоимость

Есть ли система отслеживания затрат?
Отслеживаются ли затраты?
Есть ли затраты, которые отслеживаются неправильно?
Вовремя ли отслеживаются затраты?
Сверяются ли затраты с корпоративны планом счетов?
Есть ли прогнозы по стоимости проекта на момент его завершения?
Все отклонения по стоимости одобрены в письменном виде?

Сроки

Есть ли достаточно подробное расписание проекта?
Оно актуальное?
Оно соответствует текущему содержанию проекта?
Используются ли контрольные точки для отслеживания хода реализации?
Достаточное ли количество контрольных точек по ходу проекта для отслеживания проекта или в расписании есть недели, когда контроль отсутствует?
Отслеживаются ли трудозатраты через систему табелирования/таймшиттинга?
Существует ли устойчивый и реалистичный план для оставшейся работы?

Качество

Есть ли план управления качеством?
Предметы поставки принимаются согласно плану по качеству?
Какие действия происходят после аудита качества и отслеживается ли их выполнение?
План проекта предусматривает время на переработку и устранение дефектов по результатам аудита качества?
План приемки и тестирования реалистичен (есть стратегия тестирования, план и тестовые кейсы)?
Правильные ли люди выделены для проведения тестирования и приемки?
Тестирование и приемка включает в себя систему, ее характеристики и интерфейсы?

Ресурсы

Ресурсов достаточно?
Они правильные?
Они в состоянии работать над проектом достаточное время?
Есть ли чувство хорошего взаимодействия в проекте?
Команда управляется хорошо?
Ресурсы используются эффективно?
Хороший ли рабочий настрой в команде проекта?

Коммуникация

Есть ли план по коммуникациям?
Он реализуется?
Как определялись ключевые стейкхолдеры?
Все ли ключевые стейкхолдеры определены?
Чувствуют ли стейкхолдеры, что их держат в курсе?
Есть ли общие области в коммуникации, которые вызывают опасения?
Приведет ли проект к изменениям в организации и есть ли план по управлению ожиданиями?
План реализуется и ожидания отслеживаются?

Закупки

Используются ли внешние ресурсы?
Есть ли актуальные договоры, по которым работают внешние ресурсы, до завершения проекта?
Есть ли план по использованию этих ресурсов после окончания плановой длительности проекта, в случае необходимости?
Требует ли проект закупки оборудования, установок, программного обеспечения, и если да, то есть ли план по проведению переговоров по договору?
Уровни и полномочия по согласованию договоров и сроки подписания понятны и включены в план проекта?

Риски

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

Сдерживающие мероприятия

Есть ли план по сдерживанию последствий, если реализация не укладывается в сроки?
План сдерживания подписан всеми заинтересованными сторонами?
План испытан?
Последствия реализации сдерживающих мероприятий понятны руководству?
Какие сроки по реализации плана сдерживающих мероприятий?
В течение какого срока будет действовать план сдерживания? Что случися потом?

Эффекты

Какие эффекты были определены на старте проекта?
Они пересматрвиались недавно?
Они все еще актуальны?
Были ли идентифицированы новые эффекты и включены ли они в результат проекта?
Измеряются ли и будут ли измеряться эффекты?
Определены ли ответственные за реализацию и использование эффектов?

Бизнес-процессы

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

Обучение

Есть ли план обучения?
Заложено ли время на производство обучающих материалов?
Тренеры определены?
Персонал будет доступен для обучения?
Есть ли план проведения пилотного обучения?

Реализация

Есть ли план реализации проекта по месту (предполагая, что проект идет по плану)?
Поддержка будет оказываться во время и после запуска?
Кто даст разрешение на ‘go live’?
Есть ли критери ‘go live’?
Если реализация подразумевает преобразование данных, известно ли состояние этих данных?
Требуют ли данные работы с ними и был ли этот процесс протестирован?

Подотчетность

Определены ли контрольные точки, в которых управляющая группа определит, соответствует корпоративным стандартам? Конечно, диагностика является такой точкой, но обычно проект должен пройти один или несколько гейтов, в которых должны быть выполнены определенные критерии.
У команды преокта есть все необходимые инструменты, навыки и процессы для успешной реализации проекта?
Кто отслеживает compliance (соответствие внутренним корпоративным нормам, регламентам, этике и т.п.)?
Если у моапнии есть методология, придерживается ли ее команда проекта?

Роли и ответственность

Четко ли обозначены зоны ответственности?
Достаточно ли точно они отражают то, что происходит по факту?
Бизнес обеспечивает необходимый уровень поддержки?
Достаточный ли уровень поддержки оказывает руководство?
Есть ли какие-то участки работы, которые не описаны в ролях и ответственности?

Документация

Хранится ли вся дкоументация по проекту в централизованном хранилище?
Хорошо ли организовано хранилище и легко ли найти необходимый документ?
Наличиствует ли корректная система контроля версий?
Основные документы обычно хорошо составлены?
Повестка и протоколы ключевых собраний ведутся и хранятся?
Ключевые решения подписаны уполномоченными лицами?
Есть ли словарь/глоссарий проекта?
Есть ли реестр принятых решений?

Требования

Требования хоршо документированы?
Есть ли система отслеживания требований и их изменений?
Предметы поставки соответствуют документации по требованиям или преображаются в ходе разработки?
Документируются ли причины и утверждающие лица при изменении требований?

В заключение

Есть и другие области, которые необходимо будет рассматривать, и этот список, в большинстве случаев, покрывает, наверное, от 70 до 80%.

Часть 3. Спасти рядового Райана

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

Кто тут главный?
Первая вещь, с которой необходимо разобраться, это то, кто руководит проектом. Мы не ищем менеджера проекта, а скорее спонсора.
Человека, который подписывает договора.
Человека, который может остановить проект, если это потребуется.
Как-то я разговаривал с консультантом, который выполнял работу для большой политической партии и разрабатывал рекомендации по тому, как ее лучше организовать. Большое количество финансовых доноров были обеспокоены тем, что текущая организационная структура является причиной потери популярности. Он ответил донорам, что приняться за работу только в том случае, если это будет с согласия первого лица партии. И он говорил не про человек с должностью, наиболее близкой к этому описанию, а о том, кто реально держал бразды правления.
На эту роль подходило несколько кандидатов. Одним из них был премьер-министр. Глава партии был другим. Была еще пара очень влиятельных спонсоров, которых тоже стоило рассматривать. Как и в большинстве партий, в этой были и финансисты, которые обладали невероятным влиянием на то, как партия управлялась. Они знали, в каких шкафах лежали скелеты и разные деликатные подробности того, как они там очутились.
Он искал, кто же, по общему мнению, был тем, кто рулил и жал на газ. Он летал по всей стране на партийные собрания с функционерами и со всеми перечисленными выше лицами и пытался достичь соглашения. После двух лет поисков он так и не приблизился к пониманию и отказался от предложения. Он сказал: "Если мы не можем договориться, кто же ведет это представление, как вообще можно задумываться о его реорганизации?"
Вам нужно определить, кто в проекте дергает за веревочки, даже если некоторые из них и обветшали. Обычная тактика в таких случаях - показать на комиссию. Мой ответ в таких случаях - а кто отвечает за комиссию? Кто председатель? Кто утверждает решения? Кто может отменить решение большинства? Вы должны найти этого человека.

Содержание проекта

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

Решение проблем с содрежанием

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

Ожидания и реальность

В тоже самое время вы можете начать записывать что люди ожидают и какова реальность. Цель этого упражнения - это определение различий в восприятии различных людей, попадающих в сферу влияния проекта.
Вот пример:

Кто владелец Клиентский отдел
Ожидание Проект завершится к Августу
Реальность Проект будет идти до конца года
"Д. Смит.; система будет обрабатывать возвраты; будут обрабатываться возвраты только для клиентов категории А"
"Команда проекта; бизнес-пользователи будут доступны минимум 3 дня в неделю; бизнес-пользователи доступны крайне редко"
Цель создания этого списка - свести вместе все невыполненные ожидания, которые и создали ощущение, что проект находится в кризисе. Возможно, проект и не в кризисе. При правильном управлении ожиданиями люди могут быть удовлетворены направлением движения и результатом.

Решение проблем

Есть искушение решать проблемы по мере их выявления. Это скользкая дорожка, ведущая к зыбучим пескам. Даже спастельные миссии могут провалиться, если их затянуть. Определите проблемы, но тратьте времени на их решение. Очевидные пути решения часто слишком примитивные и никогда не работают. Как только вы начнете реализовывать простые решения, вы погрязнете в технических деталях, которые окажутся под водой.
Во время одной спасательной операции с самого начала было понятно, что наибольшей проблемой было непринятие 15-20 основных решений, которые должны были быть приняты. Значительное количество работ по проекту стояли в ожидании принятия этих решений. Большинство из них касалось достаточно сложных проблем и ситуаций, но все-таки некоторые из них стали жертвой неправильной расстановки приоритетов. Люди тратили все свое время на решение сложных и больших проблем, не уделяя малым никакого внимания. Было искушение выделить время на решение этих малых проблем проблем во время ревизии. К счастью, я устоял против этого искушения и быстро завершил анализ.
Моя рекомендация была остановить проект на неделю-другую и провести серию рабочих совещаний, на которых бы присутствовали главные лица, принимающие решения, и где были бы решены все найденные на данный момент вопросы. Рабочие совещания проводились по принципу суда присяжных - никто не имел права выйти с совещания, пока решение не было принято. Конечно, это привело к тому, что топ-менеджмент посвятил проекту все свое время на несколько дней. Это имело свое воздействие на скорость принятия решений.
Для принятия некоторых решений потребовалось менее часа, но одно заняло более двух дней. Никто не покидал совещания по распоряжению генерального директора, который сказал сидеть до последнего. Внедрение ERP зачастую требует такого от компании. Смысл моего рассказа в том, что не пытайтесь решить все проблемы с первого раза. Соберите факты как можно скорее, затем ищите решения. Помните, что люди ждут, пока вы не построите им курс. Чем дольше они ждут, тем болше вероятность, что они откажутся следовать вашим рекомендациям.
При поиске проблем используйте чек-листы и вопросы из первых двух частей статьи. Аспекты бизнеса и технические моменты будут различаться от проекта к проекту. Например, при ремонте здания, вопросы будут касаться строительных материалов, доступа в здание, архитектурых чертежей, одоюрений юристов и т.п. При происзводстве программного обеспечения, вопросы бизнеса могут касаться юридических моментов, бизнес-процессов, маркетинга, а технические аспекты относиться к безопасности, хранению данных и апгрейду оборудования. Вам нужно создать свой чек-лист для каждого из проектов.

Игра "Кто сидеть будет?"

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

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

После определения содержания

После того, как вы определили содержание, нужно обратит ьсвое внимание на план и ресурсы. Какие ресурсы есть в наличии, и на какие ресурсы еще надо получить одобрение? На этой стадии полезно сделать несколько сценариев. Например, с двумя людьми, которые есть сейчас, рабта будет завершена за три месяца, если добавить еще один ресурс, можно справиться за два.
Как только план готов, можно оценить его стоимость. Если было разработано несколько планов, надо обсчитать их все. Вернитесь к начальному бюджету и проанализируйте расхождения по статьям расходов. На этом шаге более вероятно, что вы сможете протолкнуть идею управленческих резервов. Например, предположим, что в проекте было изначально заложено 20 тыс. долларов на тестирование программного обеспечения, но оно оказалось намного сложнее, чем ожидали, и тестирование вызвало задержку. Вы можете заложить в бюджет 25 тыс. и добавить 10 тыс. управленческого резерва, т.к. у вас нет понимания сложности задачи. И до тех пор, пока вы не поймете задачу полностью, вы не сможете оценить затраты на нее. Обжегшись один раз, организации обычно более консервативной подходят к оценке предстоящих затрат.

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

Эффекты

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

Черновик отчета

К этому моменту у вас должен быть:

Идентифицирован ключевой игрок. Человек, который принимает решения или по крайней мере, дает рекомендации исполнительному комитету либо совету директоров.
Понимание содержания проекта – начальное и текущее, согласованное участниками.
Список ожиданий и реальности и различия между этими двумя
Определены основные проблемы и открытые вопросы, мешающие ходу проекта
Определены роли и ответственность, необходимые для продолжения проекта
Один или несколько рабочих планов для завершения проекта
Новый расчет затрат и эффектов
Теперь вы можете давать рекомендации. Никогда не сбрасывайте со счетов варианты «ничего не делать» и «отменить». Иногда вы обнаружите, что настоящей проблемой является различия между тем, что люди верят, должно произойти и тем, что на самом деле должно произойти. Если проблема в том, что все ожидают завершения проекта за 6 месяцев, в то время, как он будет идти еще 12, то решением может быть смириться с 12 месяцами. Проблема в том, что делать с ожиданиями по 6 месяцам. Проект может идти как идет, но нужно провести коммуникацию, которая объяснит почему проект займет в два раза больше, чем было запланировано.
И точно также, не стоит оставлять в живых проект только из-за того, что люди с ним эмоционально связаны. Играйте в адвоката дьявола, спрашивайте людей: «Почему нужно продолжать проект?»
Если не найдется хорошей, ориентированной на бизнес, причины, то выдвигайте рекомендацию с отменой. Даже в стадии рекомендации вариант «отменить проект» может быть приемлем и должен рассматриваться. Реальность многих организаций такова, что никто не хочет принимать сложное решение. Если среди вариантов, которые вы предложите, будут только варианты с продолжением проекта, люди, которые думают, что проект надо отменить, будут бояться что-нибудь говорить, т.к. они могут подумать, что это отразится на их карьере. Ваша задача – обсудить все возможные варианты.

После принятия решения

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

«Билл покидает нас, потому что у него не хватает навыков для управления проектом. Да и вообще, Билл херовый проектный менеджер и поэтому его и увольняют».

Или

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

Другой фактор, требующий рассмотрения, это рабочий настрой команды. Когда в проект приходят аудиторы, то вполне вероятно, что мораль команды будет невысокой и даже могут образоваться фракции. Есть много способов решения проблем с рабочим настроем, но мой любимый способ – это дать понять, что командой слишком долго пренебрегали и теперь руководство признало важность происходящего. Обычно я объясняю лицам, принимающим решения, что они руководители и сейчас правильный момент, чтобы начать руководить. Это означает, что они должны найти время на то, чтобы поддержать настроения участников проекта.
Другим вариантом может быть ужин, организованный спонсором проекта для команды, посещение им проектных совещаний, разговоры с участниками об их вкладе в проект, вознаграждения (все, что угодно, от билетов в кино до бонусов), обратная связь о ходе реализации, чтение еженедельной отчетности и самых важных документов. Полезно также определить, что делает эту команду отличающейся от других. Однажды я организовал для команды проекта особые места на парковке ближе к зданию, т.к. они надолго задерживались по вечерам. Это ничего не стоило для организации, разве что цену краски для разметки парковочных мест «Зарезервировано для команды проекта». Зато мораль взлетела до небес.

Реализация

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

Скорее всего, потребуется еще больше планирования, но «план по составлению плана» будет частью движения вперед. Если следующую неделю придется потратить на планирование, объясните как пойдет процесс и кто будет вовлечен. Организуйте еще одно рабочее совещание, когда план будет готов.

Заключение

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

Перевод, оригинал статьи

Как награждают РПО в финских компаниях (это медицинский факт)


В скучных рассказах о людях прошлого скрыты тайны их великих свершений

http://zhu-s.livejournal.com/211737.html


Почему надо перечитывать блоги умных людей.

Про микропрактики составления расписаний - опыт SpaceX

Очень важная вещь из проекта SpaceX 'Various "off the shelf" project management methodologies and ways to estimate how long projects will take do not work for his team. It is important to set something up that works for your people and set of tasks, Rose said. They have tried various techniques for estimating time requirements, from wideband delphi to evidence-based scheduling and found that no te...chnique by itself works well for the group. Since they are software engineers, "we wrote our own tool", he said with a chuckle, that is a hybrid of several different techniques. There is "no silver bullet" for scheduling, and it is "unlikely you could pick up our method and apply it" to your domain. One hard lesson he learned is that once you have some success using a particular scheduling method, you "need to do a sales job" to show the engineers that it worked. That will make it work even better the next time because there will be more buy-in.'

Про Джастина Бибера тоже смешно.


https://lwn.net/Articles/540368/




Про модели познания мира (Lattice of mental models)

Motto!

В Space Balls у флагмана имперского флота был отличный девиз. А я нашел свой, для проектного управления:
"All I want to know is where I’m going to die, so I’ll never go there". В этом и состоит работа РП.


Индуктивный метод

Многие не могут отличить индукцию от дедукции. Поясню в картинках - это индукция.





Как заставить команду проекта отказаться от провала?

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




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

Руководство по полевому саботажу (сарарименам посвящается)

Выдержки из «Полевого руководства по простому саботажу»:

Организационный процесс и совещания

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

Управленцам и руководителям подразделений

• Требуйте поручения в письменной форме.
• «Недопонимайте» поручения. Задавайте миллион вопросов или ведите бесконечную переписку. Придирайтесь при каждой возможности.
• Делайте все возможное, чтобы отложить выполнение поручения. Даже если какая-то часть уже сделана, ждите пока не будет сделано всё вместе.
• Не заказывайте новые необходимые материалы заранее, до тех пор, пока на складе ничего не останется для того, чтобы любое промедление в заказе новых материалов сопровождалось возможным риском прекращения всей работы.
• Заказывайте материалы и оборудование высокого качества, дефицитные на рынке. Но если вам их не согласовывают, настаивайте на закупке. Аргументируйте тем, что менее качественные материалы или оборудование приведут к менее качественной работе.
• Распределяя поручения, всегда начинайте с самых незначительных и маловажных.
• Контролируйте качество исполнения самых незначительных поручений; отправляйте на доработку незначительные вещи. Пропускайте дефекты и ошибки там, где есть что-то важное и крупное в работе.
• Выстраивайте неэффективную логистику, например, на заводе отправляйте детали и материалы не туда куда нужно.
• Тренируя новых работников, проводите неполный и непонятный инструктаж.
• Для снижения морального духа и производительности будьте обходительны с неэффективными работниками: давайте им незаслуженные повышения, «приближайте» их. Эффективных работников следует дискриминировать, жаловаться на них, придираться к их работе.
• Проводите совещания при наличии большого количество серьезных задач.
• Увеличивайте бумажную работу. Дублируйте все документы.
• Усложняйте административные процедуры путем введения новых регламентов работы и т.д. Удостоверьтесь, чтобы согласовательная процедура включала не одного человека, а минимум трёх.
https://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf


В общем-то, не хуже "Жизненного цикла корпораций" Адизеса. Стадия "Аристократизм".

Sometimes project review goes like this


Виртуальные команды или виртуальные результаты?

Разница - в навыках людей. Применять на старте глобальных проектов с новыми командами.

Управление и лидерство в распределенных командах
Бриф тренинга

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

Средства достижения цели: руководители проектов и тим-лиды получат систематические знания и навыки применения наиболее часто работающих практик организации удаленной работы (robust remote teams organizational practices), увидят примеры применения этих практик непосредственно на материале тренинга, получат интерактивный опыт использования этих практик во время тренинга, получат домашнее задание на отработку практических навыков и обратную связь и рекомендации по результатам использования этих практик. Соотношение “теории-демонстраций применения практики-практики” в тренинге 10-20-50%, 20% отводится на обсуждения и ответы на вопросы. Тренинг построен с помощью инструментально-ориентированного подхода.

Тренинг состоит из трех частей:
День1. 4,5 часовой модуль по Skype for Business/Lync (далее SfB).
Домашнее задание - подготовить и выслать тренеру два-три типовых кейса с описанием сложностей организации работ в удаленных командах по сравнению с локальными. Какие основные вызовы и точки развития? Контент тренинга уточняется и модифицируется под эти кейсы, в случае, если они будут присланы минимум за неделю до тренинга. Прохождение теста Белбина всеми участниками тренинга.

Повестка модуля 1:
Знакомство, айсбрейкер “Управление удаленными командами, опыт Римской и Британской империй”, инструмент картографирования виртуальной команды (демонстрация примера этого инструмента тренером для конкретно этого тренинга с текущими участниками).
Изучение инструментов совместной работы SfB - маркеры, текстовые блоки, отметки, интерактивные презентации PPTX. Особенности работы с PPTX по SfB - приемы и правила презентации. Шаблоны kick-off, code review, gate review, phase/project closure.
Совместная разработка участниками базовых правил проведения тренинга (практика применения SfB whiteboard and polling tools).
Смещение точки зрения - это не они удаленные и виртуальные, для себя они реальны и близки, это вы для них виртуальные и удаленные. Приемы приближения к текущему состоянию удаленной команды - фокус на здесь и сейчас (комфорт в помещении удаленной команды, как доехали на работу, когда обед, какая погода/пробки и т.п.). 4 безопасные темы для разговоров в любых культурах.
Запоминание иностранных имен, фамилий, пола, позиций - пиктограммы, флеш-карты. Как действовать в неловких ситуациях - сделал ты, сделал другой.
Остановка блуждающего ума перед собранием. Использование инструмента OARRS (Objective/Outcome-Agenda-Roles-Rules-Structure) при организации собраний (meeting) и рабочих совещаний (structured workshop).
Вовлечение удаленных участников в обсуждения. Удержание фокуса внимания с помощью постоянного запроса обратной связи. Организация обсуждений в чатах и с помощью голосований. Работа с “трудными участниками”, отключение микрофона, удаление из собраний. Типовой цикл внимания. Организация контроля вовлеченности с помощью карты вирутальной команды и фокуса на здесь и сейчас. Использование приема “толстый кролик” для модерирования собраний с большим количеством участников.
Позитивные подкрепления и негативные подкрепления, смена мотивации - как сделать, чтобы люди следовали плану и правилам? Основные ошибки при энфорсменте плана управения проектом и регламентов. Рекомендация “Не рычите на собаку” Прайор Карен, “Одноминутный менеджер” Кен Бланшар.
Разработка сетевой карты стейкхолдеров. Management by walking around (MBWA) и виртуальный кофе.
Мотивация удаленных команд - внутренние валюты нематериального стимулирования, рециприкотность и торговля ценностями, инструмент “Журнал интересов и обмена ценностями”. Правила выявления интересов, базовые правила торговли. Рекомендации по Dan Pink ‘Puzzle of motivation’/Мотивация 2.0 - как выстраивать мотивацию для кодеров, тестеров, разработчиков и архитекторов.
Проведение удаленных собраний - правила большого пальца и чего нельзя делать ни при каких обстоятельствах.

День 2. Очный модуль, через 1-2 недели после первого.
Повестка модуля 2:
Лидерство в удаленных командах. Отличие лидера от менеджера, почему лидерство в удаленных командах критично (локальные культуры, разница во времени, индентификация проблем). Нетворкинг и влияние через локальных лидеров мнений (influence through opinion leaders), использование сетевой карты стейкхолдеров с 1-го модуля для построения влияния и при решении проблем. Модерация и решение проблем в парной работе участников - парные коуч сессии.
MBWA и виртуальный кофе - дискуссия кто использовал в работе и что получилось в результате.
Типы власти руководителя проектов и основная проблема РП при входе в проект с удаленными участниками (невозможность использования формальной власти вначале, когда она имеет наибольшее значение). Доверие и формирование собственной культуры команды как основные инструменты решения этого противоречия. Формирование культуры команды на базе принципов компании и ценностей отдельных участников. Домашнее задание - изучение кейса Spotify. Шестикомпонентная модель Хофстеде, интерпретация компонентов, гэп-анализ культурных профилей, типовые непонимания при столкновении культур с разной дистанцией до власти. Предостережение о различии между культурами и отдельными людьми.
Использование модели Белбина при формировании команды и диагностике кризисных проектов.
Две составляющие доверия - компетенция и человечность. Важность первой встречи, принцип 4П “Провалить подготовку, подготовить провал”. Как быстро сформировать доверие и как не разрушить его.
Принцип “Не предполагайте, всегда проверяйте”, инструмент “Пять почему”, принятие решений, основанных на фактах. Основы факт-чекинга. Использование техники майндмэппинга для разделения фактов и выводов/мнений.
Планирование и контроль коммуникаций в удаленных командах. Разработка плана коммуникаций - упражнение. Черновик плана предоставляется в начале упражнения, команды дорабатывают его в течении 15 минут, разбор полетов
Идентификация, планирование реагирования и контроль рисков в удаленных командах. Разработка плана по управлению рисками - упражнение. Черновик плана предоставляется в начале упражнения, команды дорабатывают его в течении 15 минут, разбор полетов.
Пять стадий формирования команды (forming-storming-norming-performing-adjourning), инструмент OMG Essence kernel ALPHA health checklist для оценки стадии команды. Планирование и учет стадии команды в проектах с разными моделями жизненного цикла - Agile, waterfall.
Рекомендации по изучению OMG Essence kernel при планировании жизненного цикла проекта.
Использование инструментов “Пять выборов” и ADC (Aligned-Different-Conflicting) для решения спорных ситуаций.
Использование lessons learned в формате PRINCE2 для сбора и обмена опытом, организация семинаров.
День 3. 4 часовой модуль по SfB.
Домашнее задание: составить план использования полученых навыков, исполнить план, подготовить краткий отчет об использовании, подготовить 1-2 кейса использования.
Вспоминаем материал, обсуждаем опыт применения, рекомендации.
Карта виртуальной команды.
Сетевая карта стейкхолдеров.
Позитивные подкрепления и негативные подкрепления, смена мотивации. Использование в плане управления проектом.
Журнал интересов и обмена ценностями.
Принцип “Не предполагайте, всегда проверяйте”, инструмент “Пять почему”, принятие решений, основанных на фактах.
Lessons learned.
Вход руководителя проекта в проблемный проект с удаленными участниками.
Культура вашей команды - какая она? Как вы ее будете закреплять?