Risk Based Software Development Management

This article is addressed to those who are related to the development of a software product. Understanding the principles of managing the development process is no less important than the actual knowledge of programming technologies. The article is not addressed only to those who want to become or work as a project manager (Project Manager), Understanding the principles of management will be beneficial in any position and in any team.

Before moving on to the control technicians themselves, it’s not a bad thing to realize how you yourself behave in the project team. I will express a few basic principles of teamwork:
• Do not lie. Even if it is very scary to tell the truth. For she is still better than cheating. It is necessary to “dress” the truth, for the right perception, and you need to look for the right moment, but you can't lie. All the same, the truth will open and the damage will be more.
• Try to understand your colleague. Whether it will be your boss, subordinate, employee or customer - stand in his place and understand what you would like in his place, then many questions will disappear by themselves.
• Be indulgent, but do not condone. Anyone has the right to make mistakes, but no one can abuse trust.
• Do not make pets and rogue. The same criteria for the attitude to all members of the team basis of credibility.
• The less noticeable your behavior, the more it will be noteworthy - do not swear, do not run around the office, do not speak loudly. The British say that a gentleman does not laugh, but smiles.

Now that you have become an almost perfect employee, let's think about what the customer needs, the one who pays the money? He certainly wants to return the money, and even with a profit. The most unpleasant words for him - we do not have time, we did not succeed, they gave the wrong requirements ... and anything else that does not give him the desired for his money. All this can be combined with one concept - the risk of losing investments. That is why we will consider various development management techniques from the perspective of risk. It can be said with guarantee that during the development process you will encounter unforeseen situations, and not in your favor. They are risks. If you do not try to analyze and suggest possible unpleasant situations in advance, you will always have to be in a situation of saving the project and protecting against "unexpected surprises." For example, we can cite a familiar case when the hard disk stops being read just then ... and backups, alas ... So friends, without analyzing the troubles in advance, will have to meet them at the most inopportune moment. It should also be remembered that risk is not always the loss of customer money, but often other negative effects - loss of confidence, future orders or a possible promotion.
However, you should not treat risks as something uniquely negative. Often, the emergence of trouble, makes us mobilize, find a non-standard solution, quickly learn the subject area and certainly allow us to remember the method of the solution and work out a defense for the future. Without risks, life would be boring.
However, there is no single project management methodology, even if the risks were of the same type. Just as there is no ideal programming language, operating system, testing tools, etc. The development of a project management methodology is also a project. And here the following input factors are important:
• The degree of readiness of the project at the head of the customer, and accordingly the availability of materials describing what needs to be developed. Here, it is also necessary to take into account the susceptibility of changes to the project due to external circumstances, when the document describing the task itself undergoes a change. For example, the operating system version has changed.
• Characteristics of the development team. Not only in terms of professional skills, but also teamwork skills, readiness for criticism and personal inconvenience.
• Project size in time and resources (people).
• Required product reliability and correct implementation methods

At the very beginning, you need to understand how the project is formed at the customer:
• Have an accurate picture of the requested product. For example, develop a communication protocol described in the standard.
• Or the customer has a rough idea of ​​the project. For example, to develop a search engine on the Internet with given options and parameters. However, it is obvious that during the development process, the criteria and their relationship with each other may change.
• Maybe the customer has a very general idea. For example, the client has a unified communications system, something like “all in one” for the purposes of communication in the company. And now the task is to develop additional "buns". There is a list of many options, but the client still does not know what would be better, more profitable to develop first, and then what. And it is more profitable for him - this is an interesting / expensive relationship.
')
We define development management based on risk analysis, as a sequence of actions to proactively determine negative events during project execution, and steps to minimize harm to the project from them. Keep in mind that it is not possible to absolutely get rid of the losses associated with risks, as it is not possible for a person not to get sick. But one can single out the most critical and costly risks, be prepared for them and control their occurrence.
According to statistics, only 28% of software projects completed on time and within budget, 23% of developments are canceled before completion, and half of the projects exceed the budget by 50%. You will get a much more relaxed life at the end of the project if you think about possible problems at the beginning and you will not close your eyes to the occurrence of an “abnormal” situation in the development process.
Risk management includes two groups of actions and a rethinking point (decision making on change - Design). The first group is Risk Assessment and the second is Risk Management.
Risk assessment, in turn, includes the identification, analysis and prioritization of risks. Risk management includes planning, counteracting and monitoring risks.

Identify risks.

In this part, the team or its leader must compile a list of all possible troubles that await the project during its implementation. Risks can be divided into Social and Technological. Social risks will include all risks not directly related to the technology. For example, the loss of a key specialist (illness, dismissal) or a temporary outage of electricity, the Internet, changing project requirements, etc. The technological risks include all those aspects that may arise due to incorrect performance of the task, no matter whose fault. This may be an incorrectly stated task, an inconvenient framework, inconsistent interface between modules, etc.
The list of risks should include:
• Condition of occurrence of risk and its description
• Symptoms of early detection (if possible)
• What will the impact of the risk (time, money, reputation)
• What happens if the risk becomes an event and we cannot counteract it

Analysis

When the list of risks is ready, proceed to their analysis. For each risk identified:
The likelihood and severity of harm. Both characteristics are quantized from about 4 sizes from “small” to “large”. The assessment of probability is carried out in a team as a brainstorm. There are many methods for assessing the likelihood of risk occurring. I will bring here some of them:
• Based on comparison with the history of similar projects.
• Poker method, when each participant gives a secret assessment and then compare the result. They take as a basis either the estimate most often obtained or the arithmetic mean.
• Group method of assessing each risk in a small group and presenting it to the whole team.
• The devil's advocate method. The risks are dealt with by the team and everyone is trying to describe it in the worst possible way. In the end can be arranged "bargaining" risks to identify less and more likely.
Each of the methods is repeated in several iterations until it reaches a clear value for each risk.
As a result of the discussion, a table of similar content should appear.

A priority	Risk description	Symptoms	Probability	Harm	There was a level	Opposition

Such a table should not contain too many items, they should be 1-2 for the number of project participants. So, if a group has 5 people, then there is no point in having more than 10 risks. With a group of 20 or more people, it is necessary to divide the risks into groups, and the collective assessment should not exceed the total number of employees.

Prioritization

Risks line up in order - the most significant first. The priority is calculated by the formula (in the system of calculation of the dimension of assessment, in our case 4):
Priority = Probability x Harm

Planning

Planning must be done for each risk separately. Also in the table are recorded the symptoms of the occurrence of risk, which may indicate an approaching event.

Opposition

There are two approaches to protecting against risk events — avoid and protect. Complete analogy with the reaction to shock. You can either evade him or put protection. However, any protection has its price. For example, the protection of information on a disk has the cost of a backup disk and actions for systematic backup. But in more difficult situations, it happens that the security system itself becomes commercially unjustified. Therefore, to counteract the withdrawal formula for its effectiveness:

The effectiveness of protection = (Cost of risk before counteraction - Cost of risk with the use of counteraction) / Cost of counteraction.

It is clear that if the efficiency is ≤ 1, then the use of such counteraction is not advisable.

Monitoring

When all elements are developed and the risk table is filled, the team begins work on the project and monitors the possible occurrence of the risk or its proactive symptoms. Risks should be reviewed with a certain regularity, for example, once a week, but not later than a “demo” or commissioning phase. If the “Stage and Gate” control method is used, then after passing through each gate, the entire table is revised. As a result of the risk revision and change of its position in the table, the previous risk level is recorded in the column “There was a level”. This allows the team to track the dynamics of change in risk and, accordingly, to understand the point of approaching risk or passing it.

The key to effective risk-based project management is the continuous exchange of information between team members, management and the customer. It is important! Without sharing risk information, you will be like a commander without intelligence.

There are two fundamental techniques for developing a software product - Consistent design and design by iteration. Most developers are familiar with terms like Waterfall and Agile methods. Below, we will consider the right balance of their use as applied to the risk-based model based on the five-step model of B. Bem and R. Turner.
But first, you need to point out the pros and cons of both technologies.

	Waterfall	Agile
Client's ability to adjust development	Low Basis of development HLD / LLD document * or TK	High. Development is conducted in stages and each next stage is discussed before the start of implementation.
Solution Reliability	High, in the framework of the described functionality	Low The idea is implemented to a greater extent.
Resources	Large groups	Small groups
Product is obtained	Slow	Quickly
The correctness of the selected architecture	Thought out and analyzed.	Sacrificed to a quick fix.
Junior percentage	Maybe big under the guidance of experts.	Not big - all team members depend on each other.

* HLD - High Level Design, LLD - Low Level Design

One of the fundamental factors in this model are the characteristics of the team. Bem and Turner developed a staff qualification scale:

Level	Characteristic	Suitable model
3	In an unforeseen situation, it may revise the instructions of the development method independently.	Suitable for work in any model. As a rule, is the head of the link
2	Can adapt the method to the situation. After some practice can go to level 3	Good for an Agile group or a small Waterfall, like Team Leader
1A	He has experience of several projects and is able to assess the resources / risks of small tasks.	Applicable in both models under the leadership of Team Leader
1B	A programmer or tester with little experience.	Not desirable in Agile team.
-one	May have technical knowledge, but does not cooperate well in a team.	Can be used as a FreeLancer or consultant, but not as a participant in both methods.

Successful project management uses both techniques, but one of them must be chosen as the base. Below is a table of the definition of the basic project management model:

Project Characteristics	Based on Agile	Based on Waterfall
Application area
The main task	Quick issue result. Not a definite task.	Architectural accuracy, performance, reliability.
The size	Small teams and projects	Big teams and projects
Wednesday	High variability	Low volatility
Control
Customer relationship	Customer Satisfaction	Targeting TK
Planning and control	The group itself controls and plans.	Satisfaction with the requirements described in the plan
Information transfer	With close personal contact	Determined by document
Technically
Requirements	Prioritized and decorated in the form of stories. Can be easily changed by customer	Described in the TK and rarely change in accordance with the TK, as a rule clarification
Development	Simple design, small development steps	Extensive design, big changes per iteration step.
Tests	Automatic with reuse and constant development.	Documented, usually in the form of black box tests.
Staff
Customer availability	Easy and frequent access	Separated and often not available
Team	At least 30% level 2 and 3. Almost no 1B	From 10% level 3 and up to 30% level 1B
Team internals - culture	The team is ready to take responsibility and enjoy freedom	Freedom and responsibility are limited under an employment contract.

Based on the following table, choose the basic method of project management. Bem and Turner identified five factors to determine the base model. They are presented in the table below:

Factor	Agile	Waterfall
The number of developers in the group	Small group Each member is responsible for everything. Personal trust and collective motivation in the group	Suitable for large groups and projects. Relationships are formalized under the contract.
Reliability and stability of the product	Poorly tested and little reliable. Not documented and often misses requirements. Effective with prototyping	Suitable for critical products. Hard to apply for prototyping
Variability	Simplicity of design and ease of implementation. The risk of high cost when moving to a reliable release	Suitable for well-documented products, such as protocol implementation.
Personnel (team qualifications), its level	There should always be a critical mass of 2-3 levels. Dangerous use of level 1B	A critical mass of 2-3 levels is necessary only at the design stage. Applicable level 1B staff
The internal structure of the group - culture	High Freedom Within a Collective Responsibility Group	Operate as part of an employment contract with high labor protection.

To visualize the project was developed polar diagram.
The closer the project is to the center of the diagram, the more it is suitable for the Agile method, as a base for the project.



Finally, when the base method is selected, proceed to the adjustment using an alternative method.

As a result, the process of forming a project management concept based on risk analysis acquires 5 steps:

The first step is risk analysis:
Designing a risk table.
Risk assessment for Agile and WaterFall techniques

Step two - risk comparison:
If the base method has been identified, proceed to step 4.
If it is impossible to unequivocally find it out, go to intermediate step # 3.

Step three - architectural analysis:
If the unambiguous result cannot be obtained by the base method or some parts are inside the Agile zone and some are outside, the team tries to isolate those parts of the project where the Agile methodology is most applicable and the rest is done by Waterfall.

Step four - building the development life cycle:
The team follows the intended base method of development by verifying itself against the risks of the table from step # 1.

Step five - implementation and monitoring:
The team is constantly reviewing the risks and coming to a point. Design rewrites the risk table.

The block diagram below graphically shows the development process based on risk analysis and balancing of two methods - Waterfall and Agile.



It should be noted that team leaders and lead programmers should participate in the Agile development methodology. While juniors are better off not attending Scrum rallies.

Successful projects to you friends!

Used sources:
Boehm, B. and R. Turner (2003). Balancing Agility and Discipline: A Guide for the
Perplexed. Boston, MA, Addison Wesley.
Larman, C. (2004). Agile and Iterative Development: A Manager's Guide. Boston
Addison Wesley.