Contribute to the Success of a Project: How to Approach the Scope Definition

In today's fast-paced project environment, teams often rush through defining project scope to start development quickly. This can lead to misaligned expectations, scope creep, and project failure. Properly defining the project scope is a crucial investment in success. Dedicating 5-10% of your project timeline to scope definition can help prevent the common issue of "what the client wanted versus what the client received."

In this article, Olena Myslitska, CBAP, CPM , Solution Business Analyst at ELEKS, discusses five key factors that every project team should consider for effective scope evaluation before starting implementation.

Understanding scope definition

When a project starts, the first thing a team needs to understand is the scope. Some companies call it a WBS–a work breakdown structure. Here, we will use the term "scope" because it relates more to a product's boundaries. More often than not, the scope is defined "at a glance". It might come from the pre-sale side or built based on 1-2 initial calls with a client.

When working on a startup project where the app's contents are not yet clearly defined, the scope is often vague. The team adapts as they go, shaping and adjusting the project on the fly. In such cases, this is the only viable approach.

However, if the client has at least a high-level vision and specific expectations, this method can lead to disappointment. It may result in the classic "What the client wanted vs. what the client received" scenario and could also cause project deadlines to stretch. Why? Because the approximate scope isn't based on those expectations and because the client and the team happen to have a different understanding of the scope from the very beginning. In other words, the clearer the client's vision, the more time and effort should go into defining the scope. Otherwise, the scope creep, tension and arguments become day-to-day routine, which boosts the risk of failing the project.

What is an alternative way of building a project scope? To spend 5-10% of the project time elaborating on the client's expectations, eliciting real problems and needs, and learning at high-level As-is and To-be states. We need to decompose features a bit deeper so that we understand that the scope meets all clients' expectations.

Key aspects of effective scope evaluation

1. The problem/need to resolve and its context

It's crucial to uncover a real problem and its root causes, as well as who is impacted and why it's important to address it. This enables doing the right things from the start. Understanding previous attempts at problem-solving and their results can be a game-changer. This information can give us the right direction and save time.

2. The main roles and their goals

Understanding the roles, their challenges in the current situation, and their goals for the new product provides insight into the problem's scale and helps define the system to be developed. It would be beneficial to have a prepared template with the roles & goals matrix, which makes it easy and fast to elicit this part. Additionally, the problem of users, the users themselves and the context in which the problem exists might be depicted with a Persona and Problem Use case, as well as with the Problem statement or list of problems/needs.

3. The main capabilities and processes of the organisation and roles

This is what the scope usually consists of: what a user can do and what steps should be taken to achieve that. It's hard to create meaningful and close-to-reality scope without discovering capabilities and processes. The main questions here are:

• "What capabilities do the organisation and each role have now, and how should they be changed to cover the need?"
• "What processes were established to realise those capabilities,s and what should be changed to resolve the problem?"

This part is the most time-consuming, but it pays off with a justified scope and will save time in the next iterations. A list of capabilities and processes opens Pandora's box.

4. Fundamental business rules

Business policies and rules oversee the organisation's and users' daily activities and processes and are the basis of the system's behaviour. Without a list of Business rules, it is impossible to estimate their complexity. As a result, a project starts with a high risk of facing many surprises when sophisticated logic and rules are revealed. That's why it's so important to devote some time to defining the list and providing a short overview.

5. Other solutions to integrate with

Integrations are often a black box that eventually becomes a black hole, where project time disappears without a trace. Investing time in clearly defining them plays a crucial role in developing a well-thought-out scope and providing accurate estimates.

Conclusion

When the team works on a project with certain expectations, these five aspects are not a waste of time but a great investment in success. The perspective "As is–To be" empowers this approach even more. It broadens the picture and uncovers more nuances. This, in turn, eliminates uncertainties and mitigates the risk of scope creep. By spending 5-10% of the time on the project at the beginning, the team contributes to the clear roadmap, delivery plan, and time set.