Управление проектами: принципы

В который раз приходит необходимость сформировать принципы управления проектами…
Попробую написать то, с чем живу я:

1. Правила по которым проходит проект, происходит поставка задач, багфиксинг, запуск и сдача проекта - ЕДИНЫ ДЛЯ ВСЕХ СОТРУДНИКОВ КОМПАНИИ. Это означает что ни генеральный, ни коммерческий директор не могут ставить задачи в нарушение этих правил….

Теоритически конечно могут, однако в этом случае стоит признать что система в не зависимости от состояния будет разваливаться…

2. Ответственность. В проекте принимает решения только ОДИН ЧЕЛОВЕК. Все члены команды должны это знать. Ответсвенный за проект может делегировать принятие решений другому сотруднику в рамках этапа, за который тот является ответсвенным, в рамках существующей документации, ограничений и сроков. Такие процедуры должны фиксироваться документально.

3. Контроль проекта со стороны менеджера проекта осуществляется в заранее оговоренных контрольных точках.

4. Управление требованиями осуществляется по ЕДИНЫМ ПРАВИЛАМ. Это означает, что никто (ни руководство компании, ни заказчик) не имеет право указывать что и как делать вне утвержденных правил.

Правило 4 как и некоторые другие по другому работают в Agile. Здесь речь идет о классическом Waterfall

5. Единственными критериями качества проекта являются: УТВЕРЖДЕННЫЕ ТРЕБОВАНИЯ ПО ПРОЕКТУ, УТВЕРЖДЕННЫЕ СТАНДАРТЫ РАБОТЫ КОМПАНИИ. Только несоответсвие этим требованиям может быть критерием неприемки работы.

6. Пожелания заказчика, пожелания сотрудников, требования стандартов не утвержденных в компании - все это обрабатывается как ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ в оговоренных точках, принятие положительных решений по ним ведет к УЛУЧШЕНИЮ КАЧЕСТВА ПРОДУКТА (а не к его доработке). Это означает увеличение сроков и бюджета проекта.

7. Процедура поддержки проектов должна быть выделена в отдельную процедуру с фиксированным сроком.

8. Правила поставноки задач и их приоритеты должны исходить их СТАНДАРТОВ компании, а не из желаний отдельных людей. Даже если эти желания и замечания справедливы.

9. Проект не запускается БЕЗ РЕСУРСОВ

10. Проект не запускается БЕЗ ТРЕБОВАНИЙ.

11. Сроки этапов и проекта могут корректироваться при:

1) Появление новых утвержденных требований в рамках проекта со стороны Заказчика.

2) Появление задач более высокого приоритета в рамках других проектов.

3) Зафиксированное изменение требований со стороны Компании.

12. Проект не запускается без БЮДЖЕТА

13. Проект не запускается без ЧЕТКО ОГОВОРЕННЫХ ВНУТРЕННИХ ЦЕЛЕЙ ПРОЕКТА

14. Планирование работ по проекту ЗАНИМАЕТСЯ ОДИН ЧЕЛОВЕК. Только план написанный лично руководителем проекта имеет смысл.

15. Переключение ответсвенности - самый важный момент в управлении проектами.

16. Любые задачи по проекту должны быть четко поделены по принципу “поддержка”, “устранение неисправности” “улучшение”.

17. Нет лучшего инструмента для расстановки приоритетов в задачах чем классические инструменты тайм-менеджмента

срочно-важно
срочно-неважно
несрочно-важно
несрочно-неважно

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

Я обычно использую следующие названия для таких приоритетов

срочно-важно - критично авария

срочно-неважно - сегодня

несрочно-важно - план

несрочно-неважно - фоновый режим

Хм… Это первая версия написанная “слету”… Чуть попозже подготовлю выверенную редакцию..