>>> Как часто имеет смысл делать сверку?
Раз в неделю, и отслеживать как будет накапливаться тенденция отклонения. В разделе Анализ тенденций я написал об этом.
Категоричный пересмотр расписания нужно делать 1 раз в 3 недели — месяц по-любому, если ситуация не улучшается!
1. Овертайм до добра не доведет, согласен! Но этот прием все-таки часто используется в работе, поэтому я вынужден был его включить.
2. Разработчик имеет право обговорить условия по внеурочке на собеседовании. Условия могут быть категоричные, типа по выходным вообще никак, либо более гибкие.
И потом когда зайдет разговор о внеурочке, напомнить РМ или своему руководителю, что он эти условия обговаривал. Пусть менеджер и руководство компании думает, кого поставить на внеурочку.
Понравилось!
Про умение сказать «нет» написано много, про вторую часть — редко пишут.
Вторую часть можно было бы переименовать «как правильно получить ответ „ДА“?
1. Слышал про случаи, когда крупные гос. и коммерческие заказчики объявляли тендеры, в требованиях к составу проектной команды было указано наличие хотя бы 1 специалиста с сертфикатом PMP.
2. В ИТ-отрасле в России мало кто использует полезные инструменты из PMBOK.
Не подготовленному мега-ИТ-менеджеру не сдать экзамен на РМР хотя бы на 40 баллов.
Очень попсово.
1. Видео — по большей части направлено на начинающих менеджеров, только что вышедших из специалистов.
2. Интеллект-карта.
— Действительно полезный инструмент в последнее время, помогающий сгенерировать или привести в порядок информацию в голове. Но я посмотрел только раздел «Принципы» — сыровато, не все разделы доделаны, особенно требует проработки блок «Мотивационные факторы»
— Также в этот раздел можно добавить блок «антипаттерны мотивации», т.е. шаблоны поведения, которые снижают мотивацию. Например, тотальный контроль, постоянные улучшения и т.д.
— Про анти-паттерны можно почитать
А. У Архипенкова
Б. itblogs.ru/blogs/hitfounder/archive/2010/08/20/66940.aspx
В. habrahabr.ru/post/59005/
Г. Систематизировать информацию из своего опыта.
3. И вот еще вспомнил про отмазы разработчиков от Ашманова. Менеджер должен знать, как его обманывают разработчики, и он должен быть готов к подобным отмазам. www.ashmanov.com/pap/obspro.phtml
если менеджер заказчика человек адекватный, то обижаться он будет только на своих, а не на подрядчика
При управлении стейкхолдерами (в том числе и заказчиками) нужно понимать самую важную вещь: Как данный проект будет влиять на различные заинтересованные стороны?
Обладая такой информацией, вы можете управлять ожиданиями заказчика, а не просто производить впечатление.
Например, вы разрабатываете и внедряете АСУ. Руководитель Департамента крупного заказчика имеет следующее главное ожидание: «Проект не должен завершиться». В случае успеха проекта, то что делали его сотрудники — наполовину будет делать АСУ и ему придется сократить часть персонала, в том числе и друзей, с которыми он работает более 5 лет.
Тогда как не впечатляй, а тут уже это не будет эффективно. Нужно будет выстраивать политическую игру, когда вы должны снижать влияние на проект этого руководителя и вовлекать боссов, которые не дадут тому руководителю вставлять палки в колеса.
Управлять ожиданиями — более эффективно, чем управлять впечатлениями.
1. В целом правильно написали, что нужно ориентироваться на впечатления и ожидания заказчика, привели некоторый структурированный подход.
Впечатление можно произвести, а впечатление на своего CEO можно произвести обратное, когда окажется, что заказчика облизали за «свой же счет».
Нужно чувствовать баланс.
2. Про ожидания и впечатления не указано важное «Собственная выгода».
Например, если менеджеру заказчику за успешно завершенный проект пообещали повышение в должности, а он получил только хороший «сервис», то по вашей же шкале его ждет «Разочарование».
Leonid76, согласен. На деле то что называется программой или портфелем проектов является всего лишь набором проектов.
Программа — поменьше проектов, портфель — потолще.
Никто не управляет выгодами программы, а про портфели и стратегические цели — я тоже промолчу.
У нас в России еще как следует не развито управление проектами, а тут уже люди управляют портфелями.
Даже методы достижения среднесрочных целей отличаются для разных типов деятельности (операционной и проектной).
ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ
Например в операционной деятельности, возьмем показатель — объем выручки.
Есть план на неделю, есть на квартал. Чтобы выполнить среднесрочный план, нужно наращивать количество выполненных операций (утрирую, поскольку одна продажа может принести 500 руб, а другая 5 000 руб.).
ПРОЕКТНАЯ ДЕЯТЕЛЬНОСТЬ
Для проектной деятельности обычным наращиванием выполненных операций не всегда возможно добиться результата.
Тут нужно использовать методы критического пути, освоенного объема, оценки по трем точкам и т.д. в зависимости от навыков менеджеров. Потому что можно выполнять быстро и много операций, а они окажутся не на критическом пути, и результат так и не будет достигнут.
1. В статье идет речь не о терминологии, а подходах, применяемых к управлению проектами.
Приемы общего и операционного менеджмента применяются к управлению проектами (правильная постановка задач, мотивация команды и другое). Тут уж никуда не деться, менеджмент есть менеджмент.
2. Также при управлении проектами должны применяться и другие ПРОЕКТНЫЕ методы, не используемые в ОПЕРАЦИОННОМ менеджменте, например составление ИСР, метод освоенного объема, метод критического пути. Последний — очень важный метод, который позволяет спрогнозировать оставшийся путь проекта и скорректировать его, если проект отстает. Обычным операционными методами здесь не решить проблему.
3. Про присутствие операционной деятельности в проекте. Например, на одном из этапов вы внедряете систему в 50 магазинах розничной сети. У вас будут одинаковые операции при каждом внедрении:
— установка ПО
— передача инструкций по пользованию системы
— обучение основным приемам
и др.
Это ли не операционная деятельность? И хороший менеджер постарается систематизировать такой вид деятельности и создать «конвейер».
4. Еще раз скажу о своем опыте. Я взаимодействовал с ПМ-ами будучи менеджером проектного офиса в ИТ-компаниях из ТОП-30. Могу сказать из своего опыта, что многие из менеджеров работают по принципу «нужно решать задачи и проблемы по мере их поступления» (операционный подход). В проектном управлении этого недостаточно. В дополнении ко всему этому нужно регулярно смотреть в будущее, предугадывать проблемы и вовремя их предупреждать (проектный подход).
Все процессы, описанные выше (отклонения и прогнозы), у нас применялись на практике и это не теория.
На практике эти процессы переплетаются. Но замечу, что даже в лидирующих ИТ-компаниях проектное управление часто заканчивается после составления план-графика. Далее идет оперативное выполнение задач и решение возникающих проблем.
Кстати, что касается чисто «проектного менеджера». Это зло. Можно посмотреть на примере Российской Федерации.
Не берите пример с плохих менеджеров портфелей.
В РФ управление еще строится на поручениях. Переход к управлению через целевые программы еще только развивается. Даже Медведев еще не до конца понимает как это должно выглядить!
Я больше говорю о подходах
Операционный подход — некогда думать, быстрее выполнять!
Проектный уровень — больше анализа, больше управленческих маневров, больше эффективности.
Вы правильно меня поняли.
Грубо говоря операционный уровень — это где скапливается много мелочи и эту мелочь нужно оперативно закрывать.
Именно так многие и работают. «У нас нет времени, некогда думать, нужно быстрее делать!»
На проектном уровне — нужно больше анализировать, прогнозировать и на основании этого корректировать проект, если такие прогнозы не в вашу пользу.
Вы хорошо пишете, но не задели самого интересного — что управлять можно только хвостом проекта.
Видимо, вы умеете управлять только тем, что отчетливо видно. Тем что вы не можете видетЬ, вы не можете управлять. В конце всегда все четче видно, чем в начале. Если вы управляли только тасками, а не управляли проектом, то хвостом уже управлять бесполезно, там нужно только «дожимать». А потом еще долго-долго дорабатывать и исправлять.
Почитайте мою статью, как использовать MS Projetc в качестве навигатора проекта и прогнозировать картину на много дней и недель вперед. Имея прогноз, вы всегда можете скорректировать что-то. Не имея прогнозов, вы может только надеяться.
Если Ваш опыт говорит о менеджерах, которые не мыслят конечными результатами проекта — подсуньте тем менеджерам пмбок.
Мой опыт работы в компаниях, входящих в ТОП-30 ИТ-компаний России, говорит о том, что менеджеры неэффективно используют инструменты, описанные хотя бы в PMBOK.
Я видел, как люди люди, управляющие проектами с бюджетами, кратными сотням млн. руб. акцентируются на тасках в JIRA, а дальше недели они ничего не видят. В итоге и проект срывается. Сам управлял такими проектами и знаю разницу в подходах.
Если для вас полноценный контроль — это обычное дело, то ответьте себе на вопрос:
— На сколько дней ваш проект отстает от намеченных планов на сегодняшний день?
— Когда завершится ваш проект/этап проекта (прогнозы)?
Тоже самое попробуйте проделать с финансами.
Готов доказать, что проект содержит операционную деятельность.
Но основное, что имелось в виду — это разница в подходах.
Операционная деятельность похожа на конвейер с однотипными задачами, что вчера, что сегодня, что завтра. Нет смысла думать о будущем. «Нормально делай — нормально и будет». Главное отработать подход на нескольких задачах, дальше все пойдет как по маслу.
«Проектеры» управляют «уникальными» результатами, поэтому завтра может сильно отличаться от вчера и сегодня. Поэтому нужно мыслить на перспективу и заранее предугадывать сценарии развития.
И в дополнение, приемы, используемые в операционной деятельности, применимы и в проектной. Однако, проектная деятельность содержит ряд уникальных методов.
Например, метод критического пути или метод освоенного объема.
Раз в неделю, и отслеживать как будет накапливаться тенденция отклонения. В разделе Анализ тенденций я написал об этом.
Категоричный пересмотр расписания нужно делать 1 раз в 3 недели — месяц по-любому, если ситуация не улучшается!
2. Разработчик имеет право обговорить условия по внеурочке на собеседовании. Условия могут быть категоричные, типа по выходным вообще никак, либо более гибкие.
И потом когда зайдет разговор о внеурочке, напомнить РМ или своему руководителю, что он эти условия обговаривал. Пусть менеджер и руководство компании думает, кого поставить на внеурочку.
Про умение сказать «нет» написано много, про вторую часть — редко пишут.
Вторую часть можно было бы переименовать «как правильно получить ответ „ДА“?
2. В ИТ-отрасле в России мало кто использует полезные инструменты из PMBOK.
Не подготовленному мега-ИТ-менеджеру не сдать экзамен на РМР хотя бы на 40 баллов.
1. Видео — по большей части направлено на начинающих менеджеров, только что вышедших из специалистов.
2. Интеллект-карта.
— Действительно полезный инструмент в последнее время, помогающий сгенерировать или привести в порядок информацию в голове. Но я посмотрел только раздел «Принципы» — сыровато, не все разделы доделаны, особенно требует проработки блок «Мотивационные факторы»
— Также в этот раздел можно добавить блок «антипаттерны мотивации», т.е. шаблоны поведения, которые снижают мотивацию. Например, тотальный контроль, постоянные улучшения и т.д.
— Про анти-паттерны можно почитать
А. У Архипенкова
Б. itblogs.ru/blogs/hitfounder/archive/2010/08/20/66940.aspx
В. habrahabr.ru/post/59005/
Г. Систематизировать информацию из своего опыта.
3. И вот еще вспомнил про отмазы разработчиков от Ашманова. Менеджер должен знать, как его обманывают разработчики, и он должен быть готов к подобным отмазам.
www.ashmanov.com/pap/obspro.phtml
При управлении стейкхолдерами (в том числе и заказчиками) нужно понимать самую важную вещь:
Как данный проект будет влиять на различные заинтересованные стороны?
Обладая такой информацией, вы можете управлять ожиданиями заказчика, а не просто производить впечатление.
Например, вы разрабатываете и внедряете АСУ. Руководитель Департамента крупного заказчика имеет следующее главное ожидание: «Проект не должен завершиться». В случае успеха проекта, то что делали его сотрудники — наполовину будет делать АСУ и ему придется сократить часть персонала, в том числе и друзей, с которыми он работает более 5 лет.
Тогда как не впечатляй, а тут уже это не будет эффективно. Нужно будет выстраивать политическую игру, когда вы должны снижать влияние на проект этого руководителя и вовлекать боссов, которые не дадут тому руководителю вставлять палки в колеса.
Управлять ожиданиями — более эффективно, чем управлять впечатлениями.
Впечатление можно произвести, а впечатление на своего CEO можно произвести обратное, когда окажется, что заказчика облизали за «свой же счет».
Нужно чувствовать баланс.
2. Про ожидания и впечатления не указано важное «Собственная выгода».
Например, если менеджеру заказчику за успешно завершенный проект пообещали повышение в должности, а он получил только хороший «сервис», то по вашей же шкале его ждет «Разочарование».
Программа — поменьше проектов, портфель — потолще.
Никто не управляет выгодами программы, а про портфели и стратегические цели — я тоже промолчу.
У нас в России еще как следует не развито управление проектами, а тут уже люди управляют портфелями.
Даже методы достижения среднесрочных целей отличаются для разных типов деятельности (операционной и проектной).
ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ
Например в операционной деятельности, возьмем показатель — объем выручки.
Есть план на неделю, есть на квартал. Чтобы выполнить среднесрочный план, нужно наращивать количество выполненных операций (утрирую, поскольку одна продажа может принести 500 руб, а другая 5 000 руб.).
ПРОЕКТНАЯ ДЕЯТЕЛЬНОСТЬ
Для проектной деятельности обычным наращиванием выполненных операций не всегда возможно добиться результата.
Тут нужно использовать методы критического пути, освоенного объема, оценки по трем точкам и т.д. в зависимости от навыков менеджеров. Потому что можно выполнять быстро и много операций, а они окажутся не на критическом пути, и результат так и не будет достигнут.
Вот такую мысль я и пытался заложить в статью.
Приемы общего и операционного менеджмента применяются к управлению проектами (правильная постановка задач, мотивация команды и другое). Тут уж никуда не деться, менеджмент есть менеджмент.
2. Также при управлении проектами должны применяться и другие ПРОЕКТНЫЕ методы, не используемые в ОПЕРАЦИОННОМ менеджменте, например составление ИСР, метод освоенного объема, метод критического пути. Последний — очень важный метод, который позволяет спрогнозировать оставшийся путь проекта и скорректировать его, если проект отстает. Обычным операционными методами здесь не решить проблему.
3. Про присутствие операционной деятельности в проекте. Например, на одном из этапов вы внедряете систему в 50 магазинах розничной сети. У вас будут одинаковые операции при каждом внедрении:
— установка ПО
— передача инструкций по пользованию системы
— обучение основным приемам
и др.
Это ли не операционная деятельность? И хороший менеджер постарается систематизировать такой вид деятельности и создать «конвейер».
4. Еще раз скажу о своем опыте. Я взаимодействовал с ПМ-ами будучи менеджером проектного офиса в ИТ-компаниях из ТОП-30. Могу сказать из своего опыта, что многие из менеджеров работают по принципу «нужно решать задачи и проблемы по мере их поступления» (операционный подход). В проектном управлении этого недостаточно. В дополнении ко всему этому нужно регулярно смотреть в будущее, предугадывать проблемы и вовремя их предупреждать (проектный подход).
Все процессы, описанные выше (отклонения и прогнозы), у нас применялись на практике и это не теория.
На практике эти процессы переплетаются. Но замечу, что даже в лидирующих ИТ-компаниях проектное управление часто заканчивается после составления план-графика. Далее идет оперативное выполнение задач и решение возникающих проблем.
Не берите пример с плохих менеджеров портфелей.
В РФ управление еще строится на поручениях. Переход к управлению через целевые программы еще только развивается. Даже Медведев еще не до конца понимает как это должно выглядить!
Операционный подход — некогда думать, быстрее выполнять!
Проектный уровень — больше анализа, больше управленческих маневров, больше эффективности.
Грубо говоря операционный уровень — это где скапливается много мелочи и эту мелочь нужно оперативно закрывать.
Именно так многие и работают. «У нас нет времени, некогда думать, нужно быстрее делать!»
На проектном уровне — нужно больше анализировать, прогнозировать и на основании этого корректировать проект, если такие прогнозы не в вашу пользу.
Все выше описанное мной и моими коллегами используется на практике.
Видимо, вы умеете управлять только тем, что отчетливо видно. Тем что вы не можете видетЬ, вы не можете управлять. В конце всегда все четче видно, чем в начале. Если вы управляли только тасками, а не управляли проектом, то хвостом уже управлять бесполезно, там нужно только «дожимать». А потом еще долго-долго дорабатывать и исправлять.
Почитайте мою статью, как использовать MS Projetc в качестве навигатора проекта и прогнозировать картину на много дней и недель вперед. Имея прогноз, вы всегда можете скорректировать что-то. Не имея прогнозов, вы может только надеяться.
Мой опыт работы в компаниях, входящих в ТОП-30 ИТ-компаний России, говорит о том, что менеджеры неэффективно используют инструменты, описанные хотя бы в PMBOK.
Я видел, как люди люди, управляющие проектами с бюджетами, кратными сотням млн. руб. акцентируются на тасках в JIRA, а дальше недели они ничего не видят. В итоге и проект срывается. Сам управлял такими проектами и знаю разницу в подходах.
Если для вас полноценный контроль — это обычное дело, то ответьте себе на вопрос:
— На сколько дней ваш проект отстает от намеченных планов на сегодняшний день?
— Когда завершится ваш проект/этап проекта (прогнозы)?
Тоже самое попробуйте проделать с финансами.
Но основное, что имелось в виду — это разница в подходах.
Операционная деятельность похожа на конвейер с однотипными задачами, что вчера, что сегодня, что завтра. Нет смысла думать о будущем. «Нормально делай — нормально и будет». Главное отработать подход на нескольких задачах, дальше все пойдет как по маслу.
«Проектеры» управляют «уникальными» результатами, поэтому завтра может сильно отличаться от вчера и сегодня. Поэтому нужно мыслить на перспективу и заранее предугадывать сценарии развития.
И в дополнение, приемы, используемые в операционной деятельности, применимы и в проектной. Однако, проектная деятельность содержит ряд уникальных методов.
Например, метод критического пути или метод освоенного объема.