Work-product state

A work-product state (hereinafter, the State) is a set of conditions that work products acquire during their development and service. The Coords work to bring the products into one or more of their states.

State definitions

1. State of acknowledgment. In this state, the future deliverable exists in the form of a noticed and documented idea.
2. State of certainty. In this state, the future deliverable exists as a validated product specification.
3. State of capability. In this state, the functional deliverable has already been produced in accordance with all the requirements that have been approved for it.
4. State of applicability. In this state, the deliverable is not only functional, but can also be used for the purpose for which it was produced in ways that are described by a validated Standing operating procedure (SOP).
5. State of manageability. In this state, the deliverable is not only used for the purpose for which it was produced, but also controlled, that is, the product undergoes periodic revisions and is either improved and its characteristics are improved, or withdrawn from service.

Hierarchy

In practice, the States do not always represent a hierarchy of five levels, in which the higher level includes the states of the lower levels. However, the Coords should strive for this ideal, for example, it is impossible to fully talk about applicability without capacity, manageability without certainty, and so on.

Thresholds

Product state	Threshold
State of acknowledgment	A record is added to the idea management system.
State of certainty	A product specification is approved.
State of capability	Acceptance criteria are met.
State of applicability	A standing operational procedure (SOP) is approved.
State of manageability	Periodic reviews find that standing operational procedures (SOPs) are both sound and followed.

Devices of certainty

For the purposes of this very wikipage, a device of certainty refers to an instrument or tool that ensures:

• Product certainty, which their development shall deliver. When the Customer agrees, products shall not necessarily possess their state of certainty for the beginning of their development, but this state shall be achieved during that development.
• Project certainty, which suggests the scope of product development. Project certainty cannot be reached unless product certainty is reached. Clearly, no one can know what to do unless they know what needs to be done. The scope of work depends on the scope of work product. Moreover, the overwhelming majority of Cyber projects cannot be fully predicted and, therefore, achieve their complete certainty only with their closure.

General certainty

For the purposes of this very wikipage, a general certainty refers to those devices that may combine product and project certainties.

1. Business requirements. Description of the needs for which the development of the deliverable is undertaken.
2. Demands of Team funded by Customer. Description of what the Team needs and, possibly, when and how it needs expressed when the Customer has funded satisfaction of those needs. Those demands are expressed in either acceptance criteria or standing operating procedure (SOP).
3. Stakeholder requirements. Description of the future deliverable made on behalf of various types of its stakeholders.

Product only certainty

A few devices ensure certainty of product deliverables:

1. Product depictions. Representation in images, layouts, mockup models, outlines, prototypes, sketches, wireframes, and/or words of a deliverable to be created. Prototypes (from the Greek "prōtos" meaning "first", "original" and "typos" meaning "imprint", "pattern"). Instances, samples or models, following the example of which others are made or finalized. Prototypes of the deliverable are often built to test a perception, concept, or process. Prototypes can either be selected from existing products or produced during a project.
2. Product specifications. Set of tasks for developers of a deliverable regarding its required characteristics.

Business requirements, stakeholder requirements, and acceptance criteria clarify product scopes, but may also clarify scopes of their production, delivery, and/or other elements of project scopes.

Project only certainty

Project scopes depend on their product scopes, so any project document can get some glimpse into its product certainty. A few devices ensure certainty of project processes and product delivery:

1. Project scope baseline. The combination of project work requirements that the Customer has approved and that are used as the base to compare with actual results. For complex projects, the baseline normally includes a project scope statement, work breakdown structure (WBS), and WBS dictionary.
   • Project scope statement. General description of the project work and its desired results, as well as assumptions, constraints and other project requirements.
   • Work breakdown structure (WBS). Hierarchical decomposition of the complete project work.
   • WBS dictionary. Detailed deliverable, activity, and scheduling data for each component in the work breakdown structure (WBS).
2. Project schedule baseline. The combination of project schedule requirements that the Customer has approved and that are used as the base to compare with actual results.
3. Project cost baseline. The combination of project cost requirements that the Customer has approved and that are used as the base to compare with actual results.

Business requirements, stakeholder requirements, and acceptance criteria may or may not clarify project scopes in addition to clarifications of product scopes.