A Socio-Technical Pattern Language
A Socio-technical Pattern Language Proposal
We are building tools to help you access the pattern langauge in many ways. For instance, you should be able to search for keywords, possibly by pattern part. You may want to access patterns that are particularly relevant to various contexts or various phases of a software development process. For now, we have organized the socio-technical patterns at the top level according to which one of four primary goals you might be working on. This classification is based on Lawrence and Nohria's book (2002), Driven: How human nature shapes our choices. These are not mutually exclusive; that is, you may be interested in meeting several of these goals, in which case, you may want to examine patterns under more than one category.
To Bond
You are interested in building or modifying a system for the purpose of increasing social capital, trust, or collaboration. Here are some relevant patterns. SocialBondingPatterns
To Acquire
You are interested in increasing group productivity or increasing sales. Here are some relevant patterns. Patterns for Group Productivity
To Learn
You are interested primarily in increasing collaborative learning, knowledge sharing, organizational learning, community exchange of information. Here are some relevant patterns. Patterns for Learning
To Defend
Your primary concern is in security; keeping access to a system limited to certain people, places, or times. Here are some relevant patterns.Patterns relevant to defending.
However, another way that you might want to consider which patterns are most relevant to you depends on where you are in a software development process or where you stand in terms of solving a problem. So, here is another cut at looking at some sociotechnical patterns.
Different organizations have different methodologies, processes or procedures that differ somewhat in the order of stages and what they are called; however, chances are that you can map your preferred or dictated process fairly well into some of the following categories.
Problem Finding
Here, you are exploring opportunities. You may be looking for a "killer App"; wanting to start a new business; just toying with possibilities.
A technique that might prove useful in finding problems, particularly within an organization, is Bohm Dialogue
If you have a service or maitenance organization, you may find that Help Desk Supports Designto be a useful pattern.
Problem Formulation: Requirements
In this stage, you see an unmet need or an unsolved problem. Perhaps a client has even performed the "problem finding" stage for you. But before trying to solve the problem, it is wise to take some time to consider alternative formulations. For example, the client may have said that they want you to train some of their personnel so that fewer costly mistakes are made. You may (if your relationship to the client warrants this much openness) want to consider other ways to meet the same goal. For instance, perhaps there needs to be a change in how people are selected. If people are performing a "vigilance task" (where nothing much happens for a long time), you may want to build a system that introduces (and then subtracts out) "false targets" to keep people on their toes. Conversely, if the current system produces information overload, further training may or may not work. You may need to redesign an overall system so that some easy tasks are carried out by computer or have people cross-check each other. It may be that errors will continue but that the system may be redesigned to minimize the impact. Often, redesigning the system so that people get more immediate feedback about the correctness of their actions will dramatically improve performance.
Relevant Patterns: Who Speaks for Wolf?
Project Definition
At some point, you will need to get some formalization to a project. Time scales, resources, funding, and so on need to be decided. At this point, you might also want to do planning, risk assessment, and contingency planning. These Patterns may help in this process.
Relevant Patterns: Setting Expectations
Radical Co-location
Invention: Idea Generation
Depending on the nature of the project, much of the material may simply be found and re-used, or considerable new invention might be required. You may find these patterns useful if you need to come up with new ideas. Generally, it is better to separate idea generation from idea evaluation.
Relevant Patterns: Elicit from Cultural Diversity
Techniques that are well-suited to Idea Generation are Synectics or semi-structured brainstorming.
If you are helping to shepherd idea generation, you might find the Facilitatorpattern and associated hints for facilitators to be useful.
You might also try the prototype tools at http://www.research.ibm.com/knowsoc/prototypes_index.html to be useful
Idea Evaluation: Prioritization
You may have more ideas than can be implemented given the resources, people, or time available. In the spirit of non-evaluative idea generation, you may have also generated ideas that are not really practical. That is fine, but now you need to evaluate the reasonableness of various ideas and if there are still too many, prioritize them.
Relevant Patterns: Use Raters for Evaluation
Incremental Value
Idea Integration and Organization: High Level Design
The various sub-solutions, ideas, and approaches must now be put into a coherent overall picture. Often, in the case of software development, this process results in a High Level Design Spec.
Low Level Design
You may now want to translate the high level design into something closer to objects, functions, groupings, pseudo-code, or flow-charts. How will you actually accomplish the functionality?
Prototyping
Before moving to full-scale implementation, it is often wise to make a prototype and check back with the client, the user, the funder. Often, the stakeholders who are important for your ultimate success will have omitted important details of their requirements. So, by building a small prototype that illustrates the main functions, and perhaps something of the look and feel, you may be able to save a lot of time, money and rework.
Evaluation
How can you evaluate the prototype? It is generally best to have some potential users actually try to "use" the prototype to do real work. All too often, developers may simply "present" the prototype and "walk people through it." Under those circumstances, the developer puts themselves in the role of "salesperson" and considers it a success if the users "like" the "prototype" and "accept it." Unfortunately, such a stance undermines the main value of building a prototype. So, under what conditions do you want to observe then? Who should be involved? How should you analyze the results? What do the reactions of your stakeholder to your prototype?
This is another occassion where it might be useful to look at the Patterns,
Reality Checkand
Who Speaks for Wolf
Redesign
If the exercise of building a prototype is done correctly, you will typically find out things you did not know. Some things will be confusing to the users that didn't seem so to you. Some of the functionality that you thought to provide will now seem relatively unimportant while other functions, not in the original plan, will emerge as vital. Typically, some redesign will be required. This, in turn, may require renegotiation of dates, requirements, and resources.
Useful Patterns include: Moderatorand
Stake Warrior
Implementation
Testing
Deployment
Relevant patterns: Small Successes Early
Jump Start
Observation in the Field
Post-Mortem
After a project is done, it is worthwhile to spend time asking yourself the question, "What did we learn from this? How can we do it better next time?" Relevant patterns include: Bohm Dialogue
and
Narrative Insight Method
Service
Relevant Patterns: Help Desk Supports Design
Maintenance
Back to Welcome Page