I recently read an excellent article in the Harvard Business Review on Lean and how it might apply to knowledge work. The article, from the October 2011 edition, is titled, Applying "Lean" Principles to Knowledge Work, by Bradley R Staats and David M. Upton. I encourage you to check it out, and take a look at HBR while you are at it.
This post will be about the second of six things the authors suggest. "Strive to make tacit knowledge explicit," they say. I think most people think that the type of work that knowledge workers deal it is fundamentally tacit. That is, it's in one guy's head, and it's not going to be able to be seen by others. I don't agree with this view. It's not going to be easy, but we need to make tacit knowledge visible.
One place to start, when we are talking about the development of instruction, is to separate the repeatable parts of a process and codify them. Here's an example. Let's imagine that we are developing a course on how to conduct a meeting for an audience of first-time team leads. There are practically an infinite number of ways we could go on this. And a lot of these would be valid approaches. And casting about, trying to decide which of these approaches is the best, well, that takes a lot of time. And when whoever the person is that reviews it sees the course, they may or may not agree with the approach. And then there will be at least one, if not several, long discussions about that approach. And all those conversations mean time, and frustration too.
So instead of that, my team and I determined what the default approach was going to be on any and all courses. We agreed that whenever possible, content needed to mirror the work environment that our students would return to. That all information should be as much like real life as possible. And content should be presented in job order.
We also reviewed a number of courses, and realized that all of the tasks that these courses taught students to do had a beginning, a middle, and an end. Every job-based task fell into this pattern. So when we were discussing the outline of a course, we would start by dividing the white board into three sections: The first for all preliminary tasks, the middle section for the main tasks, and then the last section for any tasks that would take place after the main tasks. Sometimes we would have a fourth section for troubleshooting and problem solving. This dramatically sped up our planning, and it also made it possible for us to collaborate on determining what the tasks were in those categories.
Another thing we did was to agree on the types of content and the requirements for those types of content, were included in instruction. We loosely followed the work of Ruth Clarke and Robert Mayer on content typing. We found over time that we improved our original model. But having a place to start from was a huge leg up. We all understood what type of content to choose if we wanted our student to determine if something was a member of a group or not. And we all understood what that content type (a concept in this example) required. Codifying this gave us consistent results, and made it much easier to use multiple writers on a project.
This post will be about the second of six things the authors suggest. "Strive to make tacit knowledge explicit," they say. I think most people think that the type of work that knowledge workers deal it is fundamentally tacit. That is, it's in one guy's head, and it's not going to be able to be seen by others. I don't agree with this view. It's not going to be easy, but we need to make tacit knowledge visible.
One place to start, when we are talking about the development of instruction, is to separate the repeatable parts of a process and codify them. Here's an example. Let's imagine that we are developing a course on how to conduct a meeting for an audience of first-time team leads. There are practically an infinite number of ways we could go on this. And a lot of these would be valid approaches. And casting about, trying to decide which of these approaches is the best, well, that takes a lot of time. And when whoever the person is that reviews it sees the course, they may or may not agree with the approach. And then there will be at least one, if not several, long discussions about that approach. And all those conversations mean time, and frustration too.
So instead of that, my team and I determined what the default approach was going to be on any and all courses. We agreed that whenever possible, content needed to mirror the work environment that our students would return to. That all information should be as much like real life as possible. And content should be presented in job order.
We also reviewed a number of courses, and realized that all of the tasks that these courses taught students to do had a beginning, a middle, and an end. Every job-based task fell into this pattern. So when we were discussing the outline of a course, we would start by dividing the white board into three sections: The first for all preliminary tasks, the middle section for the main tasks, and then the last section for any tasks that would take place after the main tasks. Sometimes we would have a fourth section for troubleshooting and problem solving. This dramatically sped up our planning, and it also made it possible for us to collaborate on determining what the tasks were in those categories.
Another thing we did was to agree on the types of content and the requirements for those types of content, were included in instruction. We loosely followed the work of Ruth Clarke and Robert Mayer on content typing. We found over time that we improved our original model. But having a place to start from was a huge leg up. We all understood what type of content to choose if we wanted our student to determine if something was a member of a group or not. And we all understood what that content type (a concept in this example) required. Codifying this gave us consistent results, and made it much easier to use multiple writers on a project.
0 comments:
Post a Comment