Описание работ ( SOW ) — это документ, который обычно используется в области управления проектами . Это повествовательное описание требований к работе проекта. [1] : 426 Он определяет конкретные для проекта действия, результаты и сроки для поставщика, предоставляющего услуги клиенту. SOW обычно также включает подробные требования и цены, со стандартными нормативными и управленческими условиями и положениями. Часто это важное дополнение к основному соглашению об услугах или запросу на предложение (RFP).
Многие форматы и стили шаблонов документов о работе были специализированы для аппаратных или программных решений, описанных в запросе на предложение . Многие компании создают свои собственные индивидуальные версии SOW, которые являются специализированными или обобщенными для удовлетворения типичных запросов и предложений, которые они получают. Однако они обычно информируются о целях высшего руководства, а также о вкладе со стороны клиентов и/или групп пользователей. [1]
Обратите внимание, что во многих случаях описание работы является обязательным договором. [2] Генеральные соглашения об услугах или соглашения об услугах консультантов/обучения откладывают определенные контрактные компоненты, связанные с конкретной работой, которые рассматриваются в отдельных описаниях работы. Генеральное соглашение об услугах служит генеральным договором, регулирующим условия потенциально нескольких SOW. Иногда оно относится к объему работы. Например, если проект выполняется по контракту, описание объема работы, включенное в него как часть, может использоваться в качестве SOW, поскольку оно также описывает работу по проекту в четких и кратких терминах. [3]
Обычно эти темы рассматриваются в описании работы. [4] [5] [6]
Для контрактов на государственные услуги США использование SOW остается сильным, хотя заявления о целях (SOO) и заявления о производительности работы (PWS) становятся все более популярными из-за их акцента на концепциях, основанных на производительности, таких как желаемые результаты обслуживания и стандарты производительности. SOW обычно используются, когда задача хорошо известна и может быть описана в конкретных терминах. Они могут быть предпочтительными, когда правительство не желает инновационных подходов или считает любое отклонение в процессах подрядчика риском. SOO устанавливают высокоуровневые результаты и цели для производительности, а PWS подчеркивают результаты, желаемые результаты и цели на более подробном и измеримом уровне, тогда как SOW предоставляют подрядчику или оференту четкие заявления о направлении работы, которым следует следовать.
SOW обычно изобилуют заявлениями «подрядчик должен» об обязательном соблюдении (например, «Эта задача должна быть выполнена в соответствии с Директивой Агентства xyz от mm/dd/yyyy»). На практике SOW также могут содержать ссылки на желаемые результаты производительности, стандарты производительности и метрики, тем самым размывая различие между SOO и PWS. Помимо надлежащей практики, существует мало руководств по политике правительства, которые настоятельно предписывают, как и когда использовать SOW по сравнению с SOO или PWS. В то время как FAR определяет PWS в Части 2 Определения и ссылается на SOO и PWS в Части 37.6 Приобретение на основе производительности, SOW не рассматриваются.
SOW обычно содержатся в правительственном запросе (RFP или RFQ) и переносятся, по договоренности с оферентом, в окончательный контракт. В федеральных запросах и контрактах SOW вставляются в Раздел C «Описания/Спецификации» Единого формата контракта [8] [9] [10] , но также могут быть вставлены в качестве приложения в Раздел J. В заказах на выполнение задач SOW может быть просто включен в условия и положения самого заказа. SOW часто дополняется техническими справочными документами и приложениями. При разработке SOW важно обеспечить, чтобы описание работы было всеобъемлющим и достаточно подробным, но чтобы заявления не дублировали условия и положения или другие положения в другом месте запроса или контракта.
Руководство в MIL-STD-881 и MIL-HDBK-245 гласит, что при разработке SOW следует использовать структуру декомпозиции работ . Это может использовать WBS в качестве схемы, где каждый элемент WBS (с тем же именем и нумерацией) является подразделом раздела 3 SOW, что упрощает разработку и улучшает последующее выставление счетов и отслеживание. WBS, которая фокусируется на разумном разделении иерархии элементов работ и их определении, может затем иметь SOW в соответствующих разделах, фокусирующихся на описании того, что будет сделано с этой частью или как эта часть будет сделана.
Описание работы должно быть напрямую связано с результатами, указанными в форме CDRL . Это достигается путем включения в каждую запись CDRL ссылки на параграф(ы) SOW, который производит или использует элемент, а текст SOW должен быть понятным, где он обсуждает результат, с использованием заголовка или заключения номера элемента в скобки (например, «[A-001]»).
Таким образом, техническое задание представляет собой документ, который в конечном итоге будет служить юридически обязывающим договорным документом, интегрирующим и связывающим элементы работы с поставляемым и не поставляемым оборудованием, программным обеспечением, документацией и услугами.