It’s no secret that quite a lot of project on the deployment of software products end in failure. The secret is what are the reasons of this failure. Which firm, the head of programmer will publicly own to it? This publication is not intended to be a comprehensive analysis and is based only on the personal experience of author. And since I had to act both from the Customer side and Executor side, I hope to avoid a one-sided assessment of the events.

Gray payoff

Payment «in envelope» for the key Customer employees on whom the conclusion of contract and its subsequent continuation is so common that you feel yourself like a «whit crow» trying to build a contract without a payoff.
Case study. One day I could act as an expert from the Customer side when deploying the industry software product on the base of «1С:Enterprise 8» by the developer company. The customer was a large enough enterprise that could afford to make a «custom design» of the mass-production product and a third-party expert. A few months everything was normal: I found small developer errors, helped to train the Customer employees and assign the access rights. The moment came when the salary for drivers and mechanics should be drawn for the first time in the program from the primary documents (waybills and tally sheets of tractor drivers and engineers). As always, before the date of salary payment very little time remained. And here it was found that for some drivers the program drew the payroll at the director level. The calculator clutch their head blaming themselves in the whole bag of tricks. But the overview of records in the accumulation register which the waybill makes showed that in some cases the recorder document write the double and triple records. We contact with developer and show him the problem.
«But why did you get to the register?!» — said the developer instead of «thank you», looked for the cause of error for a long time and corrected it in the end. Later he conferred with the chief financial officer. And then the chief financial officer invited me and offered to terminate the contract by mutual agreement. «Love cannot be compelled» — and I agreed.
Therefore, the reasons of my skepticism to the payoff are not so much moral as practical.

• Firstly, it is more complex to «earn» the total amount of the contract. Those people who are not involved in the gray scheme will be reasonably wonder: «Why do we pay so much?».
• Secondly, the process of decision making in the complex project situations will be distorted by self-interest of individual managers.

Weaknesses of strong leader

The influence of personality traits of the leader on the decision making mechanism is expressed by the concept «management style». In the management thesaurus it is said: «Management style — a set of the most characteristic and sustainable methods for solving the tasks and problems used by the leaders of organizations and enterprises in their practical activities».
The factors that determine the management style chosen by the leader include:

• Skills and abilities to use the power. The unskilled leader tends to use only the strong-willed or only democratic methods. The experienced leader chooses the methods which are the most effective in each particular situation.
• Psycho-physiological features of the leader (temperament, character). A person with a strong type of nervous system is more inclined to the volitional decisions and less – to thinking through the consequences of the decisions.
• The social priorities declared by the society and compliance with them in every locality. So, in the «backwoods» the people are more inclined to regard the leader as the «king, father of nation ».

Authoritarian management style — the most problematic in terms of the works to deploy the software products. The owners and leaders who use this management style usually solve themselves the most of questions regardless of the views of others, do not tolerate the objections of subordinates, constantly look for mistakes and violations in order to punish the perpetrators. They have such relations with the subordinates as «guard-prisoner». They do not comply with the service hierarchy of subordination. The ancient management principle «Vassal of my vassal is not my vassal» is not for them. They humble even the educated workers trying to prove their superiority. Autocrat with his self-will paralyzes the work of the team which he relies on. The frightened, angry resentful subordinates can let him down and misinform. They are not only unreliable, but also do not work hard, are passive, hide their shortcomings in the work. In such enterprises servility and squealing prosper instead of work with claims, the picture of the true situation is distorted. The people try to get rid of the responsibility and most want protectability.
In defense of this management style it is possible to cite the following arguments:

• These leaders are effective to work in the critical situations, when there is no time to think about the decisions. In the short term, this gives a certain effect, but in the long term, it can lead to the crisis.
• The staff problems, especially in the periphery, may create for the leader a pattern of behavior and perception. In fact, several times I have been present during the search for the chief accountant for the enterprise. The candidates described the process of cost generation for the production only as Dt20 Ct60, and the question «What is recorded in the account 09» they regarded as almost indecent.

Case study. I participated in the project where the management company (MC) from the creditor bank intervened in the work of enterprise in complex financial state. All he works of IT-project deployment were charged to the chief financial officer by the order. Already the fact that the chief financial officer has to report to the General Director of MC and the owners set the slow pace of works. But when the deployment process reached the production laboratory, it stopped at all, because the head of laboratory does not report to the chief financial officer. The attempts of CFO to inform the heads (owners and MC General Director) in advance about the problems and to bring them to overcome these problems have not been successful. And only when the entire new procurement season found itself under the threat, the General Director of MC intervened in the situation.
For a start, he deprived the CFO of bonus «for the accounting failure», then started with us (implementers). I was called to the meeting, where six people prepared for me a «Lynch law». MC General Director was sitting at the head of the table «as black as a thundercloud». My efforts to start the talk off in the constructive plane failed. The other side did not want to talk about its errors. Verdict of General Director was simple: we will be paid for a month of works, if we will do everything for the procurement season. Honestly, the jobs given by the stepmother to the Cinderella were more executable than this requirement. Any implementer knows that «everything» can mean the path to the Moon and back. I had in the folder the requirement of different employees and some of them already seemed to be inappropriate. For example, the desire, instead of paper journal to keep the records of laboratory analyses, to create its electronic equivalent. The explanations that the primary paper accounting is necessary for the control were not accepted. I could still understand the situation, when the data are entered directly in the program from the measurement devices. But this was not the case. Or the creation of report form which was generated by the services once a month and the calculation algorithm changed depending on the different situations on the factory and was reach in the manual corrections. Creation of this report in Excel took a couple of hours, but development and debug in SP threatened to take several weeks. The problem was that nobody of the Customer employees wanted to accept the responsibility for the change and reduce or requirements.
After meeting, I create an approximate work schedule in which I included all the suggestions I had. Of course, the General Director of MC and the owners were satisfied neither by the terms nor by the volume/payment of works. The arm-twisting started like «We hired you like the specialists, you must …». The fact that the time constraints and volumes should be specified and corrected by both sides according to the contract was firstly avoided to discuss by the Customer representatives. Then I created an approximate work schedule in which I included only the most necessary from the point of view. And on the Customer enterprise the representatives of companies appeared that represent other software products. The Customer employee who maintained «1С:Enterprise» told me in confidence that he sees such confusion with the program before the procurement season already the fourth (!) year. Realizing that the payment for the work already performed in the last month I, most likely, will not get, I write a letter to the head that either I am ready to terminate the contract by mutual agreement or insist on its observance:

• written reasoned refusal or a signed certificate of work completed are required;
• payment of completed works;
• agreement of the Job by both sides for deployment in the next month.

«Never go to meet the person who insists on the legitimacy of the illegitimate requirements». The desire of MC General Director «to continue the work according to his requirements» was illegitimate, but I was ready to help the Customer in its real desires and priorities. Another meeting was held with the Customer on which the advantages and disadvantages of three software products were discussed.
To my surprise, the common sense won and the work with us continued.

Analog versus discretion

There is a book «Analog versus discretion in language and thought» of V.V. Nalimov. In this paper a proposition is erected about the fundamental insolubility of human-computer dialogue by means of formal logic. Once, this book has made me to look in a new way at the process for generating the Customer requirements to the software product operation. Here are some excerpts from the book:
«There are two levels of understanding. The first, when you learned some question and it looks like you know everything you need, but you are still unable to answer yourself a new question related to the learned field of study; and the second level of understanding, when the general picture appears, the clear understanding of all relations. Such questions which it is impossible to answer while there is no this second level of understanding we call paradoxes. Analysis of these paradoxes is very useful to achieve such complete understanding.
The mathematicians, especially those who are related to the work with computer, will not see any fundamental difficulties for the discrete devices compared with analog ones. Indeed, if we, for example, need to find an area under the curve not specified analytically, then it will cause much trouble if the points can be read from the curve with any, no matter how small step. But the formulation of problem would be absurd by itself, if we would have been given only a code designation of curve and its quite indistinct description using the code designations of other curves specified with the same way.
And in the language we face exactly with that: we know a word – code designation of semantic field – and some indistinct description of this field given using other similar code designations. All variety of semantic context remains hidden –it reveals itself only through the potentially embedded ability to construct the unlimited set of phrases. Continual semantic context behind the discrete language symbols is immeasurable in essence. We are provided with its fragments that occur when interpreting certain phrases.
Human is characterized by the discrete (in parts) perception system, when the mind better analyses and assimilate voluminous information only after its prior division into a certain number of parts.
Discretion of our language is indisputable evidence of the discretion of our perception.»
Discretion of human perception explains the fact that the most of employees on the deployment project are able to explain only fragmentarily the essence of their work and to perceive also fragmentarily those innovations that are implemented in the software product. The perception discretion explains the fact that the complete algorithm of software product behavior appears only after the process of its operation testing or event later sometimes. The deployment paradox is that the user knows something, but does not know what exactly the implementer has to know. «the correct question usually contains 70% of answer». Therefore, the implementer has to collect exactly these 70% of knowledge on subject to ask a correct question to the user. That is why the users often ask: «Do you have the deployment experience in this area?».
In terms of management, the enterprise must have such document as the Accounting politics of enterprise in which the accounting rules and interrelationship should be described. But only a couple of times during my sixteen-year deployment experience I saw a fairly complete Accounting politics. Most enterprises are limit themselves by the formal description and set of phrases like: «distribution of indirect costs is conducted according to the IRC of Russian Federation». And some chief accountants explain the brevity of accounting politics by the fact that it is easier to defend so the features of enterprise accounting in the tax inspectorate. And the creation of finished Accounting politics is a hellish work, especially under PEM.
The implementers are trying to protect themselves creating the RC and offering the Customer to sign it. But sooner or later the problem occurs in the project concerning the discrepancy of singed RC and Customer wishes. And this problem can turn into a question of the possibility of joint continuation of work.
Case study. Deployment problem described in the previous section had another simple explanation: the accounting data did not always coincide with the actual data. Submission of claims to the contractor is fairly troublesome. Besides, with every contractor the leadership made agree its own version of controversy settlement. With the further deployment a number of inconsistencies between accounting and management accounts were detected. But the customer employees hold back this. Of course, we dealt with the situation, but as the phrase goes:

Never before Shtirlits has been so close to a failure.