Making Do: How Bricolage Explains Improvised IS Innovation

There is a financial analyst at a mid-size manufacturing company I know of who built the company's entire cost tracking process in Excel. Not a quick dashboard, not a prototype. The actual process, with formulas that pull from three different upstream systems, macros that format the output, and a tab for exceptions that the ERP was never designed to handle. The ERP has been in place for eight years. The Excel file is eleven years old. The ERP was supposed to replace the Excel file. It never did, because the Excel file does things the ERP cannot, and everyone knows it.

That Excel file is what Claude Lévi-Strauss would have called bricolage. His 1966 concept, borrowed from the French term for someone who makes do with whatever materials are at hand, described a mode of thinking and making that works with existing resources rather than seeking ideal ones. The bricoleur does not wait for the perfect tool. The bricoleur picks up what is available and recombines it to solve the problem in front of them. The result is not elegant. It is functional, and sometimes it is genuinely novel.

Baker and Nelson (2005) applied this idea directly to entrepreneurship. In a study of resource-constrained firms, they found that organizations facing genuine scarcity often created value by recombining existing resources in new ways rather than acquiring what they thought they lacked. The bricolage was not a placeholder until the real solution arrived. It was the solution, built from whatever was at hand, and it often developed into a durable organizational capability. My study materials reference bricolage in the context of IS and organizational change, and the logic maps cleanly onto what I keep observing in enterprise settings. The paper is in my local library from the Faik, Barrett, and Oborn (2020) paper in MISQ Executive, which mentions "enabling bricolage" as part of how IT matters in societal change.

The IS application of bricolage is not complicated to see once you have the concept. Organizations that cannot afford the right system, or that face a procurement cycle so long the need has become urgent before any official tool arrives, build solutions from what they have. Spreadsheets, email threads, shared drives, Slack channels, repurposed calendar invites. The combination is improvised. The function is real. What makes IS bricolage interesting is the same thing that makes Baker and Nelson's entrepreneurship bricolage interesting: the improvised solution sometimes works better than the official one, and the capability embedded in it is often invisible until someone tries to shut it down.

The tension with IT governance is real and worth taking seriously. IT departments have legitimate reasons to push back on improvised solutions. They create security risks when data leaves controlled environments. They create compliance risks when processes are not documented or auditable. They create operational risks when the one person who understands the macro structure leaves the company. I have read enough post-incident reports to know that spreadsheet complexity is a genuine vulnerability. The Reinhart-Rogoff spreadsheet error, which affected economic policy for years, is the canonical academic example, but there are quieter versions of that risk in enterprise finance and operations everywhere.

But the governance response to bricolage often throws away the capability with the security risk. When IT shuts down a shadow Excel process and replaces it with the official module, the replacement is usually designed by people who were not present when the original problem was being solved. The Excel file understood the exception tab. The official module often does not, because nobody thought to ask why that tab existed. The capability disappears. The workaround reappears, somewhere else, in a newer format, because the underlying problem was never addressed.

This connects directly to what I wrote about workarounds and shadow IT as requirements documents. Bricolage extends that argument into the territory of innovation rather than just workaround. The distinction matters. A workaround is a response to a system that does not fit the work. Bricolage is a creation, assembling something that did not exist before from available materials. Both can coexist in the same Excel file: the workaround is the part that does what the ERP was supposed to do, and the bricolage is the part that does something the ERP was never designed to do at all.

Gartner's coverage of citizen development and low-code platforms is, in one reading, an institutional attempt to channel bricolage. When a major analyst firm says that organizations should expect a significant portion of their applications to be built by non-developers by the end of this decade, what they are acknowledging is that users have always been building their own solutions, and the question is whether to ignore that fact, suppress it, or try to shape it. The Gartner newsroom at https://www.gartner.com/en/newsroom regularly covers low-code and citizen development as governance responses to the reality that employees build things whether or not IT approves. Low-code platforms are formalized bricolage. They give the bricoleur better materials without asking them to stop building.

The most interesting IS research question here, at least to me, is about what happens to bricolage capabilities over time. Baker and Nelson found that resource-constrained firms developed genuine organizational capabilities through repeated bricolage. The practice of making do becomes a skill. The people who built the improvised solutions develop a deep understanding of the problem space that the official system architects often lack. When the organization eventually gets the resources to implement a proper solution, the people who did the bricolage are the ones who understand what the proper solution actually needs to do. They are also the ones most likely to be dismissed from the design process, because their solution looks like a mess.

The underresourced hospital that runs its patient flow on a combination of whiteboards, personal phones, and a repurposed scheduling app understands patient flow. The consultant who comes in to implement the $3M patient flow system often does not. The bricoleurs have knowledge that is sitting in their improvised solution, waiting to be extracted. The question is whether anyone will bother to look before they replace it.