Business studios: about stages, money, a calculator and kanban
I am very lazy to seriously engage in risk management. I always considered this a complete nonsense created by losers for excuses in the style of: “Ah! We said that you won’t succeed! ”Get out of my project!
In addition, we use aggil. Small iterations. Both our risks and the risks of our customers are negligible! And we also have typical stages that are clearly defined in contractual relations (not to be confused with agile iterations;). Every time we are faced with uncertainty - we break the task into several small stages and our risks are reduced. It's that simple! Yes? And now the bad news:
By reducing the risk of adding steps, we reduce the profitability * of the entire project.
Your profitability, in the sense. When I discovered this with a simple excel table, and figured out what it costs to add another step, I whistled.
So, we have absolutely standard stages:
- Presale [0.10];
- Sale [0.50];
- Analytics [0.8];
- Design [0.9];
- Layout [0.9];
- Coding [0.9];
- Support [0.8];
The numbers in brackets are the probability that your project will move from one phase to another with success and profit. Fictional, but pretty close to realities. For example, if you ordered only a design, then the number in brackets decreases. You can calculate this for your company. Do this at least once a year. Just analyze all sales and projects. It will be somewhere
* We had quite a heated debate about whether to use the word "profitability" correctly, because we get money for each stage. That is, the profitability of the stages does not decrease. 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 profit from the previous stages, instead of generating it. In addition, it is at the final stages that the project takes on the form in which you want to put it in the portfolio, put copyright on it and be proud of it. And this is the attraction of new projects and +100 to the fighting spirit. So let it be "profitability."
This exercise immediately discourages the addition of 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 down into smaller stages or do many iterations of the code and design. This usually happens on large projects. Basically, that's what we do. This is important, because on a large project, selling, caring for a client, gaining mutual trust and respect is one of the very costly operations. Moreover, it is very long and unpredictable. And now for the fun part:
An expensive and unpredictable operation is at the beginning and at the end of each stage of the workflow.
In fact, we have to sell the result of the current stage and the development of the next each time 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 be sold.
Sometimes it’s even the other way around: a well-made prototype will make it clear to the client that the project does not need to be done.
It turns out that the more stages and iterations a project goes through in an agile process, the more demonstrations, and each demonstration is a risk that the client will slow down the project. Or arrange a BARRIER!
There is no contradiction with marketing. For marketoids, in general, a tool was invented for this: a sales funnel. One evening I was bored, and I decided to calculate how many calls I need to have “at the entrance” to ensure:
- Optimum workload of teams on projects.
- 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 for a month.
The result was approximately the following plate:
In the column "probability of transition further" - the probability with which the project will move from the current phase to the next. In the lines are the stages through which the project passes.
For example, we should have a minimum of 137 projects in the lead phase per month. With a probability of 0.1, each of them goes into the transaction phase (i.e., 14 projects remain). And so on - from all incoming only 4 projects will be brought to the release phase.
It’s 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 are too few or too many projects at some phase). In addition, I can estimate how many total cards (total work in porgress) are allowed on my kanban board. In our case, these are 39 and 59 projects. It’s also convenient to consider how much money I have “stuck” in each phase.
Probably, if I were not so lazy, I would constantly monitor how overloaded or underloaded my project managers are. I would even make such a tablet:
But usually it is already clear from their appearance, why such troubles? ;)
Everything is simple. Now I take risks and sometimes do free work consciously!
Why? I know that splitting a project into smaller stages:
- Reduces the risk of "not fit into the assessment" (good).
- It increases the risk of "non-release" of the project in full from the originally conceived (bad) and adds tyayagomooootiny (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 on more risks of uncertainty. DO NOT break the project into additional steps. Or even do some of the stages as if at your own expense. For example, analytics. If only to push the project to the next stage faster and without loss. Which already pays for everything. For free to work is a sin;)
So keep track of the number of projects in work, take risks and sometimes play with your calculator. All agil, boys!