How do you manage scope creep and change requests in the SAM model?

I find it is helpful to have 2-4 specific project goals and purpose statement. These items provide anchor points as the project or program progresses. Continually asking, 'How does X relate to the purpose or goal?' is an excellent strategy to remain focused.

SAM is they type of ID model that can very easily cause scope creep, as it's a cyclical type of model, where steps can be repeated. During such cycles, there can be a tendency to add unrelated material or to divert from the original scope of the project. Clear and well define goals and objectives are the framework to use in order to reconcile any task and milestone of the project. In learning this is extremely important due to the tendency to add details and features that can become references, but that do not contribute to the well-established objectives.

In SAM model, manage scope creep by defining clear project scope, communicating regularly with stakeholders, evaluating change requests using MoSCoW method, and implementing approved changes in line with SAM best practices. This ensures efficient project progress and successful learning solution delivery.

I agree. In SAM, managing scope creep and change requests demands sharp boundaries and tough prioritization. Set clear objectives upfront—if changes don’t align, they’re out. SAM’s iterative process means feedback happens early and often, so don’t let changes sneak up on you. Establish a strict change request protocol: every request gets evaluated for impact on time, cost, and value. Communicate the trade-offs bluntly—no sugar-coating. Prioritize ruthlessly using tools like MoSCoW. Stick to what matters, and keep the project on track. Flexibility doesn’t mean chaos—control the scope, or it controls you.

The Savvy Start is not for making all final decisions about the project before beginning development. It's where you take most of the discovery meetings you would normally have with SMEs, stakeholders, and learners anyway, and you combine those audiences and have the meetings in a short block of time, rather than spreading them out over several weeks. Though you don't have to come up with all the answers, it's a good start. Discovery and design can continue afterwards. Give an afternoon or a day between meetings, so the group can return to their normal work and you can prototype ideas. Get the group to evaluate your prototypes early and often. At the end of the Savvy, you should have a clear idea of scope, and a good potential solution.

I've rarely seen a SME review a first draft of a course design and reply: "It's perfect, don't change a thing!" Designing as a tandem of ISD/SME is a game of give-and-take, of mind-melding, and of two heads producing a final product better than what could have been achieved alone. This said, there will be feedback and subsequent iterations of most projects. They should be planned for - both in time allocation toward the backend of the project, as well as in setting boundaries for the number of review cycles a course can produce. Never let "perfect" be the enemy of "good" - courses may never achieve perfection, but a solid team effort should produce high-quality results nonetheless!

Feedback iterations are a key step in successful projects. Identifying natural breaks within the project to pause, reflect, and provide feedback creates a collaborative work environment and forces team members to remain focused on the project purpose and goals.

Stakeholder analysis can help define the part and/or phase of the learning project where stakeholders intervene. SME's can be confined to their area of expertise in order to maintain the flow of the project within scope.

Gantt charts and project management software, such as SmartSheet, are ideal to manage communication and documentation in real time and inline with the task. These tools are also easy to share with internal team members and external stakeholders, which promotes transparency and collaboration.

Communication and documentation are part of everyday life. However, project communication adds an important dimension, where the communication means and stakeholders to be included are clearly defined, sometimes included in the contract. Completion of project milestones should be communicated for review and approval, and such phase completions must be documented. Documentation of all project communication is what can protect the manager of the project if/when conflicts and disputes arise.

The scope of the project should have a clearly stated purpose and number of review cycles. Endless or excessive review cycles constitute one of the most common causes of scope creep. Some consultants negotiate the number of review cycles, and additional cycles are available for a cost, and with the understanding that they will cause delays. A time-cost tradeoff analysis can help the project manager determine if/when to suggest additional reviews if needed.

One identifies scope creep is occurring. One brings it to the attention of work group. One illustrates how the creep is not with accepted and approved scope. Then one allows the additional information because it’s just easier to extend the deadline.

Most importantly, use the collected data for future projects. Future contracts can integrate lessons learned from previous projects that might have derailed due to project scope creep. There's a difference between lessons discussed and lessons learned. Lessons learned are the ones that result in actions that avoid problems from previous projects. Lessons discussed are those that are mentioned but never integrated in future projects. When projects are used as relationship-building exercises, most times there are lessons discussed, but not learned.