Управление интеграцией проекта

А ваша команда отдыхает?

0

Много недель постоянной работы. Месяц сменяет месяц – команда работает над проектом.

А вы не замечали что команда начинает “подтормаживать” когда переходит от реализации одного большого куска требований к другим?

А сетует ли команда на то что они могли сделать что-то лучше если бы у них был день на изучение новой библиотеки?

Не успевают с подготовкой для сертификации? Уже хотят в отпуск?

Команде надо дать отдохнуть.


Поюзанная команда – это плохо.

 

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

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

Между пакетам работ на протяжении последних 3-4 недель следует сделать день (лучше два) перерыва.

  • Хорошо когда этот день будет пятница или другой день перед однодневными выходными.
  • Сделайте рабочий день – днем работы с чем угодно. Но после него убедитесь что есть выходные
  • Дайте обязательно день на обучение. Предварительно соберите информацию о том кто к каким сертификационным экзаменам готовится. Поставьте открытую доску продвижения к результату. Это будет мобилизировать тех кто готовится к экзамен и руководству напомнит про то что надо способствовать продвижению сотрудников на сложной стезе к успешной сдаче экзаменов. И день на подготовку хотя бы раз в две недели – это то про что вы должны не забывать.
  • Если у вас “жирный бюджет” – сделайте сдачу промежуточных результатов в Форосе, на берегу Черного моря. Или на худой конце в ближайшей рекреационной зоне около вашего города. Это не значит поехать бухнуть! Это именно сдача результатов + небольшое обучение.

Ведь это же не задача полететь на Марс, правда? ;-)

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

0

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

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

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

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

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

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

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

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

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

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

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

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

Перевод «How we got rid of time reports» Henrik Kniberg

0

Отличная статья на Хабре “Как мы избавились от отчетов о выполненных работах” - http://habrahabr.ru/blogs/agile/111732/

PS Сразу хочу оговориться что данные идеи классные но могут быть не применимы для определенных видов бизнеса. Например, если надо выставлять счета клиенту с часами и с разбивкой по задачам – то вам не избежать процедуры фиксации времени. Другое дело что ее нужно максимально упростить.

Цитаты из статьи:

“Это раздражало. Не только потому, что это просто занимало время и отвлекало всех, но и потому, что моя работа по «утверждению» отчетов было в основном игрой в
угадайку. У меня не было никаких рабочих способов узнать, правилен ли отчет.”

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

“Сейчас мы используем эти отчеты, чтобы считать овертайм. Но заполнять отчеты уныло, а работать овертайм – это еще более уныло. Мы все знаем, что один час энергичной, мотивированной, сфокусированной разработки полезнее целой недели зомби-кодинга”

Так что такое предложение. Больше нет отчетов. И больше нет овертайма.

«Конечно, иногда могут быть исключения. В таких случаях будет работать традиционная система компенсаций за переработки. Мы будем стараться минимизировать такие случаи и разбираться с ними в каждом отдельном случае. Если сомневаетесь – позовите меня».

«Manage for the normal and treat exceptions as exceptional»
— Edwards Deming

Обязательства, задачи и факт

0

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

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

С обязательствами может быть связан перечень задач. Часть это перечня задач может быть видна заказчику, часть – нет. По задачам мы собираем факт затрат – времени сотрудников, компонент, закупок и т.п. Часть затрат получают оценку (по установленным в контракте часовым ставкам, по прайсу), могут быть предоставлены скидки.

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

0

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

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

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

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

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

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

 

NASA Guidance for writing Work Statement

0

http://www.hq.nasa.gov/office/procurement/newreq1.htm

DoD Handbook for Preparation of Statement of Work

0

DOD Handbook For Preparations of  SOW.pdf

Документ определения работы

0

В данной статье к вашему вниманию предлагается один из первых документов проекта – Документ определения работы (Statement of Work, SOW). По результатам описания документа будет предложен к обсуждению шаблон данного документа.

Следует отметить что в нашей практике документ с названием Документ определения работы встречается редко. Чаще всего он принимает вид Технического задания или просто договора или приложений к договору. Далее будем придерживаться его классического названия – Документ определения работ (Statement of Work). По тексту будем применять как полное так и сокращенное название документа (SOW)

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

Типы SOW. SOW может составляться на разных этапах проекта. На этапе инициации подачи предложений от поставщиков (Proposal SOW, PSOW) и на этапе подписания договора с конкретным поставщиком (Contract SOW, CSOW).

Состав документа. Давайте рассмотрим более подробно каждую из составляющих документа определения работы ориентируясь на CSOW тип документа:

  • Определение проекта
    • Проблема/Возможность – что является основанием для выполнения проекта (почему).
    • Стратегия решения – какая стратегия решения проблемы реализации возможности (каким образом)
    • Видение решения – краткое описание решения (что).
    • Цель проекта – определение целей проекта со стороны заказчика
    • Границы проекта – что входит и что не входит в проект.
  • Результаты проекта – состав продуктов и услуг которые получит заказчик от исполнителя проекта, ключевые документы и результаты работ проекта. Желательно не перегружать основной документ большим объемом описания бизнес требований к продуктам и услугам – а вынести это в отдельное приложение.
  • Роли и ответственность – указание ролей и ответственность за результаты проекта, процессы или отдельные работы. Перечень конкретных людей с указанием их ролей.
  • Условия - перечень условий и правил выполнения работ. Следует рассмотреть условия выполнения работ с обеих сторон – заказчика и исполнителя.
    • Условия оплаты
    • Условия по объему работ
    • Условия по срокам
    • Условия конфиденциальности
    • Условия по определению прав собственности
    • Условия по квалификации участников проекта
    • Санкции и штрафы
    • Условия по соответствию стандартам и законодательству
    • Форсмажор
  • Подход к выполнению работ – описание ключевых требований к порядку выполнения работ. Если есть задокументированная методика проектного управления – достаточно указать требования по следованию методикой и включить ее как приложение к документу. Следует рассмотреть порядок выполнения работ с обеих сторон – заказчика и исполнителя.
    • Порядок контроля выполнения работ
    • Порядок управления изменениями
    • Порядок приема работ
    • Порядок передачи результатов работ
    • Порядок оплаты работ
    • Подход к решению проблем
    • Порядок коммуникаций
    • Порядок замены состава участников проекта

Рекомендуемые приложения к документу:

  • Ключевые бизнес требования к продуктам и услугам (business requirements)
  • Первичная структура работ (WBS)
  • Соглашение по качеству предоставляемых услуг (QoS)

Опциональные приложения к документу:

  • Методика проектного управления применимая к проекту
  • Шаблоны документов, форм
  • Детальные политики на которые ссылаются из документа
  • Первичная оценка графика работ
  • Перечень ключевых показателей проекта (KPI)

Опубликована книга Collaborative Project Management Guide от brightwork

0

Ссылка на книгу – правда это скорее большая статья :-)

Заход на регистрацию для получения книги и дополнительных материалов тут – http://www.brightwork.com/webcasts/collaborative_project_management.asp?event=4

Сделать сделали, а передать то – забыли!

0

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

Эта ошибка коренится в том что проектный менеджер забывает включить в перечень ключевых заинтересованных лиц ИТ менеджеров по операциям:

  • менеджеров сервиса
  • менеджеров по обслуживанию пользователей,
  • техническая поддержка – контакт центр поддержки ИТ

Какие могут возникнуть риски? Масса!

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

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

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

Что необходимо сделать менеджеру проекта:

  • Обязательно включить в перечень заинтересованных лиц менеджеров по ИТ операциям. Найти всех кто отвечает за работу с пользователями, техническую поддержку. Включить в перечень ключевых лиц в работу над архитектурой, развертыванием и тестированием. Обязательно в этап передачи в эксплуатацию и go live.
  • Определить порядок приема в эксплуатацию. Какие внутренние стандарты приняты в компании по передачи ИТ сервисов в эксплуатацию?
  • Вовлечь в работу и информировать. Делать рассылки о всех операциях в рамках проекта которые касаются конечных пользователей. Установить процедуру согласования подобных операций.
  • Включить в план проекта работы по обучению технической поддержки и менеджеров по ИТ операциям на всех стадиях проекта – от ознакомительной на ранней стадии, совместной работы над архитектурой, планами по развертыванию и тестированию до конечного обучения.

 

Go to Top