RISK!!!! The Human FACTOR Remains the Strongest , but the Favorable Risk in Software Development. Part 1

Even in a well thought-out and formalized the field, like software development, it does not cease to be relevant to risk management. Is it even possible to manage uncertainty, random variables?

Optimists argue that they can be classified and learn to anticipate. In the case of software development risk managers try to predict which part of the project will cause more problems, at what point that happens, someone on the team - the weakest link, which features can give a time delay. It is more difficult to understand what features the client wants to modify in the process of developing - as they say, at full speed. Aerobatics - add to the functionality of the development plan, which the customer forgot to say or did not know that she needed him.

And the risk that the project suddenly leave the key developers generally horrifies many risk managers.

If you still take into account all possible risks associated with the situation in the country, the Earth's magnetic field, currency fluctuations, changes in supply and demand balance, the closing of the client company finally, each company will have to build for the recording and analysis of all these risks, its research center with a high level of paranoia.

Some of the above problems, one way or another, help to solve the flexible project management methodology. But there are also problems associated with a lack of competence of the risk managers, the ALM managers and low motivation of employees to a strict observance of the principles of these methodologies.

Of course, at different stages of the development of these problems and risks are manifested in varying degrees: at the stage of the work plan over the risk to make a mistake with the estimates and priorities of features; during the design phase, developers can make a "fatal" error in the project; in the early iterations of a temptation to move too many tasks for the next iteration; the deployment phase should be prepared to ensure that the process does not go smoothly.

It is no coincidence in the description of risks an association with temptation. Developers - real people who may not always work with the same efficiency. Everyday temptations "to postpone for tomorrow", "leave early", "come back later", and so on, have a cumulative effect. If N employees will go on about the M temptations, it will significantly reduce the overall discipline and local productivity.

This story is a continuation of that sooner or later these employees would have to catch up, and then the risk lies in wait for them to make mistakes due to haste and fatigue. It turns out that the slight variations in the power of "human weakness" may lead to a significant "subsidence" of the project. How to predict when a particular employee will be tired? How many risk managers need to keep track of all?

And if some team members just sours the relationship? Can we predict it? If so, the risk manager should be part-time psychologist or work in conjunction with it. Perhaps in small projects for all to follow as possible, but whether it will be possible to more large?

Of course, for each IT company in this issue to look for a middle ground. But so far at every stage of the development and implementation of software products involved non-deterministic mechanisms (ie, people), the human factor will remain the main risk.

So we come to the most important question - is it possible to somehow stay in the "human factor" in the list of risks and learn to manage it?

To Be Continue...
Vyacheslav Smirnov