This approach redefines standards in complex system-product development projects, suggesting outcomes over activities.
Not all complexities are equal: Complex system‐product development projects are more complex than the complex system‐products they are developing. This is due to the interaction of the social and technical elements of the project's enabling system along with those of the system‐product under development. Standards are often applied in an approach that obscures the risk of the project's total complexity by overemphasizing governance of the development work activities. While effective for many projects, the application of standards to a complex project using an “activity‐driven” approach can result in increased waste. Excessive up‐front documentation, unnecessary revision, project delays, project inflation, or other disruptions of the project's purpose are all possible forms of waste. We propose an “outcome‐driven” approach that addresses the total complexity of a complex project; where project outcomes drive the application of standards by comparing the evolving state of the project's work products vs. the desired outcomes. We define key characteristics of activity‐driven and outcome‐driven project approaches; the effect on project inputs, processes, and outputs; identify key differences between activity‐driven and outcome‐driven project approaches; and disambiguate relevant supporting terms within their sources from their respective standards bodies. We present examples of both activity‐driven and outcome‐driven approaches in illustrative scenarios for development of a simple hardware system‐product item, a complicated software system‐product item, and a complex software‐intensive system‐product item.
No takes yet. Share an insight, caveat, or question.
Wade et al. (2025) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: