“Emergent knowledge processes are organizational activity patterns that exhibit three characteristics in combination:

  • ‘deliberations’ with no best structure or sequence;
  • highly unpredictable potential users and work contexts; and
  • information requirements that include general, specific, and tacit knowledge distributed across experts and non-experts.” [180-181]

Walls et al. (1992) is a big deal: said IS design theory must have set of user requirements, system features, and set of principles for guiding development. It’s based on theory and guides practitioners. They are normative, not just descriptive. Walls’s idea is to facilitate development and research by reducing uncertainty, setting out the clear, limited parameters under which the designers will operate.

Scibelli [INFS614 post] is on to something in questioning whether “emergent” is a more useful term for the processes Markus et al discuss. Maintaining a continuum of “structured — semi-structured — unstructured” may speak more immediately and clearly to non-specialists about the difference between processes without establishing a hierarchy. “Unstructured” does not suggest as clearly as Markus et al. would have it that “structuring is possible and desirable” [182]. The word certainly leaves room for that possibility: that which is unstructured might benefit from structure. The discovery and creation of knowledge — “emergent” processes — work better for some researchers (like me!) in an unstructured fashion; however, some emergent processes may be improved with some structure. I thus concur with Scibelli that replacing the term “unstructured” may not be necessary.

The term “emergent” is useful, though, to emphasize the very different nature of such work. The end product is unknown. The nature of the knowledge that emerges may require any number of changes in whatever structure was used to get to that knowledge. That doesn’t necessarily mean that researchers and inventors need to operate completely without structure. They may adopt highly structured investigation and design processes; they simply need to be open to the possibility of changing that structure to accommodate whatever results accumulate as they work.

The “tool glut” — now there’s a useful term! “Knowledge workers are supported today, not with a dearth of tools, but with too many tools and with tools that are not integrated” [185]. To remove uncertainty from developers’ jobs, previous design methodologies may lead to the creation of lots of very specific tools for specific jobs but which cannot be generalized to emergent tasks, goals, and user groups.