When working remotely, it is possible to build both the interaction of processes and to combine work with other things in a reasonably harmonious way.
In difficult times, there is always more interest in IT. Be it economic crises, when everyone starts to count money and cut costs. Or deterioration of the political situation, when suddenly people remember that information is an important weapon. The current growing emphasis on IT is associated with recurrent lockdowns, when many employees are forced to work remotely and become heavily dependent on communication and IT.
At the same time, IT quality categories such as reliability, security, performance, and recoverability are being discovered to have a serious impact on the performance of more and more people.
Usability has an equally serious, though not so obvious, impact on results, because when you are stressed in the workplace for 8 hours, you can hardly show good results.
Thus, what experts have been saying for quite a long time, namely that IT quality is determined not only by software functionality, but also by many other characteristics, has become obvious to many. Although back in 2015, the approach to software quality was significantly expanded and the first standards of the SQUARE series (Systems and software Quality Requirements and Evaluation, GOST R ISO/IEC 250** standards, for example, ISO/IEC 25010-2015 Quality Models for Systems and Software Products) appeared. I would also like to note that modern IT allow not only in the vast majority of cases to achieve the required values of quality parameters, but also to monitor their changes in real time. Why this is not given enough attention? Typically the answer to questions of this kind I hear: “There is not enough budget,” a little less often: “We don’t have time for this.
Budget
As a member of project teams, as a manager and a supervisor of many projects, I can conclude that the quality of developed software in no way directly proportional to the budget allocated to the project. Quite the opposite, in fact. High-budget projects which are subject to increased attention and strict control are seldom successful. The project team and PMs of such projects are too afraid to make a mistake, which is not good for the cause. Excessive caution leads to trampling, and the main effort is spent on proving to management that the money was not spent in vain. Potemkin villages, and colorful presentations, and deployed dashboards are used. And since the project team’s efforts are not limitless, there is no more time left for the actual creation of the project result. Our book on digital transformation[1] has a chapter on budgeting. It deals with digital transformation projects, but the described methods are quite suitable for automation projects as well. It is high time to stop annual budgeting, which is a relic of the Soviet era and state centralized planning. In the book Terry Wright convincingly proves that this approach goes against the methods of agile software development. The annual budgeting itself is often the main obstacle to the introduction of such techniques in organizations. Of course, planning for such a serious period of time prevents the flexibility that IT projects need in today’s environment, even if they are conducted according to a cascade model. Not only that, but it also impedes the agility that organizations need in other areas of activity. Budgets must be planned for short periods of time, each time analyzing whether the project is worth continuing, whether it still meets the company’s needs. If such planning goes against the company’s financial policy (and this policy is “sacrosanct”), it is advisable to budget a portfolio of projects, within which to use more flexible methods of budget distribution. In conclusion, I would like to point out that all the mega-expensive IT projects that I know of, and there are quite a few of them, have ended in high-profile failures.