From Understanding programs and projects—oh, there’s a difference!: Programs focus on the coordination of a number of related projects and other activities, over time, to deliver benefits to the organization. (Contra projects)
Unlike something like architecting a building, the point of doing§Program Design^1 is not to create a blueprint that encodes all the information of the process and can be handed off to someone to execute on. In this sense, it’s a misnomer to call it “program design” and to call the resulting artifact a “roadmap.” Both of these terms imply a process whose main goal is to produce something static that can be separated from the people involved. In reality the goal is to create a shared purpose (in the Dancoland/Complex System sense)^2 and then maintain that shared purpose.
Program design coordinates people in three distinct ways:
There are several takeaways from treating program design seriously as a coordination mechanism.
Andy Matuschak points out that this description of program design clashes with the story of J.C.R. Licklider. Instead of an iterated process of understanding the state of a field and finding a target point that aligns the various stakeholders <Stakeholders are sometimes the maximum level of precision for complex systems>, Lick (the story goes) had a vision and did a combination of funding the few people who shared it and forced other people to go along with it by threatening their other funding.
It’s the difference between
There are several corollary questions here:
^1: Note that as of at least 3 Sep 2021 I’m still feeling around what program design actually is but you can still make assertions about a Nebulous thing.
^2: At least as of 8 Sep 2021 I find this to be a really powerful concept to think about the equivalent for a “goal” in complex systems to sidestep the pressure to either think about goals or simply the things that a productive system does like conversations and decisions.