Where Are Incidents Born?
Where Are Incidents Born?
Some time ago I was talking to a group of experienced IT service managers with a wealth of experience in incident management. We were discussing the moment a crisis arises, the involvement of different areas of the business, the discussions held between professionals from various sectors, the activation of the operations teams, and all of the other factors involved in a crisis situation.
In this conversation and information exchange, one of these managers commented on some absurdities that in his vast experience, happen daily. We know that there are actions that occur in our daily lives that can often be described as unorthodox or would not be the best solutions to be taken at that time. But the problem gets worse when basic concepts like processes, activities and procedures are unclear to some practitioners.
Additionally, there are those who still cannot understand the difference between management and governance and blend concepts and assign activities, roles and responsibilities in the wrong way. More annoyingly, there are a huge range of professionals who do not give due importance to good practices, methodologies and frameworks tested and validated not only by renowned institutes but by an international community, which give us guidelines to be followed to facilitate our decision making, solutions and activities, generating better quality, service and value for our customers.
When confusion begins, symptoms occur. Service level and operational agreements are broken, indicators almost explode and turn a glaring red, accusations between areas arise almost immediately. Due to a lack of alignment and even knowledge at times, we impact the business, generating an absurd amount of stress between those involved directly and indirectly, as well as unnecessary and additional costs. But the question I would like to bring to our reflection is … Could all of this be avoided?
The truth is that all of this could be avoided if we understand where incidents are born and take some small precautions, going straight to the source of the incident rather than getting waylaid in confused decision making and poor communication.
Poorly Designed Vision, Strategy and Planning
We often hear phrases like “users never really know what they want” in our daily lives. This is typically an excuse for something we fail to accomplish, and then we blame them for something that would be our responsibility. But in certain situations, this phrase and others with the same connotation can become the purest truth.
Why is this? Because in many instances, the vision of the business area is not clear and objective. In other words, our clients want something to optimize their activities or even improve their capital and income, but they themselves either don’t know what they want or can’t express themselves properly.
This results in the business view becoming blurred or incomplete; and an incomplete view makes both the strategy and the planning activities adopted incomplete. Ultimately this reflects on the final solution, as business requirements surveys will be conducted on top of this flawed vision, strategy and subsequent planning. These inaccurate business requirements surveys are then reflected in all subsequent processes.
Following our line of reasoning, many incidents arise in operations because the vision, strategy and planning that were born in the business were not clear enough.
A Mistaken Systemic Analysis
Lacking a clear and objective vision, strategy, and planning, the problems that began in this service lifecycle spread to systemic analysis. It is at this time that the systems analyst will sit with the business or requirements analyst to understand your business first and then your needs, translating your business requirements into functional and technical requirements.
If this survey was incomplete or poorly designed, it will reflect in the design of the solution. We do not even need to delve deeper into our thinking to know what will happen when this solution enters the production environment: crisis, followed by incidents.
An Incomplete Architecture, a Precarious Development
In some companies, it will be the systems analyst who will design the solution architecture and even code it, choosing the best environment (language, development suite, database, etc.). But many organizations have the role of solution architect or systems architect. They will be responsible for taking the analysis previously done, for example, functional, structural, aspect or object oriented, etc., and based on the requirements raised, transforming them into a technical language, elaborating the best solution for the organization or client environment. But if the systemic analysis was poorly done, either due to lack of requirements or clarity in the survey done with the business areas, we will surely have a solution that will not meet the business requirements.
A poorly elaborated or incomplete design will generate a development that is flawed and incomplete. This picture gets worse when the solution that is already designed is in transition. When it built and tested, it may have to go back to the design cycle or even the strategy cycle, due to errors in the testing or deployments uncovering the fact that business and system requirements do not match. Then, as the final delivery deadline approaches, solution development enters a chaotic moment as the teams involved are forced to do additional hours and hours of work, increasing the cost of the solution for the business and generating what we see almost daily: poorly designed environments, banal coding errors and stressed professionals. The proposed solution, which should generate business value, turns into dissatisfaction for the end customer, generating crises and constant incidents when it enters the production environment.
The Chaos of Operations
Here we are already in the almost daily cycle of many organizations: poorly designed, flawed production solutions that generate countless incidents. At this stage, business areas are no longer friendly, and IT is to blame for everything. Even ordinary facts or situations that are the responsibility of
other segments or areas of the company become the responsibility of IT, based on this poor relationship.
When we get into this cycle, we often feel that our hands are totally tied, because due to the daily rush and even the dynamics of the business, we have neither the time, nor the resources, nor the budget to fix the damage done. At this point, the solution may be so out of sync with the business that it would no longer be worth reviewing processes, procedures and activities, and it might be better to simply retire the whole solution and start a new one.
But of course, this does not happen and we are in an eternal pattern of something that could have been avoided if we spent more time and effort at each of the phases or cycles we have so far mentioned.
I could go on to explain other situations, in greater or lesser detail, that leadus to constant crises and incidents, but I just wanted to share a little of the exchange of experiences we had during this period of collective discussion.
I believe that not only do we experience situations like these, but many professionals also experience them. Situations that are due to carelessness,poor planning, hurry or even lack of experience and maturity, lead us to put to our production environments or our customers, solutions that instead of collaborating with business capital and value generation, end upgenerating the chaos we see in everyday life.
Think about this and see you in our next chat. If you’d like to share your thoughts, please leave us a comment below or tweet @itsmzone.