Управление проектами
Проект Антона Витязя
Управление рисками проекта
Воздушная атака на неопределнность оценок
03 years
by Антон Витязь
in Планирование, Управление сроками проекта, Управление рисками проекта
В проекте при необходимости оценки работ можно столкнуться с ситуацией когда необходимо дать оценку проекта – а опыта выполнения данных задач нет и достоверных оценок тоже нет. Если вам повезло и это несколько десятков типичных задач разной сложности и вы можете позволить себе их попробовать - то следует выполнить пилот перед получением оценки.
Вот что по этому поводу советует из своего опыта руководитель проектов Киевстар Евгений Петров:
“Планировали миграцию данных (контент). Даже после проведенной инвентаризации трудно было оценить длительность. Кроме того исполнители еще были заняты функциональной деятельностью, их доступность была переменной величиной.
Что сделали:
1) Разделили мигрируемые данные на 3 категории (простой, средний, сложный);
2) Провели пилот. Несколько специалистов проводили миграцию разной сложности контента, скажем по 2 единицы каждой сложности. Данные усреднили по исполнителям. Получились оценки длительности миграции каждого типа сложности контента. Например Простой 1 день, средний – 2, Сложный – 5 дней.
3) Умножив оценку на количество, получили общий объем трудозатрат
4) Назначаем ресурсы, получаем длительность
5) Закладываем резерв после оценки рисков:
- переменная загрузка специалистов
- больничные
- инструменты миграции могут сбоить
- и т.д.
6) Коммуницируем спонсору и заказчику риски, договариваемся, что будем делать в случае их наступления
7) Начинаем работать!”
Из своего опыта работы по аналогичному сценарий могу добавить что после пункта (2) был сделан вывод что мы можем рассмотреть варианты
- Отправить задачу на outsource менее квалифицированным ресурсам (смогли найти в части задач ресурсы, провели обучения и задача была выполнена)
- Купить инструмент для миграции (рассмотрели, оказалось очень дорого по сравнению с бюджетом всего проекта)
- Написать инструмент для миграции которые делает ее полностью автоматически или существенно облегчает ряд рутинных операций (разработали несколько утилит которые сократили на четверть время и отбили с лихвой время потраченное на их разработку)
Спрашивайте про отсутствие
03 years
by Антон Витязь
in Управление сроками проекта, Управление человеческими ресурсами проекта, Управление рисками проекта
При общении с ключевыми лицами со стороны клиента периодически спрашивайте их про возможное отсутствие на ближайшее время. Дополнительно стоит договориться с HR и получать информацию про отпуска. Но все равно – вам нужно спрашивать людей лично.
Неизвестное отсутствие ключевых участников проекта как со стороны заказчика так и внутри команды проекта – это риск существенного сдвига сроков. И этот риск один из наиболее часто срабатывающих практически в любой период. Летом отпуска – более прогнозируемое. Зима – люди могут заболеть в любой момент, наибольший риск – эпидемии.
Отсутствие может быть самое разное. Для каждого из типов отсутствия стоит предпринимать разные действия:
- Отпуск - получайте данные у HR но обязательно сверяйте с сотрудником и его руководителем. Часто встречается ситуация когда отпуск в кадрый подает за год, а потом планы на отпуск меняются.
- Командировка - уточняйте как у сотрудника так и у его руководителя
- Обучение - уточняйте как у сотрудника, у его руководителя и у HR. Есть такие виды информации которые могут знать только HR (их планы по обучению сотрудников), только сотрудник (его личные планы по обучению), руководитель (договаривается об обучении сотрудников с тренером)
- Личные события (свадьба, лечение, небольшие отсутствия, посидеть с ребенком) – у сотрудника.
- Болезнь - уточните как человек часто болеет. Есть такие люди которые болеют пару дней в году, а есть такие – которые 3-4 раза по неделе за зиму. Уточните есть ли дети и как часто они болеют
Список вопросов по проблеме
03 years
by Антон Витязь
in Книга по управлению проектами, Мониторинг и управление, Управление качеством проекта, Управление рисками проекта
Когда перед нами проблема нам стоит себе задать ряд вопросов:
Первый взгляд на проблему
- Эта проблема имеет отношение к проекту?
- Как влияет проблема на проект – как это влияет на стоимость, качество, график проекта?
- Как это влияет на еще не реализовавшиеся риски проекта?
- Стоит ли нам вообще как-то реагировать на проблему?
- Кого мы должны оповестить о возникновении проблемы?
Вопросы по решению проблем
- Кто займется проблемой? Когда?
- Кого мы должны включить в группу решения проблемы?
- Кто оплачивает решение проблемы?
- Проблема должны быть вынесена на уровень выше?
- Эта проблема застрахована?
Вопросы по анализу проблем
- В чем причина возникновения проблемы?
- Какой это был риск? Повторится ли он еще раз?
- Как мы можем быстро ликвидировать проблему?
- Как мы можем ликвидировать источник проблемы?
- Какие меры нам надо предпринять чтобы минимизировать влияние проблемы?
Меряем проблему
- Как это влияет на удовлетворенность клиента?
- Сколько нам стоит проблема?
- Кто оплатит расхода ны проблему, ее устранение и предотвращение? Один за все части или можем как то перераспределить затраты?
- Какой приоритет у этой проблемы по отношению к другим проблемам и задачам проекта?
Закрываем проблему
- Как мы определим что проблема решена?
- Кто должен принять решение о закрытии проблемы?
- Кого мы должны оповестить о решении проблемы?
Данная статья взята из материалов книги Наша книга по управлению проектами
Философия проблем
03 years
by Антон Витязь
in Книга по управлению проектами, Управление рисками проекта
- Проблемы будут. Мы управляем рисками и готовим запас на непредвиденные проблемы. Плохо когда мы наступаем на проблему дважды и когда все наши проблемы – непредвиденная случайность или происки злых духов (судьбы, конкурентов, гавнюков с соседнего отдела). Чем мы тогда управляем?
- Проблемы – это сработавщие риски. Наша работа управлять рисками, не допускать их реализации или минимизровать их влияние в случае реализации. Делайте выводы из анализа проблем и в следующем проекте работайте над риском проблемы а не опять над проблемой. Не наступайте на грабли дважды.
- Мы говорим о проблемах сразу же. Все члены команды должны знать это и делать это. Если вы будете наказаывать гонца за то что он нам рассказал о том, что вражеское войско перешло границу – то вы узнаете об этом от вражеского войска под вашим домом.
- Мы обсуждаем проблемы без личностых выпадов и переводов стрелок. Мы решаем проблему а не людей. Нам необходимо решить проблему и принять меры по пресечению ее появления в будущем. Самое важное для команды которая работает длительный срок – капитализация знаний.
- Проблемы часто касаются именно руководителя проекта – в первую очередь это вопрос к качеству управления рисками, к качеству работы с командой и других процессов. Поэтому при анализе человеческого фактора – ставьте себя первым в список на разбор полета. Если причина проблемы это член команды и это не исправимо – это вопрос дипломатичного решения без театральных публичных действий. Хорошо подумайте о мотивации человека, о том дали ли ему реашть задачу адекватную его компетенциям, о его загрузке и приоритетах. Вычеркните неконтролируемые обстоятельства. Семь раз подумайте – а потом только принимайте решения бьющее по человеку.
- Если мы не решаем проблему – мы часть проблемы.
- Если мы скрываем проблему – мы проблема.
- Проблема часто не решается одним человеком и даже командой. Вполне нормально если мы обращаемся к менеджеру проекта. Также нормально если менеджер проекта эскалирует проблему на более высокий уровень.
- Менеджер проект постоянно эскалирующий проблемы вызывает вопросы в своей компетентности.
- Менеджер проекта который постоянно пытается решить проблемы вне его компетенции вызывает вопросы в своей компетентности.
Данная статья взята из материалов книги Наша книга по управлению проектами
Компоненты информационной среды управления проектами
03 years
by Антон Витязь
in MS Project, Sharepoint, Инструменты, Мониторинг и управление, Планирование, Управление интеграцией проекта, Управление качеством проекта, Управление человеческими ресурсами проекта, Управление коммуникациями проекта, Управление рисками проекта, Управление поставками проекта
Для более менее крупных проектов мы задумываемся о построении информационной системы для управления проектами. Прежде чем говорить – да у нас есть MS Project – и в северном варианте (Project Server) он будет очень классно покрывать все нужды – не спешите. Давайте рассмотрим основные компоненты такой среды и какие потенциальные компоненты могут подойти.
Коммуникации - сайт проекта, форум, рассылка, группы. Это может быть как сайт на SharePoint так и любая WiKi/Wordpress/LinkedIn группа. Для небольшого бизнеса вполне удобно создавать закрытые группы в социальных сетях и использовать их как готовые платформы для проектных коммуникаций.
Документы проекта – минимум файловый сервер. Лучше всего – сразу SharePoint или аналогичное средство с функционалом управления версиями. Если документы проекта будут готовиться исключить в веб форме – то вам также отлично подойдут Wiki системы. В них очень легко контролировать версии документов (но несколько сложнее научиться писать их с использованием внутренней разметки)
Записи проекта - это различные типы записей – структура работ, запросы на изменения, вопросы, дефекты, риски, требования, тесты, результаты выполнения тестов. Кроме фиксации самих записей важно чтобы работали хотя бы простые workflow по организации работы над записями – это даже крайне желательно. Для управления такого рода записями нужна система с удобным конструктором как новых записей так и процессов, удобными формами. SharePoint в базовой конфигурации для этого не очень хорошо подходит (но вполне терпимо для малых проектов). Хорошим кандидатом сюда – Microsoft Dynamics CRM 2010, SharePoint + Nintex + кастомные решения для организации документооборота. Также могут подойти ваши существующие ERP системы (в них легко создавать новые сущности и формы но менее просто решаются вопросы по автоматизации процессов)
Календарь проекта и Фактические данные – тут рулит Microsoft Project.
Управленческий учет – фиксация затрат, закупок, выставление счетов, поступление денежных средств, выплата заработной платы и компенсаций участником проекта). В проектах где мотивация персонала крепко связанна с их ежедневным вкладом в проект а их бонусы зависят от успеха проекта – крайне важно наладить прозрачную процедуру для перетока информации из записей проекта, плана проекта и фактических данных в управленческий учет.
6 углов проектного менеджера – уже не так железно
03 years
by Антон Витязь
in Методика, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта, Управление качеством проекта, Управление рисками проекта
Развитие концепции железного треугольника управления проектами- стоимость, время и содержание проекта – шестиугольник проектного управления.
В состав шестиугольника входят следующие дополнительные компоненты:
- Удовлетворенность клиента (Customer Satisfaction)
- Риск (Risk)
- Качество (Quality)
С моей точки зрения железный треугольник был действительно железным – меняя одну из составляющих мы неизбежно оказывали влияние на одну из двух других или обе. В случае с шестиугольником это уже не очевидно.
Удовлетворенность клиента – безусловно одна из важнейших составляющих проектного управления. Но в ней есть немало эмоционального контекста – и далеко не всегда она имеет прямые (железные) связи с изменением других компонент.
Аналогично риск. Сама природа риска такова что мы скорее не может полностью покрыть перечень рисков которым подвержен проект. В свою очередь точность измерения рисков также условна. Таким образом трудно утверждать насколько реально повлияло изменение одной из компонент на риск.
Сделать сделали, а передать то – забыли!
03 years
by Антон Витязь
in Внедрение, Завершающие, Инициация, Исполнение, Планирование, Управление интеграцией проекта, Управление содержанием проекта, Управление качеством проекта, Управление коммуникациями проекта, Управление рисками проекта
Среди ошибок проектных менеджеров при разработке новых ИТ сервисов встречается ошибка отсутствия блока необходимых работ по передаче сервиса в промышленную эксплуатацию.
Эта ошибка коренится в том что проектный менеджер забывает включить в перечень ключевых заинтересованных лиц ИТ менеджеров по операциям:
- менеджеров сервиса
- менеджеров по обслуживанию пользователей,
- техническая поддержка – контакт центр поддержки ИТ
Какие могут возникнуть риски? Масса!
Риск проблем с технической поддержкой. Уже во второй половине проекта часто начинается доносится тревожный звоночек – некоторые пользователи, которые участвуют в ознакомлении с первыми релизами продукта, вместо обговоренного контакта с менеджером проекта начинают по привычке звонить в техническую поддержку. Техническая поддержка может по разным причинам сделать следующее:
- Отказать пользователю в обслуживании – что создаст негативное впечатление о проекте
- Дать неверный совет по использованию ПО – что может привести к негативному впечатлению о продукте
- Дать обещание ответить пользователю и не выполнить обещание в срок – пока поддержка начнет искать кто реально может обслужить данный вопрос. Хуже всего если в технической поддержке просто забросят вопрос.
Конфликт с другим сервисом находящимся в промышленной эксплуатации. Хуже всего если это важный операционный сервис критичный для работы бизнеса. Данный конфликт может создать проблемы для текущих операций пользователей. Кроме всего прочего это может косвенно указать на архитектурные ошибки или ошибки в планировании развертывания – связанные с тем что не были учтены все сервисы работающие у конечных пользователей продукта.
Что необходимо сделать менеджеру проекта:
- Обязательно включить в перечень заинтересованных лиц менеджеров по ИТ операциям. Найти всех кто отвечает за работу с пользователями, техническую поддержку. Включить в перечень ключевых лиц в работу над архитектурой, развертыванием и тестированием. Обязательно в этап передачи в эксплуатацию и go live.
- Определить порядок приема в эксплуатацию. Какие внутренние стандарты приняты в компании по передачи ИТ сервисов в эксплуатацию?
- Вовлечь в работу и информировать. Делать рассылки о всех операциях в рамках проекта которые касаются конечных пользователей. Установить процедуру согласования подобных операций.
- Включить в план проекта работы по обучению технической поддержки и менеджеров по ИТ операциям на всех стадиях проекта – от ознакомительной на ранней стадии, совместной работы над архитектурой, планами по развертыванию и тестированию до конечного обучения.
Критичность закрытия фаз/итераций. Пример из практики
03 years
by Антон Витязь
in Анализ, Завершающие, Инициация, Исполнение, Мониторинг и управление, Планирование, Процессы, Управление интеграцией проекта, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта, Управление качеством проекта, Управление человеческими ресурсами проекта, Управление коммуникациями проекта, Управление рисками проекта, Управление поставками проекта
Очень важно в крупных корпоративных проектах закрывать фазы (этапа, итерации) согласованием пакета закрывающих документов.
Сам факт закрытия фазы позволяет:
- показать промежуточный результат в проекте
- согласовать с заказчиком понимание где сейчас находится проект
- отметить срез ключевых показателей проекта – по срокам, стоимости и объему работ
- определить легитимную основу для дальнейших действий
- снизить риски разногласий, проблем в понимании достигнутых договоренностей и результатов
- приучить заказчика к умению закрывать проект – приучать к этому нужно с ранних этапов, делать это системно по четко определенной процедуре
- выстраивать логическую связь от достигнутых результатов к запланированном на следующем этапе
Из практики отечественных проектов встречались ситуации когда в проекте на этапе зависли на согласовании несколько аналитических документов. Казалось бы согласованным в документах было около 80%. Команда проекта решила что необходимо двигаться к разработке и по ходе решить оставшиеся 20% требований. Однако в течении нескольких последующих месяцев это привело к тому что
- аналитический документ и зменился более чем на половину
- объем работ вырос в полтора раза
- было потеряно около трети времени на разработку в следствии кардинального изменения
- существенно изменились сроки проекта
- поставщик понес убытки на потерянном объеме работ
- клиент был недоволен что “его по-прежнему не пониманию и делают всякую ерунду”
- клиент наблюдая податливость в протягивании согласования аналитического документа позволял себе “пропихивать” новые изменения и расширять рамки проекта
Рискариум
03 years
by Антон Витязь
in Новости, Управление рисками проекта
Уважаемые коллеги!
Есть предложение создать пополняемый реестр рисков ИТ проектов. Формат – аналогично описанию паттернов: указываем описание рисков, причину возникновения, влияние на проект, возможные методы предотвращения, минимизации и т.п.
Считаете ли вы интересным и полезным создание такого ресурса? Готовы ли вы участвовать в создании и/или наполнении такого ресурса?
Производить или закупать? Плюсы и минусы делать самим
03 years
by Антон Витязь
in Инициация, Управление рисками проекта, Управление поставками проекта
Когда в компании запускается очередной проект – всегда возникает вопрос со стратегией его выполнения:
- Делать полностью самим
- Отдать на outsource (объявить тендер, отдать большую часть работы подрядчику)
- Промежуточный вариант – около половины работ выполняется внутри компании (как правило это проектный менеджмент, анализ и тестирование) а остальное – по прямым контрактам с фрилансерами или небольшими компаниями.
У каждого из этих вариантов есть свои плюсы и минусы. В этой статье мы рассмотрим плюсы и минусы варианта делать самим.
Делать самим – плюсы:
- Полный контроль над ресурсами
- Низкая стоимость ресурсов (в большинстве случаев это так – если за управление проектом не берется менеджмент с очень высокими зарплатами)
- Конфиденциальность выше
- Накопление и сохранение опыта (если нет высокой текучести кадров)
Делать самим – минусы:
- Неравномерность загрузки ресурсов. Далее привлеченные ресурсы могут быть не востребованы
- Недостаток опыта у ресурсов, недостаток опытных руководителей проектов
- Перегруженность ресурсов проекта в операционной деятельности
- Невысокий уровень масштабируемости – нет возможности быстро добавить ресурсы необходимой квалификации
- Зависимость от потери сотрудников – чем меньше людей в курсе проекта тем больше компания зависит от знаний индивидуума. Как правило во внутренних проектах низкий уровень документирования решений.
Типичная ситуация – развитие ИТ системы, которое требует выполнения множества мини проектов по изменению или небольшой доработке. Такие проекты не требуют уникальной и/или высокой квалификации ресурсов. Например – долгосрочная программа по развитию внутреннего корпоративного портала или системы документооборота. Для изначального развертывания и проектирования архитектуры уместно будет привлекать внешнего подрядчика с передачей опыта дальнейшей поддержки решения внутренней команде разработки.
Next »