November 30, 2015 at 10:48Top 5 Risks of Custom Software Development
We continue the series of articles in which we consider the methodological issues of creating software. Methodology is, first of all, ownership of the strategy through the use of various development principles. Knowing the principles allows you to make the work more conscious, predictable and less exposed to risks. Management of the latter and the article is devoted.
It is based on chapters from the book “Waltzing with the Bears: Risk Management in Software Development Projects” by Tom DeMarco and Timothy Lister, which we can safely recommend to every programmer and manager in the field of software development. The book does not have a hard focus on agile development methodology, but authors are constantly turning to Agile.
You can discuss the topic of risks for a long time and, if you wish, name a few dozen, but the most common and dangerous of them are only five:
And only the fifth risk in a row 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 software, the leader must adequately calculate risks and manage them. Such an activity does not guarantee 100% successful completion of the project, but provides some reserve in case 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. give wishful thinking. The result is a significant discrepancy in the planned and actual terms of the project, which sometimes reaches 50-80%. In this case, problems in relations with the customer and with resource overruns are inevitable.
And all dogs are often hung up on programmers because of deadlines, although this error occurs due to 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 the opposite situation occurs: the implementation period is overstated. 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 do faster and cheaper.
To reduce the risk of non-compliance with the schedule in the methodology of agile development, it is necessary to lay some reserve of time in case of planning errors and unforeseen circumstances, as well as involve programmers as much as possible in evaluating the deadlines.
Customer requirements for the final product often change along the way, especially for large tasks. This means that if you agreed on the delivery of product X in 10 months, the customer will most likely need a product not X, but an X-bar. This entails additional labor costs.
How many supplements are reasonable to plan? Adequate is an estimate of 1% of expected changes per month, i.e. For a one-year project, approximately 12% of the time should be set aside to satisfy new customer wishes.
Agile involves 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 allows rational implementation of 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 an investment of time.
There are two things you need to do to reduce this risk in Agile.
The risks of this item are somewhat distinguished from the list: they either come true and lead to collapse, or do not come true and in no way affect the project. The danger is that the concluded agreement often carries hidden conflicts and does not really suit either side. And during the development and implementation of software, these points pop up, and problems begin. If it is not possible to reach consensus, the project is often collapsed, and the real reason for this is insufficient coordination. The proportion of projects discontinued 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 the early stage all the existing contradictions, helps the parties reach agreement on all issues. This is especially true for data flow arrangements.
The productivity of the individual and the collective as a whole is a dynamic, non-linear thing, and it is rather difficult to evaluate. The consequence of Parkinson’s law is of greatest importance: the development team is activated only at the end of the project’s deadline, and the rest of the time it’s working at half strength.
In a flexible methodology, the task is divided into short stages, constantly causing a feeling of imminent deadline.
DeMarco and Lister give an interesting calculation: when the planned time for completion of the project is 26 months, the probability of meeting the deadline is only 4%. With 75% probability, the work will be completed by the 38th month, and in 15% of cases the project will not be completed at all. This assessment is quite discouraging and makes you think about how you can reduce risks and shorten project implementation times.
As you can see, the authors of “Waltzing with the Bears” consider the flexible development methodology a rather productive means of reducing risks. However, even in this case, close monitoring of all possible difficulties is necessary.
It is based on chapters from the book “Waltzing with the Bears: Risk Management in Software Development Projects” by Tom DeMarco and Timothy Lister, which we can safely recommend to every programmer and manager in the field of software development. The book does not have a hard focus on agile development methodology, but authors are constantly turning to Agile.
You can discuss the topic of risks for a long time and, if you wish, name a few dozen, but the most common and dangerous of them are only five:
- the intricacies of scheduling;
- increase in customer requirements during project implementation;
- staff turnover;
- violation of specifications;
- low productivity.
And only the fifth risk in a row 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 software, the leader must adequately calculate risks and manage them. Such an activity does not guarantee 100% successful completion of the project, but provides some reserve in case of force majeure situations.
The intricacies of scheduling
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. give wishful thinking. The result is a significant discrepancy in the planned and actual terms of the project, which sometimes reaches 50-80%. In this case, problems in relations with the customer and with resource overruns are inevitable.
And all dogs are often hung up on programmers because of deadlines, although this error occurs due to 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 the opposite situation occurs: the implementation period is overstated. 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 do faster and cheaper.
To reduce the risk of non-compliance with the schedule in the methodology of agile development, it is necessary to lay some reserve of time in case of planning errors and unforeseen circumstances, as well as involve programmers as much as possible in evaluating the deadlines.
Increasing 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 agreed on the delivery of product X in 10 months, the customer will most likely need a product not X, but an X-bar. This entails additional labor costs.
How many supplements are reasonable to plan? Adequate is an estimate of 1% of expected changes per month, i.e. For a one-year project, approximately 12% of the time should be set aside to satisfy new customer wishes.
Agile involves 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 allows rational implementation of 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 an investment of time.
There are two things you need to do to reduce this risk in Agile.
- Increase targeted communication between team members so that the loss of any employee is not critical. Development should not be "closed" to a specific person.
- Create a comfortable environment for employees so that there is no desire to leave it. If working in a company is materially beneficial, interesting and exciting, then the probability of dismissal is reduced.
Specification violation
The risks of this item are somewhat distinguished from the list: they either come true and lead to collapse, or do not come true and in no way affect the project. The danger is that the concluded agreement often carries hidden conflicts and does not really suit either side. And during the development and implementation of software, these points pop up, and problems begin. If it is not possible to reach consensus, the project is often collapsed, and the real reason for this is insufficient coordination. The proportion of projects discontinued 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 the early stage all the existing contradictions, helps the parties reach agreement on all issues. This is especially true for data flow arrangements.
Low performance
The productivity of the individual and the collective as a whole is a dynamic, non-linear thing, and it is rather difficult to evaluate. The consequence of Parkinson’s law is of greatest importance: the development team is activated only at the end of the project’s deadline, and the rest of the time it’s working at half strength.
In a flexible methodology, the task is divided into short stages, constantly causing a feeling of imminent deadline.
DeMarco and Lister give an interesting calculation: when the planned time for completion of the project is 26 months, the probability of meeting the deadline is only 4%. With 75% probability, the work will be completed by the 38th month, and in 15% of cases the project will not be completed at all. This assessment is quite discouraging and makes you think about how you can reduce risks and shorten project implementation times.
As you can see, the authors of “Waltzing with the Bears” consider the flexible development methodology a rather productive means of reducing risks. However, even in this case, close monitoring of all possible difficulties is necessary.