“Social Technical Gap” and Participatory Design

Abstract

Social technical gap is a concept common to computer supported cooperative work (CSCW); in this write up, Social technical gap was redeJined and discussed Jrom PD perspective. This was done within three sections oJ PD − (f) Politics oJ design, (2) nature oJ participation and (3) the principle oJ organization, methods, tools, and techniques. Based on my experience, I compare PD approach with one oJ the SoJtware system implementation project I lead in the past; highlighting merits, demerits and learning points oJ the assessment oJ PD and traditional soJtware development process.

1. Introduction: “Social Technical Gap” in Participatory Design

Social technical gap is a term peculiar to Computer Supported Cooperative Work (CSCW); Ackerman⁸ defined it as the great divide that exist between what is to be supported socially and what can be supported technically. The idea behind CSCW combines the understanding of the way people work in groups with enabling technologies that promotes collaboration communication³ ; Participatory Design (PD) on the other hand is a design paradigm that advocates active participation of all stakeholders in system design and implementation process. Kensing and Blomberg gave a concise and clear distinction between PD and CSCW in this quote:

” A great deal oJ PD research also is directed at designing computer based systems, but the explicit motivation Jor such design eJJort is oJten to strengthen workers control over their work lives and to create more democratic work environments. Technology design (the core oJ CSCW) is but one aspect oJ a strategy aimed at achieving these larger workplace objectives”⁶.

It therefore means that CSCW can be seen as a tangible subset of PD; in the same vein 'Social Technical Gap' could be redefined in the context of PD as a disconnect that exists between the designer and user perspectives of a system, this emphasizes the gulf between what the user want and what the designer[system] grovides.

Here is an example, a true life story:

There is a village in a remote area of northern Nigeria where villagers depend solely on a river for water supply; village women over time have formed the habit of going to the river at a particular period of the day. Not long after, a politician thought it wise to provide borehole at the village square (synonymous to city center), he paid a contractor and the project was executed in no time, the politician's intentions was to provide good and hygienic source of water, to reduce the distance, time and effort required in fetching water and to crave the good will of the people. You will agree with me that the politician have good intentions. However the borehole was intentionally destroyed within one week of its commissioning. Sounds strange? Yes! but the villages did not see any good in the project, they see water from borehole as artificial, they see it as a contradiction to their believe that water should be natural with a traceable source, the women see it as a denier of daily interaction and physical exercise enjoyed on their way to the river.

From this example, the villagers wanted a hygienic water supply but tools and method of providing this water must not contradict their believe system. ' Social

Technical Gap’ in this context is the disconnect between the hygienic water supply needed by villagers and borehole provided by the politician that contradict their believe system − the gulf between what the villagers want and what the politician provided.

The subsequent sections of this write−up will take a careful look at distinctive features of PD in relation to other design traditions; this will be done within the three main issues associated with PD − Politics of design, nature of participation and the principle of organization, methods, tools, and techniques. Based on my experience, I compare the concept of PD with one of the Software system implementation project I lead in the past. Lastly I will outline some of my learning points having compared PD with Traditional Software development method.

£. Distinctive ¢eatures oł Participatory Design łrom Project Management Perspective Participatory design unlike many systems design paradigms is polymorphic in nature; the application of PD is not limited to specific field or area of specialization; be it Information Technology, Medicine, Art etc. Although application of PD seems to be more obvious in IT systems deployment in workplace environment; ”Information system design is not the only productive activity where the need for participatory methods has been identified” ⁶. The 'gospel' of PD is to enhance user participation in design, strengthening user's control over their lives and to foster a more democratic environment. PD researchers often address system design from three perspectives;

(f) Politics of design, (2) nature of participation and (3) Methods, Tools and technique engaged in PD. A lot has been said about this basic PD frame work, but I discover it has close alliance with conventional Project Management 'body of knowledge'; I want to review the PD framework in that light.

Project management (PM) starts with Project definition and basic objectives, PD and PM are closely related in the following areas

1. Stakeholder Management
2. Communication Management
3. Human Resource Management
4. Change Management
5. Risk Management

Communication is important in any project implementation, PD and PM require that stakeholders be identified and segmented before communication could be effective. Stakeholder identification and segmentation is the first major task of any project management task, which is also important in PD.

Politics of Design and Human resource management also share a number of similarities, while PM Change and Risk management corresponds to PD methods, tools, and techniques. Politics of Design and nature of participation are closely related; as a matter of fact, prevailing politics of system (work) environment determines the nature of participation. Figure 2a below attempt to provide clear relationship between politics (power) and participation (Interest or direct impact). All stakeholders in a given system occupies a position within the four quadrant of the graph.

illustration not visible in this excerpt

Figure 2a: Stakeholders quadrant

1. Low Power, Low Interest: Stakeholders in this quadrant have insignificant political influence over the project, their interest is also dwindling because they are not directly affected or they are not knowledgeable about the impact of the proposed system will have on them.
2. High Power, Low Interest: People in this sphere has power, they could influence (determine) the success or failure of the project but they have less interest in the project. These set of people are often overlooked by designers during system implementation because the system has little or no relevance to them
3. High Power, High Interest: These set of people are the 'obvious' stakeholders. They are easily identifiable because they are actively involved in the system implementation. They have both political and will powers; they equally have strong interest in the system.
4. Low Power, High Interest: Stakeholders in this quadrant can easily be taken for a ride. Most often than not, developers or designers take their high interest for granted and 'unconsciously' decide for them. The thinking is this ' They will take anything, since they are interested in the project, they can aJJord to adjust their way oJ liJe to Jit and accommodate the system’

Having properly identified and classified stakeholders, the challenge is to consciously deploy methods, tools and techniques that will improve stakeholder's participation. The concept of PD is not to increase stakeholders' political power; but to increase their interest. A wise Participatory Designer will employ tools that will increase people's interest while managing their ego and power at the same time. These tools include interviews, observations, questionnaires, workshops, trainings, newsletters, outdoor rallies, group focus campaigns etc.

Drawing an example from a paper on health informatics in Africa by Korpela e tal; the paper reports an experimental tripartite workshop for participatory requirements analysis of a Public health care information system⁷. The stakeholders in that paper can be re−arranged on stakeholder's quadrant for better representation as show in figure 2b

illustration not visible in this excerpt

3. Participatory Design and Traditional Sołtware Development Project

As an active programmer and systems developer over the years, I will like to compare my work experience in implementation of 'Procurement Management System’ (PMS) with the tradition of PD.

PMS is workflow oriented expense processing system; it is a web application with over f,OOO active users and over fO user types (roles). PMS was developed and deployed in the 'traditional' software development. It took fO months to develop an additional 8 months to attain very good system stability after deployment. This represents over 6 months delay with reference to initial project plan. The question is: would there have been a difference if PMS was approached with PD method? Answering this question will require a review of PMS under the 5 traditional software development processes as depicted in figure 3a

illustration not visible in this excerpt

Figure 3a: Generic software development life cycle [11]

illustration not visible in this excerpt