Push-Pull KMS – Stage 2
Link to Part 1 – here.
Link to Part 2 – here.
Note – this was written in 2000 for my former quarterly newsletter, and I’ve made only slight edits to it for posting here in 2018.
I am publicizing and promoting my view that KMS, as well as e-learning (newfangled, not-so-traditional, and blended) and t-learning (oldfangled, traditional, and blended), should be undertaken only when the shareholder’s short-term, mid-term, and/or long-term needs are served.
To me, the shareholders are served when the benefits/returns (as measured mostly in dollars) significantly outweigh the costs/investments required. It must do as well “return-wise” as any other opportunity/problem the enterprise faces, or it is simply the wrong thing to do situationally.
Otherwise, why bother? Would you feel that way if you “owned” all of the shares? This approach requires targeting KMS only after some careful (but potentially quick) analyses.
I only believe in “push-pull” KMS, not “build it and they will come” KMS. Too often I see in the literature and in conference presentations too many thoughts, tips, methods, and promotions devoid of sound business thinking regarding why do this in the first place and for whom. We see the sad potential for enterprise investments and returns for KMS to become out of control and unpredictable.
To me, KMS should be all about return on investment (ROI) and economic value added (EVA). Otherwise, again, why bother? If you’re unsure, ask a shareholder.
Push-KMS is when enterprise leaders deliberately target certain processes and target audiences for KMS treatment. Then their needs are addressed, and knowledge products are produced (using good ISD methods) and deployed (pushed) to them. These knowledge products can include
- Best practices
- Lessons learned
- Job aids/EPSS
- Example plans
- Example documents
Pull-KMS is when other, nonkey target audiences tap into the knowledge repository and pull the content to meet their needs. Note that not all of their needs will be met, because they weren’t “targeted” by the enterprise leadership.
In my evolving/updated model (back in the late 1990s and in 2000) for push-pull KMS, the four stages for KMS implementation are:
- Stage 1 – KMS Business Case Development
- Stage 2 – KMS Processes and Infrastructure Development/Deployment
- Stage 3 – Initial KMS Content Development and Implementation
- Stage 4 – Ongoing KMS Operations and Maintenance
Once the business case has been made and bought in to by the enterprise leadership in Stage 1, Stage 2 is all about putting the systems, processes, and infrastructure needed into place, consistent with the business case plans.
To build the details and price the investments needed in the business case in Stage 1, these systems, processes, and infrastructure that will be needed have to be roughly determined, scoped, and priced.
KMS Implementation Stage 2 – KMS Processes and Infrastructure Development/Deployment
In my models for EPPI (Enterprise Process Performance Improvement), T&D Systems View, and PACT (Performance-based, Accelerated, Customer-/Stakeholder-driven, Training & Development), I bundle “processes” into “systems.”
These systems and processes fit into my T&D Systems View model (AKA: the T&D “clockface”) presented in Figure 1. Whether you call it T&D, L&D or KMS, we believe that the systems and processes framework would be the same.
The T&D Systems View Model (the Clockface)
The 12 systems on the clockface include 47 processes. See the spring 1999 through winter 2000 newsletter issues for the article series on the T&D Systems View, or find a related article and an “assessment tool” on the website here.
The clockface sums up the T&D Systems View (a 2001 book) of the systems and the processes needed within any internal or external T&D organization (or replace “T&D” with “Learning” if you must). We believe that any T&D/KMS system will require all of these, however named or configured within any enterprise.
These processes need to be performed by humans using the environment provided. To ensure that the critical processes are in control, where an uncontrolled state presents risks too great to leave to chance, the future-state processes should be mapped, human performance modeled, and all enablers derived.
If this is being done for a planned “KMS greenfield” approach, the next step is to build or buy the piece parts of the infrastructure and then deploy, test, debug, etc.
If this infrastructure analysis is being done for a planned improvement initiative for an existing KMS system, then a gap analysis needs to be conducted to identify the changes needed for planning how to get from here (the current state) to there (the future state). Perhaps you’ll plan to do it incrementally, in baby steps, or go for the whole enchilada in one fell swoop.
Okay so far? Then let’s get into the infrastructure specifics needed to enable the KMS’s processes.
My model for infrastructure, covered in prior issues of this newsletter (see the fall 2000 and winter 2000 issues on our Website) includes both human infrastructure and environmental infrastructure. In combination, these two sets of required infrastructure enable the process(es).
Humans have to have various knowledge (sometimes at an awareness or detailed level), skills, attributes (sometimes physical, psychological, and intellectual depending), and values necessary to perform the process tasks given the environment in place. If the environment contains EPSS, the humans will need to memorize less and can just follow the procedures that they’ll have to know how to follow. The same is true for the other enablers. Either the humans know how to and have the physical capability to lift the heavy objects required, or they are provided with an environmental asset, such as a forklift, to assist them.
The enterprise’s process requirements are met by building capability into either the human element or the environmental elements. Typically, short production runs would have the performance engineers build the intelligence and capability into the human side; for long production runs, it would be better to build it into the environmental side.
By production run we really mean the longevity/quantity of the performance. If the process is going to be stable for years and years, let the environmental elements carry the load. If the process is seen as more volatile, prepare the humans to carry the load. Would you build expensive tooling and systems for something that might last for 3 to 6 months, or prepare craftsmen to get the job done and then let them evolve/adapt and roll with the inevitable changes?
Our model for the human and environmental assets/elements is shown in this next graphic.
This model can be used to systematically derive these enablers, per process, and then can be rolled up into a systems view as well as departmental/job views.
We think this is what ERP systems are looking for, as well as KMS for many of the knowledge/skill items and information/data elements.
Once the human environmental elements required are determined, they can be developed/built or bought (and then used as is or modified as needed). With the insights gained in the prior step of determining what is needed, the investment costs can be determined. If these numbers were rough-cut estimated earlier for the business case, then they’ll have to be refined at this point and the business case ROI revalidated before continuing.
Infrastructure Pilot-Test and Revision
If the effort still makes business sense, the developed/acquired elements are pilot-tested, unless the ultimate deployment’s scope or stakes make that unnecessary.
Once any pilot-test efforts and then any subsequent revisions are concluded, the entire set of change elements can be rolled out per the plan.
With the systems, processes, and infrastructure in place, guidance from the Governance and Advisory Boards should steer the ship toward the mission-critical-only target audiences and processes for the KMS to address for “push” treatment.
In the next Post in this 6-part series, I will address Stage 3: Initial KMS Content Development and Implementation.
# # #