Many of you have probably experienced the tree swing scenario depicted above. It typically occurs when an organization hasn’t dedicated enough time and talent to understanding and defining requirements for new technology. However, you can avoid ending up with the wrong “swing” by working with a LMS business analyst during your LMS implementation.
A LMS business analyst helps associations translate business and technical needs into system requirements so you end up with an LMS that meets and maybe even exceeds your organization’s and system users’ expectations.
An LMS business analyst has a time-tested process for guiding associations through the requirements analysis stage of a project. Their methods have been honed their experience with dozens of association projects. They bring an insider’s knowledge of associations along with an outsider’s perspective.
This outsider objectivity is critical. Unlike staff, the business analyst is not wedded to “the way we’ve always done it.” Their job is to ask questions that uncover real needs and reveal the information needed to clarify requirements. They also are in a unique position to recommend changes that will improve processes related to the LMS.
Many business analysts come from an IT background, and some even have a software development background. This experience is a big plus when writing technical requirements and functional specification documents for integrations.
The LMS business analyst’s first concern is identifying, prioritizing, and documenting LMS requirements, but the impact of their work is felt throughout the project.
First, the LMS business analyst consults with the client’s project manager to identify the people who should participate in the requirements analysis process. Then the analyst decides on the best approach to discussing requirements with them, for example, requirements workshops. The analyst might also conduct interviews with LMS administrators and users on staff. This process can last a few hours or a few days.
You may need to prioritize requirements if your project has what we call a “strict go-live timeframe.” For example, you have an aggressive implementation timeline because your board gave you a deadline: the LMS must be live by the annual meeting.
Another reason to prioritize requirements is a tight budget: you can’t afford your nice-to-have requirements right now but will roll them out later when the new budget kicks in with the start of the fiscal year.
When you must take a staggered approach to launch or “go-live,” high-priority requirements are rolled out first, and medium- and low-priority requirements are rolled out later. One way to decide on the importance of each requirement is to divide them into “must-haves” and “nice-to-haves”—but the project team and stakeholders must all agree on these decisions.
Another way is the MoSCoW prioritization method. Those uppercase letters stand for:
Because of their work with many different associations and other organizations, LMS business analysts have seen all kinds of different processes related to online learning. They help clients spot ways to simplify and automate administrative processes, and configure features and functionalities instead of customizing them.
The business analyst brings an experienced, objective perspective that can help you imagine and develop new processes and workflows that increase productivity and enhance the user (both staff and learner) experience.
Once the requirements have been identified and prioritized, the LMS business analyst develops a requirements document. Each requirement is categorized and given a unique ID. Requirements must be simple, clear, and concise. They must be so easy to understand that there’s no ambiguity—and no chance of the tree swing situation occurring.
Depending on the level of development required, the requirements document might be several pages or hundreds of pages. The document is reviewed by core project team members and formally signed off before any development work begins.
The LMS business analyst acts as an intermediary between the client and the LMS vendor’s in-house developers. The analyst is responsible for making sure everyone has a clear understanding of each requirement. If the developers need further clarification on a requirement, the business analyst works closely with them as the internal voice for the client.
The requirements document is used constantly for reference throughout the project lifecycle by association staff, project managers, and developers.
The LMS business analyst is just one of the professionals from your LMS vendor’s team who will work for and with you during your implementation project. In the coming weeks, we’ll take a look at some of the other LMS professionals who work with a client or behind the scenes for a client.
