Among the subjects frequently discussed in this blog, are the differences between the Agile Method and the Traditional Method (Waterfall) of software development and the benefits of the first in relation to the latter. Today, we will continue to talk about this topic, but we will specifically address one of the most important items in building digital products: scope.
Projects of any kind always involve three main restrictions known as the Iron Triangle of Project Management: cost, time, and scope. Cost refers to how much will be invested to carry out the project in items such as resources, acquisitions, and even risks; time concerns the deadline for it to be delivered, and scope explains what will be contained in the job; it is the definition of the “border” between what will be done and what will not be done.
Such restrictions are present in both closed-scope and open-scope projects, but they are worked differently in each. In software development, it is common to hear that traditional projects are closed-scope and agile projects are open-scope.
So, what does Closed or Open actually mean?
It is necessary to understand that to define cost, time, and scope, estimates are made. Since estimates are not exact, it is not possible to fix the three variables of the Triangle. For example, let’s say you leave home for a bike ride. Within your scope, there is a 10km ride and the time you estimated is 30 minutes. Which of these variables are you going to fix, and which are you going to make flexible? Well, it depends on your needs!
- If you only have 30 minutes available, you will fix the time and try to do 10km within that period, which can result in a variation to 8km, 9km, or even 11km.
- However, if you need to get to a place that is 10km from your home, then you will fix the distance, and maybe get there in 25 minutes, or 35 minutes.
Therefore, when we talk about closed-scope projects, we are referring to the scenario in which the project is fixed in scope, and thus time and cost may vary. In open-scope projects, the process is the opposite: time and cost are fixed, and the scope may vary. Let us learn more about this, shall we?
Source: Leandro Faria’s Lecture
Closed-Scope
When the fixed variable is the scope, the first issue that arises is the need to detail the scope we want to fix. Therefore, closed-scope projects often involve a long planning stage.
This very detailed planning often creates a sense of security, predictability, and control. However, it is important to remember that this security is only real in situations where the defined scope is stable – which can happen in some areas such as civil engineering but does not usually happen in the software world.
In closed-scope projects, it is also common for the participation of the customer or the user of the solution to be concentrated at the beginning and at the end of the project, without the need for frequent monitoring: after all, everything that will be developed in the middle is already defined. This can be seen as an advantage in environments where all the knowledge about what needs to be done is already mature and stable, but in projects that involve the development of new knowledge, this type of approach is a source of failure, as it does not consider the need for interaction and feedback.
Think: how many times, while starting a project of any kind, did you know exactly what needed to be done during execution? How many times have you or someone on your team changed your mind when looking from new perspectives?
Closed-Scope Problems
First, there is a set of problems related to scoping itself. The closed-scope process is quite naive and unfair to users and stakeholders, as it requires them to define all the requirements at the beginning of the project. Well, how can you really know how the features will work before you even try them?
Problems with scoping include:
- Understanding: when describing all the requirements for the product, clients may believe they are being clear about what they want, but the team’s interpretation may be different.
- Completeness: Providers of requirements rarely design all possible user journeys, and the lack of this study ultimately results in multiple uncovered usage scenarios.
- Adaptation to innovation: The worst case is trying to define the scope of an innovative project in advance. Think: If we already know all the details in advance, what is innovative about it?
Secondly, there is a set of issues related to the false sense of security created by detailed estimates. Estimating means analyzing probability based on available information. In the case of closed-scope projects, this happens only in the planning stage: time and cost are calculated due to the scope implementation effort.
Issues with estimates include:
- Not meeting the deadline: as we explained before when you decide to fix the scope, it is known that the other variables will fluctuate! However, as estimates were presented at the beginning of the project, expectations were created in the stakeholders, and now any fluctuation will be seen as a delay.
- Excessive buffers: in order not to run the risk of missing strict deadlines and failing at the expectations that were created, time estimates end up being purposely increased by the team – it’s the famous overestimate of buffers. More time, consequently, results in a greater cost. And as Parkinson’s Law says, “work expands so as to fill the time available for its completion”.
- Compromising Quality: To meet expectations created about budget and deadline estimates, it is a common solution to think about cutting quality and verification steps, causing products to be delivered without proper testing.
Open-Scope
Open-scope projects, on the other hand, have a fixed time (and resources), which makes it possible to set their budget; but the scope is variable. Thus, the goal is to deliver the highest priority product in the shortest time and with the highest possible quality.
In practice, instead of just a planning stage, in open-scope projects, there are work cycles that go through inspection and adaptation. Deliveries are made in every Sprint (two weeks) or in every completed item (which can generate a daily cadence, for example). This way it is possible to readjust the scope frequently, within the fixed time and cost.
Also, with the customer following the work closely and users testing the product, changes become a more agile and less bureaucratic reality. See: every two weeks, with the delivered items at hand, it is possible to analyze the product and get new insights, which can be included in the next Sprint.
Advantages of Open-Scope Projects
The main objective of agility is to eliminate waste and focus on Value-Driven Deliveries. That is, the value that a specific part of the scope has for the business is considered in each planning session, and this analysis is the basis for prioritizing items. As a result, the following advantages emerge:
- Prioritizing what matters: With the fixed-time strategy, it makes sense to start with what delivers the most value rather than what is most comfortable or most obvious. Thus, the whole work logic changes, and the famous Student Syndrome (delivering at the last moment) is naturally fought by the process.
- Adaptive planning: As it is carried out constantly during the project, planning is molded to the project’s current scenario. This means that if the customer’s business undergoes any changes, for example, it is possible to include, exclude or modify items in view of this new reality.
- Constant learning: Customer and user participation ensures frequent feedback, which generates learning about the project and the product. At each new Sprint, the team adds new knowledge that is applied during development.
- Mitigation of uncertainties: Predictability becomes more real than in closed-scope projects. After all, after a few Sprints, the team can be surer about its delivery capacity, and thus it becomes possible to carry out projections based on reliable data.
- Quality first: The definition of a project’s quality requirements is an essential part of its scope composition. Open-Scope allows spaces to be created for modifications necessary for quality. This way, the development team has the flexibility to solve the real problems of the product’s users’, and there is assurance that it will not be outdated at the end of the project.
- Value assurance: With constant monitoring, the value of the project is not lost, that is: it continues to solve the issue proposed, even if this issue changes during development.
A Paradigm Shift
Despite the benefits, open-scope projects suffer resistance in medium and large companies that fear losing control over their work. There is a belief that agile projects would not have proper management and would represent greater risks for the client.
In the book Agile Project Management, Jim Highsmith talks about this paradigm shift in management methods. He explains why, in a knowledge-based economy, traditional projects fail to achieve results: they limit products. This is a disadvantage in a competitive and innovative market and can cost any business its own survival.
Also, in closed-scope projects, the client pays for activities that do not add value to the business – since all activities were initially planned and “must” be delivered, even if they no longer make sense. It is a change in mindset: instead of measuring success by the list of deliverables, success is now measured by the impact caused by the product.
Collaboration and Value Delivery
At SoftDesign, our development method is agile and therefore involves an open-scope. Our contracts prioritize trust and collaboration, and our multidisciplinary teams are ready to build your digital product with quality.
Please contact us to discuss scope, cost, and time and find the best way to put your project into practice.
