"The view, that purposeful action is determined by plans, is deeply rooted in the Western human sciences as the correct model of the rational actor."
– Lucy Suchman in Human-machine reconfigurations: plans and situated actions, p. 27
Plans are deemed to be important. But what do plans do? And what do they not do?
This blog post summarizes the argument of Agre and Chapman’s "What are plans for?", but does not cover artificial intelligence. Instead, it connects the ideas to project management and design.
Plans as algorithms
Assuming that “purposeful action is determined by plans” (italics added by me), a plan is like an algorithm 1 and the person using the plan is like a computer, running the program. If the plan (the algorithm) was correct for the given input and if it was executed faithfully, you get the correct result. A recipe for a cake would needs the ingredients, an oven; it it needs to be executed by a baker and it will produce a cake. So far for cakes. However, in more complex situations it shows how brittle plans are if they are seen as action-determining-algorithms: Without the capability to react to changes, the plan will fail. Design projects, for example, are hard to plan, since goals will be redefined 6 and actions will be taken opportunistically 11.
Plans as communication
A plan could also be seen as a resource. You can use it, if it makes sense. However, it does not determine action. Instead, it is a resource like a line on a map showing the way you could walk or “like following natural language instructions” 1 (thus the model of "…as communication”). The plan is not exhaustive. This is not a huge problem since the plan will be used in connection with other knowledge and interpreted as what makes most sense in the situation 1. If what the plans suggests does not work, you can find another way.
Literature on the role of plans for work give examples for such replanning: Button and Sharrock 5 describe a deviation from the plan to use the C language in programming a chip: The memory of the chip available to the programmers could not fit in the needed code in C. Thus, engineers deviated from the plan, using the “smaller” assembly language (which is also harder to maintain and thus not favored). Schmidt and Simone describe the temporary abandonment of a work organization method, Kanban, in a manufacturing process. This happened in situations where fluctuating demands would have caused delays and inefficiency if the protocol would have been followed 9. Guindon 7 describes how a design process is not done in the prescribed order, but often in an opportunistic way, using new insights on requirements and possible solutions. Visser 11 shows that designers’ work does often not rely on pre-existing plans. These are “ …only one of various action-proposing knowledge structures”.
(Here ends the part which explicitly builds on Agre and Chapman’s "What are plans for?")
Plans structure communication
While the idea of plans as communication is not only a way to think about plans differently. A lot of the literature on plan use actually covered how plans are used for communication and coordination.
A plan can help to coordinate many people who need to work together 2 3, an task for which “our everyday social and communication skills are far from sufficient.” 9. Bardram illustrates the use of plans for coordination with an example from medical work: “…the patient's diagnosis and the associated treatment plan are essential coordination mechanism… Without this plan, extensive communication has to take place in order to inform all involved personnel about the patient, his illness and how the physician in charge intends to cure it.”
But plans are not only useful before actions are taken: They are also useful to reflect on past actions and their outcomes.
By comparing plans and current actions, the contrast can be made visible and thus discussed together 8. This makes it possible to keep working in a coordinated way in the face of unexpected or unclear situations.
In comparing the plan (as an assumption of what one might do in the future) and the outcome (what one did), deviations from the plan can be used to reflect past actions as well as on assumptions held when creating the plan. This facilitates learning 2.
Plans do not determine future actions. They are just one of many sources people draw from to decide how to act. Thus, they can be also be helpful in contingent and changing situations. Plans also help to communicate, particularly in situations when there was needed deviation from the plan.
Update 19.07.2018: From “Sensemaking in Organizations”, Weick, 1995 p.54: "Strategic plans are a lot like maps. They animate and orient people. Once people begin to act (enactment), they generate tangible outcomes (cues) in some context (social), and this helps them discover (retrospect) what is occurring (ongoing), what needs to be explained (plausibility), and what should be done next (identity enhancement). Managers keep forgetting that it is what they do, not what they plan, that explains their success. They keep giving credit to the wrong thing—namely, the plan…”
What do help us plans to do? by Jan Dittrich is licensed under a Creative Commons Attribution 4.0 International License.
Bardram, Jakob E. 1997. “Plans as Situated Action: An Activity Theory Approach to Workflow Systems.” In Proceedings of the Fifth European Conference on Computer Supported Cooperative Work, 17–32. Springer, Dordrecht. https://doi.org/10.1007/978-94-015-7372-6_2. ↩↩
Churchill, Elizabeth F. 2017. “Planning Time: HCI’s Project-Management Challenges.” Interactions 24 (5): 20–21. https://doi.org/10.1145/3125391. ↩
Brooks, Jr, Frederick P. 2010. The Design of Design: Essays from a Computer Scientist. 1 edition. Upper Saddle River, NJ: Addison-Wesley Professional. ↩
Button, Graham, and Wes Sharrock. 1996. “Project Work: The Organisation of Collaborative Design and Development in Software Engineering.” Computer Supported Cooperative Work (CSCW) 5 (4): 369–86. https://doi.org/10.1007/BF00136711. ↩
Dorst, Kees, and Nigel Cross. 2001. “Creativity in the Design Process: Co-Evolution of Problem–Solution.” Design Studies 22 (5): 425–37. https://doi.org/10.1016/S0142-694X(01)00009-6. ↩
Guindon, Raymonde. 1990. “Designing the Design Process: Exploiting Opportunistic Thoughts.” Hum.-Comput. Interact. 5 (2): 305–44. ↩
Rönkkö, Kari, Yvonne Dittrich, and Dave Randall. 2005. “When Plans Do Not Work out: How Plans Are Used in Software Development Projects.” Computer Supported Cooperative Work (CSCW) 14 (5): 433–68. ↩
Visser, Willemien. 1990. “More or Less Following a Plan during Design: Opportunistic Deviations in Specification.” Int. J. Man-Mach. Stud. 33 (3): 247–78. ↩