Home > KCS v6 Adoption Guide > Phase 1 - Design and Planning > 1.4 The KCS Design Session

1.4 The KCS Design Session

 

The KCS Design Session is a four to five day workshop with three goals: 

1.     Develop the initial documentation for KCS

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

3.     Align KCS with the goals of organization. 

 

At the completion of the KCS Design Session, the first wave of adopters (Pilot Team) will use the new workflow and content standard with existing software tools and provide feedback for improvement before engaging any additional users or modifying technologies.

 

In the Design Session, the first draft of the foundation deliverables are created. These must be tailored to the needs of the organization, and in the case of very large support organizations, there may be variations of the deliverables based on the unique characteristics of each support group.  This is particularly true for the content standard and the workflow.  If different groups support different customers or different kinds of products, or if they use different tools for incident management unique requirements for the workflow and content standard may be appropriate. That being said, we find 80% of both the workflow and the content standard are common across all groups.  Unique requirements are reflected in variations that represent less than 20% of each of the documents.   

Design Session Deliverables

The deliverables from the 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 Article Quality Index (AQI): how article will be scored.
  • Workflow – Describes the Solve Loop process, which includes integrating the creation and maintenance of knowledge into the problem solving process.
  • Performance Assessment Model – The measures for individuals, teams and organizational performance.
  • Technology Functional Specifications – The list of features and integration requirements needed for the tools to support the KCS practices.
  • Communications Framework  - 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 Strategy and Road Map – Identification of the waves of adoption, list of Wave I Pilot Team 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 support the pilot. The adoption team will continuously improve these deliverables based on the experience of the early users.

 

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

The Adoption Strategy and Road Map

We have talked about the concept of waves of adopters – not everyone across the organization starts doing KCS at the same time.  The Adoption Strategy and Road Map is typically one of the last exercises in the Design Session. It helps the Adoption Team 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 – 40 Analysts who are most likely to be successful with KCS and who will test and improve the workflow and content standard based on their experience.

 

A few criteria for selecting the participants in the first wave:

  • Support Analysts who would benefit from each other’s experiences - that is, they work in the same product area.
  • Represents all levels of the problem solving process – levels 1, 2 and 3
    • If the Article is framed (work-in-progress) by a level 1 person, the person they escalate to needs to be in wave 1.  Similarly, whoever the level 2 person escalates to needs to be in wave 1.
  • Represent multiple geographies (at least two, if applicable).
  • The team is open to new and different ideas.
  • Management of the team is open to new and different ideas.

 

For large support organization this can become quite complicated. Attached is the Adoption Planning Matrix, which is a helpful tool in facilitating the discussion on the adoption waves.  By identifying the numbers of people in each product area, level, and location, we can get a picture of the landscape. 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.

 

Once we have the map of the organization’s landscape and attitude, it becomes easier to pick out a group of 25-40 Support Analysts who share a product area and would likely be successful at a KCS adoption.  These are our candidates for this first wave. 

Criteria for Design Session Success

workflow.pngWhile the entire KCS Adoption team needs to be aligned to the goals of the program, much of the work in the Design Session is done in sub-groups: one team for the communication plan and performance model and one for the content standard and the workflow.

 

The team that owns the communications plan and the performance assessment model should be mostly managers and supervisors with some representation by Support Analysts. The team that owns the content standard and the workflow should be mostly Support Analysts. It is critical that the people who solve problems and create and use knowledge Articles everyday develop the content standard and the workflow model.  When management gets involved in the content standard and the workflow, they inevitably over-engineer it.

 

Additional success criteria for the Design Session:

  • All members of the KCS Adoption team 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 24 people is difficult to manage. If the group is larger than 24 people it is better to break into two design teams aligned with different product areas.

Criteria for Evaluating Options

The design session should be very interactive; discussion on various ways to address the challenges is important.  The KCS 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. However, successful implementations adhere to a few fundamental principles.

 

When exploring implementation options the following principles should be applied to test ideas for compliance to the KCS ideals:

  • The intent of KCS: capture the collective experience of the organization as part of the problem solving process and make it available to
    • Our peers
    • Our customers
  • Create content that is findable and usable by a specific audience
    • In the context of the audience that is likely to be looking for it
    • Sufficient to solve or “good enough”
  • Demand driven
    • Capture and solve the issue the customer asked about
    • Don’t extrapolate or expand
    • Don’t attempt to assess the future value of an issue.  If the issue is worth resolving, it is worth putting in the knowledge base
    • Reuse is review.  Content that is used is constantly being reviewed and improved. If something is never reused … it never gets reviewed – no wasted effort!
  • Keep it simple – don’t over-engineer it
    • Make the Design Session deliverables just what they need to be to get started. Do not make them everything they could be.
    • Then, let them become what they need to be based on experience from the pilot (a variation on demand driven).  Experience is always more accurate than presumption!
You must to post a comment.
Last modified
12:11, 11 May 2016

Tags

This page has no custom tags.

Classifications

This page has no classifications.