Consideration of risks in assessing the complexity of software and project planning

Let's talk about the risks

What are the risks? What is risk and what is not? How to take into account the risks in assessing the complexity of software and project planning? I propose to talk about this in this topic. At the same time, in order not to inflate a topic and not to repeat , the issues of identifying and mitigating risks — actions to identify, reduce the likelihood of risks occurring and minimizing their consequences — will not be discussed here.
After the publication of the article about the deadly sins in the assessment of the complexity of the software I was told that neither the author nor I said anything about the risks. I want to correct this annoying misunderstanding and tell you a little about the risks and my experience with them.

Typical risks

Below is a list of typical risks for a software development project.

• distraction of employees from the current project to work with other projects
• illness, special holidays, weddings, pregnancy, time off, etc.
• unreasonable delay in reconciling claims
• unpredictable change / expansion of customer requirements
• use of relatively new technologies in the development
• care of key developers / architects
• change of key employees / representatives on the customer side

What is NOT a risk

Is global warming at risk? And what about the change in the market situation? And the possible collapse of the customer’s company or, God forbid, your company?
It is more correct to ask: “Which of these risks should be taken into account in your project?”

Somehow we carried out an assessment of the complexity of the next project. Having burned on a recent project, we tried to lay as much risk in the evaluation of a future project as possible. It turned out very impressive list.

After reviewing this list, my previous supervisor and mentor told us: “Don't put your unprofessionalism in risks!” How? Me and my colleagues were accused of lack of professionalism ?! I was a little offended by him then. We were forced to exclude quite a few points that really seemed like risks to us. Some time passed since then, I got a little cold, read books, rethought my previous experience. Now I can say that I have to agree with him on a number of points. So, I will list some cases that should not be considered risks.
')

Risks whose probability tends to 100%

• lack of qualifications of employees is not a risk due to the fact that qualifications should be initially included in the assessment (for example, using the focus factor )
• regular employee leave - they can be predicted more or less in advance and added to the project plan
• predictable changes in requirements - may occur if a particular development model is selected (for example, Fixed Team )

Risks whose probability tends to 0

This list may seem a bit far-fetched. It is given only to illustrate possible "incredible" risks. It is important to understand that the same risks can become unbelievable depending on the nature of the project and its duration.

• change of existing legislation, during the implementation of short-term projects
• complete loss of project source codes

Works that are part of a project or methodology

• review of the code - it happens that this activity is classified as risk
• refactoring - they say: “refactoring may be required”. The word “can” is confusing and suggests that this is a risk. In fact, refactoring refers to those works that are planned in advance.

Risk management planning

Here you need to make a small digression and explain why the risks need to be considered . As Tom De Marco said, "in order to manage a project, it is enough to manage its risks ." But! This concerns the moment when the project has already started. When there is, what to manage. Now imagine that the evaluation and planning of the project is carried out before its start. And in general, it is not known whether the project will be launched or not. Do I need to take into account the risks at this stage? Yes and no…

On the one hand, at the initial stage, possessing insufficient information, we can either overfill the risks and underestimate them. On the other hand, it is not a reason to completely ignore them. We have to look for a reasonable balance and yet somehow take into account the most significant risks for this project, which we identified at the very beginning.

Definition of terms

We introduce the concept of "pure labor intensity"
We define net laboriousness as laboriousness in “ideal man-days” necessary for the implementation of a particular task. To explain what is meant here, I will use the description taken from the book Scrum and XP from the Trenches from the experienced Scrum Master Henrik Kniberg . So:

“ An ideal man-day is the most productive day when nobody and nothing distracts from the main occupation. Such days are rare.” (c) Henrik Kniberg

In other words, we will assume that the task is so laborious, provided that none of the risks are realized.

Uniform distribution of risks by task or hidden hat technique

As an “introductory” report, I’ll give an anecdote told to us by one of the top managers in response to the presented estimates of a recent project:

The employee comes from a business trip, delivers a expense report, and there, among other things, is “Hat: $ 100”
They ask him in accounting ...
- What kind of hat is that?
- Well, I bought myself a hat ... cool ... all things.
- $% & * #! Go change the report!
Well, brings a new, there again, "Hat: $ 100"
Well, again, "$% & * #!", Go change it so that there is no hat.
It brings ... They look - everything is normal ... you’re not digging, there are no hats ... but the final amount has remained as it was.
Ask:
- Where's the hat?
- Yes, there she is ... there ... only you find her hell!

So, this method can be applied when considering risks.
For example, one or more risks, expressed in the form of some additional complexity, can be simply evenly distributed over the other specific tasks, as indicated on the fragment of the Gant chart below:

Here, blue color indicates task rectangles with net laboriousness. Signatures - resources assigned to tasks (people). Red color denotes a rectangle in which the labor intensity is concentrated, which is added due to the risk response.
Thus, on the one hand, risk is assessed in the assessment, and, on the other hand, non-focusing on them. This is the method of accounting I met in the book to which I referred above. I note that this book does not explicitly say that it is precisely risk management, but the analogy can be traced very clearly. If interested, see the chapter on planning.

Separate tasks

Now imagine that we have identified some kind of risk that is tied to both resources, but does not increase the duration of work on the tasks they solve. Take a look at the chart below:

The figure shows that the total duration of all tasks has not increased, since the risk rectangle is parallel to other rectangles. This approach makes sense to apply in the event that the risk, increasing the overall complexity of the tasks, does not shift the final deadlines. This happens (when the total duration of the project does not increase), unfortunately, very rarely.

Now let's turn to another diagram:

Here the red task-risk goes sequentially (end-to-end) with other tasks. Thus, the total duration of work (term) increases.

The approach of risk accounting by identifying independent tasks makes sense if the plan consumers are required to designate risks in an explicit form. It is important to remember that task-risk is fictitious. As a result, during the implementation of the project, this task will either degenerate into a specific task (a new blue rectangle), or “join” into other tasks, or will not be executed at all. Such accounting is important precisely at the initial stage of planning, so as not to lose a possible time shift or budget increase.

findings

I will make an additional emphasis on the fact that taking risks into account does not mean refusing to deal with them; this is not an attempt to avoid a problem instead of solving it. In many cases, it will be more appropriate to create such conditions when the risk from the category of probable becomes the discharge of the impossible . It is possible, however, that part of the risks could not be eliminated. In this case, it will be useful to take into account such risks.

Please forgive if the topic is too long. I limited myself to wherever I could. In particular, in the post there is absolutely nothing about how risk accounting can be used in the PERT method. If the topic is sufficiently demanded, then a separate topic will be created on this topic.
Thanks to those who read to the end!