Cloud software, by its nature, is released through continuous deployment, a regular release cycle that keeps customers happy but sets a difficult pace for the production of enabling materials. Learning departments must develop a rapid decision-making process to keep up with software changes, accommodate to market trends, and adapt to organizational changes.

With a agile content development (ACD) framework, companies can prioritize the content backlog to make transparent quality decisions on education content production in a large enterprise.

The challenge

Running an education team in a large enterprise in the IT industry means your educational materials – videos, tutorials, classroom, or virtual training – must form a cohesive portfolio. You must release them in sync with the software, tailored to the right audience and their needs. Your product is running on a continuous release cycle, and you have resource constraints and limited information about your audience. Being part of a big enterprise also means engaging with many stakeholders: product teams, customer- and partner-success organizations, services, etc., who will come to you with their audience’s needs, ideas, and opinions, all to influence your decisions on what assets your department should produce next. You must also adapt effectively to trends in e-learning and your industry as well as changes in your organization.

So, with so many moving parts, how do you decide which educational asset to produce now? By introducing the content backlog and the prioritization process around it.

To understand it, you need to know a bit about the ACD first.

Agile content development

If your software teams follow an agile development methodology, so should the adjacent departments, like learning. That’s what we did when we created the ACD framework. We borrowed concepts from the agile project management framework (see DSDM) and the scrum agile methodology and adapted them to fit the development of educational material in a large enterprise. Sandra Policht’s post explains more about the ACD.

In agile software development, the product backlog is essentially a prioritized list of product features. This list is dynamic, and each entry (feature) has an estimated effort and measurable value to the customer.

In ACD, the content backlog is a prioritized list of all requests for content. It’s a living document, transparent to all internal stakeholders. Each content request is scoped to determine the estimated effort, and like its software development counterpart, it has measurable value to the customer.

Maintaining the requests on the content backlog is the responsibility of a product owner (PO). In the ACD world, this is a person with an understanding of customers’ needs and what’s essential for them. The PO owns the corresponding education portfolio and has a high-level understanding of product capabilities. Their key responsibility is to continuously and proactively seek feedback from various sources and turn them into requests on the content backlog. The sources usually are customers, product management, trainers, customer/partner success organizations and consultants, feedback from the company’s learning platforms, surveys, etc.

In a software enterprise with a vast software portfolio, a team of POs (with each PO having a distinct area of responsibility) is accompanied by a portfolio manager (PM) who owns the execution of the content backlog prioritization process; and by a project coordinator (PC) who owns production estimates and governs the team of scrum masters (SM) to ensure the expected workload doesn’t the exceed team’s capacity.

To understand the scope of all involved roles and their responsibilities in ACD, refer to Angelina Padarnitsas’ post. Keep in mind these roles diverge from their DSDM and scrum prototypes, and we invented a few new roles.

Prioritizing the content backlog

The content backlog prioritization process is a methodical approach to cope with the competing requests and many different factors/criteria to consider. The process consists of the following four steps, which each PO executes to arrive at the optimal decision for the next production cycle.

Step 1: Measuring against key criteria

For each request on the backlog, the PO goes through the following list of criteria (this is not an exhaustive list but a solid start) and gives it a score (e.g., 0-10). The higher the total score on a request, the more important it is to address it in the next production cycle.

• Business and product strategy: These are the most important criteria to consider. The PO and the education material must follow it. What are the company’s focus areas? Is there a key customer segment, region, or audience? What’s coming in the next product release? What is the company’s flagship product? Is there a part of the product that should be emphasized? For example, the education department may have to support building a software-developer community and therefore would focus production on content for a technical audience and their preferred asset types. POs should prioritize accordingly and give high scores to the content requests that are in line with company strategies, and give low (i.e., 0) scores to all other requests.

• Audience size: While addressing all relevant audience types is important, POs must prioritize proportionally to audience size and importance. For example, POs in a company selling a software framework may prioritize coding tutorials for partners’ developers over end-user guides for business users. Requests addressing the major audience get a high score and those for niche audiences get low scores.

• Portfolio gap: Is each learning path fully covered with content? If an asset is missing in a learning path, especially at the beginning, and for the key audience, POs must prioritize accordingly (i.e., give a high score).

• Release stretch: If an asset (e.g., a video) is relevant for the audience but becomes outdated and far behind the current software version, the PO should give a high score to the corresponding request, low in other cases.

• Feedback: Consider external and internal feedback about content quality and topic accuracy: if it is negative and the topic is in demand, the PO should give the request a very high score.

• Timing: Are there upcoming events, hack-a-thons, marketing campaigns, or other promotional opportunities? The PO will give higher scores to those highly exposed topics and assets.

• Product road map: By staying close to product teams, the PO can identify which elements from the product roadmap may change (be postponed or dropped) and prioritize content requests accordingly: stable topics get a higher score; volatile topics a lower score.

• Product adoption and revenue: Is a product or module in high demand by customers? Content for a frequently used or sold product takes priority over others (i.e., gets a higher score).

• Content adoption and revenue: A very popular free asset (tutorial, video) or a frequently scheduled or high-revenue paid asset (training, e-learning) takes priority (higher score) over less-consumed assets.

Step 2: Defining the scope

At this stage, each PO has a prioritized list with high-score requests on top. What remains is to estimate the production effort and analyze the scope of the top requests.

• Adding estimates: Maintaining the data for past projects is the best effort predictor of future projects – see the roles of the project coordinator and scrum master. The PO consults with the content architect (CA) who has detailed technical product knowledge to ensure the estimates’ accuracy.

• Analyzing the scope: While detailed scope definition of each request is part of the content production (which happens after Step 4), at this stage the PO determines the “must-have” and the “won’t have” from the customers’ point of view (see the MoSCoW method). This approach enables the PO to consider alternative types of assets for the required work. The PO finds smarter alternatives to fulfill (at least partially) more resource-demanding requests, e.g., a video series instead of an extra day of training, or covering a “should have” topic with a trainer demo instead of an exercise for students (a lower system cost). In the end, each request’s scope is reduced to the minimal viable product, but not less. Because POs own the corresponding education portfolio, they keep it clean of duplicates and outdated material. For example, they have the discretion to address a request for new developer training by changing the content of existing assets in the developer learning path. They find smarter alternatives to fulfill the more resource-demanding requests.

Step 3: Deciding

At this stage, POs have all the necessary data at hand to make a quality decision on what to produce next. Thanks to the criteria scoring, they know the importance of the requests and the necessary scope of each (“must” vs. “won’t”). Thanks to the PCs, they know team capacity and how many of the high-score requests their team can address. Thanks to the CAs, they understand the technical complexity, such as introducing demos or exercises (if there are any). POs start to see alternatives and focus on what’s essential. They can, with confidence, decide to reduce an asset’s scope without compromising the quality and still effectively increase learner engagement with the content. In the end, the PO has the content production road map ready.

Step 4: Communicating

The PM and the PO communicate with stakeholders, presenting the portfolio production roadmap for the next production cycle, the decisions behind it, and the team’s capacity to produce the content. Presenting all gathered requests, considered criteria, and explaining the decision-making process prevents disappointment from the more vocal stakeholders. Opportunities for synergy also emerge here, as other teams decide to reuse assets and volunteer to co-produce assets together. After this step, the team starts the next content production cycle; but that’s material for another article.

Summary

ACD has served us well for the past several years, and it’s evolved along with our team to meet our growing set of products, audiences, channels, and organizational complexity. What once was done by a single person now is split into several roles.

Whatever the size of your organization, you will need a repeatable method to make quality decisions on content production. The next time you are under pressure from time and stakeholders, apply this prioritization process or even consider fully implementing the ACD.

Dive deeper into The Digital Workforce Experience: The Shift From HR Tools To Employee Tools.

This article originally appeared on SAP Community.

Let’s block ads! (Why?)

Digitalist Magazine