Internal factors
Areas of internal focus for process changes are:
- Communication
- Risk
- Influence
- Assumptions
- Leadership
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, you should be aware of some key differences in how communication relates to a rapid implementation project.
For a standard implementation, a weekly project team meeting is the norm. Huddling up once a week during a six-month project to go over issues or concerns, and the planned resolution for those issues and concerns, is probably reasonable. If you are looking to implement in a matter of weeks rather than 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 into 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 e-Learning specialists, project coordinators, and hosting engineers. Extended team members should include content developers, security analysts, and business analysts – 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, they will not necessarily be 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 you can cover all material in a timely manner. Inviting too many people on status calls can result in ineffective and irrelevant discussions, ultimately wasting time.
Risk
The key component to be aware of with regard to risk is the amount of time you have to respond in a rapid implementation. Every project management plan should contain a risk analysis section that identifies the risks associated with the project, along with the risk triggers and mitigation plan for each risk. Add a risk mitigation section to the project plan, addressing potential contingency plans for prioritized risks. This section should also clearly indicate how to manage each risk: 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 rapid implementation 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 organizations 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 mitigation of those risks.
Assumptions
Every project depends on a list of assumptions (or additional clarifications), which may or may not be clearly documented. Even documented assumptions 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 rapid implementation 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 has.
Documenting business and technical assumptions in a rapid implementation is important because, as James P. Lewis points out, “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. Identify assumptions 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
A few distinct styles of leadership may apply to any given project. Realistically, your leadership style falls into one of four types: Directive, Participative, Coaching, and Delegating. I will only focus on Directive and Participative in this article, because Coaching and Delegating are simply variations on these two. Some writers refer to the Directive style 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 (“Gelling” or “Norming”), as you may have guessed, is a looser leadership style. 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 adequate intelligence and experience, and can personally identify with the project goals and objectives.
Every project manager should note that the terms “leading” and “managing” are not the same thing. Managing, as John Kotter says, primarily involves “consistently producing key results expected by stakeholders.” However, leadership provides a 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 because all project members must be “on the same page.” The team is looking to you, the project manager, for direction, guidance, and project expertise.
You may need to alter your leadership style in order to encourage team members to perform at their best to meet the aggressive timeline of a rapid implementation. 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 style or the other when considering rapid implementation. In the past, I have used each style alone, or in combination. Sometimes I actively engaged the details of the project, whereas at other times I could allow more flexibility for a strong project team to just “get the job done.” No matter which approach you choose, you require much more engagement with every detail of the project during a rapid implementation.
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 switch instinctively between styles, according to the people and the work they are doing.
Influence
Your ability to influence team members will certainly play a larger role in a rapid implementation than in a conventional implementation. As compared with other enterprise platforms, I believe that, as the project manager of a rapid e-Learning project, you must have better influencing skills. Lou Russell provides a few influencing tips for e-Learning project managers:
- 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 a rapid implementation. Ms. Russell suggests “lots of food gifts” for her team members as part of her influencing techniques. I can surely attest that picking up a few employee meals or “Go-Live Happy Hour” can go a long way toward helping achieve project success.
Conclusion
By now, you can see that managing a KMS rapid implementation can be challenging, intense, and stressful. However, it can also be very rewarding if you alter the appropriate project management principles in order 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 outlined in this article can (and should) apply to any enterprise-wide COTS application deemed a good candidate for rapid implementation. Whether you want 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.
References
The American Heritage Dictionary of the English Language, 3d Ed. s.v. “culture”
Crawford, J. Kent. Project Management Maturity Model: Providing a Proven Path to Project Management Excellence. New York: Marcel Dekker, Inc. (2002), iii.
Shields, Murrell. E-Business and ERP: Rapid Implementation and Project Planning. New York: John Wiley and Sons (2001), 107.
Lewis, James P. Project Planning, Scheduling, and Control: A Hands-on Guide to Bringing in on Time and on Budget, 4th Ed. New York: McGraw-Hill (2005), 178.
Kotter, John P. A Force for Change: How Leadership Differs from Management. New York: The Free Press (1990).
Russell, Lou. “Project Management and E-Learning: MORE is Worse.” Learning Circuits, August 2006. Retrieved April 21, 2008, from http://www.learningcircuits.org/2006/August/russell.htm (Editor's Note: As of March 30, 2010, this article appears to have been removed from the Web.)
