This does not mean that a scope creep should be considered a major threat. Rather, it should be taken as a fluid risk that can crystallize as a project progresses. Therefore, L&D managers should negotiate scope creed as a risk throughout a project’s development life cycle.
If a change is important enough to require urgent implementation, the addition or change should be a flexible process. Be sure to negotiate the trade-offs, comparing positive aspects against project constraints like effort, schedule, risks, quality, and so on.
Due to ever-evolving requirements and subjectivity in L&D projects, it is important to understand how we should manage a scope creep. Fortunately, there are time-tested processes you can follow. Here are five tactics for managing additions and changes to your next L&D deliverable.
-
Clarity is worth much more and costs little. Clearly outline the requirements, including the pricing estimates and timelines, in the Scope of Work (SOW) document during the analysis and requirement-gathering stage. It helps identify any changes in scope, distinguishes between needs and wants, and guides the design and development team in the right direction. Before the stakeholders sign-off on the SOW, it’s critical to help the stakeholders understand what might go wrong, what out-of-scope tasks may cost for each phase of the project development life cycle, and what the change order process is.
-
Break the bigger project into small deliverables. Per a recent Gartner survey, large projects fail more often than small projects. For easy management, execution, and timely identification of scope creep, break the project into milestones and deliverables. Make a detailed project plan, including time for analysis, documentation, and changes that may get discovered during the development process.
Advertisement -
Do not hurry, do not flurry. If a project stakeholder requests a change, be it small or big, do not accept it on the spot. Assess the requirement with the team to evaluate its impact on the larger effort and schedule. Then you can make a well-informed decision.
-
Help everyone see the big picture. Often, when stakeholders suggest a change, they don’t think through the impact the change will have on the final product—not to mention the ultimate business goals they want to accomplish. Help them understand the risk, if any, and involve all the stakeholders to ensure that the final decision works in everyone’s interest.
-
Generosity is not always the best investment. Do not keep adding value to the deliverables beyond the requirements captured in the SOW to increase stakeholders’ satisfaction. Such gold plating usually exceeds the planned effort and inflates the project scope. For some over-satisfied stakeholders, it raises their expectations. Meanwhile, others may not relish that extra icing on the cake.
- Go far, go together. It’s critical to pre-define all the stakeholders who will review a deliverable and provide a sign-off at the project initiation stage. This avoids multiple review rounds for each deliverable. Most importantly, do not forget to include a team of actual learners in the requirement analysis phase, as well as when you execute UAT cases. Involving them at a later stage and then receiving defect reports may lead to changes in a project’s scope.
Managing Scope Creep the Agile Way
While traditional project management methods still effective, they come with a drawback. On discovery of an urgent and important change, a project might lose momentum and lead to serious impact on the planned schedule and effort. Given the dynamic nature of learning, defining the scope for L&D projects is challenging in the initial stages due to their ever-evolving nature. For such projects, an Agile development approach is better than the traditional waterfall approach because it allows managers to handle scope-creep situations differently.
With Agile, work items are well defined and broken into Epics, User Stories, and Tasks. Working on the smallest identified logical chunk (Task) allows to control ambiguity. New work items may be added and prioritized at the start of each sprint or iteration, when a project backlog is being reviewed. As all stakeholders are involved throughout an iteration, it reduces the chances of rework. Moreover, it makes the L&D team better equipped to address any changing requirements at a very early stage of a project.
However, often after defining the scope at the start of a task iteration, project stakeholders ask for minor modifications in a deliverable that create additional work for the team. The L&D team might end up gold-plating or even reworking the deliverable. Typically, such back-door changes do not get absorbed in the 10 to 15 percent contingency plan for changes that are discovered in the development phase.
This scope creep can be highlighted in a Burn Down Chart (indicating the consumption of total effort against a deliverable) and Velocity Metric (indicating a decrease in the rate at which an L&D team completes a deliverable). It’s critical to discuss such changes at the end of the project iteration to avoid a similar situation in subsequent reiterations. Detailed discussions may include comparison of the tasks that were planned for the deliverable and the actual tasks or revisions done by the team.
Whether you follow the traditional or the Agile approach, managing scope creep is a continuous process. Changes that can crystallize into scope creep can happen at any stage of a project development life cycle. Therefore, the new scope must be documented and approved by authorizing parties from the L&D team and project stakeholders. This helps you trace the requirement from an initial to the changed state. What’s more, change management practice should be followed throughout a project to minimize the risk of running into a situation where you have no control over the project.
Bottom line: the onus is on you. Will you let scope creep control your project?
