Scope creep

There is a trap any project can find itself in, which is called scope creep. Scope creep means constant changes to the number of features to be implemented toward increasing.

Scope creep can happen due to additional feature requests from the client when the initiation phase is over during the active delivery stage or UAT. There is nothing wrong with the changes themselves or the desire to add more value and functionality to the solution. Additionally, many projects follow the Agile methodology that implies constant change. The problem arises when changes happen without proper management and control. In such cases, the project scope increases dramatically without corresponding adjustments in timeline, budget, and team allocation. Such a case is called scope creep.

To study this phenomenon properly, first, we identify its reasons and give a definition of scope.

Project scope or project requirements are documented project deliverables. It comprises the project plan, the specification of features, deliverables, and boundaries or constraints that the future solution will have. The solution scope is described in terms of the major features and functions to be included, interactions that the solution will have with people and systems, and in-scope and out-of-scope solution components.

Techniques to identify the scope are as follows:

• Functional Decomposition. Understand the scope of work and break the solution into smaller deliverables.
• Interface Analysis. Depict the scope of work required to integrate the new solution into business and technical environments.
• Scope Modeling. Identify appropriate boundaries for the solution.
• User Stories. Describe processes and the goals the system supports.

When the initial scope or amount of features selected for development starts increasing, the scope begins creeping. When the problem is not handled properly, it can affect productivity and overall project success with main deliverables and MVP not being achieved and budget being exhausted. Often, the changes that lead to scope creep are not properly reviewed. Therefore, the project team is expected to complete more tasks, deliverables, and milestones with the same resources and at the same time as the original scope.

Reasons for scope creep

The reasons for score creep are as follows:

• Statement of Work (SoW) is vague and undefined. Deliverables and success criteria are not defined before the delivery starts.
• Requirements are gathered while conversations and oral agreements occur between the client and team members without any documental fixing.
• Change requests are captured by the team and taken into delivery immediately upon receiving to do the client a favor.
• The change management process is not established. The client and team members do not follow the procedure and document change requests.
• There is poor communication between team members, project managers, and stakeholders. There is no mechanism for decision making and prioritizing.
• Insufficient investigation and project study result in many changes required on top of the finalized solution to make it running and effective.

The primary reason why scope creep happens is the insufficiently defined or undefined and vague scope. When you start the delivery, and you do not know exactly what needs to be delivered, it will be a big challenge to do it effectively, on the one hand, and keep track of any changes, on the other. When you need to identify changes, compare the items you want to check for differences. If you have no well-defined scope at the beginning, there is nothing to compare to identify changes. So, you can find yourself in a situation where you need to build a rocket for the client instead of a carriage as it initially seemed, and you have no evidence that the agreement was only about the carriage because you agreed to build a means of transport.

The solution to the problem is to dive deeply into the client's processes, establish their actual needs, capture and document all the requirements carefully, and align them with the client. While investigating, it is necessary to give top priority to client needs, how to address them, and bring value with your solution. Even if your properly documented solution does not correspond to the client's needs and does not bring value, there is no sense in it. In the best case, your solution will have a series of amendments to make it useful. In the worst scenario, the client will lose trust in your solution and cancel any future collaboration.

If you have a properly defined scope, you can encounter a situation where stakeholders do not understand the process of change management and deliver the change requests in the middle of the delivery phase. Sometimes, it happens once people become more educated on the process and start seeing more room for improvement. Subject Mater Experts who know all about business requirements are the biggest source of knowledge here. The Data Analyst needs to capture and document all the change requests and to communicate correctly to SMEs that their feedback is valuable and heard. It is also necessary to set the right expectations that changes will be implemented not immediately but prioritized and selected for delivery in the project's next phases.

Manage scope creep

To prevent scope creep and manage the changes in scope effectively, the Data Analyst needs:

• Identify client needs and find the best ways to address them with the team.
• Document properly all the requirements and receive a written sign-off from the client.
• Keep track of clients' change requests, document them properly, and trace requirements and features that might be affected in the current solution with these changes.
• Distinguish between bugs that must be fixed and change requests, and communicate each case to the client properly.

The most important thing to avoid scope creep is to document your project requirements. A clear definition of the project requirements allows you to define the scope of your project. Talk to stakeholders, write the requirements, manage conflicts, and prioritize.

Keep track not only of the requirements but of the assumptions as well. Suppose the solution is build on the base of some assumptions, for example, that documents will be received in particular formats only or the response form the third-party system will contain particular data for document processing. In that case, it is critical to include these assumptions and receive the client's confirmation on that. While delivery, it might turn out that some assumptions do not correspond to reality (for example, files don't contain document type in the filenam, and you need to build a classification model instead of simply parsing the filename) but when you have evidence from the client how it is supposed to be, you can communicate it easily and handle as a change request instead of a gap in designing from WorkFusion.

Set up the change control process on the project. When stakeholders suggest a change via a change request, it is reviewed, approved, or rejected. When approved, it is incorporated into the project plan. Setting up the change management process for your project means thinking about who is going to review and approve changes from both sides. The procedure is also important to align on the change and its circumstances by both the team and the client. Both sides should clearly admit the change request. It is especially critical during the UAT phase when there is a need to distinguish bugs and CRs. Bugs should be fixed, but any functionality not planned in the scope should not be considered as bugs.

To summarize, projects should always allow some flexibility and room for improvement regarding requirements' details, approaches, and tools. For your flexibility not to become a nightmare, document everything properly, even if it is not billable or a small change request.