Треугольник качества проекта = треугольник вины менеджера

Кто я: меня зовут Науменко Алексей и я руководитель ИТ-проектов с более чем 5 летним стажем и с профессиональным образованием в области ИТ-менеджмента.

Цель статьи: Я описываю свой опыт в реализации ИТ-проектов для повышения своей сознательности и профессионализма, а также для обмена опыта с представителями профессионального сообщества, для личного роста в профессиональной сфере.

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

Ядро моего представления о проблемах и решениях ИТ-проектов сводится к социальной инженерии. Кадры решают все и ключи повышения эффективности ИТ проекта кроются не в технологиях, а в личностях, отношениях между ними и сообществах.

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

Проблема №1: Треугольник качества проекта

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

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

Задача РП сводится к тому, чтобы реализовать треугольник качества проекта максимально приближенным к плановым параметрам.

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

Правила параметров:

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

Решение проблемы треугольника качества:

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

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

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

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

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

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

Как применять треугольник качества проекта на практике:

Вывод: выбор в пользу сохранения качества и соответствия требованиям в ущерб срокам и стоимости сохраняет ценность продукта является единственно правильным решением в неразрешимом конфликте “сроки/затраты/практическая ценность”