EVAL-ForwARD (www.evalforward.org)
– сообщество специалистов по оценке, созданное по инициативе офиса оценки
Продовольственной и сельскохозяйственной организации ООН (FAO). Идея была создать платформу для
обсуждения оценки проектов в области продовольственной безопасности, сельского
хозяйства и сельского развития, но на практике обсуждают больше оценку в целом.
Сообщество открытое, но жестко модерируемое. Все письма, которыми обмениваются
члены сообщества, переводятся и приходят с текстом на трех языках: английском,
французском и испанском.
Меня в EVAL-ForwARD пригласили,
потому что я участвовала в оценке нескольких проектов FAO в Центральной Азии. А некоторое
время назад модератор предложила мне выбрать тему для обсуждения, инициировать
дискуссию среди членов сообщества, и затем подвести ее итоги.
Я решила обсудить проблему, с которой регулярно сталкиваюсь
при проведении оценки для агентств ООН. Все внутренние процессы в них жестко
регламентированы, и для каждого процесса есть соответствующее руководство. И я
регулярно сталкиваюсь с тем, что руководства (методические рекомендации) по
планированию и руководства по проведению оценки по-разному трактуют, что такое «output».
В оценке «output»
традиционное определяют как непосредственные результаты/продукты действий в
рамках проекта, достижение которых в значительной мере зависит исполнителей
проекта, то есть находится в зоне их контроля. Соответственно, руководства по
оценке для анализа этого уровня результатов рекомендуют вопросы типа: «Насколько
своевременно были получены «output»-ы,
и как сроки достижения «output»-ов
повлияли на достижение нужных проекту изменений в жизни благополучателей
проекта?». (Изменения в жизни благополучателей принято называть «outcome».)
Понятия «output»
и «outcome», у которых,
к сожалению, нет прямых эквивалентов в русском языке, сформировались в те
времена, когда проекты международных организаций в основном что-то строили:
дороги, колодцы, школы и т.п. Поэтому разделить результаты на «output» и «outcome» было несложно: дорога – это «output», а то, как ее
используют местные жители – «outcome».
Но если проект дает участникам какие-то знания и навыки,
разделить результаты на «output»
и «outcome» уже
сложнее. Исполнители проекта в значительной степени контролируют подготовку и
публикацию учебных пособий для благополучателей, сроки проведения учебных мероприятий,
а также количество и состав их участников. Понятно, что участники должны
приобрести какие-то знания и навыки, используя которые они затем должны изменить
свою жизнь в нужную проекту сторону. Если следовать классическому определению «output», то «output»-ами такого проекта следовало
бы считать подготовленные учебные пособия, проведенные мероприятия и обученных
людей. Но руководства по планированию предписывают описывать «output» как изменения в том, какими
знаниями и навыками обладают участники проекта.
В результате, если менеджеры начинают использовать руководства
механически, ты как внешний консультант по оценке получаешь Техническое задание
с вопросом «Насколько своевременно были получены «output»-ы?», а при изучении проектной
документации выясняется, что в рамках проекта для одних и тех же участников регулярно
проводили семинары, которые в совокупности должны были обеспечить достижение
такого «output» как «рост
лидерских качеств участников», благодаря чему они должны были стать лидерами в
своих сообществах (это уже формулировка «outcome»). В принципе, такой вопрос мог бы иметь смысл, если бы проект
готовил участников, например, к участию в местных выборах. Но в данном случае
такого не было. И хотя руководство по оценке говорит, что вопросы можно
корректировать на этапе разработки методологии оценки, мне сказали, что раз в
руководстве по оценке приведена такая формулировка вопроса, пусть и в качестве
примера, значит, на такой вопрос и нужно отвечать.
В этом случае мне удалось договориться с менеджерами,
которые управляли оценкой, что результаты можно представить не по отдельным вопросам,
как это принято, а шире - по критериям оценки. А формулировки вопросов мы оставили
как есть.
И вот на EVAL-ForwARD я
предложила коллегам поделиться, сталкивались ли они с подобными ситуациями в
своей практике, и как из них выходили. Дискуссия получилось оживленной, в ней
приняли участие одиннадцать человек. Один из выводов, который можно сделать по
итогам: когда задача заказа оценки делегируется на уровень проекта, лучше дать
менеджерам проекта не руководство по проведению оценки, а возможность поработать
несколько дней со специалистом по оценке, чтобы спокойно обсудить структуру
ожидаемых результатов проекта и сформулировать адекватные вопросы оценки.
В ходе обсуждения меня зацепила одна из историй, которыми поделились
коллеги. В богатой скандинавской стране построили мост через пролив, отделявший
небольшой остров, чтобы жители острова могли добираться до работы на материке
не на пароме, а на своих авто. Но когда мост был готов, люди перевезли по нему свое
имущество в дома и квартиры на материке рядом с работой, а дома на острове
стали использовать как дачи.
Коллега поделился этой истории, когда дискуссия на EVAL-ForwARD свернула на то, что проектные
менеджеры не только не понимают разницы между «output» и «outcome», но и спланировать проект
нормально не могут, и история с мостом должна была проиллюстрировать данную
мысль. Но мне показалось, что еще лучше
она иллюстрирует то, что происходит с руководствами по оценке.
Руководство по проведению оценки призвано быть мостом между
проектным менеджером, который должен заказать оценку и управлять ее
проведением, и специалистами в области оценки, которых нанимают эту оценку
проводить. Руководство должно дать менеджеру всю информацию, которая ему
потребуется в процессе управления оценкой, чтобы он выполнял эту работу
осознанно и уверенно. Для разработки руководств приглашают опытных специалистов
по оценке, которые подробно описывают, что нужно делать на каждом этапе. Но в результате
для неспециалистов в области оценки руководства оказываются слишком сложными, и
менеджеры часто пользуются ими формально – в основном для подготовки Техзаданий
методом копи-паста, и потом отказываются обсуждать с внешними консультантами любые
изменения. Кстати, с точки зрения оптимизации затрат сил и времени – это оптимальное
решение.
И я вот думаю: в случае с мостом оценку результатов проекта,
похоже, сделали. Делал ли кто-то оценку того, как используются руководства по
проведению оценки?
Мой пост в блоге EVAL-ForwARD
(на английском): https://www.evalforward.org/blog/eval-forward-community-really-output
