A reactive organization is one which does not act unless it is prompted to do so by an external driver, e.g. a new business requirement, an application that has been developed or escalation in complaints made by users and customers. An unfortunate reality in many organizations is the focus on reactive management mistakenly as the sole means to ensure services that are highly consistent and stable, actively discouraging proactive behaviour from operational staff. The unfortunate irony of this approach is that discouraging effort investment in proactive Service Management can ultimately increase the effort and cost of reactive activities and further risk stability and consistency in services.
A proactive organization is always looking for ways to improve the current situation. It will continually scan the internal and external environments, looking for signs of potentially impacting changes. Proactive behaviour is usually seen as positive, especially since it enables the organization to maintain competitive advantage in a changing environment. However, being too proactive can be expensive and can result in staff being distracted. The need for proper balance in reactive and proactive behaviour often achieves the optimal result.
Generally, it is better to manage IT services proactively, but achieving this is not easily planned or achieved. This is because building a proactive IT organization is dependent on many variables, including:
The maturity of the organization. The longer the organization has been delivering a consistent set of IT services, the more likely it is to understand the relationship between IT and the business and the IT Infrastructure and IT services.
The culture of the organization. Some organizations have a culture that is focused on innovation and are more likely to be proactive. Others are more likely to focus on the status quo and as such are likely to resist change and have more reactive focus.
The role that IT plays in the business and the mandate that IT has to influence the strategy and tactics of the business. For example, a company where the CIO is a board member is likely to have an IT organization that is far more proactive and responsive than a company where IT is seen as an administrative overhead.
The level of integration of management processes and tools. Higher levels of integration will facilitate better knowledge of opportunities.
The maturity and scope of Knowledge Management in the organization; this is especially seen in organizations which have been able to store and organize historical data effectively – especially Availability and Problem Management data.
From a maturity perspective, it is clear that newer organizations will have different priorities and experiences from a more established organization – what is best practice for a mature organization may not suit a younger organization. Therefore an imbalance could result from an organization being either less or more mature. Consider the following:
Less mature organizations (or organizations with newer IT services or technology) will generally be more reactive, simply because they do not know all the variables involved in running their business and providing IT services.
IT staff in newer organizations tend to be generalists because it is unclear exactly what is required to deliver stable IT services to the business.
Incidents and problems in newer organizations are fairly unpredictable because the technology is relatively new and changes quickly.
More mature organizations tend to be more proactive, simply because they have more data and reporting available and know the typical patterns of incidents and workflows. Thus, they forecast exceptions far more easily.
Staff working in mature organizations also generally tend to have more established relationships between IT staff and the business and so can be more proactive about meeting changing business requirements – this is especially true when IT is seen as a strategiccomponent of the business.
Figure 3.5 Achieving a balance between being too reactive or too proactive
Table 3.4 outlines some examples of the characteristics of positions at extreme ends of the spectrum. The purpose of this table is to assist organizations in identifying to which extreme they are closer, not to identify real-life positions to which organizations should aspire.
Extremely reactive
Extremely proactive
Primary focus
Responds to business needs and incidents only after they are reported
Anticipates business requirements before they are reported and problems before they occur
Typical problems experienced
Preparing to deliver new services takes a long time because each project is dealt with as if it is the first
Similar incidents occur again and again, as there is no way of trending them
Staff turnover is high and morale is generally low, as IT staff keep moving from project to project without achieving a lasting, stable set of IT services
Money is spent before the requirements are stated. In some cases IT purchases items that will never be used because they anticipated the wrong requirements or because the project is stopped
IT staff tend to have been in the organization for a long time and tend to assume that they know the business requirements better than the business does
Capacity Planning
Wait until there are capacity problems and then purchase surplus capacity to last until the next capacity-related incident
Anticipate capacity problems and spend money on preventing these – even when the scenario is unlikely to happen
IT Service Continuity Planning
No plans exist until after a major event or disaster
IT Plans focus on recovering key systems, but without ensuring that the business can recover its processes
Over-planning (and over-spending) of IT Recovery options. Usually immediate recovery is provided for most IT services, regardless of their impact or priority
Change Management
Changes are often not logged, or logged at the last minute as Emergency Changes
Not enough time for proper impact and costassessments
Changes are poorly tested and controlled, resulting in a high number of incidents
Changes are requested and implemented even when there is no real need, i.e. a significant amount of work done to fix items that are not broken
Table 3.4 Examples of extremely reactive and proactive behaviour
While proactive behaviour in Service Operation is generally good, there are also times where reactive behaviour is needed. The role of Service Operation is therefore to achieve a balance between being reactive and proactive. This will require:
Formal Problem Management and Incident Management processes, integrated between Service Operation and Continual Service Improvement.
The ability to be able to prioritize technical faults as well as business demands. This needs to be done during Service Operation, but the mechanisms need to be put in place during Service Strategy and Design. These mechanisms could include incident categorization systems, escalation procedures and tools to facilitate impactassessment for changes.
Data from Configuration and Asset Management to provide data where required, saving projects time and making decisions more accurate.
