Gary

would be interested in this further. I'm using Cynefin Framework to help MBA students understand some of the underlying problems with Requirements gathering i.e. people think they're operating in one domain when they're operating in another.

Dermot

Gary:

As a systems engineer/architect I have worked for almost a decade at a major defense contractor to socialize the social & cognitive aspects of (a) the engineering process (the systems engineering "vee"), and (b) the capabilities being enabled by a new/modified system. Luke Hohmann pointed me to Weick's "Social Psychology of Organizing" in the late 90's, which moved me away from Nonaka's SECI framework and toward a more naturalistic approach.

Despite the emphasis that Network Centric Operations/Warfare places on the social and cognitive domains (see, for example, "The Implementation of Network Centric Warfare" at www.oft.osd.mil), it is difficult to get systems engineers in the defense industry to truly appreciate the importance of addressing these domains. My experience has been that it takes several months (at a minimum) for the basic concepts to sink in to the point that an engineer truly begins to see the world differently.

Your emphasis on decisions is exactly right. A good lead engineer will usually appreciate the importance of understanding how a new capability may affect existing decision structures. As a result, there may be an opportunity to highlight concepts/tools/frameworks that help address that challenge.

Don't underestimate the difficulty of convincing engineers of the importance of CSE. Most feel uncomfortable with the relative fuzziness of the cognitive/social domain since most of their training is based in an analytic framework (rationalism + empiricism) best suited to the Known/Knowable domains. The fact that management culture is similarly grounded (e.g., EVMS) further increases the challenge.

I have had some success using the Cynefin framework to explain why many of the tools we have been trained to use are ill-suited to Complex/Chaotic contexts. I was very happy to see that this framework will receive the imprimatur of HBR...I hope it will make my job a little easier.

Gary

Apologies for being "picky", but I do not believe in the statement that a major cause of software disasters is a "failure to specify the requirements correctly". As far as I am concerned, in the context of systems including people, this is an old myth that is well past its sell by date.

I spent some considerable time on a research programme examining the topic of requirements, which started from this same viewpoint i.e. all we had to do was fix the requirements problem and many of our system failures would go away.

As ever, life is not as simple as this, for many reasons. For example, as soon as we put the software into running systems, usually in a human context, it changes the context in which the requirements were envisaged. Typically this then invalidates some of the initial requirements.

This "fix the requirements view" also assumes that we have sufficient mental capacity to hold the together coherently the entirety of a problem and solution space, but we cannot do this, and neither can we use "divide and conquer", as simple reductionist approaches tend not to work in a socio-technical context. The fact that this is problematic is not new understanding - it was very neatly expressed by McCracken and Jackson in their small but hard hitting diatribe as far back as 1981, McCracken, D. and Jackson, M. (1981) "A minority dissenting position", along with a number of supporting papers in Agresti, W. (1986), New Paradigms for Software Development. IEEE Computer Society Press.

So I would like to argue that we cannot "fix" the problem by "fixing the requirements", because we can only get so far by making improvements in this way. Arguably, the biggest wins come by accepting that we can never get the requirements "right", and instead create development approaches that accept this reality, rather than trying to triumph over it.

What I would like to know is, does CSE recognise some of these fundamental problems? Does it assume that we can design a system right first time, or does it accept that the only development solution that is likely to work is the use of a more evolutionary approach?

How good is CSE at coping with tasks which are continually changing and morphing, in response to changing external realities? If you can answer this question, it would perhaps make it more obvious how CSE fits with the Cynefin framework - would you like to comment on this?

Walter -- thank you for your reactions. We are obviously in synch here.

Dermot -- ditto. Hopefully my comments (and those of Marv Dainoff) will give you some of the additional information you want.

Peter -- Oddly, I think you and I line up very well. You took issue with the problem of "getting the requirements right," but that actually isn't your concern. It is "getting the requirements right at the outset," and that's very different.

I completely agree with you that in a complex situation it is foolhardy to expect that we will get the requirements right at the outset. In fact, I would generalize this to specifying goals for any project. If the goals are ill-defined, as they usually are, then there is no hope for pinning them down at the outset. I wrote about this back in 1978 (Klein & Weitzenfeld, Educational Psychology), and I have another piece coming out on this in IEEE Intelligent Systems in the next few weeks. I believe many in the CSE community appreciate this issue -- it is core to our emphasis on replanning as opposed to planning-then-executing.

Peter

Since I was responsible for providing the “requirements” statement to Gary, I would like to respond. I was simply reporting on data collected by the Standish Group relating to underlying causes of software system failures. These data are summarized in Fig 4.1, p. 27 of the INCOSE Systems Engineering Technical Vision Version 1, Feb 25, 2005. In that chart, the top two causes of system failures are identified as: 1. Incomplete Requirements 13.1%; 2, Lack of User Involvement 12.2%. Overall, only 16% of projects are reported successful!!

To me, the take-home message here is that: (a) the systems engineering community recognizes that there have major problems in achieving successful system design and (b) the top two causes of such problems are arguably the domain of cognitive systems engineering. (You can’t have “complete” requirements without user involvement.) This is why it is essential we should have a seat at the table and we should use these data to make this argument.

None of the above contradicts the important points made by Peter. In fact, requirements themselves should have a built-in evolutionary component. This is also not new. Doug Engelbart was talking about “bootstrapping” back in the 60s.

Marv Dainoff