I love this quote...
You've assumed, incorrectly, that a software project is an engineered system.
It comes from a popular voice in the agile software development community. I'd just love to bring this person with me on my travels around the country to our teams at our clients. That won't happen thought, because our clients have a "No Foreign Nationals" policy.
But here's the point. In the absence of a context and domain, statement like this provide little to the conversation of project management, especially software intensive projects.
Of course software is engineered. Just board the next Boeing or Airbus flight and ask if the millions of lines of code in the 3 to 4 dozen computers on board got "engineered" in some way.
Look our the window - I assume you like window seats, I don't - and find the Air Traffic Control tower. Ask of the millions of lines of code running the US and world wide Air Traffic Control (ATC) systems. Think about the process - both human and technical - embedded in this software. Not Engineered - are you out of your frink'in mind - of course it's engineered.
Here's another - my favorite - Flight Avionics. These software systems do a variety of things. They have Human Interfaces. There is hazard analysis software. Maintenance systems are part of the avionics suite on commercial and military aircraft. The design and development of the software is guided by many specifications. DO-178B is a starting point. In most modern commercial and military aircraft the software is needed to keep the aircraft flying - the flight dynamics of modern fighter planes allow the pilot to actually control the flight. In the absence of the software the airplane crashes.
Next comes my second favorite - process control systems. I started my career in software development writing digital filters (Kalman, FIR) for signal processing on particle accelerators and then radar/sonar systems. This turned into adpative filters and then into the control systems themselves.These systems were software intensive and engineered - some time over engineered. But engineered.
The people that build these systems are engineers. They "engineer" the product, they performance engineering roles. These roles are "engineered" to fit the need of the project.
The Primary Gap In the Discussion
The notion - and I say notion - that somehow people on the project turn the project into a Complex Adaptive System is valid in the minds of those starting with the people side of the project. On the projects that we work, the people are critical to the solution. There is no way this can not be true.
BUT, those people have specific roles, skills, experiences, and capabilities, they bring to the project. They are mature suppliers of these skills and experiences. They know how to convert the desires of the customer in the form of specification, concepts of operations, regulations, and industry standards into working product. Many time, using the agile software development processes agilest claim cannot be used in the CMMI-DEV V1.2 and DO-178B environments we work.
Once you abandon the notion that somehow software is this special discipline not subject to the standards of good engineering and good project management practices - you end up claiming everything is a Complex Adaptive System, unable to be guided by "engineering."
