A Wish Level is specified on a defined Scale, under specified Conditions [time, place, event, Scale variables]. A project can determine if they want to convert the Wish to a comitted and/or promised Goal.
There is no commitment to deliver a Wish Level. A Wish Parameter simply specifies some Stakeholders’ desired Level, without considering its Cost or practicality.
1. Wish Parameters can be useful for acknowledging and recording Stakeholder desires (while clearly not committing to them), until suitable Design-Ideas are identified, until Resources are provided for those designs, or perhaps until deadlines are adjusted.
3. Subject to qualifying Conditions, Wish specifications have the lowest Scalar Requirement Priority. (The order from highest to lowest Priority is Survival, Fail, Goal, Stretch, then Wish.)
4. A “Wish” specification can apply to a performance or Resource-Requirement.
5. Conditions for Conversion from Wish to Goal
1 Feasible (technically): the Wish Level much be within the state of the art.
2. Profitable: the long term benefits of delivering the Wish Level must exceed the Life-Cycle costs.
3. Resource-Available: the necessary Resources to deliver the Wish Level must in fact be available.
4. Prioritized: even if the Wish Level is feasible, profitable, and there exist enough Resources; it must be prioritized in front of other desired performance Levels that meet these Conditions. This generally implies that this Wish Level needs to be the most profitable option in order to get converted to the more committed Priority target Level, the Goal Level.
Rationale: If we did not have a Wish Parameter to articulate uncommitted Stakeholder needs, then this information might never be collected, and maintained. So, we might lose the competitive advantage of knowing what our Stakeholders desire and value, when the Resources or technology ultimately become available.
This Concept entered by Sailendra.