Solutions are the Means to the ends , or , Solution defined for project management: Solutions are anything, which moves us along Stakeholder-Value & Product-Value Scales, from where we are, the Status-Level, towards where we want to get, the Goal-Level, within defined conditions and Budgeted Development-Resources.

Alternative Names

Concept Number: *047
English Master: Solution-Idea
Synonyms, Variations & Acronyms:
to-do tasks
Design *047
Strategy *047
Proposed Solution *047
Means *047


Solutions relate to the Level preceding it.

Stakeholder-Value and Product-Value Requirements define what we want to achieve using a Scale and a Goa-Llevel, while Solutions are intended to move us along that Scale from where we are towards the Goal-Levels.
To have a Solution, we must first understand the Requirement it is intended fulfill. Solutions only exist in the light of the Requirements it is meant to achieve. Solutions can only be as great as our understanding of the Stakeholder-Value and Product-Value Requirements are.
Discussions about for how good Solutions are, or which Solution is better, without having a clear Idea of what kind of challenge it might solve, are fruitless. I avoid discussing which Solution we should use without having Stakeholder-Value and Product-Value Requirements specified first.

Your Solutions my Project

Your Solutions might become someone else’s projects, and your project might be someone else’s Solution.
The chain of someone’s Solutions becoming someone else’s projects might have many layers. The number of layers depends on, among other things; the size and complexity of a project, as well on how you choose to organize your organizational structure.

At every distinct Level, we can describe the end states with its; ‘what it does’ (Functions), and its ‘how well it does it’ (using a Scale).

In smaller projects, we might operate with two levels, Product Level & Solutions Level. At the Product Level we express the end states with Product-Functions and Product Values. At the Solutions Level, we might just specify Solutions, like; use titanium, use a Standard GUI layout etc.

In more Complex projects, we might have 3 levels, a Stakeholder-Level, a Product-Level, and a Solutions Level. Each Level is viewed as Solutions for the Level Before it. The Products-Level are Solutions for the Stakeholder-Level, the Solutions Level are Solutions for the Product-Level.
We can expand in both directions as needed. We can have several Stakeholders, some Before others, we can have several products, and the products can be broken down several levels. Each Level down are Solutions for the Level above.






Categories of Solutions with Examples
I find it useful to separate Solutions into categories. Here are four main categories.
Build Solutions
Build Solutions describe the actual parts, material, design and components of the Product.
Examples are material used to make a Product; computer code, the physical design of the Product, parts to be used in the Product.
.Titanium: use titanium.
.Thickness: 10mm ± 0.2 mm.
Screen Shot 2015-12-17 at 15.28.50.png

Sub-Function Solutions
Sub-Function Solutions are Sub-Functions that support a higher Requirement. They differ from ordinary Sub-Functions in that they are not a necessary part of the Product, no one is requiring the Product to perform a Sub-Function Solution, it is an option, a Means to an end. A Sub-Function Solution does not tell us how, just what it will do.
Examples are any Sub-Functions that are not a Requirement; air-cooling in a room, an address book on a telephone, internet in a hotel room.
.Euro: include all the European languages.
.US: include US English.
Process Solutions
Process Solutions describes Processes that can be used to develop the Product. Processes that alone will not make any Product, but when applied to the developing Process can increase the Effectiveness of the development.
Examples are anything that can help the developers do their job better; computer applications, a System to sharpen the knifes regularly in a kitchen, a Checklist to follow, a Document change management tool, Evolutionary Delivery, Waterfall, Inspection.
Speckqc: use specification Quality control
.Req: on all new Requirements
.Qual: No more than 1 Major Defects per page remaining
.Sol: On all new Solutions
.Qual: No more than 3 Major Defects per page remaining
Testing: …
Product-Values and Sub-Product-Values
Sub-Product-Values are Solutions to satisfy Product-Values. Product-Values are Solutions to satisfy Stakeholder Values. As an example a Product-Value of Usability can possibly be there to help us meet a Stakeholder Value about reducing the Cost of ownership of a Product. Usability is not an end in itself; it is a Solution to meet a higher end state. As seen from the perspective of Stakeholders, all Product-Values are Solutions.
Scale: average time to learn how to operate the System
Past 2004 120 min.
Goal 2005 30 min.


1. A Solution-Specification is a written definition of a Specific-Solution-Idea. A template for Solution-Specification is given in Figure 7.6.

2. A Solution-Idea is not usually a Requirement. A Solution-Idea can, in Principle, be changed at any time for a ‘better’ Solution-Idea (without having to ask the permission of any Stakeholders because the System designers are responsible for the proposed Solution-Ideas). A ‘better’ Solution meets the Requirements by giving more performance and/or less Cost.

Requirements are inputs into a Design-Process; Solution-Ideas are the outputs.

Note: A Solution can be a Requirement if it is a Solution-Constraint. That is, a Specific-Solution is stated as mandatory or prohibited in the Requirements.

3. A satisfactory Solution-Idea can have some negative performance Scalar Impacts, and still be acceptable overall. As long as the negative Impacts (negative Side-Effects) of a Solution-Idea do not prevent us from reaching all the required Goals Levels, the Solution-Idea can be used.

4. <A Solution may be described in terms of its Attributes. Solution Attributes can be Function (and sub-functions). Performance Attributes, costs, technical specification.

5. ‘One mans Solution becomes another’s Requirement.’. The Concept of Requirement and Solution is relative to the Level of Process observation. A top Level Solution becomes a ‘Requirement’ at the next Level


[Solution-Idea *047]: ||

S1 S2
O---[----]----- P
M Vb B T1 Vb T2

Illustration for paper ‘Vision Engineering’ (July 2008). M = Mission, Vb = Core Value barrier – Constraint. B = Benchmark Level. T1 and T2 are Target Levels of Performance Attribute P (a Core-Purpose). S1 and S2 are Strategies. Based on ideas in Collins and Porras, “Built To Last”.


A lying-down rectangle. (The standing rectangle is a Document icon.)

Architecture *192
Policy *111
Solution-Constraint *181
Solution-Specification *586
Solution-Target *338
Solution-Problem *654
Entity *645
Function-Solution *521



This Concept entered by Adore.
Table of contents: