
I am very lazy to seriously engage in risk management. I always considered this to be complete rubbish, created by losers for the excuses in the style: “Ah! We said that you will fail! ”Get out of my project!
In addition - we apply agil. Small iterations. And our risks, and the risks of customers - are negligible! And we also have typical and clearly defined
stages in contractual relations (not to be confused with agile iterations;). Every time when we are faced with uncertainty - we divide the task into several small stages and our risks are reduced. It's easy! Yes? And now the bad news:
By reducing the risks of adding stages, we reduce the profitability * of the entire project.
Its profitability, in a sense. When I discovered this with a simple excel spreadsheet, and figured out how much it costs to add another stage - I whistled.
')
So, we have absolutely standard stages:

- Presale [0.10];
- Selling [0.50];
- Analytics [0.8];
- Design [0.9];
- Layout [0.9];
- Coding [0.9];
- Support [0.8];
The numbers in parentheses are the chances that your project will move from one phase to another with success and profit. Fictional, but pretty close to reality. For example, if you ordered only a design, then the numeral in brackets is reduced. You can calculate it for your company.
Do this at least once a year. Just analyze all sales and projects. It will be somewhere
0.8-0.95, probably. Now multiply these numbers, and you will get the probability that the project from the current phase will reach the end of the production chain, and you will earn well.
* We had a rather violent debate about whether it is correct to use the word “profitability”, because we get money for each stage. That is, the profitability of the stages is not reduced. However, a project that has fallen off in the middle of the chain means that the developers at the last stages may suddenly be underloaded and will take profits from the previous stages instead of generating it. In addition, it is at the final stages of the project that takes the form in which you want to put it in the portfolio, put on it the copyright and be proud of it. And this is the attraction of new projects and +100 morale. So let it be "profitability."
This exercise immediately discourages adding new steps to the workflow.
Just open the calculator, enter 0.9 there, press [X] and poke the [=] button as many times as you have stages.

Each of these stages can be broken up into smaller stages or do a
lot of iterations on the code and design. It usually happens on large projects. Basically, that's what we do. This is important because on a large project - selling, courting a customer, gaining mutual trust and respect is one of the very costly operations. And it is very long and unpredictable. And now the most interesting:
An expensive and unpredictable operation is at the beginning and at the end of each stage of the work process.
In fact, we have to sell the result of the current stage and the development of the next one every time when we have something in our hands that can be shown to our client and use it. Usually it goes like clockwork. But the whole truth is that your good work does not always affect whether the next phase will sell.
Sometimes even the opposite: a well-made prototype will make it clear to the client that the project should not be done.
It turns out that the more stages and iterations the project goes through in the agile process, the more demonstrations, and each demonstration is the risk that the client will slow down the project. Or arrange a TRAY!
There is no contradiction with marketing. In general, markeoids invented a tool for this: sales funnel. One evening I was bored, and I decided to count
how many calls I need to have at the entrance to ensure:
- The optimal workload of teams on projects.
- The desired income level of my company.
I proceeded from the fact that I have 8 teams, and I need about 4-6 projects at the RELEASE stage in a month.
The result was something like this tablet:

In the column
“the probability of transition further” is the probability with which the project will move from the current phase to the next. In the rows - the stages through which the project passes.
For example, at a minimum we should have 137 projects in the lead phase for the month. With a probability of 0.1, each of them goes into the transaction phase (i.e. there are 14 projects left). And so on - of all incoming projects, only 4 projects will be brought to the release phase.It is convenient for me to use a kanban board to store the entire list of projects. I use the minimum and maximum number of projects as indicators for each of the columns (the board will highlight them with the desired color, if something went wrong, and if there is too little or too many projects at some phase). In addition, I can estimate how many cards (total work in porgress) are permissible on my kanban board. In our case, these are 39 and 59 projects. It is also convenient to consider how much money I have “stuck” on each phase.

Probably, if I were not so lazy, I would constantly monitor how overwhelmed or underloaded my project managers are. I would even make such a sign:

But usually this is so clear in their appearance, why such problems? ;)
It's simple. Now I risk and sometimes do free work consciously!
Why? I know that splitting a project into smaller stages:
- Reduces the risks of "do not meet the assessment" (good).
- Increases the risk of "non-release" of the project in full from the originally conceived (bad) and adds to the impact (very, very bad).
In addition, I know (and predict) the likely load of managers and their teams for a couple of months in advance.
And sometimes it’s more profitable for me that the manager and the team take more risks due to uncertainty.
Did not break the project into additional stages. Or even to do some of the stages as if at his own expense. For example, analytics. If only it is faster and without losses to push through the project to the next stage.
Which will already pay for everything. For free to work - a sin;)So keep track of the number of projects in the work, take a chance and sometimes play with your calculator. All agile, guys!