The TopClass Blog

Congratulations, you got the okay for a new learning management system (LMS). But guess what? You also found out you’re the LMS project manager, despite your lack of project management experience. 

Acquiring project management experience will be great for your resume, but project management is a profession unto itself. People do it for a living, and now you have to pull it off without the benefit of years of training and experience. 

We’re sharing the basics of project management in this post and the next, so you can keep your technology project on schedule, within budget, and on the path to success.  

The truth about the project manager role

Here’s the hitch about being a project manager for any technology selection and implementation: at times, it can take up to half of your working hours. Sorry to break that to you, but it’s best to know this going in. 

And it’s best for your boss to know it too. It’s going to be difficult to keep doing your regular job effectively while taking on this huge responsibility. But there is a silver lining: you’ll learn highly marketable skills and gain valuable experience. Many professionals, like you, don’t have “project manager” in their title but will end up managing projects at some point. 

Project management is truly an area where what you don’t know can hurt you, that is, hurt the project. These two posts only touch on some of the basics of project management. With further exploration, you’ll see there’s a lot more to learn. 

What you need to know about being an LMS project manager

Project charter

One of the first things you should do as project manager (PM) is develop a project charter—the documented authorization for the project and the PM’s authority. A charter gets everyone on the same page so you can avoid problems later. More importantly, developing a project charter forces you and your core team to work through the project planning process so you’re more prepared for the work ahead.

Here are some of the major elements of a project charter.

•    Project objective: What you’re doing and why—the business case for the new technology, and how it’s connected to your organization’s strategic objectives.

•    Project requirements/deliverables: Major stakeholder requirements and key project deliverables.

•    Project sponsor: The official project champion.

•    Project stakeholders: People impacted by the technology, for example, system users or users of data from the system.

•    Project scope: What the project will deliver—this is the most important thing for stakeholders to understand since it manages their expectations.

•    Project schedule

•    Project budget: Think beyond the technology itself to any consultants or temporary staff you’re hiring to help you with business analysis, requirements, selection, and/or implementation, and any services your vendor doesn’t provide. Don’t assume. Ask. 

•    Team member roles and responsibilities

•    Risks: Threats to the project, for example, change in requirements, key staff leaving the association, or unplanned work.

•    Constraints: Anything that can restrict or dictate the work of the project team, for example, budget, timeline, scope, business interruptions, or change in the market.

•    Assumptions: Examine assumptions so you can verify whether they’re true or not, for example, staff availability, staff performance (skills and knowledge), accuracy of project milestone dates, or vendor delivery times.

•    Success criteria: What a successful outcome looks like—use quantifiable metrics.

•    Signatures of sponsor and stakeholders: Their sign-off holds them accountable to their roles and responsibilities, and prevents them (hopefully) from coming back later to say they thought X was within the scope of the project.

Project sponsor

Every project needs a sponsor or champion. The sponsor is usually someone in the C-suite or senior management who has the authority to deliver the budget and staff resources needed for the project. They are the liaison with the rest of leadership, keeping them updated on the project’s status.

At the project kick-off meeting, the sponsor puts the project in context for the stakeholders and project team, explaining how it aligns with organizational strategy and why it’s mission-imperative.

The sponsor comes to the rescue when you run into obstacles, for example, a department head who’s reluctant to release staff for a meeting, training, or testing. The PM manages the team, but the sponsor is the ultimate enforcer, if needed, of team accountability.

Project stakeholders

Stakeholders are those who have a stake in the project, usually users of the technology or users of data residing in the technology.

As subject matter experts, stakeholders have a critical role in gathering, defining, prioritizing, and documenting requirements. You must take great pains to identify and interview stakeholders about system data, processes, user experience, and requirements. If you don’t, the requirements won’t reflect organizational needs. 

Project team

You may have experience in “herding cats” if you’ve worked with committees, which is a good thing since that’s basically a PM’s job. You must build relationships with people—your project team, vendor team, sponsor, and stakeholders—to get things done.

Identify a small core team consisting of one representative from each primary stakeholder group, plus someone from IT. A small core team is better for decision-making and communication. 

A supplemental team can get involved as needed. For example, if you plan to integrate the new technology with systems “owned” by other departments, you need to bring someone in from that department.

It’s imperative that you get a commitment from both the people on your team and their supervisors about their roles and responsibilities. Make sure they understand the time commitment required at different stages of the project: tasks, regular meetings and calls, testing, and training. Many PMs use a RACI chart to outline roles and responsibilities.

Project decisions

Find out from your technology vendor or experienced project managers about the decisions that will arise during the project. At the outset, talk with the project sponsor about these decisions. Establish ahead of time how tasks will be assigned and changes to scope will be made. 

•    Which decisions should the sponsor make? 
•    Which should you (the PM) make? 
•    When should you seek input from the team before making a decision? 
•    When do you decide alone? 
•    When does the team make a decision? 

Be very clear on who can make different types of decisions—and share that information with the stakeholders and team. Everyone must know what to expect.

Project planning

Remember the 5Ps: Proper Planning Prevents Poor Performance. Talk to people inside and outside your association who have managed similar projects—ask your vendor for referrals. They can help you figure out what to include in your project plan and how long tasks will take. You can find templates for project management plans online.

Project plan

Develop the project plan with your core team so they’re invested in its success. The plan outlines how the project will be executed, managed, and closed. It includes charter elements, such as scope, schedule, and budget baselines, as well as subsidiary plans—communication, training, testing, etc.

Discuss project assumptions, constraints and risks with the team. Work though these issues now so they don’t hinder your project later.

Put together a work breakdown structure made up of specific tasks. You need to easily track progress on tasks, so don’t make them too general or lengthy. You should be able to detect early on if someone’s falling behind on a task.

You also need to work out dependencies, for example, Sally can’t do Task A until Marco does Task B, or the vendor can’t do Y until we provide Z.

Project approach

You may hear vendors talking about “agile” and “waterfall”—or sometimes a mix of the two. 

Agile is a cyclical, change-driven approach to project management. In an agile project, requirements are prioritized and work is broken up into short segments (sprints). After one set of requirements is designed, prototyped, and tested, the next set is taken on. An agile project schedule may only include the first few sprints, since the results of that work will drive the rest of the project.

Waterfall is the traditional, stage-by-stage approach to software project management, for example: requirements, RFP and selection, design, development and integration, testing and acceptance, and launch. Because the project always moves forward, never backward, the project schedule includes all stages of the project.

Project schedule 

Your vendor has been through an implementation hundreds of times, so take advantage of their knowledge. Ask for their help in developing a work plan and timeline. Make sure you’re allocating enough time to tasks so your timeline is reasonable and doable. But it doesn’t hurt to build in a buffer—remember your risks, assumptions, and constraints. 

Allow time for situations that could take staff away from the project, for example, association events and meetings, lobbying calendar, pregnancies and scheduled medical leave, and vacations. 

You may have had experience with a board or senior staff wanting a new system launched in time for an annual meeting. Sometimes that’s possible but it depends on many variables: staff availability, vendor schedule, vendor reliance on third parties, extent of customization, and whether the vendor or third-party has to build an integration—luckily, we have many standard integrations and build everything in house. 

When you reach certain milestones, take time to celebrate your team’s progress so they know how much they’re appreciated.

Risk analysis

What could possibly go wrong? Can you prevent it? How can you minimize any negative impact? Be proactive by identifying possible problems and discussing the steps you can take to prevent or address these risks. Document the tactics you and your team have identified to manage risks.

A risk analysis plan also allows leadership or stakeholders to see all the ways a project could go off the rails between now and their crazy deadline. It gives them a better understanding of the complexity you might be dealing with. The plan may also help you make the case for more resources. 

When you take these project planning steps, you demonstrate to leadership your prowess at thinking ahead, being responsible about the situation, and having the project under control. In our next post, we’ll take you through the project from kickoff to close.