Why do we need a WIP?

There are a few important reasons to use the “Work in Progress” (WIP) status in a KCS implementation.

First is to preserve the customer context across the life of the case.

If the issue takes some time to resolve, as is often the case in moderate to complex support environments, or if we have to escalate the issue to get a resolution (assuming the traditional tiered support model), it is critical that the customer’s context (how they described the issue) be captured at the beginning of the issue resolution process: at the first point of contact with the customer.

The customer context is a key factor in findability, and it is nearly impossible to recreate how the customer described the issue after we know the answer. Additionally, if the case gets escalated to another group for resolution, by passing both the case and the WIP article we preserve the customer’s context.  The person who figures out the solution to the issue adds the resolution to the article, reviews the environment statements, and updates the article status as appropriate.

Second is to enable collaboration across space and time.

A WIP article promotes collaboration in environments where the resolution of issues takes some time, and especially when teams are working in multiple locations around the world.  If someone working in a different shift or geography gets a case with the same issue (or even a similar issue) and they search the knowledge base, they will find that the issue has already been reported and is being worked on.  Visibility to WIP articles prevents duplicate effort and promotes collaboration across different shifts and locations.

As a general rule of thumb, an article should only be in a WIP state while the case is open and being worked.  If the case is closed because the issue has been resolved, the article status should be updated to “Not Validated” or “Validated” as appropriate.

For more information on the confidence states for KCS articles, visit the KCS v6 Practices Guide

2 thoughts on “Why do we need a WIP?

  1. I very much agree with this point Greg and appreciate you taking the time to call attention to it.

    In my opinion, our industry does not address this concept very well today. I believe that’s because the WIP article falls in to the difficult space between Case Management, Knowledge Management, Search, and Collaboration. The WIP article must start in this “grey area” that no vendor owns entirely…yet that’s where our KCS author’s journey begins. It’s further complicated that a good WIP implementation must account for the author walking away from the WIP article should it not be required at the end. After all, we don’t want to occupy space in the KB with a bunch of WIP articles that were left unfinished because the author made the right decision to not publish something in the end (i.e. nothing to share).

    I believe this boils down to approach. Our KCS teams should work an issue with the intent of authoring an article. The key here is intent, as we’re not committed. The problem is, KM providers that I’ve reviewed approach the WIP article assuming an issues is worked where we’re committed to writing an article. That’s two different things.

    As a result, practitioners in the field spend a lot of time solutioning this concept in our individual environments. I applaud you for the public call out and hope that maybe in the future there is a KCS certified solution that adequately addresses the WIP article concept. To do this well today, we have to build our own.

  2. Just to share our experience: following the practice to create WIP we realized that it is not that important in some environments:
    >First is to preserve the customer context across the life of the case
    This can be done at the end, all the information on a ticket and you won’t lose it if you decide to put all once you find a resolution.

    >to enable collaboration across space and time
    Generally, reoccurrence is very low for us, so the chance 2 people will work on the same article is almost 0%. In exceptional cases, when we have major drivers we get multiple cases at once and engineers just notify each other and establish collaboration through slack.

    And opposite “cons” to follow this:
    Often it results in the fact the problem is known, and as a result, you have to merge article to existing or to remove it at all.

Leave a Reply

Your email address will not be published. Required fields are marked *