“Socio-technical design is not just about designing things, it is about designing things that participate in complex systems that have both social and technical aspects. Furthermore, these systems and the activities they support are distributed across time and space. One consequence of this is that the systems that are the sites for which we are designing are in constant flux. And even if we were to ignore the flux, the distributed nature of the systems means that they surface in different contexts, and are used by different people for different (and sometimes conflicting) purposes.”
Socio-technical design is, understandably, related to sociotechnology. There is much work to be done to develop the processes and techniques that will be required to manage quality and continuous improvement in the context of socio-technical design!
For example, we typically build a bridge when there’s some expectation that people need to get from Point A to Point B, and there’s something they need to bypass along the way (e.g. a river, a canyon, another road). Failure to consider the social factors as well as the technical factors could lead to a “bridge to nowhere” – and we all know at least one person who’s had a problem with those. Non-technical factors pertaining to the environment in which an idea is created and implemented are crucial.
According to Bunge (1998), sociotechnology is the process of applying insights from the social sciences to design policies and programs. More specifically, this is how Gingras & Niosi (1990) explain Bunge’s perspective:
Ten years ago we were talking about the convergence of customer touch points: phone, fax, web, cell phones, email and regular mail. With handhelds and mobile devices becoming more and more ubiquitous, and services like Facebook becoming more integrated into our daily lives, the next convergence is between people and the technologies we use. The boundaries are becoming increasingly blurred, and the impact of this convergence on business must be explored. Reviewing research by pioneers like Tom Erickson is a good place to start. We are all becoming sociotechnical.
Bunge, M. (1985). Philosophy of science and technology. Vol. 7 of Treatise on basic philosophy, Dordrecht: Holland.
Bunge, M. (1998), Social Science under debate. A Philosophical Approach. Toronto University Press: Toronto.
Gingras, Y. & Niosi, J. (1990). Technology and society: a view from sociology, in Georg Dorn and Paul Weintgartner (eds.) Studies on Mario Bunge’s Treatise, Poznan Studies in the Philosophy of Science, Amsterdam and Atlanta, 421-430. Retrieved from http://www.archipel.uqam.ca/506/01/On_Bunge.PDF
Nieto, C. C., Neotropica, F., & Durbin, P. T. (1995). Sustainable development and philosophies of technology. Society for Philosophy and Technology, Vol. 1, Fall 1995. Retrieved from http://scholar.lib.vt.edu/ejournals/SPT/v1n1n2/nieto.html – (Note: I added this one simply because I really like it, and it’s related to the discussion on sociotechnology.)
Software is the executable representation of knowledge.  As a result, I find that software development provides a fruitful basis for exploring how problem solving is done by diverse team members in a cooperative (or even combative!) context.
Here is one example. In June 1997, Tom Gilb wrote an article for Crosstalk on “Requirements-Driven Management”. He noted that his purpose was intended to discuss, among other things, “some of the current major problems in systems engineering.” I stumbled upon this article again over the weekend, and it’s still as relevant now as it was a decade ago.
Standards are a prerequisite for systematic continuous improvement; the means to achieve an improvement process, not the ends, according to Glib. Furthermore, he remarks that Deming’s perspective on continuous improvement establishes, in part, that the reason we should adopt standards is to normalize our project to other projects . Once we do that, we’ve opened the doors to be able to use industry best practices, derived from other projects who also applied the standards – so that we can “clearly see the effect of any changes experimentally introduced into a process and not have to worry too much about other potential factors that impact the results.”
Learning, learning, learning. It’s all about continuous improvement through continuous learning, and in presenting this, Gilb is essentially promoting the same philosophy as Alistair Cockburn’s Cooperative Game Manifesto for Software Development. Both see the learning process as the key to successful software development. (So why do we not focus on this aspect of development more?) Glib addresses the issue of learning directly:
“The time has come to recognize that projects are so large, so complex, so unpredictable, and so state-of-the-art new that we have no practical alternative except to maximize our learning process during the project and as early as possible in the project life. “
In this article, Gilb also presents “Evo” – short for “Evolutionary Project Management” – which has been used at IBM since 1970. It’s an implementation of Deming’s PDCA (Plan-Do-Check-Act) approach, and the author likens it to Humphrey’s Personal Software Process (PSP).
 This definition is credited to Eric Sessoms, who I consider a true artisan of software development. See some of his work at libraryh3lp.com. He likes the elegance of simplicity in his software.
Mitra noticed that across many disciplines, there were different perspectives on what quality was all about. To understand the meaning of quality from the marketing perspective, which is his interest, he investigated over 300 journal articles in different fields. He found that there were five stages of the dynamic process of achieving and improving quality:
Organizational antecedents – creating an organization whose capabilities can support achieving world-class quality in products and services
Operational antecedents – designing quality into products, managing processes to achieve quality
Production quality – meeting specifications for features, reliability and performance; adequately addressing aesthetics and customer taste preferences to create demand
Customer consequences of quality – whether and how customers perceive quality, and how this impacts retention
Market consequences of quality – in terms of market share, as well as the impact of quality and quality improvement on its contribution to profitability and global competitiveness
Here’s my rendition of Mitra’s original charts, showing the relationships between these areas:
“Zero defects” is an aspect of production quality. “Fitness for use” is part of the customer consequences of quality. Strategy, competitiveness and innovation can be related to any of these five categories, but particularly the market consequences of quality. TheISO 8402 definitionis the only one that spans all five stages of the dynamic process.
The notion of job implies that there’s been some supreme architect who designed this system so that a lot of parts fit together and produce whatever the desired output is. No one in a job can see the whole. When we ask you to join us, we are saying, “Do you have the skills and the willingness to shape yourself in this way so you will fit into this big machine? Because somebody did this job for you, somebody who was different from you. Someone will do it after you. Those parts of you that aren’t relevant to that job, please just forget about. Those shortcomings that you have that really don’t enable you to fill this job, please at least try to fake, so that we can all have the impression that you’re doing this job.”… We ought to be saying, “What can you bring to this that’s going to help?” Not, “Here’s the job, just do it.”
Later in the book, this concept of authenticity – the ability to be real, and get connected to your intrinsic motivation – is broken down into two distinct parts:
Differentiation – How and why are you unique? What can you alone bring to the workplace? What skills and talents are you dedicated to developing so that you can contribute those aspects of yourself to the team? Does the team know what specialized contributions each individual is there to bring, and do they value the contributions that are expected?
Integration – How well are you connected with the needs of others? Can you relate to – and empathize with – your manager’s needs? How well, and how honestly, do you hear the voice of the customer? Do you have the willingness and the attitude to respond to it?
Authenticity within an organization can influence quality in many ways: people will feel more comfortable recommending and implementing changes, products and services will be tailored meet customer needs and demands more effectively, egos will be tempered, and teamwork will become natural.
Although Shapiro’s example considers differentiation and integration with respect to an individual, the concept also applies to teams in the workplace, and companies and how they relate to their customers and the external environment.
Initially conceptualized by Herbert Simon (1996), the design science paradigm “is fundamentally a problem solving paradigm, [which] seeks to create innovations that define the ideas, practices, technical capabilities, and products through which the analysis, design, implementation and management and use of… systems can be effectively and efficiently accomplished.” (Hevner, 2004) The aim of design science is to produce new artifacts that can be used to enable different modes of problem solving, or to solve emerging problem categories. The framework for the design science paradigm establishes innovation as an outcome that results from the design process.
This field is interesting and important to quality researchers because applying the philosophy can help us more rigorously design, develop and validate new quality systems and new tools for quality improvement.
I’m particularly intrigued by this paradigm because it embraces learning-by-doing: “In the design science paradigm knowledge and understanding of a problem domain and its solution are achieved in the building and application of the designed artifact.” To understand it, you build it. Software developers understand this instinctively, but the tools used by project managers can’t handle the uncertainty. Can we use the philosophical approach of design science to build and validate new tools to improve the project management process itself?
It’s hard to get a group of people to agree on something. But, I’ve found out, if a) all members of the group understand what consensus really is, and b) if there is a good process in place for establishing consensus before a discussion begin — it is possible to establish consensus quickly, easily, and with no broken glassware or hard feelings.
1. An opinion or position reached by a group as a whole: “Among political women . . . there is a clear consensus about the problems women candidates have traditionally faced” (Wendy Kaminer).
2. General agreement or accord: government by consensus.
“General agreement” does not imply unanimous agreement, however. When people do not recognize this distinction, a group seeking to make a decision by consensus can fail.
I’ll give you an example of how consensus can work, because I just experienced it over the past two days. First, some background. The ASQ International Team Excellence Award (ITEA) is the only team performance competition of its kind – the process seeks to identify teams that establish effective quality systems to get their projects done, and then use those systems impeccably. I had the opportunity this past Monday and Tuesday to be a judge for the 2009 competition, where I joined several other professionals with expertise in quality and performance management to review this year’s candidates.
Our trainers had a tough job though: in 36 hours, they had to get a group of 7 people working together effectively enough to achieve a consensus-based evaluation of competing projects. Not so difficult until you take into consideration that each project had to be evaluated on over 30 different unique points. (That’s at least 200 potential points of conflict for each project that’s evaluated.)
Achieving consensus was possible because our trainers first set expectations: Be sure to evaluate the candidates based on how they compare to the criteria, not to your own personal background or biases. Next, they gave us guidelines for action in the form of a process to follow to guide our decision-making. The process included personal note-taking, forming individual scores, collecting all of the scores together, looking at ranges and variability, and discussing our differences in all the cases where the spread of scores exceeded half of the total range. They let us know that the reason we were doing this in a group was to achieve consistency and sustainability – consistency in the judging from group to group, and sustainability of our processes as we moved towards consensus as a unit. Our discussions were focused on the points where we recorded the most variability, but not on all points. This helped us to manage our time well in order to sustain an effective process. Finally, we had a basis for evaluation – a 30 point collection of guidelines and a training program to help us use it.
Most importantly, we used our differences to identify “hidden meaning”. If we disagreed vehemently, we listed to opposing arguments, and instead of trying to convince each other of the truth or merit of each side we asked ”What does this difference tell us?” Often, we found out that the difference illuminated a key aspect of the problem that no one recognized at face value. Because we entered the discussions with a firm time limit, and the understanding that we were there to help each other learn about our collective product, we were able to succeed in achieving consensus in just a couple hours for each project that we evaluated.