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

Пара советов:

1. Всегда давайте исполнителю меньше времени, чем планируете на выполнение задачи. Практика показывает, что многие исполнители «расплываются», когда на задачу больше времени чем нужно, и даже в завышенный срок не укладываются.
    
2. Мотивируйте материально менеджера на успешность проекта (например положительная маржа). А уж менеджер должен всячески мотивировать исполнителей, это одна из ключевых его компетенций.
    
3. Ведите отчетность рабочего времени исполнителей, только не жесткую. На основе отчетности вы сможете получить множество полезной статистики: маржинальность проектов и конкретных этапов, эффективность исполнителей, будете знать коэффициент погрешности оценок каждого исполнителя и т.п.

Вывод: на мой взгляд, у вас проблема не с исполнителями, а с менеджментом.

Знакомая история. Жизни учить не будем, просто расскажем, как действуем в похожих ситуациях.

1. Весь объем работ разбиваем на очень мелкие итерации. 2 дня — максимум, 4 часа — средняя продолжительность.
    
2. Для каждого вида работ определяем нормочасы.
    
3. Последовательность работ по каждому этапу дотошно планируем в формате диаграммы Ганта.
    
4. И нормочасы, и план обсуждаем с исполнителями. Не обещаем клиентам заведомо невозможного.
    
5. Мелкие итерации контролируем: поработал 2 часа — покажи результат.
    
6. Сотрудников с высоким риском выхода из нормочасов (как ни странно, это вовсе не программисты) держим на почасовке. И в случае проблем платим за нормочасы, а не за реально потраченное время. 
    
7. Проблемы со сроками, конечно, остаются. Но бюджеты в минус не уходят, уже приятно.

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

Думаю, что оплата труда должна быть привязана к срокам. У всей проектной команды, а не только у разработчиков. Все должны быть в одной лодке. Например — 30% за досрочную сдачу проекта, 15% за сдачу в срок. Если сроки не выдержаны — премиальный фонд отсутствует.

Второй аспект данного вопроса — нематериальный. Важно, чтобы все члены проектной команды разделяли мнение, что выдержать сроки — это очень важно. Что командный успех важнее, чем самому «запилить» какую-то фичу. В противном случае — никакая материальная стимуляция не поможет.

Проблема неверных оценок существует ровно столько же, сколько существует IT отрасль.

Как правило, чем более опытен и квалифицирован человек в своей отрасли, тем точнее его оценки.

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

Ну и заодно, вводя систему штрафов/поощрений на основе попадания в оценку, вы получите заведомо завышенные оценки от сотрудников, «чтобы точно не прогадать».

Решайте проблему обучения сотрудников, и вы решите проблему плохих оценок.

Олег, отчасти Вы сами ответили на свой вопрос. Когда процесс будет стандартизирован, а у Вас накопится опыт повторного использования типовых решений, Вы будете более точно оценивать сроки проектов. У нас используется следующая практика: специалистам оплачивается только та часть, которая была оценена изначально. То есть если проект оценили в 100 часов, а реально он был сделан за 150 часов, то в оплату идет только 100 часов. Другой вопрос, почему происходит превышение сроков? В большинстве случаев удорожание происходит по вине заказчика, когда он постоянно хочет еще чего-то. Здесь менеджерам проекта нужно сдерживать «хотелки» заказчика в рамках заранее оговоренной спецификации и убеждать его в том, что все сделано согласно прототипу и техническому заданию, а если он хочет получить дополнительный функционал, то за него нужно отдельно платить. Что же касается системы мотивации сотрудников — более эффективно использовать механизм премирования за часы, закрытые сверх установленной нормы.

Мы тоже прошли через такую проблему после реструктуризации компании. Идея оказалась в следующем — есть специалист, который управляет проектом и знает возможности дизайнеров и программистов. При получении ТЗ каждый специалист указывает сколько часов ему потребуется на реализацию данной задачи. Ответственный за проект уже выбирает того, кто будет исполнять заказ, причем сверху надбавляет корректировочные часы, чтобы потом не работать за бесплатно. Проще сжать часы, чем потом объяснять клиенту что он должен заплатить за дополнительный час-два. Причем сжатие часов чаще всего работает, как способ повышения лояльности клиента.

Так сложилось в мире, что программист или дизайнер не могут давать верные оценки объёмов работ и склонны смотреть на них слишком оптимистично. Опытный менеджер или тимлид знает это и корректирует их оценки в своих планах. Так что первое и главное — опытный руководитель. Что касается инструментов мотивации, то какие-то из них (не обязательно денежные) конечно, должны зависеть от попадания в сроки реализации проекта. И в любом случае стоить помнить, что надбавки работают лучше штрафов.

На мой взгляд, почасовая оплата без ограничения сроков может разорить студию. Студия будет оплачивать постоянные «переработки», которые не были заложены в смету. А что еще хуже, клиент будет недоволен задержкой и переносом сроков.

Большинство известных мне дизайнеров и программистов ошибались в оценке сроков. Чаще всего в меньшую сторону.

1. Я бы советовал умножать озвученные дизайнером и программистом сроки на коэффициент, подобранный эмпирически. И учитывать это при расчете стоимости проекта.
    
2. Установите обязательные промежуточные внутренние дедлайны, после которых вы не продолжаете доработку прототипов. Используйте метод «прогрессивного джипега».
    
3. Показывайте первую версию клиенту пораньше. Так у вас будет запас времени на работу с замечаниями.

А еще лучше согласуйте с клиентом четкий календарный план с датами показа промежуточных результатов работ. И обязательно предусмотрите в нем достаточное время на доработку после первого показа.

Общее мнение экспертов — дело не столько в системе премирования, сколько в выстраивании процессов, формировании команды и развитии навыков менеджера. «Серебряной пули» нет и здесь. Только нарабатывать опыт, стандартизировать процессы, и, вероятнее всего, премировать за превышение плановых показателей (а не штрафовать за срыв сроков).