Мониторинг и управление

Волна по каплям принятых сдвигов по ресурсам

0

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

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

Поразительно – но даже согласованные и благославленные сдвиги ресурсов высшим руководством в конце концов не спишутся. О них руководство через месяц точно забудет – для них это будет все рутина принятых мимолетных решений. А вот через месяц ваш проект и ваш сдвиг со сроками будет им резать глаз.

Что можно делать в такой ситуации?

  1. Записывать все изменения в ресурсах и их влияние. По возможности получать согласование такой записи – или хотя бы прикреплять к ней то что можно считать согласованием (например, письмо от руководителя).
  2. По каждому изменений – в какой форме оно бы не поступало - отписываетесь коротким письмо на руководителя с обратной связью – что вы приняли измение и что вы напоминаете про эффект данного изменения на проект.
  3. Доводите информацию об изменениях в статусе проекта.
  4. Не принимайте изменения которые противоречат уставу проекта или стратегии определенной спонсором проекта. Если это конфликт – решайте его. Если не можете – вовлекайте спонсора проекта.
  5. Постарайтесь найти способ компенсировать выдернутые ресурсы – возможно вы сможете найти замену человек или договориться про увеличение его ресурса времени на ваш проект позднее

 

Управление по контрольным точкам

0

Часто повторяемым инструментом на последней конференции было управление по контрольным точкам (Milestone Trend Analysis) – как инструмент для топ менеджмента / спонсора проекта.

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

Ключевые точки могут быть как частью проекта так и лежать вне его – быть на уровне программы или портфеля проектов. Для руководителя строится одна или несколько карт контрольных точек – набор связанных по смысле контрольных точек (7+/-2) отложенных по вертикали на плановую дату контрольной точке а по горизонтали – на состояние контрольной точки на отчетную дату.

Влияние спонсора на успех проекта – понимать и использовать

0

Спонсор проекта – это ключевое заинтересованное лицо в проекте, “играющий” инвестор. Как правило, это один из топ менеджеров компании. Именно его высокий статус, полномочия, связи и знания крайне важны для проекта. Все это является сильнейшим компонентом в проекте.

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

Время его участия в проекте может быть минимальным- но влияние на успех проекта – огромным. Руководитель проекта должен знать про ключевые возможности своего спонсора проекта и использовать их по возможности:

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

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

Есть немало вопросов, которые стоит обсудить об отношениях между руководителем проекта и спонсором:

  • А всегда ли руководитель проекта это понимает и правильно использует?
  • Какие нюансы возникают в отношениях между спонсором и руководителем проекта?
  • Что делать руководителю проекта, если внимание спонсора проекта угасает?
  • Что следует знать о внутренней политической ситуации в компании руководителю проекта?

Приглашаю вас послушать подробный доклад, а также обсудить все эти вопросы с моим коллегой, Олегом Андриенко, руководителем проектов/тренером компании SMART business, http://www.smartbusiness.com.ua/) на Project Management Camp (http://pm.camp.org.ua/).

 

Оценки с размахом. Как нам оценить такую задачу?

0

В вашем проекте есть задача по которой эксперт дает такую оценку: задача эта дня на 3-4, но если будут сложности то может понадобиться дней 6-7, не меньше как часа 3-4 в день успею поковыряться. Но если будут серьезные проблемы то может недели две а то и вовсе не знаю сколько. При серьезных проблемах у нас нет гарантии скорости ответа и готовности ответа от вендора.

Как нам оценить такую задачу?

Их убить невозможно, но бороться – надо

0

Только что Вася сказал Гол, а 10 минут назад у Светы заиграла на телефоне Ломбада. Пришел емейл …. И тут зазвонил у меня телефон.

Кто говорит? …

И такая чехарда – каждые 15-20 минут.

Шумелки-мешалки-отвлекалки.

Это очень-очень-ОЧЕНЬ мешает работе команде.

Отвлекалки могут быть:

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

С личными бороться надо строго индивидуально – строго и индивидуально. Запретить шумные звонки на мобильном – скажем так – вибро хватит. Общаться по телефону – вышел и пообщался. Умерить пыл любителей громко зачитать новое хокку или новость про Яблоки. Все в меру, всему свое время. Прежде чем радостно завопить про то что в Грузии был съеден еще один галстук – как минимум оглядеться и убедится что команда в это время готово оторваться от дел ради того чтобы перейти к командной коммуникации на тему.

Командные отвлечения все таки нужны – небольшой командный расслобон – это часть культуры команды. Главное чтобы его не было много и часто. Рабочие разговоры лучше проводить в отведенное время – а не тогда когда командное Гыыыы срывает одного-двух членов команды из сфокусированной работы.

Сложнее всего бороться с первым типом – операционными отвлекалками. Это сложно когда ваш отдел работает в Большой Компании – и кроме проектной работы сотрудники еще отвечают за поддержку систем. Частота звонков, емейлов и заходов из соседних отделов может разваливать на глазах планы человека “сегодня часа четыре поработать над проектом”. Время просачивается от звонка к звонку – на звонок, на отвлечение, на какие-то небольшие действия + на все это переключение контекста. Что делать?

Пробуем следующее

  • Если у вас есть Контакт Центр – договоритесь что переключите на время Ч звонки всех сотрудников на него. Контакт центр записывает обращение и руководителю проекта или менеджеру поступает информация о них. Исключение – заявки с определенным высоким статусом.
  • Просите сотрудников отключать почту минимум на пол часа – особенно в те моменты когда им надо сосредоточенно поработать. Всплывающая информация о поступивших емейлах – это не меньшее зло чем звонящий телефон. В любом случае отвлекает внимание. Еще и рука на автомате тянется проверить почту.
  • В течении месяца потратьте время на фиксирования всех отвлекалок. Скорее всего вы определить ряд центров генерации отвлечения – с ними вам потребуется провести переговоры. Поговорите о том какой вред наносит проектной команде разные виды отвлечения.
  • Внимательно посмотрите в зеркало. Руководители отделов и менеджеры проектов иногда являются одним из серьезных типов раздражения в команде. Цените время команды – успех в ее работе – это ваш успех.

Про правильное измерение прогресса проекта

0

The measures of progress using the passage of time and the consumption of resources is simply Bad Management.

Herding Cats

Отчёты работают только для самодисциплины

0

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

 

http://habrahabr.ru/blogs/agile/111732/#comment_3567856

Список вопросов по проблеме

0

Когда перед нами проблема нам стоит себе задать ряд вопросов:

Первый взгляд на проблему

  • Эта проблема имеет отношение к проекту?
  • Как влияет проблема на проект – как это влияет на стоимость, качество, график проекта?
  • Как это влияет на еще не реализовавшиеся риски проекта?
  • Стоит ли нам вообще как-то реагировать на проблему?
  • Кого мы должны оповестить о возникновении проблемы?

Вопросы по решению проблем

  • Кто займется проблемой? Когда?
  • Кого мы должны включить в группу решения проблемы?
  • Кто оплачивает решение проблемы?
  • Проблема должны быть вынесена на уровень выше?
  • Эта проблема застрахована?

Вопросы по анализу проблем

  • В чем причина возникновения проблемы?
  • Какой это был риск? Повторится ли он еще раз?
  • Как мы можем быстро ликвидировать проблему?
  • Как мы можем ликвидировать источник проблемы?
  • Какие меры нам надо предпринять чтобы минимизировать влияние проблемы?

Меряем проблему

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

Закрываем проблему

  • Как мы определим что проблема решена?
  • Кто должен принять решение о закрытии проблемы?
  • Кого мы должны оповестить о решении проблемы?

Данная статья взята из материалов книги Наша книга по управлению проектами

Компоненты информационной среды управления проектами

0

Для более менее крупных проектов мы задумываемся о построении информационной системы для управления проектами. Прежде чем говорить – да у нас есть MS Project – и в северном варианте (Project Server) он будет очень классно покрывать все нужды – не спешите. Давайте рассмотрим основные компоненты такой среды и какие потенциальные компоненты могут подойти.

Коммуникации - сайт проекта, форум, рассылка, группы. Это может быть как сайт на SharePoint так и любая WiKi/Wordpress/LinkedIn группа. Для небольшого бизнеса вполне удобно создавать закрытые группы в социальных сетях и использовать их как готовые платформы для проектных коммуникаций.

Документы проекта – минимум файловый сервер. Лучше всего – сразу SharePoint или аналогичное средство с функционалом управления версиями. Если документы проекта будут готовиться исключить в веб форме – то вам также отлично подойдут Wiki системы. В них очень легко контролировать версии документов (но несколько сложнее научиться писать их с использованием внутренней разметки)

Записи проекта - это различные типы записей – структура работ, запросы на изменения, вопросы, дефекты, риски, требования, тесты, результаты выполнения тестов. Кроме фиксации самих записей важно чтобы работали хотя бы простые workflow по организации работы над записями – это даже крайне желательно. Для управления такого рода записями нужна система с удобным конструктором как новых записей так и процессов, удобными формами. SharePoint в базовой конфигурации для этого не очень хорошо подходит (но вполне терпимо для малых проектов). Хорошим кандидатом сюда – Microsoft Dynamics CRM  2010, SharePoint + Nintex + кастомные решения для организации документооборота. Также могут подойти ваши существующие ERP системы (в них легко создавать новые сущности и формы но менее просто решаются вопросы по автоматизации процессов)

Календарь проекта и Фактические данные – тут рулит Microsoft Project.

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

 

Применение горизонта планирования в Microsoft Project

0

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

В таком случае мы говорим о Горизонте планирования.

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

При использовании Microsoft Project вы можете несколькими способами определить в плане проекта горизонт планирования:

  • Использовать стандартную колонку (атрибут задачи) Publish (Публиковать)
  • Добавить колонку с указанием входит задача в горизонт планирования или нет

При использовании атрибута Publish (Публиковать) вы получаете возможность определять какие задачи будут опубликованы для исполнителей на проектном сервере а какие нет. Таким образом достигается автоматическое определение какая задача готова для передачи к сведению исполнителям – а какие еще не готовы.

Ниже для примера план проекта в котором несколько задач разработки закрыты для публикации:

Go to Top