Техническое задание - Statement of work

А техническое задание (СОУ) - это документ, обычно используемый в области управление проектом. Это повествовательное описание рабочих требований проекта.[1] Он определяет деятельность по конкретному проекту, Практические результаты и сроки для поставщика, предоставляющего услуги клиенту. SOW обычно также включает подробные требования и цены со стандартными нормативными положениями и условиями корпоративного управления. Часто это важный аккомпанемент к генеральное соглашение об обслуживании или же запрос предложения (RFP).

Обзор

Многие форматы и стили шаблонов технических заданий были специализированы для аппаратных или программных решений, описанных в запрос предложения. Многие компании создают свои собственные индивидуализированные версии SOW, которые являются специализированными или обобщенными для удовлетворения типичных запросов и предложений, которые они получают. Тем не менее, это обычно определяется целями высшего руководства, а также вкладом клиентов и / или групп пользователей.[1]

Обратите внимание, что во многих случаях техническое задание является обязательным контрактом.[2] Генеральные соглашения об обслуживании или соглашения с консультантами / услугами по обучению откладывают определенные контрактные компоненты, относящиеся к конкретной работе, которые рассматриваются в отдельных рабочих заданиях. Генеральное соглашение о предоставлении услуг служит генеральным контрактом, регулирующим условия потенциально нескольких SOW. Иногда это относится к объему работ. Например, если проект выполняется по контракту, описание содержания, включенное как его часть, может использоваться в качестве SOW, поскольку оно также описывает работу проекта в ясных и сжатых терминах.[3]

Рассматриваемые области

Техническое задание обычно затрагивает эти темы.[4][5][6]

  • Цель: Почему мы делаем этот проект? Заявление о цели пытается ответить на этот вопрос.
  • Объем работ: Здесь описывается работа, которую необходимо выполнить, и указывается задействованное оборудование и программное обеспечение. Определение объема становится заявление о сфере действия.[7]
  • Место работы: Здесь описывается, где должна выполняться работа, включая расположение оборудования и программного обеспечения, а также места, где люди будут встречаться для выполнения работы.
  • Срок исполнения: Здесь указывается допустимое время для проектов, такое как время начала и окончания, количество часов, которые могут быть выставлены в счет за неделю или месяц, где работа должна быть выполнена, и все остальное, что связано с планированием.
  • График выполнения работ: В этой части перечислены и описаны, что должно быть сделано и когда.
  • Применимые стандарты: Здесь описаны все отраслевые стандарты, которых необходимо придерживаться при выполнении контракта.
  • Критерии приемки: Определяет, как покупатель или получатель товаров будет определять приемлемость товара или услуги, обычно с помощью объективных критериев. Видеть Приемочное тестирование.
  • Специальные требования: Это определяет любое специальное оборудование или программное обеспечение, специализированные требования к персоналу, такие как степени или сертификаты для персонала, требования к командировкам и все остальное, что не оговорено в деталях контракта.
  • Тип контракта / график платежей: Принятие проекта будет зависеть от того, хватит ли имеющегося бюджета для покрытия необходимых работ. Таким образом, разбивка платежей в зависимости от того, являются ли они авансовыми или поэтапными, обычно оговаривается на ранней стадии.
  • Разное: Многие пункты, которые не являются частью основных переговоров, могут быть перечислены, потому что они важны для проекта, и игнорирование или игнорирование их может создать проблемы для проекта.

Государственные контракты США

Для контрактов на государственные услуги США использование SOW остается сильным, хотя заявления о целях (SOO) и отчеты о работе (PWS) становятся все более популярными из-за их акцента на концепциях, основанных на производительности, таких как желаемые результаты обслуживания и стандарты производительности. SOW обычно используются, когда задача хорошо известна и может быть описана в конкретных терминах. Они могут быть предпочтительнее, когда правительство не желает инновационных подходов или считает любые отклонения в процессах подрядчика риском. SOO устанавливают итоги и цели высокого уровня для производительности, а PWS подчеркивают результаты, желаемые результаты и цели на более подробном и измеримом уровне, тогда как SOW предоставляют четкие указания о направлении работы для подрядчика или оферента, которым следует следовать.

SOW обычно изобилуют заявлениями "подрядчик должен" об обязательном соблюдении (например, "Эта задача должна выполняться в соответствии с Директивой Агентства xyz, датированной мм / дд / гггг"). На практике также можно обнаружить, что 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]»).

Смотрите также

Примечания и ссылки

  1. ^ а б Керцнер, Гарольд (2009). Управление проектами: системный подход к планированию, составлению графиков и контроллингу, десятое издание. Хобокен, Нью-Джерси: Джон Уайли и сыновья. п. 426. ISBN  9780470278703.
  2. ^ Родни Д. Стюарт (1992). Подготовка предложения. п. 108. ISBN  978-0471552697. Следовательно, техническое задание - это документ, который в конечном итоге будет служить юридически обязательным контрактным документом, который объединяет и связывает элементы работы с поставляемым и не подлежащим доставке оборудованием, программным обеспечением, документацией и услугами.
  3. ^ Хельдман, Ким (2006). Управление проектами JumpStart. Сан-Франциско, Калифорния: SYBEX. стр.100. ISBN  0782142141.
  4. ^ «Руководство по написанию технического задания (SOW)» (PDF). DAS Procurement Services, версия 2. Правительство штата Орегон. 2018-04-02. Архивировано (PDF) из оригинала на 2019-07-18. Получено 2019-07-18.
  5. ^ «Примеры технического задания (SOW)» (PDF). Район управления водными ресурсами Южной Флориды. 2007-02-28. Архивировано (PDF) из оригинала на 2019-07-18. Получено 2019-07-18.
  6. ^ «Образец шаблона описания работы» (PDF). Министерство сельского хозяйства США. 2006-06-30. Архивировано (PDF) из оригинала на 18.02.2017. Получено 2019-07-18.
  7. ^ Николас, Джон; Стейн, Герман (2008). Управление проектами для бизнеса, инженерии и технологий: принципы и практика, 3-е издание. Берлингтон, Массачусетс: Elsevier. стр.162. ISBN  9780750683999.
  8. ^ См. Единый формат контракта, FAR 14.2.
  9. ^ «Единый формат контракта». дау.мил. 2008-07-14.
  10. ^ «Единый формат контракта». дау.мил.

внешняя ссылка