Forum Discussion
A lightweight workflow for handling scope changes after storyboard approval
Hi everyone,
One problem I keep seeing in training projects is that a storyboard is reviewed and approved, but new requests continue to arrive afterward.
The issue is usually not the feedback itself. The problem is that a late request can quietly become part of the approved scope without anyone making an explicit decision about:
- whether it is inside or outside the original scope;
- what impact it has on course duration and development effort;
- who is responsible for the decision;
- whether it belongs in the current version or a later release.
I have been testing a lightweight workflow with three parts.
1. Lock the approved baseline
Record the original learning objective, approved scope, version, and decision owner.
After approval, the baseline should not be silently overwritten.
2. Turn every late request into a decision
For each request, record:
- requester;
- requested change;
- in scope or out of scope;
- impact on duration, effort, and review cycles;
- decision owner;
- target version;
- accept, defer, or reject.
3. Separate four different events
These should not be treated as the same thing:
- Review completed
- Changes requested
- Version approved
- Final release recorded
A reviewer finishing their comments does not necessarily mean that the version has been approved, and version approval does not necessarily mean that the course has been released.
I also converted this workflow into a small browser-based pilot:
https://training-learning-rails.vercel.app/
It requires no account, does not upload files, and stores the pilot data only in the user’s own browser.
The tool is secondary to the workflow. What I am most interested in understanding is:
At what point does this process differ from how SME and stakeholder approval actually works in your organization?
I would especially appreciate examples where:
- multiple SMEs give conflicting instructions;
- an approved storyboard continues to grow;
- nobody is sure which version was finally approved;
- review completion and final sign-off are confused.
Moses
2 Replies
This is super interesting MosesZhu! Did you vibe code this app?
I'm not answering your questions directly, but chiming in to say that I have found it really interesting the way AI has been able to make workflows like this more seamless.
Another option I've seen some folks doing, which might be an interesting approach to this same problem, is creating a Claude skill their colleagues can use to submit requests. That way you can build in a lot of this logic & decision-making into the skill so it can know what the "locked scope" is and help them understand how a late request will be treated.
Thanks for sharing, and hoping to see some folks chiming in about how they handle this kind of workflow, too.Moses-- I looked over at your small browser-based pilot and in the section: Architecture and contract details -- there were some additional details, that I was not familiar with- as someone not formally trained in Articulate-- I would appreciate more information on these sub topics-- if you availability to explain
