Skip to main content
Consortium for Service Innovation

The KCS Design Session

The goals of the KCS Design Session include: 

1.     Develop the initial foundation elements (documentation) to prepare for Wave I:

  • Content standard
  • Workflow or process map
  • Performance assessment model
  • Communications plan

2.     Establish ownership of the documents the team creates, and

3.     Create the strategic framework: align the benefits of KCS with the goals of organization

The design session usually takes 3-4 days. The ideal sequence is to have the KCS Council members attend a KCS v6 Practices workshop followed by a KCS Design Session the following week. While there are always open issues or questions after the design session that need to be resolved before Wave I starts, the time invested upfront to fully understand and exercise the KCS practices pays off in the long run.

After the KCS Design Session, when Wave I is kicked off, the knowledge workers will test the new KCS workflow and content standard with their existing technology. This early experience will identity improvements before engaging the Wave II knowledge workers. It will also identify functional and integration requirements for the technology.  It is critical that we finalize the technology requirements based on actual experience with the workflow and content standard, not based on presumption. Only after we have some experience with the process and the content standard should we finalize the technology and integration requirements. If we have the option to shop for new technology, between Wave I and Wave II is the time to do it. Shopping for technology before we have experience is like shopping for clothes before we know what size we wear.

As mentioned, we create the first draft of the foundation deliverables in the design session. These must be tailored to the needs of the domain, and in the case of very large support organizations, there may be variations of the deliverables based on the unique characteristics of each domain. This is particularly true for the content standard and the workflow.  If different groups support different customers or different kinds of requests, or if they use different tools for interaction, incident management, or knowledge management, there may be unique requirements for the workflow and content standard. That being said, we find 80% of both the workflow and the content standard are common across all domains.  

Design Session Deliverables

The deliverables from the KCS Design Session include:

  • Strategic Framework – Describes how the benefits of KCS align with or contribute to the company’s high-level goals and objectives.
  • Content Standard – Describes the structure or format of an article, the intent of each of the fields, recommendation on the writing style, metadata definitions, and the article life cycle and states. The content standard also defines the Content Standard Checklist: the criteria by which the article can be assessed against the content standard.
  • Workflow – Describes the Solve Loop process, which includes reuse, linking, and integrating the creation and improvement of knowledge into the problem solving process. This deliverable also describes the Process Adherence Review (PAR) that will be used to assess compliance with the workflow (link rate and more importantly link accuracy)  
  • Performance Assessment Model – The measures for individuals, teams, and organizational performance. Defining the KCS licensing or proficiency model is also an important element of the Performance Assessment Model. 
  • Technology Functional Specifications – The list of features and integration requirements needed for the tools to support the KCS practices.
  • Communications Plan  Identification of the audiences, key messages, frequently asked questions, and objections as well as the timeline or project plan and mediums for communication activities.
  • Adoption Plan and Road Map – A road map for implementing KCS that includes the waves of adoption, list of Wave I participants, and timeline for engagement of the subsequent waves and phases of adoption.

The output of the design session is a first draft of each of the documents listed above. By first draft we mean it must be sufficient to start Wave I. The KCS Council will continuously improve these deliverables based on the experience of the early adopters in Wave I.

Details about all the deliverables listed above can be found in the KCS v6 Practices Guide with the exception of the Adoption Strategy and Road Map, described below.

The Adoption Plan and Road Map

We have talked about adopting KCS in waves: not everyone across the organization starts doing KCS at the same time. The Adoption Plan and Road Map is typically one of the last exercises in the design session. It helps the KCS Council decide who should be in the first wave. This is a critical decision and often requires considerable discussion. The goal is to identify a group of 25-50 knowledge workers who are most likely to be successful with KCS, and who will contribute to testing and improving the workflow and content standard based on their experience.

Considerations for selecting the participants in Wave I:

  • Knowledge workers who would benefit from each other’s experiences - that is, they work in the same knowledge domain
  • Represent all levels of the request resolution process:
    • If an article is framed (work-in-progress) by the first point of contact and they cannot solve the issue, the person they escalate to, who will finish the article, needs to be in Wave I as well.  
  • Represent multiple geographies (perhaps not all geographies but at least two, if applicable)
    • Having the experience of some who work in a different culture and/or language is important in Wave I 
  • The team is open to new and different ideas - they have a history of success with change initiatives
  • Management of the team understands KCS and is bought-in

For large support organizations this can become quite complicated. The Adoption Planning Matrix is a helpful tool in facilitating the discussion on domains and adoption waves. By identifying the numbers of people in each knowledge domain, level, and location, we can see the landscape and more importantly the scope of those involved. Do not get hung up on the accuracy of the numbers; ballpark estimates are fine.

Typically teams and managers have a personality or history around embracing change. Some are good at it, some aren’t.  Use the + 0 – indicators for team and manager attitudes towards change (positive, neutral, negative).

Once we have a map of the organization’s landscape and attitude, it becomes easier to pick out a group of 25-50 knowledge workers who work in a domain and would likely be successful at adopting KCS. These are our candidates for this first wave. 

Criteria for Design Session Success

While the entire KCS Council needs to be aligned to the goals of the program, much of the work in the design session is done in sub-groups: one sub-group for the strategic framework and performance assessment model, and one for the content standard and the workflow. The entire KCS Council needs to work on the communications plan together.

The sub-group that works on and owns the strategic framework and the performance assessment model should be mostly managers and supervisors with some representation by knowledge workers. The sub-group that owns the content standard and the workflow should primarily be made up of knowledge workers. It is critical that the people who resolve issues and create and use knowledge articles every day be the ones to develop the content standard and the workflow model. When management gets involved in the content standard and the workflow, they inevitably over-engineer it.

Let the people who solve problems (and create and use knowledge articles) design the workflow and the content standard.

Additional success criteria for the KCS Design Session:

  • All members of the KCS Council must be in the same room
  • Best if held at an off-site location to limit distractions
  • The ideal size group is 14-18 participants. A design team of more than 20 people is difficult to manage. If the group is larger than 20 people it is better to break into two design teams aligned with different domains, or engage two facilitators for the session. 

Criteria for Evaluating Options

The design session should be very interactive and include discussions on various ways to address the challenges the KCS Council will face; this is very important. The KCS v6 Practices Guide is a great resource but it is, as the name states, a guide. It describes an approach to implementing KCS. There are many ways to implement KCS.  Other than the four KCS Principles, there are very few absolutes. These four principles along with the eight KCS Practices make for excellent criteria when evaluating options.

principles quadrant.pngSome groups have created posters with the KCS Principles graphic (right) and posted them in the meeting rooms where the design session work is being done.  The following questions are helpful when evaluating options:  

Aligning with the KCS Principles

  • Trust
    • Are we designing from a basis of trust?
    • Are we trusting people’s ability to make good judgments?
    • Are we giving them the information they need to make good judgments?
  • Create Value
    • Are we doing tasks in the context of the big picture: the desired long term outcome?
  • Demand Driven
    • Are we doing things just-in-time, in response to demand, and in the context of the requestor’s experience?
  • Abundance
    • Are we promoting learning, collaboration, sharing, and improving?

The Goal of KCS

Create findable, usable knowledge for a specific audience.

  • Findable: how does the option being considered improve the audience's ability to find it? 
  • Useable: how does the option being considered contribute to the usefulness of the knowledge?  
  • Was this article helpful?