The TopClass Blog

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.

The specialized expertise of an LMS business analyst

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 role during a LMS project

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.

Identifying requirements

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.

Prioritizing requirements

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:

• Must have: critical requirements that must all be delivered.

• Should have: important requirements that don’t have to be delivered in this initial project phase.

• Could have: desirable requirements that aren’t really necessary so are included only if time and resources permit.

• Won't have (this time): the least critical requirements that can either be dropped or reconsidered for inclusion in a later phase of the project.

Recommending process changes

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.

Documenting requirements

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.

Translating requirements

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.

How the LMS requirements document is used throughout the project

The requirements document is used constantly for reference throughout the project lifecycle by association staff, project managers, and developers.

• The project manager uses the requirements document to outline scope for the project, develop a project plan with development timelines, and allocate resources to the project internally.

• The developers constantly refer back to the requirements document as a reference during development.

• The requirements document is used later during testing to ensure the product meets the organization’s needs.

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.