Тренинги Сергея Бережного Консультации Сергея Бережного Бесплатные материалы

Видео-Курс «Как руководителю проекта правильно переносить сроки?» уже в продаже

Курс «Как руководителю проекта правильно переносить сроки?» уже стартовал!

Старт продаж курса по переносу сроков

Если вы живете в реальном мире сложных ИТ проектов с реальными Заказчиками, то сталкивались с проблемой перепланирования и сложных переговоров с Заказчиком. Такие переговоры всегда проходят напряженно, так как изменение плана – это нарушенные ожидания, дополнительные затраты денег, времени и нервов. При этом руководитель проекта (ПМ) часто становится «крайним» в такой ситуации и все «шишки» падают на него. А затем уже проигрывает команда (работая в овертайм), Компания (теряя репутацию и деньги) и Заказчик (теряя деньги, получая продукт с худшим качеством). В итоге проигрывают все!

Для того, чтобы избежать многих ошибок был создан видео-курс

«Как руководителю проекта правильно переносить сроки?»

Видео-курс (~4 часа видео) состоит из нескольких связанных модулей-инструментов:

  • Как понять, что проект выходит за рамки текущего плана?
  • Как найти основные причины, которые привели к отставанию от плана?
  • Как правильно превратить эти причины в действия, а затем и в новый план. Какие ошибки чаще всего совершают ПМы на этом этапе?
  • Как подготовиться к переговорам с Заказчиком (базовые и продвинутые рекомендации)?
  • Как избежать ошибок переговоров с Заказчиком? Как правильно использовать эмоции Заказчика!
  • Как победить «пост-переносной синдром» (оказывается такой есть) и не провалить и этот план?

 

 Для кого этот курс

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

Курс специально спроектирован с учетом специфики ИТ-проектов. Продукт содержит практические инструменты, которые позволят обсудить и утвердить с Заказчиком нежелательные изменения в плане проекта.

Специальный акцент курса сделан на сроках сдачи проекта, так как они всегда были и будут самой сложной темой для обсуждения с Заказчиком. Еще раз подчеркну, что курс для айтишников, так как разные аспекты управления проектом, ожиданиями и эмоциями связаны в единую логическую структуру. Никаких “настроек EQ” и других страшных слов, а только действия и факты. Точно так же я рассказывал бы это своему другу, который попросил меня помочь!

Если подумать…

  • Сколько стоит один единственный сорванный проект?
  • Сколько стоит неделя работы в овертайм для твоей команды?
  • Сколько стоит потеря перегруженного сотрудника? А если нескольких?
  • Сколько еще скидок и неоплаченной работы ты сделаешь со своей командой, потому что тебя может “отжать” Заказчик?
  • Сколько километров нервов и килограмм авторитета ты еще собираешься потратить на невладение этой темой?

Сколько стоит решение этой проблемы:

Продукт доступен в двух версиях: индивидуальная и корпоративная.

Стоимость индивидуальной лицензии составляет $280. Видео-тренинг суммарной длительностью более 4х часов, в котором подробно описаны шаги и подходы к решению проблемы изменения плана проекта и переноса сроков.

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

Бонусы:

Приобрести видеокурс

Купить курс сейчас и получить 5 бонусов сразу:

бесплатный билет на Стратоконф 4 + 3 вебинара + чеклист

Nov 23rd, 2011

Ограниченный бонус курса: “Как руководителю проекта правильно переносить сроки?”

Тема изменения планов проектов, отставаний и, как результат, – переговоров с Заказчиком продолжается. Мои друзья и коллеги и просто хорошие блоггеры и тренеры решили поделится своими секретами на эту тему. И курс о том, как правильно переносить сроки проекта дополняется новыми материалами! 

Слайд-видео-каст: Реактивные реакции – Владимир Железняк и Дмитрий Снисарь, авторы проекта www.it-boost.com, для курса по переносу сроков записали слайдкаст, в котором подробно описана динамика принятия неприятных новостей. Использованы классные примеры, видео-записи тренингов и кадры из фильмов!  
Наши Заказчики (как и все другие люди) подвержены реактивными реакциям, поэтому алгоритмы работы с ними помогут нам правильно использовать аргументы и контр-аргументы во время переговоров.

Слайдкаст: “Защити свою карьеру. Как нейтрализовать последствия переноса сроков” – Слава Панкратов и Саша Орлов, создатели Stratoplan.ru.
Как профессионалы в карьерном построении и развитии, Саша и Слава (с) расскажут о том, как руководителю проекта или техническому лидеру сделать так, чтобы сам факт переноса сроков и переработок не загубил вашу карьеру. Что нужно сделать внутри организации, чтобы создать правильное видение ситуации в проекте.

 

Слайдкаст: “Как понять, что пора переносить сроки проекта?” – Сергей Поволяшко, РМР, большой профессионал в проектном менеджменте и автор блога http://it-tuning.com/.

С методологической точки зрения, Сергей расскажет о признаках того, что проект идет “не туда” и что с этим делать. Рассматривает основные инстременты: метрики, контроль сроков, задач и объема работ, как с точки зрения PMBoK, так и Agile.

 
Чеклист “Что спросить у руководителя проектов раз в неделю?” – создан совместно с Сергеем Мовчаном, он же COTOHA.
Изначально я хотел сделать список вопросов, которые должен задать “большой босс” или куратор проекта, чтобы понять, насколько проект ПМа идет в рамках плана. Но вместе с Сергеем пришли к выводу, что такой чеклист поможет любому ПМу в подготовке к регулярным встречам с начальством и с Заказчиком. Если вы, как руководитель знаете ответы на эти вопросы, то у Заказчика и у Босса не останется сомнений в том, что вы все контролируете.

Внимание, бонусы доступны только тем, кто оплатит курс до 27 ноября. 

Приобрести видеокурс

Купить курс и получить 5 бонусов сразу:

бесплатный билет на Стратоконф 4 + 3 вебинара + чеклист

Nov 21st, 2011

Бонусный билет на он-лайн конференцию по работе с Заказчиком в ИТ

А почему бы нам не продолжить тему обсуждения интересных и проблемный ситуаций с Заказчиками в ИТ? И сделать это в интерактивном формате с интересными людьми?

По статистике просмотров, проблема овертаймов и их последствий выбилась в лидеры блога anotherpm.com.  Посмотрите хотя бы на комментарии к постам:

1.       Путь овертаймов

2.       Путь овертаймов. Часть 2.

Чтобы продолжить обсуждение и разбор реальных кейсов в общении с Заказчиком я договорился с коллегами из Стратоплан.Ру посвятить очередную онлайн-конференцию Стратоконф-4 теме работы с Заказчиком.

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

Полная стоимость билета на конференцию Стратоконф составляет 2.000 рублей (~$70), но все покупатели видео-курса “Как руководителю проекта правильно переносить сроки?” получат возможность принять участие в профильной, четвертой конференции Стратоконф совершенно бесплатно.

Приобрести видеокурс

Купить курс и получить 5 бонусов сразу: бесплатный билет + 3 вебинара + чеклист

Nov 18th, 2011

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

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

  1. Чтобы переговоры с Заказчиками приводили к нужным результатам
  2. Чтобы не потерять авторитет в сложных проектных ситуациях
  3. Чтобы иметь проверенный способ избежать изнурительных авралов и переработок для команды

Приобрести видеокурс

Для тех, кто не знает: меня зовут Сергей Бережной

Моя работа и хобби – это управление проектами. Я уже 8 лет управляю самыми разными проектами в ИТ: в разных областях – розничная торговля, медицина, банковская деятельность, ERP системы; в разных масштабах – от 4 до 56 человек; в разных методологиях – PMBoK, SCRUM и Lean. С проблемами изменения планов я сталкивался неоднократно как в своих проектах, так и в тех, которые консультировал.

Что я обнаружил: часто проблему изменения планов проекта не рассматривают вообще. По-умолчанию считается, что ты, как руководитель, должен уметь это делать и делать это правильно.

Как работает весь процесс и его динамика – непонятно и зачастую совершается огромное количество ошибок, которые приводят к большим проблемам:

  • Заказчик недоволен незаконченными задачами и это приводит к уменьшению цены (читай потере прибыли) или уходу Заказчика к другим поставщикам
  • Руководитель не умеет правильно спланировать новые даты и разработать варианты решений, что приводит к невыполнимым обещаниям и новому циклу перепланирования
  • Овертаймы становятся нормой и команда сначала перегорает, а потом быстренько меняет место работы

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

  • Недовольный Заказчик – потеря прибыли
  • Новый перенос сроков – недовольный Заказчик + потраченное напрасно время
  • Овертаймы команды и возможный уход ключевых людей – потеря прибыли.

Внимание вопрос! Зачем компании нужен такой лидер проекта, если от него одни убытки?!

Nov 16th, 2011

Избежать овертаймов. Как договориться с Заказчиком?

Разбор кейсов на тему переработок и овертаймов показал, что эта тема является актуальной или болезненной для многих: 3000+ просмотров видео и 60+ комментариев к 2 статьям. При том, что многие не поддерживают этого подхода, работа в дополнительные часы (иногда в ненормальных количествах) остается самым популярным и простым решением проблем проекта.

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

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

1. Начну с истории, которую можно было назвать «бесстрашием обреченных».

Вместе с моим коллегой мы «продали» проект, конечно же за fixed price, под даты, которые нам назвал Заказчик. Да мы сделали это (хотя это неправильно!), потому что от этого зависел наш бизнес. Через несколько недель мы осознали, что проект не закончится вовремя. Точнее мы не успеем сделать все до указанной даты.

Все простые (внутренние) варианты решений и резервы команды мы уже исчерпали: работали несколько недель по 60+ часов в неделю; отказали в отпуске всем «до выхода из кризиса»; перебросили людей из другого проекта. Запасы ресурсов и вариантов выхода из кризиса закончились  и помощи не предвиделось. Терять нам стало нечего, кроме репутации  и пришлось идти к Заказчику с вопросом об изменении сроков или объема работ.

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

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

Наши аргументы во время переговоров: Мы хотим сдать проект и хотим, чтобы он был нужным и полезным! У нас не хватает ресурсов, чтобы сделать все к этой дате. Денег, чтобы нанять новых людей у нас нет (проект уже не прибыльный) и даже если наймем кого-то, то нужно будет долго вводить их в курс дела. И другие аргументы о качестве и стоимости, которые я приводил от лица «умного Заказчика» в «пути овертаймов». В качестве уступок предложил дополнительный продукт в подарок (без доработок) и значительное увеличение в прозрачности управления проектом.

Пара недель переговоров нас (двух менеджеров) утомила больше, чем недели работы в режиме 16-тичасового рабочего дня вместе с командой. Но мы смогли убедить Заказчика, что разумное изменение сроков и стоимости поможет нам сделать проект, а не превратить его в «вечный долг» (это когда компании делают проект, который уже никому не нужен, но нужно завершить с контрактной точки зрения).

2.       История 2: «Все оказалось намного сложнее»

Мы работали с командой по модели Time&Material, но в рамках «годового бюджета». Хотя все аутсорсеры и называют T&M модель раем, даты релизов никуда не уходят. Бюджет формируется на основании каких-то ожиданий. Большие менеджеры со стороны наших Заказчиков также сформировали свои ожидания по поводу того, что будет сделано в этом году.

Изначально нашей командой была проведена оценка одного из под-проектов. У нас была неделя на оценку. За неделю (работая по 16 часов в день, что было приемлемо для нас троих) мы выжали «the best we can get» и отправили оценку Заказчику. Оценку приняли за базу и мы начали работу. Через пару месяцев стало понятно, что технически мы сделали правильную оценку, но overhead (доп. нагрузка) связанная с процессом разработки и тестирования сделала все наши оценки нереальными. Ожидания на основании наших оценок уже сформированы, но мы столкнулись с тем, что должны делать больше. Были различные варианты решения (см. историю №1), но все они делали проект невыгодным для компании. Да, последующие проекты с этим Заказчиком должны были бы сделать свое дело и окупить затраты. Только до последующих проектов нужно «дотянуть» (не растерять все сбережения и сохранить лояльность Заказчика).  Да и рассчитывать на последующую лояльность Заказчика довольно рискованно: а вдруг проект из разряда «одноразовых»?

Ошибка тут была в том, что мы не рассматривали риск того, что обязательный процесс станет настолько трудоемким. Причем мы винили Заказчика в том, что он промолчал, а он нас в том что мы «не спросили».

Рассматривались несколько вариантов: найм дополнительных людей, овертаймы, отказ от проекта, смена команды на более дешевую и т.д. В любом из случаев мы проигрывали. Все равно НАСТОЛЬКО мы не могли изменить объем трудозатрат.  Одним из решений, которое рассматривалось, было увольнение меня как ПМа чтобы потом, свалив все на «неправильное управление» на мои ошибки, можно было бы идти на новый виток переговоров.

В итоге, мы собрали аргументы к переговорам: неоцененный объем работ, специфический для Заказчика (настаивая на том, что технические оценки правильные); указание того, что сроки недостижимы при таком объеме работ; последним аргументом стало то, что нам дешевле отказаться от проекта заплатив неустойку, чем доделать его, но указали, что другие вендоры не сделают проект за меньшее время и тот же бюджет. В результате переговоров команду увеличили, но дату оставили той же. За 10 человек согласился платить Заказчик, за 4 – мы.

Я не зря рассказал об этих историях. Я вынес из них очень важные уроки управления проектами, особенно работы с Заказчиком. Как оказалось, Заказчики готовы к диалогу, когда у вас в руках есть разумные аргументы (ошибки, риски, изменившиеся обстоятельства, новые задачи…). Предыдущие истории стали для меня ключевыми, так как я был в безвыходном положении и отступать было некуда.

После этих переговоров я получил опыт, который стал применять на постоянной основе, а не только в критических ситуациях.  Я доказываю на практике, что правильные переговоры – инструмент работы менеджера. Это не исключение, которое нужно применять только когда «позади Москва» и отступления нет, а инструмент, который нужен в повседневной жизни. Нужно идти на переговоры, когда:

  • Есть основания говорить о переносах сроков проекта или изменении объемов работ
  • Процесс работы требует пересмотра (организация процесса разработки, тестирования, управления требованиями, …)
  • Срабатывают риски или возникают неучтенные изменения

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

Большим неприятным открытием, для меня стало то, что переговорам нигде не учат в курсе проектного менеджмента. Будь то PMBoK, MSF, SCRUM методологии, они все умалчивают об этом! То есть они подразумевают, что Заказчики (а заодно и твои боссы) не люди(!) и они спокойно принимают все логические аргументы и соглашаются с этим. Да не бывает так! Помню, во время одних из переговоров Заказчик кричал, матерился и обещал приехать и разнести наш офис. И угрозы эти звучали очень реально. Тогда я растерялся и наобещал лишнего, что стоило нам очень дорого.

Переговоры – ключ к успеху в большинстве сложных проектов. Невозможно (даже с математической точки зрения) предопределить все условия и варианты поведения в проекте. Значит, успешный менеджер должен уметь правильно общаться с Заказчиком и добиваться результатов с помощью переговоров. Все руководители, которые вызывают мое уважение, умеют правильно обсуждать с Заказчиком острые вопросы. Каждый делает это в своем стиле, но они идут на переговоры зная, как переработки или поведение в стиле улитки («я пока спрячусь в домике») негативно влияют на проект. Проактивность в решении проблем со всех сторон, а не только за счет команды и прибыли компании, как раз и делают из них хороших менеджеров!

Вывод: Нужно признать, что одним из действенных вариантов выведения проекта из кризиса могут и должны стать переговоры с Заказчиком. Ситуации, когда никакие переговоры не решают вопрос – редкость. Чаще всего менеджеры не умеют этого делать (задайте себе вопрос, кто ВАС обучал это делать правильно?) и поэтому наши попытки поговорить с Заказчиком или откладываются на неопределенный срок или приводят к провалу. Ведь Заказчики они же, зачастую, из бизнеса, где переговоры – это норма. А мы (ИТ-шники) не особо опытны в переговорах и поэтому Заказчики выигрывают так сказать «на классе». 

Nov 14th, 2011

Путь овертаймов. Часть 2

Разбор кейса “Путь овертаймов” продолжается. Обязательно посмотрите кейс-оригинал в виде слайдкаста до того, как вы будете читать часть 2.
Эта ситуация стала для меня отличной иллюстрацией многих аспектов во взаимоотношениях Заказчик-Исполнитель. Предыдущий слайдкаст показал точку зрения “умного Заказчика” а сейчас я попытаюсь посмотреть на проблему с точки зрения команды и руководителей.

Уставшая командаКоманда

Самой простой в этой ситуации будет точка зрения команды. Ребята будут задавать себе простые вопросы, на которые сложно ответить:

1.    «Почему я должен работать столько времени без выходных?»  и  «Что я получу в конце? Будут ли мои заслуги оценены по достоинству?».

2.    Хватит ли мне сил «дотянуть» до конца этого марафона?

3.    Примет ли моя семья тот факт, что меня нет дома?

А правильно ли я делаю, что вкалываю сейчас а не ищу новую работу? Окупятся ли мои усилия? Нужно ли оставаться работать в этой команде?

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

Большой руководитель

Давайте попробуем посмотреть объективно со стороны более высокого руководителя (например руководителя программы):

1.    Сейчас мы теряем прибыль:

  • Оплачиваем дополнительную работу в овертаймы. И это еще хорошо, если Заказчик платит двойной тариф, а если одинарный или полуторный, то прибыльность страдает. Как остаться в рамках бюджета?
  • Делаем неоправданные инвестиции: Заказываем новое оборудование/тестовые сервера/платформы/свой_вариант, чтобы ускорить сдачу.
  • Оплачиваем «дополнительные» расходы: пиццы, тим-билдинги и т.д.

2.    В будущем мы потеряем прибыль:

  • Нужно в конце проекта выплатить премии сотрудникам, иначе «не поймут». Просто оплаты овертаймов не хватит.
  • После сдачи проекта многие из команды придут за повышением зарплаты и должности. Хватит ли у меня должностей для повышений и бюджета?
  • Некачественный продукт (а мы это доказали) станет причиной недовольства Заказчика. А значит, у него появятся аргументы, чтобы просить скидки и уступки (а даже 5% скидка превращается с большие деньги на протяжении  времени работы с этим Заказчиком).

3.    Добавляем большой риск проекта: Мы потенциально будем искать новых людей вместо «перегоревших» и «разочаровавшихся». А простая калькуляция показывает, что это очень дорого в условиях перегретого айтишного рынка: найти, отобрать, продать компанию, обучить… несколько месяцев работы (переводите в деньги сами. Если лень, то  Саша и Слава (С) посчитали, что это как в среднем 20К у.е. на человека)

4.    Текущий ПМ приобретет негативную репутацию в компании, и в следующих проектах будет очень мало желающих с ним работать.

Посмотрев на это со стороны руководителя я задам себе вопрос: Зачем мне такой «толковый» ПМ, от которого так много потерь?

Вывод со стороны более высокого руководителя: ПМ выбрал очень агресивную модель работы с командой. Овертаймы и риски по качеству окупятся только в двух вариантах: если нам “грозит” большая прибыль от последующих проектов с этим Заказчиком (будущая прибыль) или нам грозят большие убытки от провала проекта сейчас. В обоих случаях есть большой повод поговорить с ПМом и Заказчиком о том насколько реальны будущие прибыли и грозящие убытки. Но если овертаймы вызваны просто амбициями ПМа или у него нет хороших причин, то существование такого руководителя команды – неоправданно в данной компании.

Руководитель проекта

Чтобы быть объективным нужно послушать мнение того самого менеджера, против которого настроены все. Что же думает он:

1.    Я работаю по 20 часов в день, 7 дней в неделю, вытаскивая их проект, а они еще и меня обвиняют!

2.    Я уговорил/мотивировал всю команду работать так много, чтобы хоть как-то спасти проект, а все без толку? Этого никто не оценил?

3.    Заказчик ожидает от нас релиза в эту дату! Чего тут непонятного? Нужно успевать.

4.    Руководитель не помогает. Вместо того, чтобы поговорить с Заказчиком «ноет» о прибыльности и долгосрочной мотивации. Зачем он вообще нужен?

Зачем мне компания и Заказчик, которые не ценят мои усилия?!

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

Что делать?

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

1. Добавить новых людей, чтобы забрать часть нагрузки

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

2. Заготовить много плюшек и правильно пообещать все команде

Правильно мотивировать ребят большим бонусом или повышением или другими мыслимыми способами. Нужно постоянно проводить с ними мотивационные беседы в стиле «счастье уже рядом». И те, кто на самом деле «доживут» до этого счастья сорвут джек-пот. Дотянут ли все до этого джек-пота или пойдут искать этот джек-пот где-то в другом месте? Вот только куда девать высокое руководство, которое и так обеспокоено маленькой прибылью. А сможет ли менеджер утвердить ТАКОЙ бонус, чтобы мотивировал?

3. Поговорить с Заказчиком об изменении плана

Нужно подготовится, тратить время и идти к Заказчику. Долго и упорно объяснять ему, что нужно что-то менять. В этот момент может донести ему аргументы «умного Заказчика» из слайдкаста истории. И если аргументы будут звучать убедительно (изначальная нереальность сроков, новая функциональность, изменяемые требования и т.д.), то есть шанс его переубедить и сдвинуть сроки или уменьшить объем работ. В худшем случае, руководитель потеряет несколько дней времени.

4. Уволиться!

А что, тоже вариант! Руководитель проекта тоже человек! Хотя в последнее утверждение не верит команда, которую он «подписал» на 50 дней без выходных :). Решит проблему «крайнего», так как все дружно свалят все на него. Отношения с Заказчиком это исправит на доли секунды, а потом прийдет озарение о том «что все равно кто-то же должен это делать»,

Наверняка есть еще варианты того, как выйти из этой ситуации. Пишите, в комментариях, будем разбирать…

P.S. Перечитал еще раз все комментарии и сделаю отдельное отступление про проекты модели “fixed price”. Как то все верят, что при такой модели овертаймы и потери исключительно со стороны компании-поставщика логичны. То есть если проект опаздывает, то овертаймы, дополнительные траты и все такое ложатся только на Исполнителя. Получается, что проект становится выигрышным только для Заказчика!
Я один такой (С) считаю, что даже такую ситуацию можно исправить? И что такую ситуацию нужно менять с целью приведения всего в модель win-win!

Nov 11th, 2011

My Story: «Путь овертаймов»

Я решил изменить немного формат разбора историй, которые мне присылают читатели блога. Сегодня история, которую можно пересказать за 1 минуту.  А вот для разбора ситуации я решил записать небольшой подкаст.

Путь овертаймов from anotherpm on Vimeo.

Комментарии приветствуются, особенно о том, как вы обосновали для себя и Заказчика все негативные последствия перегрузки для последующих задач и релизов?

В случае обсуждения перегрузки с командой, было ли что-то более разумное, чем стандартное «Нам нужно это доделать к этой дате!»?

Nov 9th, 2011

Анонсы событий ноября

Nov 6th, 2011

Разбор кейса: Недостижимое отставание

Что же, кейс «Недостижимое отставание» стал рекордсменом, как по количеству комментариев, так и по качеству и объему (текста комментариев, советов и т.д – где-то в 20 раз больше, чем история).

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

Что-то мне подсказывает, что проект этот с просторов СНГ и как решится подобный вопрос сдачи проекта можно догадаться («ресторан-откат»). Потому что нормальными проектными средствами этого не решить в недельный срок.

Давайте предположим, что этот проект нельзя решить «русскими методами» и пойдем до конца. Я попробую сделать акцент исключительно на взаимоотношениях Исполнитель-Заказчик

Disclaimer 1: Так как у меня в практике были подобные проекты, то многое из оригинальной истории я «воссоздал» из своего опыта. Анализ требовал намного больше фактов, чем было в истории.

Disclaimer 2: Делаю акцент исключительно на том, что можно сделать, чтобы этот проект вытащить. Об ошибках управления проектом хорошо написали в комментариях, дополнить нечего.

Oct 16th, 2011

Вредные советы: Тратим бюджет Заказчика

Вредные советы. Тратим бюджет КлиентаСегодня опять пост из жизни проектов. На этот раз в формате «вредных советов» (С).

Ситуация 1: Представьте ситуацию, когда Заказчик просит вас приехать в командировку. Говорит, что лимит суммы на транспорт и жилье примерно N условных единиц.

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

Ситуация 2: Заказчик приглашает в ресторан, чтобы отметить событие.

Вредный совет: Нужно обязательно заказать самые дорогие блюда.  30 летний коньяк и редкое вино – лучший выбор. Фуа-гра, дефлопе и т.д. – лучшие кандидаты для того, чтобы немедленно попробовать. Нужно съесть и выпить столько, чтобы потом не есть 2 дня. А лучше 3!

Удивительно, сколько ребят являются живыми примерами реализации вредных советов.

Для себя я нашел интересную взаимосвязь между отношением к бюджету и успешностью отношений с данным конкретным Заказчиком. Чем более «легко» мы относимся к тратам, тем более недоверчивым становится Клиент. А недоверчивость проявится в более придирчивом отношении и, в итоге, неразумные растраты все равно станут видны.

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

Почему вы не берете в прокат самую дорогую машину и не выбираете самый дорогой отель, когда путешествуете сами? Потому что это ВАШИ деньги, которые заработаны. А почему вы решили, что они не заработаны Заказчиком и он к ним будет относиться также расточительно?

Не вредный совет №1: Относитесь к расходам так, как будто они ваши. С умом и разумной экономией.

Если вы себе не позволяете самый дорогой виски в ресторане (или гигантские устрицы), почему это становится доступным за деньги Заказчика? Если сами не летаете бизнес-классом, то почему вдруг стали?

Не вредный совет №2: Покажите Заказчику, что вы правильно и экономно расходуете бюджет.

Если вы покажете, что нашли вариант, который сохранит пару тысяч на командировке или при покупке сервера, то он поймет, что вы заботитесь об общем бюджете. Заказчик подумает: «Если человек внимателен к каждой трате, то и проектные траты у него точно под контролем».

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

И еще одно следствие из НЕ вредных советов. Я общаюсь со многими менеджерами в ИТ, некоторые из них занимают высокие позиции(Program Manager, Directors, VP, CEO) и они единогласны в своем мнении: Если человек неразумно (расточительно) подходит к расходам за счет Заказчика, то и к корпоративным тратам он отнесется так же. А значит, бюджет ему доверить нельзя. В большинстве случаев карьерное продвижение останавливается.

Вывод в стиле назойливой рекламы: Вы еще хотите лететь бизнес-классом за счет Заказчика, когда остальные летят экономным?

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

P.S.S. А еще вспомнил про извечное желание ШАРЫ, но почему-то писать о ней не хочется.

Oct 10th, 2011
Page 8 of 22« First...678910...20...Last »