How Fast Can You Implement an Enterprise Knowledge Management System?

Isn't it time to review the way you manage your e-Learning implementation? Five to seven years ago, when the e-Learning industry really took off, traditional project schedules for e-Learning system implementations ranged from 12 to 18 months. At the time, this duration was common for most enterprise-wide commercial-off-the-shelf (COTS) applications. By two years ago, many organizations were able to implement most functionality of a knowledge management system (KMS) in half that time.

Editor’s Note: Parts of this article may not format well on smartphones and smaller mobile devices. We recommend viewing on larger screens.

Today, more and more organizations expect to implement such systems in a matter of weeks, not months. This new urgency forces implementation teams to rethink their project management approach.

In this article, I examine the factors that you will find you need to consider if you want to change your project management culture in order to achieve rapid implementation of a KMS. You may wonder what this has to do with e-Learning. Although some analysts disagree, I am of the opinion that a KMS does not exist by itself. A KMS is the result of integrating multiple e-Learning applications (LMS, LCMS, CMS, Portal, etc.) to provide one consolidated platform that will deliver and maintain knowledge to or within an organization.

Rapid implementation approaches (RI) go by various names, depending on the audience, industry, and personnel involved. Fast Track, Agile Methodology, and Rapid Application Development (RAD) are all examples of dividing software projects into smaller pieces to complete them faster. Traditional software project management usually does not allow for RI success, because it is simply too slow and costly. In any case, there are key areas in the project management lifecycle that an organization should prioritize in order to ensure RI success.

While the Project Management Institute's Project Management Lifecycle can provide an excellent foundation for managing projects successfully, it is important to note when to apply these fundamentals and when to change them. During rapid implementation, you will find it necessary to alter certain elements of your project management style, as well as the team project-management culture. It is most critical to understand the matter of culture.

The American Heritage Dictionary of the English Language defines culture as the “totality of socially transmitted behavior patterns, arts, beliefs, institutions, and all other products of human work and thought.” (See references at the end of this article.) Cultural change related to the rapid deployment of KMSs falls into two categories: project-related and process-related. This means that some of the cultural changes relate to the structure of the implementation-tasking (project), while other changes deal with required modifications to internal project management processes. Although not every element in each category requires a complete process or procedure overhaul, all are areas you must highlight and understand when considering rapid deployment and implementation of an enterprise knowledge-management solution. Specific areas will also focus on how and why they are different when in a rapid implementation versus a conventional one.

Changing your project management culture is not something you can accomplish overnight. It takes most organizations many man hours to adequately adjust. To adopt a change in project management culture, company executives must have buy-in, and the Project Management Office must enforce those changes. If your organization does not have a PMO, changing PM culture is going to be extremely challenging. J. Kent Crawford notes that, “Effective cultural change occurs and will be sustained only by altering (or in some cases creating) everyday policies, practices, procedures and routines in order to impact the beliefs and values that guide employee actions.”

Every project differs in these areas, and you may find it necessary to change other elements of your project management approach. What follows is my analysis of where you should focus your attention as a project manager during a rapid enterprise Knowledge Management System implementation.

External factors

The specific external areas of focus to consider for traditional project management culture modifications are:

• Requirements
• Phase-Approach Methodology
• Project Scope, Schedule
• Project Completion Criteria
• The Customization vs. Configuration challenge

Requirements

Like most software projects, a KMS implementation project begins with the requirements. Traditionally, organizations may have considered vendors to come in-house and conduct formal KMS requirements-gathering sessions that could take months to complete before they were ready to issue a final RFP for the implementation. Today, most companies with a well-defined learning strategy understand their requirements well enough to include them as part of the initial RFP package that goes out the door, saving time and money to the project. Usually the organization has prioritized the requirements to reflect their importance. KMS requirements are no exception. Most COTS KMSs meet 80-90% of an organization’s training requirements “out-of-box,” meaning without customizations to the base product. However, for any organization that sets out specifically to implement using a rapid approach without customizations, you can divide requirements into phases, based on scheduled attainment of those requirements during the entire project.

Using a phased-approach methodology to control project scope

Let us use a Learning Management System as an example of how you can divide a rapid implementation into phases. There is no question that most major LMSs are extremely robust, and that the amount of functionality can be mind-numbing. Robustness aside, most clients do not utilize every piece of functionality that an LMS has to offer — simply because clients do not need all of it. As a result, there is no sense in trying to implement all the functional components of a system during the initial implementation. Instead, it makes more sense to break up the functionality into phases according to need. If an organization needs more than 30-35% of the functionality that major e-Learning applications provide off-the-shelf, the organization is not a good candidate for a rapid implementation.

 It is also important to understand that most organizations are more apprehensive about enterprise-wide IT investments than they were five to ten years ago. A full implementation is much more costly and time-consuming than a rapid implementation approach. John Murcott, Vice President of Products and Strategy at Fatwire, summarizes this issue best: “In the past, many companies spent millions of dollars with the largest vendors on a “Big Bang” approach to content management, and experienced major disappointments. Today, customers are much more circumspect with their technology investments and are looking for content management solutions that can start small, establish a record of success, and then scale across the enterprise.” Mr. Murcott makes an excellent point, but his view should not apply only to content management solutions. A phased approach can ensure all knowledge management system projects are a success, with minimal initial investment – Learning Management Systems, Learning Content Management Systems, Portals, and so on.

Project scope

Project scope in a rapid implementation is the first thing to alter when looking at traditional project management culture. I have yet to see an organization use every functional element in one of these platforms, even when they implemented all elements over several years. Most information systems (e-Learning included) operate under a variation of the Pareto principle (80/20 rule), and I do reiterate the word “variation.” I am sure you are familiar with the fundamentals of the principle. Due to the robustness of most COTS KMSs, 80% of the organizations seeking a RI are only going to utilize 20% of the functionality. For some organizations, the 20% may be slightly higher. Yet, if this situation arises, there is usually a correlation in project schedule duration. Therefore, as an implementation project manager, your task is to try to identify that 20% and implement it in the first phase of the project.

Project planners for a rapid implementation must trim the scope to include only the “must have” requirements, or those requirements that consider the “primary needs” of the customer. Other requirements, or what I will call “nice-to-haves” (also known as “secondary needs”), are ones that you implement in a later phase of the project. You may need to assist clients with this request, as it is not always initutive for an organization new to the e-Learning arena. To easily address this, ask yourself this question: “What do users need to have on Day 1, to consider the implementation a success?” The answer is usually the same for most organizations looking to implement with schedule as their primary driver. I have provided some examples in Table 1, which is a Phased-Approach table. I believe this is the most successful implementation strategy.

While the scope of a Portal Integration is certainly different from a standard LMS implementation, it is important to remember that the same principles apply. The most frequent requirement is to “portalize” the most common functionality of other systems, and serve those components via the portal. To remain consistent, I will demonstrate a typical phased approach for an LMS/Portal Integration and what elements of the project fall into Phase 1 or Phase 2. (See Table 2.)

By reducing the Phase 1 scope in each of these examples, I have given my end users access to the system’s core functionality in half the time. For example, it is reasonable to expect to be able to implement the scope in Phase 1 in 30 to 60 days; whereas, the scope in Phase 2 may take a few more months to complete (longer in some cases). This allows the organization to begin utilizing the system to meet their training requirements, and potentially identify any kinks or business process improvements you must make before implementing Phase 2. Again, this approach also saves the client time and money, since they do not have to expend millions of dollars for a full-blown implementation. Having time to evaluate Phase 1 functionality, along with detailed metrics on system usage, allows organizations to have a better idea of how to plan their Phase 2 strategy.

As a Project Manager, you will face constant challenges with scope creep, requirements creep, or both. Too often, you may find yourself trying to appease customer expectations by sliding in tasks not agreed upon by both parties or in the contract. It is important to remember that in a phased-approach, you are not saying “no” to your clients as a project manager, but “no, not right now.” This allows the team to accomplish those tasks in subsequent phases of the project. Failure to control scope creep will have a detrimental impact on your project’s success.

Schedule

I believe that nearly all rapid implementations have schedule as their Number One driving factor, followed closely by cost. As a project manger, you may have heard of the term “time boxing,” which I find most appropriate in a rapid implementation project schedule. Murrell G. Shields, Director of Management Solutions and Services at Deloitte & Touché, refers to time boxing as deciding up front how long the project will be allowed to take, and thus managing its scope to complete it within that timeframe. This may be exactly what a project manager must do, as I see this requirement constantly. If a client must be up and operational in 45 days, you must sit down with your project team and determine what you can implement in that time. The customer must also realize any limitations he may have to endure due to imposed schedule restrictions.

A project schedule for a rapid implementation effort will likely look much different compared to the schedule for a full implementation. Besides the obvious difference in length, the primary delta (change) in comparison to a regular implementation is the number of fast-tracked tasks (those conducted in parallel to each other). In addition, in most situations, there is zero lag in the schedule – simply because there is no room for it. As a project manager, you must know on a daily basis where your project is, against the schedule you base-lined at the beginning of the project. In a rapid implementation, you will likely need schedule updates daily, and should communicate them to the team, especially when there are variances.

Another important note with regard to schedule is to make certain you build in the tasks that the client will repeat. This is critical, as a delay in a client task that is a predecessor task may cause project delays. Lastly, in most cases, as a project manager you only need to build your project schedule to the lowest level in the work breakdown structure (WBS) in which you can track and manage a resource. As a result, do not overdo your project schedule. (See Table 3.) You want to spend most of your time executing the project, not managing the actual schedule. A rule of thumb is, if you have more than 200 tasks in Phase 1 of your rapid implementation project schedule, you may want to rethink your project schedule approach. However, we all understand that client expectations will have the last say in this.

Project Completion Criteria (PCC)

I am a firm believer that it is imperative to document the agreed-upon project criteria at the project kickoff meeting. There is nothing worse than going full steam for two months, delivering a rapid implementation project on time and on-budget, only to have a disagreement on what actually constitutes project success. In project management, the PCC become the key elements that are necessary in order to consider the project successful. In my opinion, these will become the most important elements of a rapid implementation, as you should consider them the exit criteria for project success. From initial project kickoff, the major project shareholders should sign off the completion criteria, and the project charter or project management plan should document the signoffs.

It is not uncommon to have a three-month window to implement an enterprise-wide KMS these days. As a PM, you should set realistic completion criteria. For example, I may consider these four specific elements in a 90-day implementation to be critical: (1) administrators have received adequate system training, (2) users have access to the system and associated content, (3) administrators have access to the system and associated roles/workflows; and (4) the KMS is integrated with the organization’s HR system. For a conventional KMS implementation, the PCC may be several pages in length.

It is important to note that the project scope and the completion criteria are mutually dependent. Remember, if you have any gaps between what is in scope and your completion criteria, you will need to revisit your implementation strategy. Table 4 is an example of what the project-completion criteria section of a rapid KMS implementation project management plan may include.

Customization vs. configuration

This is a topic that will surely come up multiple times during your project, whether rapid or not. During a rapid implementation, warning bells should be going off in your head every time you hear the word “customization.” That word should be an immediate signal that the request is out of scope (more than likely). Remember that most rapid implementation contracts contain a fixed price obligation for the customer’s benefit. Funding for development of customizations to the base application usually comes under a separate contract, and usually in Time and Materials (T&M) format. Also, remember that from an implementation standpoint, you should focus on the 80/20 rule. Customization requests will certainly fall outside the scope of the initial phase. Therefore, considering the impact on scope and cost, you should look at developing customizations in a subsequent phase. An Enterprise COTS KMS project that involves a major amount of customization is not a good candidate for a rapid implementation strategy.

Comments

Login or subscribe to comment