Say scope remains constant, then if cost decreases, time should increase.
The relationship between cost, time, and scope is a bit more complex. The main statement is that you cannot tweak one corner of the triangle without affecting at least one of the others, too, but the direction isn't always obvious.
There's a factor which has been left out of these diagrams (team size), and if you assume that is constant, then you're right that a budget cut should both decrease the possible scope and the total time to completion. That would mean that the upward arrow in the first diagram is wrong.
The second diagram seems to assume that team size is increased to be able to manage the same scope in shorter time. Naively, this would not affect total cost (if 5 devs get the project done in 10 weeks, then 10 devs should get it done in 5 weeks at the same cost) but in practice this isn't true due to increased communication and learning overhead. However, that cannot be expressed in a single general formula (there may be approximations valid for specific areas).
I would somewhat question the reliability of your source. Even if it's printed on paper, sometimes you need to question the truth of what you're supposed to learn. Learning material authors are humans, after all, and they do make mistakes.
Each of these variables is correlated with the others. If a change occurs on one of them, it will likely drive some degree of change in one or both of the remaining variables. There are several reasons that will cause variation in the degree of change the other variables will experience.
Different tasks have different degrees of resource elasticity. And that elasticity itself will have variability depending on the environment in which the task is performed. Therefore, the degree of change you might observe with two of those variables when you move one of those variables can dramatically differ from task to task.
Also, every task has itself a performance variability in both costs and time. If you did a task 100 times, and document the amount of time and cost, you will have a performance distribution with a minimum value, a maximum value, and a modal value. Depending on how much risk you assume when planning your tasks, i.e., choosing a planning value in both cost and time that approaches the minimum value on your distribution, then you may see more significant movement on the other two variables after you alter one of them.
The bottom line is that the variables that make up that triangle impact each other but each line of that triangle is affected by both random and epistemic variability.
As Hans-Martin says, the reality is rarely so simple, particularly in technology projects and other kinds of creative problem-solving work. There is often an optimal team size and so changing the timescale doesn't necessarily mean a corresponding change in cost or scope, it may just require resizing the team appropriately. On the other hand, the relationship between scope and cost tends to be much more direct and changes to to scope are usually expected to alter the cost.
Don't think of the iron triangle as a mathematical equation. The iron triangle is generally a cause & effect rule for project management.
In projects, generally;
- The scope does not reduce. Customers always want more with less budget in a shorter time; this is called capitalism.
- If somehow it seems that you are going to spend less, customers tend to add additional scope to the project or save the money for later.
- Customers tend to add additional scope to the project or go live earlier if you deliver faster than expected.
We can interpret the iron triangle as below;
If you want to add additional scope to the project, you have three options;
- Increase the budget: Add additional team members, outsource some parts to 3rd parties, buy a ready product/code, etc.
- Extend the deadline: Keep the team structure the same but accept that the delivery will take longer to complete
- Hybrid; increase some budget + extend the deadline a little bit
If you want to decrease the budget of the project, you have three options;
- Reduce the scope: Move some non-critical, non-show-stopper requirements out of scope.
- Extend the deadline: Shrink the team but accept that the delivery will take longer to complete.
- Hybrid; reduce some scope + extend the deadline a little bit
If you want to deliver the project earlier than planned, you have three options;
- Increase the budget
- Reduce the scope
- Hybrid; increase some budget + reduce some scope
What the others have said about it not being straightforward is correct. However, at least when considered as an abstraction, I'd argue that it does get pretty simple.
You can't increase one constraint without decreasing at least one of the others.
Where your given figure gets confusing is the (wide) arrows. An upward cost arrow there means the same as a downward time arrow, means the same as a... double sideways scope arrow.
It's much simpler to just visualize the constraints. When cost increases, the cost constraint increases. When scope increases the scope constraint increases. When time decreases, the schedule constraint increases. And vice versa.
When you visualize it that way, it becomes easier to understand. An upward arrow means at least one of the other constraints must have a downward arrow.