Fixed-price со скрытым конфликтом

Последние полгода был занят на fixed price проектах, и что характерно несмотря на различния в сферах применения в них было много общего.

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

Самое основное, что объеденяет проекты такого рода это изначальное наличие конфликтной ситуации:

Чтобы завершить проект, как планировалось, во время и в рамках бюджета, необходимо зафиксировать требования (freeze requirements), и не допускать дальнейшего изменения и разрастания требований.

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

Данную ситуацию можно изобразить с помощью следующей «грозовой тучи конфликта» которые исспользуют в теории ограничений

В основном заказчик зачастую сам не подозревает как сказываются на конечном результате фиксированые требования, и так как к этому вынуждает его существующая юридическая практика, а также его опыт работы с не-ИТ подрядчиками.

Итак заказчик объявляет тендер, и находит подходящего исполнителя. Подписываются все общепринятые документы в которых как правило фиксируется бюджет, сроки (с обозначены штрафами за их нарушение) и содержание проекта (в виде ТЗ или другого документа). Итак исполнитель приступает к работе и оказывается, что все стороны «проектного треугольника» зафиксированны.

При этом особо не играет роли детально ли описано ТЗ (так как оно стало устаревать не успев попасть на стол к разработчикам), либо не детальное ТЗ с туманными формулировками — в любом случае оно потребует уточнений и внесения изменений.

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

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

Т.о. fixed-price проекты не ведут к win-win ситации как для заказчика, так и для исполнителя.

Вывод напрашивается сам собой: Осторожно fixed-price !!!

PS: А как же жить дальше попробуем разобратся в следующих выпусках.

5 Comments

  1. Даже в случае fixed-price исполнитель ведь может закладывать буфера по стоимости, скрытые, либо явные (отдельно оговорив это с заказчиком). В российской практике, конечно же, активно практикуются скрытые буфера.

  2. Буфер закладывать конечно необходимо, однако найти балланс очень трудно, если он будет большой то стоимость проекта будет неконкурентна, если маленький, то нет гарантии что его будет достаточно.

    Также я пока еще не встречал заказчика который бы в начале проекта подтвердил что будут изменения и необходимо закладывать запас на них, как правило для него в fixed price это не выгодно делать.

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

  3. Этот процесс называется в управлении проектами как «Управление изменениями в содержании».
    Такой конфликт между Заказчиком и Руководителем проекта даже необходим. Для Заказчика проект — способ улучшить свой бизнес. Поэтому он будет стараться «впихнуть» в проект как можно больше «фич», которые выражаются в эффекте для его бизнеса. Руководитель проекта отвечает за достижение целей проекта в утвержденные сроки и бюджет. Поэтому он управляет требованиями Заказчика, предлагая на выбор 4 варианта:
    а) исключить новые требования из текущего проекта (принцип: «Сделаем в следующей фазе»).
    б) включить в проект с увеличением срока и/или стоимости (принцип: «Ваше желание за такие-то деньги и сроки»)
    в) включить в проект без увеличения сроков и/или стоимости (принцип: «Сделаем, есть возможность». Редко, но бывает часто).
    г) включить в проект, исключив уже согласованное содержание на новое (принцип: «Откажитесь от чего-то в пользу нового требования»).

    Буферы — вопрос сложный.
    Во-первых, как их рассчитать? Теория управления рисками не отвечает на этот вопрос внятно, кроме статистических 15-20% бюджета или сроков на неопределенности.
    Во-вторых, как продать резервы проекта Заказчику? Очень часто Заказчик не просто получает детальные планы, но и участвует в их разработке. Так что просто так там не скрыть «буферы»
    В-третьих, как поступить с резервами, которые оказались невостребованными? Команде проекта отдать? Или оставить Заказчику? В цивилизованном обществе отдают Заказчику. Но на практике ни разу не встречал.

    С уважением.

  4. Я закладываю где-то 65% буфер на возможные прояснения требования, от которых нам не отбиться.
    этого вполне хватает.
    Все остальное — размазываю «тонким слоем» по возникающим change requests. При чем идет подряд довольно много проектов от одного и того же заказчика и чем дальше тем легче с ним договориться, т.к. повышается взаимное доверие, следовательно он не опасается, что я «заряжаю» сроки, а я не боюсь, что он выкинет какой-нибудь фокус во время проекта.
    зы — проекты от 7 до 3Х человек.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *