In my previous two posts, I showed how we can understand a delivery process as a knowledge discovery process. As professionals do their work, a sequence of dominant activities creates knowledge. The initial post contained an example of diagramming such process for a generic Agile software delivery team. The follow-up post had an example of understanding how a lean startup produced its validated learning through hypothesis testing.

Our next example takes us to the world of training and courseware. It is due to my colleague Travis, who manages a Training Department for a high-tech company. Travis’ department delivers many services, but we’ll consider only one of them in this example: developing courses.

In the process of creating a course, Travis and his colleagues have identified five dominant activities:

• fact finding
• instructional design
• drafting
• beta-testing
• publishing

Fact finding is a highly collaborative activity. Knowledge workers from Travis’ department collaborate with Research and Development, Customer Support, Technical Writers and System Engineers. As we saw in other examples of dominant activities, this one creates a lot of knowledge initially, but eventually starts to produce diminishing returns and yields to the next one.

Instructional design is handled largely within the Training Department, but Technical Writing and Sales have a say in its approval. Then drafting begins.

Drafting the course material eventually reaches the point where a different activity turns out to be a more productive way to create knowledge. So this activity begins to dominate the process of knowledge creation. Beta-testing brings together yet another different group of collaborators, including Marketing, Field Engineers, product line management and, of course, actual beta users. Testing produces another layer of knowledge and eventually yields to the final activity, publishing. This involves creating videos, printed media, presentations, handouts, and so on.

From the previous knowledge discovery process diagramming examples, you may know what to expect here, but it’s a busier diagram this time:

Next (although it won’t be the next post in this blog’s sequence), we’ll consider the practical issues with creating such diagrams and using them in improving service delivery.