“ We don’t carry out everything that is proposed; And it’s a long way from the project to the thing .”
Jean-Baptiste Poquelin, known as Molière
What is the scope of a project?
The scope of a project is a fundamental component of the Golden Triangle, also known as the triple bind, comprising cost, time , and scope, where each influences the other two.
It essentially represents what the project needs to accomplish, which is the “WHAT”.
This scope is defined by the requirements that detail the expectations of the project.
The requirements correspond to the needs of the end users expressed by the customer and must be met by the product.
They encompass the expected features or services, the standards to be met, and the dependencies to consider, such as third-party services.
Depending on the development model used (V-cycle, sequential, iterative or Agile), the requirements repository or the initial backlog of the product materializes the scope.
The scope plays a crucial role in guiding the work of the teams throughout the execution of the project, helping them to stay on track and avoid potential drifts.
Agility:
Establish the scope
The scope of a project is the main sizing element of the Pre-Sales phase, thus influencing the system proposed to the customer, including costs, budget, deadlines, commitments and level of risk .
It is closely related to the business proposition and justifies a large part of it.
The scope, often materialized by a reference of requirements, is also a crucial component of the Project Plan and can be annexed to the contract with the client. In some cases, it can be formalized in the form of a Specification.
These scoping documents are subject to the client’s approval.
Perimeter quality
The more comprehensive and precise the requirements formulated by the customer, the better the estimates will be in the Pre-Sales phase.
Thus, the costing will be based on clear and documented assumptions , guaranteeing the company a fair and well-regulated commitment.
However, the expression of the client’s needs is not necessarily binding.
Some requirements may be discarded (due to questionable feasibility, minor relevance, or offered as an option for cost reasons), or adjusted upwards or downwards in terms of ambition.
It is essential to clearly identify the requirements that will not be addressed as is or at all, and to explicitly inform the customer of their exclusion from the scope covered by the service provider and their liability.
It is the requirements that the service provider meets with its own structuring hypotheses that, once validated by the client, will define the scope of the project, rather than the initial expression of needs.
Requirements & Product Approach
The requirements, usually functional to meet the needs of the end users, must be considered holistically in both Pre-Sales and Delivery, because “
The devil is in the details
“. With this in mind, it is essential to take into account:
The business value to prioritize or even segment the elements.
- Usability, including user experience (UX), user interfaces (UI), devices, languages, etc.
- Reliability, including product stability and availability.
- Performance, covering response time, data volume, number of users, etc.
- Security, by adopting a Security By Design approach.
- Regulatory compliance, especially with regard to GDPR.
- The impact of CSR (Corporate Social Responsibility): eco-design, accessibility, compliance, etc.
- Maintainability through architecture, configuration, standards, documentation, etc.
To prevent the scope from becoming an indigestible list of requirements and to make it directly usable by project operators, it is preferable to adopt a product approach.
This involves breaking down the scope into by-products or intermediate products, with a granularity adapted to the context: detailed enough to form coherent functional sets that can be used by end users, but also fine enough to reduce the time to delivery to these users.
The product approach is also more flexible when it comes to reviewing the scope with the client and more engaging for all stakeholders during the project implementation.
Managing change
Although the scope is defined more or less precisely at the beginning of the project, it can evolve due to various changes such as additions, modifications, substitutions or deletions of requirements, as well as the questioning of assumptions.
These changes can be triggered by factors that are external to the scope of the product, but that have an influence on it, such as:
- Unavailability of stakeholders
- Replacement of interlocutors
- New regulations
- Budget Restraint
- Cyclical impacts
- security hazards.
It is important to note that such a change is normal in a complex, uncertain and evolving project, but it is essential to measure the impacts and adopt the right approach.
The project leader should exercise caution in changing the scope and document any changes made during the process, usually via governance body reports and/or a change log.
It should be remembered that the triple constraint applies: any change in the scope can have repercussions on the cost and time of the project, as well as on its objective or quality , especially if it leads to undesirable effects.
In the context of a predictive methodology such as the V-Cycle, where the scope is initially assumed to be largely fixed, unless the change is compensable by a decoping or commercially negotiable, the project manager must:
- Revisit the project plan and contract, integrating change management mechanisms.
- Qualify and estimate new requirements, while revising those that depend on them.
- Submit a new proposal to the client, covering the additional burden.
- Update the schedule to account for the induced drift.
- Produce an amendment to formalize the change.
- Obtain validation of all these elements before their implementation.
In the context of an Agile project, although adaptability to change is inherent in the method, a change is not neutral in consequences.
The Agile project is usually time-bound (e.g., a minimum viable MVP ) and the budget is fixed.
In this context, we will favor a barter system to absorb the change, i.e. the replacement of User Stories by others with the same value in terms of effort and therefore Story Points.
Otherwise, the number of funded sprints can be expanded to absorb the change.
0 Comments