“unproblemising” the technical complexity of shelter in post disaster reconstruction

Abstract

The provision of shelter after a disaster is a complex problem that manifests itself in all post disaster contexts. Its intractable and ‘wicked’ nature means that donors and agencies involved in humanitarian aid see it as “easy to get into, but hard to get out of”. There are seemingly no one-off, “silver bullet” solutions and where such “cookie cutter” solutions are applied, their weaknesses soon become apparent to all involved. While most lessons learnt and evaluations have pointed towards better coordination, stronger leadership, more innovation and integration of service delivery there remains little appreciation of the role of technical complexity in resolving the apparently ‘intractable’ problem of shelter provision. This chapter uses a case study approach to identify and propose an approach that is not evident in the current literature. The technical complexity of shelter provision is seemingly relegated out of the decision making. However, the presented case study and experiences from the shelter sector when re-framed suggest another reality; that the technical resolution can untangle parts of its social complexity that can foster solutions that were prior to that considered ‘intractable’. And the idea that ‘engineers have feelings too’. Thus, appropriately addressing the technical aspects releases the social complexity and allows better solutions to be determined for affected communities. This process has been termed ‘unproblemising’ because while technical resolution can release the pressure on the social dimension final resolution ultimately still rests with the social, albeit with a much better fit than would have been otherwise been possible. The appropriate technical resolution is through reflective ‘design’ that is a design not only mindful of the material realities of working in the field usually in a fragile and developing infra-structure but also of the goals and context of a ‘humanitarian’ situation. Consequently, the chapter firmly positions itself between the problem framing to problem solving domain.