1. Where the goal is not to design some complex artefact but to deliver some set of outcomes. For example, to make an organization more efficient or intelligent, to make a tax system more equitable, or to make a community more self-sufficient.
2. Where the target system is complex and governed by conflicting value systems, so that the challenge is to formulate and negotiate a series of interventions, from which a useful and acceptable change to the target system might emerge.
3. Where the agency for change is embedded within the target system, rather than being external. Anyone who gets involved in the project becomes part of the target system, and it no longer makes sense to ask the popular question "are you part of the problem or part of the solution?"
One of the attractions of the problem/solution distinction is that it helps to build agreement around a statement of the problem, and focuses the debate on different ideas and preferences for solving the problem. But to see the limitations of this distinction, we only have to look at the political sphere. There is surprisingly little difference between the political parties in their statement of the fundamental problems facing the government; but there are wide differences in the policy instruments they advocate to solve these problems. Of course, these differences are not just alternative sociotechnical designs, but are produced by different belief systems (how the economy really works, what are the root causes of crime and terrorism, and so on) as well as different value systems (what kinds of prosperity and well-being matter most).
So is there a discontinuity between highly complex and messy sociopolitical problems on the one hand and relatively simple and self-contained engineering problems on the other? To answer this kind of question, some people appeal to a simplistic interpretation of the Cynefin framework, treating it as if it were a simple 2x2 matrix mandating different problem-solving or problem-tackling methodologies according to the degree of complexity in the problem domain - but of course this kind of answer begs lots of questions about the relationship between problem and solution which a more subtle and sophisticated application of Cynefin should expose.
Any human system (including organizations) will display some degree of complexity and messiness, and it is in this context that the concept of "requirements" needs to be understood. In a separate post, I shall explore how such a concept of requirements applies to organizational intelligence.
Requirements engineering is about the interaction between five kinds of system. In the problem-solving paradigm, these fit together as follows.
- A deliverable system is designed to be a "solution" to some "problem". (In a simple case, this could be a single complex artefact or a coordinated series of interventions.)
- A target system is where the "problem" is located, and where the "solution" must fit. (In a simple case, this could be an organization unit or operational business process.)
- A value system provides the criteria justifying why the problem is a problem, and why the solution would count as an improvement. (In a simple case, there is a single sponsor whose value system is paramount.)
- A belief system, an explanatory model or theory that explains the cause of the problem and the plausibility of the solution. (In a simple case, everyone broadly shares the same belief system.)
- An intervention system, a force of people and resources mobilized to do something relevant. (In a simple world, the intervention system is a project team under the exclusive governance of a project sponsor with a unified and dominant value system.)
See also
- Niklas Björnerstedt, The obsolete idea of requirements (Feb 2010)
- Richard Veryard, Zero-Based Requirements (Sept 2010)
- Richard Veryard, Third-Order Requirements Engineering (Slideshare presentation based on a paper I wrote in 1995 with John Dobson).
Richard
ReplyDeleteWith respect to your comment "simplistic interpretation of the Cynefin framework, treating it as if it were a simple 2x2 matrix mandating different problem-solving or problem-tackling methodologies according to the degree of complexity in the problem domain"
I think there are 2 separate points here.
It is true that people often don't understand that Cynefin is a 'sense-making' framework, not a categorisation framework, and the 'classification' emerges from an exploration of the factors and elements in a particular context.
However, I'm puzzled by your critique of using is it as a way of selecting 'problem-tackling methodologies', given that's very much what the award-winning HBR article by Dave Snowden and Mary Boone, published in November 2007 is about, in the context of leadership strategies.
http://hbr.org/2007/11/a-leaders-framework-for-decision-making/ar/1
I take your point about the distinction between problem and solution being a messy one, which is why I have never been a fan of the phrase "requirements engineering"
Sally
Richard,
ReplyDeleteWhat? No mention of Wicked Problems?! I find the characteristics laid out by Rittel and Webber to be the best and most widely cited for determining when the conventional problem solving approaches (incl conventional requirements engineering) "no longer hold valid". Here they are:
1. There is no definitive formulation of a wicked problem. (defining wicked problems is a problem)
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true-or-false, but better or worse.
4. There is no immediate and no ultimate test of a solution to a wicked problem.
5. Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered to be a symptom of another problem.
9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution.
10. The planner has no right to be wrong (planners are liable for the consequences of the actions they generate).
See http://en.wikipedia.org/wiki/Wicked_problem .
Sally. In the HBR paper you reference, Snowden and Boone present Cynefin almost as if it were just another contingency theory, in the tradition of Burns and Stalker and more recently Mintzberg. More recently Snowden has approved Shawn Callaghan's four minute explanation of Cynefin considered as a categorisation model. So there appears to be a spectrum of legitimate (i.e. Snowden-approved) uses of the Cynefin framework, from categorization to sense-making. Categorization assumes that the problem is logically prior to the solution, whereas sense-making doesn't.
ReplyDeleteNick. I agree that wicked problems cause further difficulties for the problem-solution paradigm, but I think the difficuilties I am talking about may arise even with non-wicked problems.