Lifecycle SCO Content

In a Sharable Content Object Reference Model (SCORM) world of learning content development and use, the developing and using parts are relatively easy. The lifecycle management of that shareable content

In a Sharable Content Object Reference Model (SCORM) world of learning content development and use, the developing and using parts are relatively easy. The lifecycle management of that shareable content is the difficult task—but of the utmost importance if an organization is to achieve the benefits it desires by adopting SCORM.

If SCORM-conformant content is to truly be reused, repurposed and referenced, organizations must have the ability to track and manage every piece of learning content they own and all the possible locations and instantiations in which that learning content might be used. Since lifecycle management of e-learning content is so important to ensure learning, organizations can help ensure learning by:

1) specifying and standardizing learning objectives;
2) associating unique identifiers with learning objectives; and
3) establishing clear rules and associations for how learning objectives are associated with learning activities.

If your organization’s experience with implementing SCORM content is similar to the author’s, it is hoped that some of the tools, lessons learned and processes in this article will benefit your organization in managing your SCORM content across its lifecycle.

To provide context for the three tenets listed above, a brief background of the U.S. Navy’s journey in creating SCORM-conformant learning content will help paint the picture.

Management RM -Conformant Learning in the U.S. Navy

In October of 2000, the Navy embarked on a cultural and strategic shift in how it approached training. The Executive Review of Navy Training (ERNT) working group was established to examine Navy training and make substantive recommendations for improving and aligning organizations, incorporating new technologies into Navy training, exploiting opportunities available from the private sector, and developing a continuum of lifelong learning and personal and professional development for sailors. That working group’s recommendations spawned what came to be known as the “Revolution in Training” (RIT) ( GetTRDoc?AD=ADA419988&Location=U2&doc=GetTRDoc.pdf).

A major recommendation for and point of emphasis in the RIT was to incorporate SCORM-conformant e-learning andW ebbased distance learning as a Navy training
delivery modality. At that time, there were some e-learning Navy pockets, but e-learning was not institutionalized Navy-wide nor did the Navy have a formal enterprise wide plan for the e-learning modality.

In the years since the ERNT occurred, an increasing number of Navy communities and commands have implemented e-learning as a result of the RIT and as financial, business case analysis, and other reasons have warranted. In fact, to support the
ERNT recommendations, the Navy built an Information Technology (IT) infrastructure with associated standards and business rules to support the standardized development and management of SCORM-conformant content. An enterprise-wide learning content management system (LCMS) and learning management system (LMS) were purchased, as well as servers, other needed IT elements, and a team of IT and SCORM-savvy professionals to manage the major tidal wave of content the Navy was to receive.

With that context in mind, the three core tenets to consider in managing SCORM content across its lifecycle are:


As the Navy was embarking down the SCORM path,Navy E-learning (NEL) leadership recognized the need to specify and standardize learning objectives for all Navy content. The need for that specification and standardization was both pedagogical and practical to help eliminate content object redundancy that could result from different communities creating similar content using very similar, but distinct learning objectives as the foundational requirements for their development. Stated simply, if the Navy was going to manage this undeterminable amount of SCORM content objects living in the LMS,more than good metadata would be
required to know what content the Navy owned and how it was being used. Clear and consistent learning objectives would also be needed to allow strategic identification and tracking of learning content.

To achieve the needed learning objective clarity and consistency, a standard was developed that required Navy content developers to create learning objectives in a standard format using standardized vocabulary (
contentItems/Navy%20ILE%20LOS_200709 15.pdf).Additionally, a government-off-the shelf tool (GOTS) called the content planningmodule (CPM; see http://aim.- .ashx) was built that would serve as an electronic performance support system (EPSS) for writing learning objectives (using dropdown boxes to support compliance with the Navy standard). It would also serve as a repository for those objectives, with the ability to house potentially all learning objectives for all learning content in the Navy.

Having all the standardized learning objectives in the Navy housed in one searchable location was certainly necessary for all Navy users and leadership. Without it, the Navy wouldn’t be able to track the content it had via learning objectives, and reuse/repurpose/reference would be severely inhibited because content developers would likely not know about learning content objects created and owned by other Navy communities unless they stumbled onto those objects through some other means.

For the Navy, getting learning objectives standardized and housed in one place was key first step in this overall lifecycle management process.


That key first step, however, still required further technical work to guard against other potentially unwanted SCORM lifecycle management woes. Specifically, a method of applying unique identifiers to learning objectives was required to guard against “object collision.” Before explaining “object collision” in more depth, a “learning objective” versus “learning object” distinction is needed.

Although unique and standardized learning objectives can be created and housed in
CPM, the content objects to which they are associated have no similar guarantee of uniqueness. CPM can digitally link learning objectives to their associated learning objects (when that linkage is created by CPMusers) and will maintain those identifying links as long as needed. However, those learning objects are only as inherently unique as identified by their creators through naming conventions and metadata. CPM controls and manages the learning objectives, but not the learning objects that satisfy the objectives.

Now, this “object collision” can be defined as the result of two structurally different content objects (teaching different content) sharing the same identifier in two different content packages. Therefore, an object associated with a SCO in one content package will inadvertently satisfy the same objective in another content package. An example: There could be 10 content objects delivered to the Navy by 10 different content vendors, and all could have the same object name embedded inside their XML metadata- “SCO #1.” If the Navy’s LMS was later required to gather and assemble a group of content objects (via a manifest) into a content package for presentation to a learner, and one of the required content objects in the package were “SCO #1,” the LMS would have 10 viable options from which to
choose. Who knows which one the learner would get, and if it would be the one he or she required? The Navy has experienced that it is not uncommon for content developers to use a generic naming convention (like “SCO #1) when creating identifiers, because they often use objective identifiers as variables in their strategy for sequencing their Sharable Content Objects (SCOs). This “object collision” problem is not the fault of Navy content developers, nor the fault of the Navy’s NEL team. It’s just a natural byproduct of attempting to manage SCORM content objects in a large organization like the Navy. Although a number of potential solutions were identified, a fairly simple one was implemented that again involved the CPM toolset.

Conceptually, since CPM links a learning objective to its associated learning object, it made sense to have CPM apply some kind of unique identifier to the learning objective that would, by extension,make its learning object completely unique and distinct as well. The solution was added to CPM to apply a unique and persistent, time-stamped,machine-generated identifier to learning objectives in CPM and embedded in LOM metadata for each learning object. This was important so that one “SCO #1” could be identified as uniquely different fromthe other nine “SCO #1” objects in the LMS (per the example in the previous paragraph). It was also important to ensure version control of objectives and associated objects, allowing them to be tracked and mapped to previous versions of each throughout the lifecycle of the learning content. Currently, as each version of a learning objective is developed, it is assigned a unique identifier. In the SCORM package, the versioned learning objective is referenced by its unique identifier,while metadata tagging provides the information that the versioned learning objective is a version of the learning objective’s persistent identifier.

Once identified and implemented, this capability allowed for simpler and more accurate learning content objective and object lifecycle management practices. Each object could now be uniquely identified (like with a Vehicle’s Identification Number, or VIN), whereas before a level of “guesswork” and risk were inherent. (“Get me the red car.Which red car???”)


This is the Navy’s least understood and least mature SCORM lifecycle management tenets, although significant progress is being made. Some prototype projects are nearly complete that identify key business rules and associations, as well as a technical capability for making associations and links from front-end job-task requirement and technical data completely through the development process to the content objects that support those requirements. This capability will allow the Navy to have a real-time, semi-automated capability to update SCORM conformant
e-learning content when front end requirements upon which the content is based change. That real-time, semi-automated capability does not currently exist today.
The readiness and cost savings realized by the ability to manage SCORM content down to this level of detail and real-time precision is exciting and represents a culmination of sorts to the Navy’s SCORM implementation and content lifecycle management.


Standardized learning objective formats, unique identifiers with version information, time stamps, and other appropriate explanatory lifecycle metadata become increasingly more important as learning systems become more integrated with other enterprise systems and with each other in presenting, tracking and  managing learning content. If your organization is considering or has already embarked upon a similar content lifecycle management journey, then some of these tools, lessons learned, processes and core tenets might be of value to you.

Jake Aplanalp is AIM/CPMproject manager for the Naval AirWarfare Center Training Systems Division (NAWCTSD) in Orlando, Fla. The author welcomes any feedback, insights, or questions. Contact him via e-mail at

Leave a reply