5 major risks in custom software development
We continue the cycle of articles in which we consider the methodological issues of software creation. Methodology is, first of all, the possession of a strategy through the use of certain principles of development. Knowledge of the principles makes the work more conscious, predictable and less prone to risk. Management of the latest and dedicated article.
It is based on chapters from the book “Waltching with the Bears: Risk Management in Software Development Projects” by Tom DeMarco and Timothy Lister, which we can safely recommend to each programmer and manager in the field of software development. The book does not have a hard focus on a flexible development methodology, but the authors constantly turn to Agile.
You can talk for a long time on the topic of risks and, if you wish, name a few dozen, but the most common and dangerous of them are only five:
')
And only the fifth risk depends directly on the developers. The remaining four are influenced by either external factors or the work of the project manager. In general, far from everything depends on the qualifications, motivation and performance of programmers. When creating a software manager must adequately calculate the risks and manage them. Such activity does not guarantee 100% successful completion of the project, but gives some reserve in the event of force majeure situations.
Quite often, when drawing up plans, managers are guided either by the wishes of the customer or by overly optimistic assessments of the capabilities of subordinates, i.e. wishful thinking The result is a significant discrepancy in the planned and real terms of the project, which sometimes reaches 50-80%. In this case, problems in the relationship with the customer and resource overuse are inevitable.
And all the dogs about the breakdown of the terms often hang on programmers, although this error is the fault of the manual. After all, if the amount of work is underestimated by 80%, then it is absurd to demand development at almost double speed. Sometimes there is a reverse situation: the implementation period is too high. In this case, there is a high probability of losing a client already at the design stage, because there are candidates who are ready to make faster and cheaper.
To reduce the risk of non-compliance with the schedule in the methodology of agile development, it is necessary to build up a certain amount of time in case of planning errors and unforeseen circumstances, as well as to involve programmers in estimating the deadlines as much as possible.
Customer requirements for the final product often change along the way, especially for large tasks. This means that if you have agreed on the delivery of product X after 10 months, the customer will probably need a product, not X, but an X-stroke. This entails additional labor costs.
How many extras are you planning to plan? The estimate of 1% of expected changes per month is adequate, i.e. for a one-year project, approximately 12% of the time should be spent on meeting new customer requirements.
Agile assumes regular discussion with the client of the change of terms and functionality at all stages of cooperation. Instead of ignoring or suppressing changes on the part of the customer, prioritization is used, which makes it possible to rationally carry out the necessary innovations along the way.
It seems that people always leave at the most inopportune moment, and this is inevitable. Of course, the loss of an experienced employee who effectively interacts with team members knows the specifics of a particular project and the organization as a whole, and replacing it with a new person entails a waste of time.
To reduce this risk in Agile you need to do two things.
The risks of this point are somewhat highlighted from the list: they either come true and lead to a crash, or do not come true and in no way affect the project. The danger is that the agreement often carries hidden conflicts and does not really suit either of the parties. And during the development and implementation of software, these moments emerge, and problems begin. If a consensus cannot be reached, the project often collapses, and the real reason for this is insufficient coordination. The share of projects terminated in this way is estimated at about 15%.
To reduce the risk of violation of specifications in a flexible methodology, they use an intermediary who sees and resolves at an early stage all existing contradictions, helps the parties to reach agreement on all issues. This is especially true of data flow agreements.
The performance of the individual and the team as a whole is a dynamic, non-linear thing, and it is rather difficult to evaluate. The most important is the result of the Parkinson's law: the development team is activated only by the end of the project’s due date, and the rest of the time it works halfway.
In a flexible methodology, the task is divided into short stages, constantly evoking a feeling of a quick deadline.
DeMarco and Lister give an interesting calculation: with a planned project completion time of 26 months, the probability of meeting the deadline is only 4%. With a 75% chance of work completed by the 38th month, and in 15% of cases the project will not be handed over at all. This assessment is rather discouraging and makes you wonder how you can reduce the risks and shorten the time of project implementation.
As can be seen, the authors of “Waltzing with the Bears” consider the flexible methodology of development to be quite a productive means of reducing risks. However, even in this case, close monitoring of all possible difficulties is necessary.
About development technologies:
Once again about the seven main development methodologies .
10 major system scaling errors .
8 principles of development planning, simplifying life .
5 major risks in custom software development .
It is based on chapters from the book “Waltching with the Bears: Risk Management in Software Development Projects” by Tom DeMarco and Timothy Lister, which we can safely recommend to each programmer and manager in the field of software development. The book does not have a hard focus on a flexible development methodology, but the authors constantly turn to Agile.
You can talk for a long time on the topic of risks and, if you wish, name a few dozen, but the most common and dangerous of them are only five:
')
- internal complexity of scheduling;
- increasing customer requirements during project implementation;
- staff turnover;
- specification violation;
- poor performance.
And only the fifth risk depends directly on the developers. The remaining four are influenced by either external factors or the work of the project manager. In general, far from everything depends on the qualifications, motivation and performance of programmers. When creating a software manager must adequately calculate the risks and manage them. Such activity does not guarantee 100% successful completion of the project, but gives some reserve in the event of force majeure situations.
Internal Scheduling Difficulties
Quite often, when drawing up plans, managers are guided either by the wishes of the customer or by overly optimistic assessments of the capabilities of subordinates, i.e. wishful thinking The result is a significant discrepancy in the planned and real terms of the project, which sometimes reaches 50-80%. In this case, problems in the relationship with the customer and resource overuse are inevitable.
And all the dogs about the breakdown of the terms often hang on programmers, although this error is the fault of the manual. After all, if the amount of work is underestimated by 80%, then it is absurd to demand development at almost double speed. Sometimes there is a reverse situation: the implementation period is too high. In this case, there is a high probability of losing a client already at the design stage, because there are candidates who are ready to make faster and cheaper.
To reduce the risk of non-compliance with the schedule in the methodology of agile development, it is necessary to build up a certain amount of time in case of planning errors and unforeseen circumstances, as well as to involve programmers in estimating the deadlines as much as possible.
Increased customer requirements during project implementation
Customer requirements for the final product often change along the way, especially for large tasks. This means that if you have agreed on the delivery of product X after 10 months, the customer will probably need a product, not X, but an X-stroke. This entails additional labor costs.
How many extras are you planning to plan? The estimate of 1% of expected changes per month is adequate, i.e. for a one-year project, approximately 12% of the time should be spent on meeting new customer requirements.
Agile assumes regular discussion with the client of the change of terms and functionality at all stages of cooperation. Instead of ignoring or suppressing changes on the part of the customer, prioritization is used, which makes it possible to rationally carry out the necessary innovations along the way.
Staff turnover
It seems that people always leave at the most inopportune moment, and this is inevitable. Of course, the loss of an experienced employee who effectively interacts with team members knows the specifics of a particular project and the organization as a whole, and replacing it with a new person entails a waste of time.
To reduce this risk in Agile you need to do two things.
- Increase the volume of targeted communication between team members so that the loss of any employee is not critical. Development should not be "closed" on a specific person.
- Create a comfortable environment for employees so that there is no desire to leave it. If work in a company is financially profitable, interesting and exciting, then the probability of layoffs is reduced.
Specifications Violation
The risks of this point are somewhat highlighted from the list: they either come true and lead to a crash, or do not come true and in no way affect the project. The danger is that the agreement often carries hidden conflicts and does not really suit either of the parties. And during the development and implementation of software, these moments emerge, and problems begin. If a consensus cannot be reached, the project often collapses, and the real reason for this is insufficient coordination. The share of projects terminated in this way is estimated at about 15%.
To reduce the risk of violation of specifications in a flexible methodology, they use an intermediary who sees and resolves at an early stage all existing contradictions, helps the parties to reach agreement on all issues. This is especially true of data flow agreements.
Poor performance
The performance of the individual and the team as a whole is a dynamic, non-linear thing, and it is rather difficult to evaluate. The most important is the result of the Parkinson's law: the development team is activated only by the end of the project’s due date, and the rest of the time it works halfway.
In a flexible methodology, the task is divided into short stages, constantly evoking a feeling of a quick deadline.
DeMarco and Lister give an interesting calculation: with a planned project completion time of 26 months, the probability of meeting the deadline is only 4%. With a 75% chance of work completed by the 38th month, and in 15% of cases the project will not be handed over at all. This assessment is rather discouraging and makes you wonder how you can reduce the risks and shorten the time of project implementation.
As can be seen, the authors of “Waltzing with the Bears” consider the flexible methodology of development to be quite a productive means of reducing risks. However, even in this case, close monitoring of all possible difficulties is necessary.
About development technologies:
Once again about the seven main development methodologies .
10 major system scaling errors .
8 principles of development planning, simplifying life .
5 major risks in custom software development .
Source: https://habr.com/ru/post/271937/
All Articles