Задо-прикрывательное управление проектами

Задо-прикрывательное управление проектами

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

И, безусловно, существуют проекты, которые можно, по крайней мере частично, определить как задо-прекрывательные.

Это происходит, как правило, когда выполняется хотя бы одно условие:

  • Клиент постоянно меняет границы проекта (scope).
  • Существует значительные задержки, которые не могут быть четко приписаны одной из сторон.
  • Проектые группы не любят друг друга.
  • Выбор поставщика является политическим решением.

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

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

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

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

  1. Письмо о принятых решениях и дальнейших действиях (Follow-up).
    В такой обстановке вы не получите больше информации на бумаге или в электронных письмах. Большинство сообщений будет сделано по телефону. Почему? Чтобы не было доказательств. Не было стресса. После важных (с вашей точки зрения) телефонных звонков просто потратьте какое-то время, чтобы написать письмо о дальнейших действиях и договоренностях : «Как мы договорились в ходе нашего телефонного разговора …». Вы должны действовать, как будто вы просто хотите подтвердить или уточнить согласованные детали.
  2. Успокойтесь.
    Вы будете получать сообщения, которые вызовут у вас гнев. Нечестные, не соответствует действительности. Вы будете торопиться гневно отвечать на такие письма. Подождите. Успокойтесь. Когда вы в гневе, есть вероятность написать то, о чем можно в дальнейшем пожалеть. Хитрость здесь заключается в том, чтобы написать ответ мгновенно, но, вместо отправки сообщения прочитать его, а затем удалить. Затем написать ответ еще раз. В экстримальных ситуациях я посылаю письмо с третьего раза.
  3. Просите доказательств.
    В атмосфере когда пытаются подловить на чем либо другую сторону вы часто сталкнетесь с ситуацией, когда кто-то имеет в виду или подразумевает что-либо, о чем вы еще не договаривались или не делали. В этом случае просите доказательств . Не рассматривайте эту ситуацию как нормальное положение дел, и утверджайте, что ничего подобного не обсуждалось и нигде не оговаривалось. И поскольку правда на вашей стороне, скорее всего вы больше не услышите подобных обвинений.
  4. Будьте активны.
    Рассматривайте это как игру. Вы не только должны защищаться, но вы можете также атаковать противника. Подумайте немного должна ли вам что-то другая сторона. Если да, то просто напишите красивое письмо: «Так как Вы еще не завершили вашу задачу мы не можем продолжать этот проект в этой области, и это предлагает задержку в …» Вы будете удивлены, каким образом это может улучшить участие другой стороны в завершении их работы.
  5. Обострение (Escalate).
    Исспользуйте организационные структуры обеих компаний (своей и клиента). В зависимости от проблемы, иногда, давайте о ней знать более высоким чинам,это может значительно помочь в ее разрешении. Особенно, когда все действия разворачиваются слишком далеко от вас. Здесь я не буду давать вам простых советов, когда следет эскалировать, если не остается ничего другого. Вы должны попробовать оценить ситуацию и пойти на то, что вам показалось наиболее подходящим в данный момент. Помните, что чрезмерные эскалации могут привести к добавлению вас в «в черный список» не умеющих принимать самостоятельные решения.

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

Оригинал статьи: Pawel Brodzinski Ass-covering Project Management

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

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

5 Comments

  1. Прямо в точку. Наверное многие видели такие методы управления проектами на своей работе. Еще одна из причин — нас не учат брать ответсвенность, у нас это непринято, у нас это не поощряется..

    P.S. Картинка что надо :)

  2. Честно говоря — почитал признаки таких проектов и понял, что не участвовал ни в одном, который не был бы в какой-то мере ass-covering. А приведённые рекомендации годятся не только для каких-то особых проектов, а вообще для любых. Т.е заказчик в любом случае будет хотеть получить больше за свои деньги, другие проектные группы наверняка будут работать в конкурентном режиме (вы же отбираете их хлеб), задержки сдачи проектов в индустрии программого обеспечения — вообще просто притча во языцех.
    Алексей, а где учат брать ответственность? Это, по-моему, не столько вопрос навыка, сколько… мировоззрения что ли.

  3. Задело за живое, я плакаль…

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

  4. Такое встречается довольно часто, но управлять нужно не только подчиненными, но и начальниками, иначе иногда преходиться время от времени из-за них же и страдать, перерабатывая и т.п. Однако тут должно быть немного другого рода управление. Как сказал мой один хороший знакомый, по совместительству еще и начальник, несмотря на то как организована работа на стороне клиента, необходимо создать и сохранять порядок у себя. Я бы порекомендовал:
    1) побольше оптимизма, не все еще потеряно
    2) определить полномочия и обязанности необходимо, не смотря на то что проект уже идет
    3) договариваться о объеме работ и сроках заранее и стараться выдерживать их добросовестно.
    4) если задания даются устно, а затем идет большой поток изменений, то ввести систему управления изменениями (простейщий случай на основе электронной почты)

  5. Оптимизма я не теряю. Пытаюсь планировать дальнейшую работу, чтобы сгладить отрицательные последствия.
    Если честно. Если б я заранее знал с чем столкнусь — пошел бы по одному из вариантов.
    1- сделал бы все по другому
    2- Вообще не брался бы за проект. ;)
    Опыта у меня мало, мало понимал с чем столкнусь. После того как столкнулся с рядом проблем, набрался немного опыта (его конечно все равно мало). Кроме того, съездил на обучение PM.
    Сейчас я вижу свою задачу как можно быстрее написать первый вариант программы (Начальный вариант ТЗ мной уже написан), протестировать. Постараться внедрить, чтобы люди могли уже работать, и привыкать к ней, а затем путем эволюции уже ее совершенствовать…

    Денис, Спасибо за советы и поддержку!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *