By Margo Bowerman
Let’s be honest – program planning is hard work. Program planning tools help, but they can be downright overwhelming to use!
There are as many ways to do program planning as there are programs. In Cooperative Extension organizations around the country, the logic model is a well used and vetted system. The University of Wisconsin has excellent resources for how to use logic models in program planning. Public health organizations offer some excellent models – the Centers for Disease Control and the Rand Corporation have some great resources. And all these models vary in the number of steps they include and how they are described.
One day as I was searching for a simple but comprehensive representation of the engineering design process, it dawned on me that program planning, at its essence, is similar. Ironically, the engineering design process also varies in the number of steps and how they’re described.
The engineering design process begins with identifying the problem to be addressed and the constraints in solving it. The next step involves brainstorming ideas and solutions, seeking out resources to help.
If we compare these steps to the beginning steps of Wisconsin’s program development model, we see similarities in identifying the issue or situation in the first step and being able to describe the desired outcomes in the second step. Both of these steps have elements of information gathering and resource identification.
The remaining steps for these two models are very similar and the concepts are easily identifiable to each other: design your plan, carry out your plan, and analyze or evaluate your plan. What I really like about both of these models is that they are visualized as cyclical. Engineering design is inherently cyclical but program planning is not as commonly represented that way. But I would argue that nearly everything we do in program planning is part of a cycle, if not part of the program, then it at least feeds into our own knowledge and informs our best practices.
What I also like about these two models is their simplicity – only five steps. And I can usually rattle these steps off the top of my head when asked (did you know there is actually some neurological evidence that supports “Miller’s Law” or “The Magical Number 7” which argues that the capacity of human short term memory is 7 (plus or minus 2) items?).
Even across all of the various and varied models of program planning, or engineering design, the underlying factor that they all have in common is that they are systematic process that helps you set a course to reach your intended outcomes.
Do you find these models too simplistic, too complicated or just right as program planning tools? What other models or tools are you drawn to?
My parting thought: Oddly, another thing program planning and engineering design have in common is that there is rarely a best or perfect solution, but rather an optimal solution given the conditions or constraints. I encourage you to research different program planning models, tools, resources, or processes to find the ones that are systematic, make sense to you (and you can remember), that help you find the optimal solutions.
You are welcome to comment on this blog post. We encourage civil discourse, including spirited disagreement. We will delete comments that contain profanity, pornography or hate speech--any remarks that attack or demean people because of their sex, race, ethnic group, etc.--as well as spam.
Let’s be honest – program planning is hard work. Program planning tools help, but they can be downright overwhelming to use!There are as many ways to do program planning as there are programs. In Cooperative Extension organizations around the country, the logic model is a well used and vetted system. The University of Wisconsin has excellent resources for how to use logic models in program planning. Public health organizations offer some excellent models – the Centers for Disease Control and the Rand Corporation have some great resources. And all these models vary in the number of steps they include and how they are described.
One day as I was searching for a simple but comprehensive representation of the engineering design process, it dawned on me that program planning, at its essence, is similar. Ironically, the engineering design process also varies in the number of steps and how they’re described.
The engineering design process begins with identifying the problem to be addressed and the constraints in solving it. The next step involves brainstorming ideas and solutions, seeking out resources to help.
If we compare these steps to the beginning steps of Wisconsin’s program development model, we see similarities in identifying the issue or situation in the first step and being able to describe the desired outcomes in the second step. Both of these steps have elements of information gathering and resource identification.
The remaining steps for these two models are very similar and the concepts are easily identifiable to each other: design your plan, carry out your plan, and analyze or evaluate your plan. What I really like about both of these models is that they are visualized as cyclical. Engineering design is inherently cyclical but program planning is not as commonly represented that way. But I would argue that nearly everything we do in program planning is part of a cycle, if not part of the program, then it at least feeds into our own knowledge and informs our best practices.
What I also like about these two models is their simplicity – only five steps. And I can usually rattle these steps off the top of my head when asked (did you know there is actually some neurological evidence that supports “Miller’s Law” or “The Magical Number 7” which argues that the capacity of human short term memory is 7 (plus or minus 2) items?).
Even across all of the various and varied models of program planning, or engineering design, the underlying factor that they all have in common is that they are systematic process that helps you set a course to reach your intended outcomes.Do you find these models too simplistic, too complicated or just right as program planning tools? What other models or tools are you drawn to?
My parting thought: Oddly, another thing program planning and engineering design have in common is that there is rarely a best or perfect solution, but rather an optimal solution given the conditions or constraints. I encourage you to research different program planning models, tools, resources, or processes to find the ones that are systematic, make sense to you (and you can remember), that help you find the optimal solutions.
-- Margo Bowerman, Extension educator
You are welcome to comment on this blog post. We encourage civil discourse, including spirited disagreement. We will delete comments that contain profanity, pornography or hate speech--any remarks that attack or demean people because of their sex, race, ethnic group, etc.--as well as spam.
Thanks Margo for this comparison of program planning with the engineering design process. I have done program planning for many years and actually enjoy the process although I do have to remind myself to document the learning or identified best practices rather than just applying to the next program designing process.
ReplyDeleteWhen I was introduced to the engineering process a few years ago, I appreciated the process in working with young people for use in problem solving design challenges. The language was easy for youth to understand the steps, and the cyclical process allowed for improving on design ideas. This actually lifted stress youth often feel if they didn't get the "right" answer on the first try, ultimately allowing for more innovative ideas.
So would presenting the program design process in a cyclical manner increase our design innovation? Would we be better able to create big and bold ideas if we started our planning processes knowing we would redesign until we sucessfully achieved the identified outcomes? Perhaps, the biggest redesign we can achieve is allowing ourselves permission to experiment until we get it right!
What a great perspective Melissa! How do we introduce innovation in our programs when the stakes are high? Program planning can be a process to isolate a particular component of programming for the sake of examining its role in the outcome of our program. And when the stakes are high, we should also have peers and colleagues critically examine our plan to make sure our reasoning is sound and our innovations will do no harm. But I think you're right Melissa, if we think of our programs as continually evolving, it would help to promote and support innovation!
ReplyDeleteMargo, thank you for always bringing the science perspective to my work. I might see how I can incorporate this into my GOT-VIVA program planning presentation. I like to think of program planning as a program improvement cycle. Using the engineering design perspective reinforces this. Thanks for sharing your thoughts.
ReplyDelete