PART 1

Customer/User Job-to-be-Done or Problem

As a Skillabi User, I want to ensure that the integrity of my curricular information in Skillabi is intact and can be reverted back to in the event of a mistake so that we can experiment and use Skillabi without fear of losing information over time as edits are made.

As a Skillabi User, I want to be able to see changes in my curriculum and skills over time in order to get a picture of how my alignment and skills have changed with the use of Skillabi and other curriculum review methods. 

If a critical error were to occur the only backup to customer data would be through rolling back the entire database which is not an ideal solution in that event. Due to the manual process of skill-tagging, many man-hours could potentially be lost if data were to be deleted. This would impact both Lightcast and the customer in this eventuality. If this error were not caught right away, it would also be difficult to roll back the database farther than a few hours to a day.  

Value to Customers & Users

• Customers would have the confidence to dive in and extend access to Skillabi to more users with the knowledge that the initial state of curricular content is saved and able to be reverted to. This opens up more avenues to use and get value from Skillabi without the fear of causing data problems down the road.

• Customers would be able to see when changes were made, how often they have been made and who made the changes in order to effectively manage Skillabi content.

• Unlocks the ability to have a “risk free” space to experiment and make changes in Skillabi while retaining a record of the original dataset. 

• Allows customers to easily see “old” catalog content and potentially compare it against newer versions.

Value to Lightcast

• Reduce the risk of losing customer data by protecting the original version and allowing us to easily revert if an error were to occur.

• Allows us to more easily track changes and efficiently refresh customer content annually.

• Allows us to easily identify where and when issues occurred with customer data delivery to find and correct the cause.

Target User Role/Client/Client Category

This feature is being built for Skillabi admins to have confidence in data integrity and to be able to structure updates to information over time. Also supports all other institutional Skillabi users.

Delivery Mechanism

This feature will be delivered in the Skillabi interface. 

Success Criteria & Metrics

Definition of Done:

• Visibility into the history of changes made (who, when, what changes were made)

• Ability to revert back to previous changes 

• Show progress over time in terms of skill gap (market alignment) change

Dependency: database changes, goal to get full postgres transition done by end of Q1 (end of March). need to wrap this up before starting data versioning. Maybe start data versioning in PI3 

Success metrics (guesstimates for now):

• 20% or more of customers actively utilize this feature to create a safe space to experiment and allow users to make changes to data.

• We see an overall 15% or greater increase in user edits to courses and programs as they can now safely do so.

• Customers report a greater sense of trust in the data available in Skillabi now that it can be tracked and saved over time.

• We see an increase in account engagement with our core features (Market Alignment) due to the reduced barriers of being responsible for data integrity.

Aspects that are out of scope (of this phase)

Saving and making every change visible and revertible akin to Google Docs may be out of scope for this phase depending on engineering input.

PART 2

Solution Description

***WIP

• Solution: Set up curriculum sets to see version history - not that tough. Would have different curriculum sets. Flexible API. Similar to how we do group types. Within the set, could see the history of versions

• Would also need to think about the interface on front-end

• Restoring versions would be more complicated. Would be a fairly complicated change to API to do this so that we can restore data - need to do some research

• We’d want to do this at the course level. Which courses are associated with a group?

• Would also need to think about the interface on front-end

• With each curricular set as a starting point, we can revert back to the beginning of the curricular set before any changes are made.

Early UX (wireframes or mockups)

<FigmaLink>

Non-Functional Attributes & Usage Projections

Consider design to clearly communicate data structures.

Dependencies

Cannot implement back-end changes until the Skillabi database is finished being switched over from MongoDB to PostgreSQL.

Legal and Ethical Considerations

No legal or ethical concerns.

High-Level Rollout Strategies

• Train CDOT team on how to separate and upload learning outcomes for courses when processing customer curriculum. 

• Train Education Success on the new feature and explain how to present this to customers.

• Pendo Announcement in Skillabi

Risks

• Reports may not include the right information, or correct information to provide value. This could create negative impressions of the tool at an institution.

Open Questions

• How can we ensure that exporting the right information is easy and obvious?

• How can we identify the right kinds of information to display in the report and make sure it can be easily parsed by readers?

Complete with Engineering Teams

Estimated Costs

Direct Financial Costs

Are there direct costs that this feature entails? Dataset acquisition, server purchasing, software licenses, etc.?

Team Effort

Each team involved should give a general t-shirt size estimate of their work involved. As the epic proceeds, they can add a link to the Jira epic/issue associated with their portion of this work.