SOA (Service Oriented Architecture) may as well be the latest craze to hit the business world and the effectiveness that it brings about in the company processes is surely noteworthy. That's because, what this concept aims at is the overall optimization of the available resources which would include both, i.e., technological resources as well as human resources.

Six Sigma is a real boon to companies in all industries, and it has proven this fact on many occasions. That's because the Six Sigma methodology can work wonders when it comes to improving the quality of products and services by eliminating the defects encountered in any particular business process.

Over the years, the Six Sigma quality management methodology has no doubt proved its worth. However, businesses should not lower their guard while implementing Six Sigma, because Six Sigma's eventual success depends a lot more on how implementations are actually carried out and not just on the type of tools and techniques utilized.

Six Sigma project charters are basically blueprints of the targeted Six Sigma quality improvement initiative. They are deemed important because it is only through them can the management hope to communicate the exact Six Sigma implementation roadmap to the implementation team.

More than three decades have passed since Six Sigma was first implemented by the Motorola Company in the seventies, but the concept still reigns supreme - mostly because of its effectiveness as a quality management technique and its versatility in terms of its applicability to all types of businesses, big or small, in services or manufacturing.

People tend to feel more comfortable in an orderly environment. This is why shops and other retail businesses spend so much time planning where to put what and how things should be arranged to make customers feel more at home. Surely you would like your own dwelling to reflect these skills honed by business owners?

CHANGING TRADITIONAL PROJECT MANAGEMENT CULTURE TO RAPIDLY IMPLEMENT ENTERPRISE KNOWLEDGE MANAGEMENT SYSTEMS BILLY BIGGS, MBA, PMP ASSISTANT DIRECTOR, KNOWLEDGE CONSULTING GENERAL PHYSICS CORPORATION Executive Summary Five to seven years ago, when the eLearning industry really took off, traditional project schedules for eLearning system implementations ranged from 12 to18 months. At that time, this duration was common for most enterprise-wide COTS applications. As recently as 2 years ago, those schedules had been cut in half for implementing most functionality of a Knowledge Management System (KMS). (Note - 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 eLearning applications (LMS, LCMS, CMS, Portal, etc) together to provide one consolidated platform to deliver and maintain knowledge to/within an organization). More and more organizations are now looking to implement such systems in a matter of weeks versus months. To do so effectively, project teams are forced to rethink their project management approach. Rapid Implementation (RI) has various names depending on the audience, industry and personnel involved. Fact-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 should be prioritized to ensure RI success. While PMI’s Project Management Lifecycle can provide an excellent foundation for how projects can be managed successfully, it is important to note when to apply these fundamentals and when to change them. During a RI, you will be required to alter certain elements of your project management style, as well as the team project management culture. Culture is the “totality of socially transmitted behavior patterns, arts, beliefs, institutions, and all other products of human work and thought. ” Cultural change related to the rapid deployment of KMSs can be divided into two categories: project-related and process-related, meaning – some of the cultural changes relate to how the implementation’s tasking (project) is constructed, while others deal with how internal project management processes need to be modified. While not every element in each category will require a complete process or procedure overhaul, they are areas to highlight and understand when considering rapid deployment and implementation of an enterprise knowledge management solution. Specific areas will also focus on some of the major differences in how and why they are different when analyzing a RI versus a conventional implementation. Changing your project management culture cannot be accomplished overnight. It takes most organizations many man-hours to adequately adjust. It is critical to note that 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. “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. ” The specific areas of focus that must be considered for traditional project management culture modifications are: Requirements, Phase-Approach Methodology, Project Scope, Schedule, Project Completion Criteria, and the Customization vs. Configuration challenge. Areas of focus for process changes are: Communications, Risk, Influence, Assumptions and Leadership. Although every project differs in these areas, and you may find it necessary to change other elements of your project management approach, this article defines the key areas where you should focus your attention as a project manager during a rapid enterprise Knowledge Management System Implementation. EXTERNAL FACTORS 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 requirements are prioritized in some fashion of importance to the organization, with KMS requirements being 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, requirements can be divided into phases of when they will be met 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 a RI can be divided 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 they have to offer – simply because they 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, the functionality that is needed should be broken up into phases. If an organization needs more than 30-35% of the functionality major eLearning COTS applications provide, they are not good candidates for a RI. It is also important to understand that most organizations are more apprehensive about enterprise-wide IT investments than they were 5 to10 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 be only limited 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, etc. Project scope in a rapid implementation is the first thing that must be altered when looking at traditional PM culture. I have yet to see an organization use every functional element in one of these platforms, even when all elements were implemented over several years. Most information systems (eLearning 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 roboustness of most COTS KMSs, 80% of the orgnizations 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. Scope for a RI must be trimmed to only the “must have” requirements or those requirements consider the “primary needs” of the customer. Other requirements, or what I will call “nice-to-haves” (also known as “secondary needs”), can be implemented in a later phase of the project. You may be asked to assist clients with this request, as it is not always initutive for an organization new to the eLearning 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 below in a Phased-Approach table, as I believe it is the most success implementation strategy. Learning Management System Implementation Phase 1 Phase 2 1. User Data a. Name, Department, Organization, Employee Type, Employee Number, Employee Status 1. User Data a. Learning History, Phone Number, Job Position, User Defined Fields 2. Course Data a. Course Type, Completion Status, Subject Area (Usually limited to 3rd party content) 2. Course Data a. Assignment types, class status, holiday profiles, training purposes, training types, work week profiles 3. Other Data a. Standard approval processes, workflows and account restrictions 3. Other Data a. Competency-related data, commerce-related data b. Approval Processes 4. Interfaces to other IT/HR systems While the scope of a Portal Integration is certainly different than a standard LMS implementation, it is important to remember that the same principles can be applied. 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 can be divided into Phase 1 or Phase 2. Portal Integration with Learning Management System Phase 1 Phase 2 1. User Single-on a. Gaining access to the LMS application through the Portal without requirement a separate user id/password. 1. User’s Access to Reports a. Run user reports such a completion certificate reports, learning needs reports, or skills/competencies reports. 2. User’s Access to Learning Plan a. Ability to see all current learning activities user is enrolled in via Portlet without having to log into the LMS 2. User’s Access to Learning History a. View user’s learning/training history from Portlet on any learning events that have been taken in the LMS or migrated from legacy training systems. 3. User’s Access to Search/Browse Catalog a. User can search/browse the LMS Catalog from the Portal 3. Administrator functionality a. Integrate administration functionality accessible via Portal. (Note – this is not a common element for portalization By reducing the Phase 1 scope in each of the above 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-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 to be made 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 be constantly challenged with scope and/or requirements creep. Too often, you may find yourself trying to appease customer expectations by sliding in tasks that were 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 more of “no, not right now” and allow those tasks to be accomplished in a subsequent phases of the project. Failure to control scope creep will have a detrimental impact on your project’s success. Schedule It is my assessment that nearly all rapid implementations have schedule as their #1 driving factor, followed closely by cost. As a project manger, you may have heard of the term “time boxing,” which I find most appropriate with regards to a RI project schedule. Murrell G. Shields, author of E-Business and ERP: Rapid Implementation and Project Planning and 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 . In essence, this may be exactly what you are required to do as a PM, 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 can be implemented 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 RI effort will likely look much different compared to that of a full implementation. Besides the obvious difference in length, the primary delta in comparison to a regular implementation is the amount of tasks that are being fast tracked (conducted in parallel of each other). Also, in most situations, there is zero lag built into the schedule – simply because there is no room for it. As a PM, you will be tested on a daily basis to where your project is with regards to the schedule you base-lined at the beginning of the project. In a RI, schedule updates will likely be needed daily and should be communicated to the team, especially when variances occur. Another important note with regards to schedule is to make certain you build in the tasks that will be completed by the client. 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 are only required to build your project schedule to the lowest level in the work breakdown structure (WBS) in which a resource can be tracked and managed. As a result, do not overdo your project schedule. 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 the 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. HIGH LEVEL STEPS AND TIMELINES FOR RAPID IMPLEMENTATION (NOTE: MANY OF THESE ACTIVITIES WERE PERFORMED IN PARALLEL.) 1. PROJECT KICK-OFF MEETING 1 DAY 2. CONDUCT TRAINING 5 DAYS 3. FUNCTIONAL WORKSHOPS 3-5 DAYS 4. TECHNICAL WORKSHOPS 3-5 DAYS 5. DEVELOP AND DELIVER DESIGN DOCUMENT 30 DAYS 6. SET-UP KMS ENVIRONMENTS 10 DAYS 7. SET-UP HELPDESK 5 DAYS 8. DATA MIGRATION 14 DAYS 9. TESTING 5 DAYS 10. MARKETING ENTIRE PROJECT SCHEDULE 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 2 months delivering a rapid implementation project on-time and on-budget only to have a disagreement on what actually constituted project success. In project management, the PCC become the key elements which are necessary for the project to be considered successful. In my opinion, these will become the most important elements of a RI as they should be considered the exit criteria for project success. From initial project kickoff, completion criteria should be signed off by the major shareholders of the project and documented in the project charter or project management plan. It is not uncommon to have a 3 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 4 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 is tied to the completion criteria. Remember, if you have any gaps between what is in scope and your completion criteria, you will need to revisit your implementation strategy. Below is an example of what may be included in the project completion criteria section of a rapid KMS implementation project management plan. Project Completion Criteria (Phase 1) WILL HAVE WILL NOT HAVE Peoplesoft integration Mentoring support Light branding – common look and feel (user interface) Financial System Interface Domain setup according to organization Multiple user interfaces/ looks and feels Baseline of roles and permissions Course completions that are stores in legacy system Level I Help Desk Legacy/Custom Content Installation KMS version x.x in a secure hosting environment COTS Reporting Interface Baseline Security Plan and Disaster Recovery Plan 3rd party content imported and operational Customization vs. Configuration This is a topic that will surely come up multiple times during your project, whether it is considered rapid or not. During a rapid implementation, warning bells should be going off in your head every time you hear the word customization. That should be an immediate signal that this type of request is out of scope (more than likely). Remember that most RIs are contracted as a fixed price obligation for the customer’s behalf. Developing customizations to the base application is almost always funded under a separate contract and usually in Time & Materials (T&M) format. Also, remember that from an implementation standpoint, you should be focused on the 80/20 rule. Customization requests will certainly fall outside of the scope of the initial phase. So, with the impact on scope and cost, you should look at customizations being developed in a subsequent phase. Consequently, a project that has a major amount of customization requirements for an Enterprise COTS KMS is not a good candidate for a rapid implementation strategy. INTERNAL FACTORS Communication We all understand the importance of effective and timely communication when managing a software/IT project. In fact, a project manager cannot be successful without a sound communication plan for most projects. However, there are some key differences in how communication relates to a rapid implementation project that you should be aware of. For a standard implementation, a weekly project team meeting is the norm. Huddling up once a week for the period of 6 months to go over issues or concerns and the planned resolution for those issues/concerns is probably reasonable. If you are looking to implement in a period of weeks vs. months, that approach is not going to work. For a 60 day implementation, the project team should be meeting twice a week, at minimum, for the first couple of weeks. After the project kicks in full gear, meetings may occur every day to resolve any critical issues that would prevent the project from going live on its agreed-upon date. Another area of focus should be communications between your core project team and your extended project team. Core team members will be responsible for the heavy lifting of the project and its day to day operations. Examples include Technical eLearning Specialists, Project Coordinators and Hosting Engineers. Extended team members should include Content Developers, Security Analysts, and Business Analyst – those not directly related to the major functions of the project. Core team members should participate on status calls and meetings. This group will be directly responsible for the project’s status. There may be other project team members involved, however, not necessarily participating in every status call or meeting. You will need to focus on ensuring you have the correct communication mechanisms in place for each team. The core team should be limited in the number of participants to ensure all material can be covered in a timely manner, as inviting too many people on status calls can result in ineffective and irreverent discussions, ultimately wasting time. Risk The key component to be aware of with regards to risk is the amount of time you have to respond in a RI. Every project management plan should contain a risk analysis section that identities the risks associated with the project, along with the risk triggers and mitigation plan for each risk. A risk mitigation section should be added to the project plan that addresses potential contingency plans for prioritized risks. Also, it should clearly indicate how each risk will be managed: avoidance, mitigation, or transfer. Risks such as losing key resources, deploying software in a timely manner, and receiving equipment on time are becoming much more critical in a rapid deployment of an enterprise KMS. As I previously mentioned, the most important risk element in a RI is to ensure you have established a contingency plan for the project itself. For instance, what happens if the project does not meet its targeted go-live date? Some organization may account for this type of occurrence and build a buffer period into the schedule, whereas others may not. Either way, a well documented and agreed upon contingency plan ensures those risks are mitigated. Assumptions Every project is built on a list of assumptions (or additional clarifications), which may or may not be clearly documented. Even if they are documented, they are likely some of the most under-prioritized components of the project plan. However, assumptions are very important in every project, and even more so in a rapid implementation. A project management plan or charter for a RI should list many more clarifications (or the assumptions should contain more detail) than a conventional implementation. Why? Rapid implementation project issues have a tendency to have a bigger impact simply because time is not a luxury the project team can enjoy. The exercise of documenting both business and technical assumptions in a rapid implementation is important because “there is a huge fallacy in the assumptions we make about managing projects, and that is that the world will stand still while we execute our carefully constructed project plan. ” This situation does not exist for PMs under normal implementation standards and is even less likely to occur under additional stress and more moving parts that come with a rapid deployment. Assumptions should be made about the scope, key project personnel, any project constraints or external dependencies. As a PM, try to clearly document everything that you are assuming needs to happen for the project to succeed, no matter how insignificant it may sound. In most cases, you should be able to copy the key assumptions right from the initial contract to your project plan. Leadership There are a few distinct styles of leadership that may be applied to any given project. Realistically, your leadership style falls into one of four styles: Directive, Participative, Coaching, and Delegating. I will only focus on Directive and Participate in this article, because Coaching and Delegating are mere variations of the former approaches. You may also hear the Directive style being referred to as “Telling” or “Forming.” Whatever your term of choice may be, the underlying principles are the same. The leader sets goals and objectives, lays out the work in great detail, and tends to be extremely active in resolving all problems and issues. Project Managers may use this style when team members lack the requisite qualifications or experience, are reluctant to assume delegated responsibility, or cannot clearly identify with the project goals and objectives. The Participative Style, as you may have guessed, is a looser leadership style. It is also referred to as “Gelling” or “Norming.” This style tends to bring people together to work as a team, enjoys open and effective communication, and allows the leader to describe work within broad parameters. This also becomes a good approach for team members who are anxious to contribute and participate in decision-making, have the adequate intelligence and experience, and can personally identify with the project goals and objectives. Every project manager should note the terms leading and managing must not be confused. Managing is primarily concerned with “consistently producing key results expected by stakeholders. ” However, leadership provides a more unique challenge for project managers, especially during such a consolidated project implementation. Leading involves establishing direction while aligning, motivating and inspiring people. Leadership is much more important in a rapid implementation as there is less room for all project members not to be on the same page. As the PM, the team is looking towards you for direction, guidance and project expertise. Leadership style may need to be altered to encourage team members to perform at their best to meet such an aggressive timeline. Of course, understanding your team members’ personalities, abilities, and expertise will probably dictate your leadership style much more than a condensed project schedule. It is hard to pick either one or the other when considering rapid implementation. I have used both styles above and even a combination of both styles in the past. Sometimes I was actively engaged in the details of the project, whereas during other times could allow for more flexibility for a strong project team to just “get the job done.” Regardless of which approach you choose, you will be required to be much more engaged into every detail of the project during a RI. Ultimately, you will need to choose a leadership style that you feel will bring the greatest chance of success to the project. Before you begin your rapid implementation, there are many considerations. To choose the most effective approach for your project, you must consider: • The skill levels and experience of your team • The work involved (routine or new and creative) • The organizational environment (stable or radically changing, conservative or adventurous) • You own preferred or natural style. A good leader will find him or herself switching instinctively between styles according to the people and work they are dealing with. Influence Your ability to influence team members will certainly play a larger role in a rapid implementation versus a conventional implementation. As compared with other enterprise platforms, I believe a project manager of a rapid eLearning project requires you to have better influencing skills. Lou Russell, President of Russell Martin & Associates and Author of Project Management for Trainers, provides a few influencing tips for eLearning project managers below : • Agility: be willing and able to change at a moment’s notice • Resiliency: don’t get mad or even when things don’t go the way you planned • Collaboration: build alliances, informal and formal. I suggest lots of food gifts to the technical people for jobs well done • Communication: create a Communications Plan to share status with all the stakeholders on a regular basis— “Bad News Early is Good News” • Flexible Structure: at all times have a plan and be ready to adapt it to another plan. While having the ability to influence is a necessary skill for any Project Manager, regardless of your industry or project, you will certainly put your influencing talents to the test during an RI. Mr. Russell suggests “lots of food gifts” for his team members as part of his influencing techniques. I can surely attest that picking up a few employee meals or “Go-Live Happy Hour” can go along way for team members that help dictate project success. CONCLUSION By now, you probably understand that managing a KMS rapid implementation can be challenging, intense, and stressful. However, it can also be very rewarding if the appropriate project management principles are altered to ensure success. Remember that both internal and external factors related to project management culture may need adjusting for RI. Simply cutting the project schedule in half and fast tracking all of the implementation activities will not work. Areas such as scope, communications, risks and project schedule are all examples of elements of focus. Lastly, it is important to realize that the above concepts do not apply only to rapid implementation of enterprise-wide knowledge management systems. All of the fundamentals that are outlined in this article can (and should) apply to any enterprise-wide COTS application that has been deemed a good candidate for a rapid implementation. Whether you are looking to rapidly implement a Learning Management System, Enterprise Resource Planning System or Business Intelligence Solution, the dynamics are the same - the 80/20 rule applies most of the time, time-boxing is extremely likely, and scope is reduced – comparing all of these to a conventional full-blown implementation. I wish you all the best in your rapid implementation success.

There are a variety of reasons why a project management training class might be a good option for you. If you hold a general business degree but aren't able to find employment that pays really well or provides you with job satisfaction, try project management. If you've suddenly found yourself unemployed through company downsizing, consider project management. And even if you're an engineer, a software programmer or the boss of your own construction outfit, think about project management. There's something in it for everyone.

The modern office has a very precise chain of command. It includes every individual in a company. Everyone needs to know their own role, from the bottom to the very top of the company. Managing well means that everything flows smoothly. This is achieved by keeping everyone up to date on all aspects of projects at every level. It allows people to function most efficiently.

Technically speaking, the size of an organization does not have any effect on the success of Six Sigma deployments. However, since the general perception is that Six Sigma benefits only large business entities, many smaller businesses often do not take too well to Six Sigma deployment ideas. So, how can smaller businesses get over these negative perceptions?

There are many variables that determine the success of Six Sigma implementation projects, but the one factor that probably plays the most important role is often the expertise and professionalism of implementation team members. So, how exactly can businesses ensure that their implementation team members are up to the mark and ready for the bumpy ride ahead?

Since the time it was first deployed in the seventies by the Motorola Corporation, Six Sigma has undergone significant changes over the years. Originally meant for use in the manufacturing industry, Six Sigma is now being deployed in almost all types of businesses, including many belonging to the services industry.