IT Change Management in the 1970s

Before the structured world of ITIL and formalized IT Service Management (ITSM), the 1970s represented a “Wild West” era for Information Technology departments, particularly within large companies. Mainframes reigned supreme, punch cards were the input method of choice, and the concept of “change management” was more akin to frontier justice than a well-defined process. This article delves into the challenges and realities of managing change within IT during this nascent period, highlighting the interesting facts and hurdles that would eventually pave the way for frameworks like ITIL.

The 1970s were a time of explosive growth for computing.  Businesses were rapidly adopting mainframe technology to automate previously manual processes, from payroll to inventory management. This newfound reliance on IT meant that changes, whether upgrades, bug fixes, or new system implementations, had a significant impact on business operations. However, the processes for managing these changes were often ad-hoc and reactive.   

Imagine a scenario: a programmer, after weeks of coding, implements a “minor” update to the payroll system. Unbeknownst to them, a subtle change in the data input validation causes the system to reject a significant number of employee records. Payroll processing grinds to a halt, impacting thousands of employees and causing widespread frustration. This type of scenario, unfortunately, was not uncommon in the 1970s.

One of the biggest challenges was the lack of standardized processes. Each IT department operated in its own silo, with its own unique (or non-existent) approach to change management. There were no best practices to follow, no shared knowledge base, and no common language for discussing IT service management. This meant that lessons learned in one organization were rarely transferred to another, leading to repeated mistakes and inefficiencies.

Another significant hurdle was the limited availability of tools and technologies to support change management.  Version control systems were rudimentary, making it difficult to track changes to code and configurations. Automated deployment tools were virtually non-existent, meaning that changes were often implemented manually, increasing the risk of errors. Testing was often performed on live systems, further amplifying the potential for disruption.   

Communication was also a major challenge. IT departments often operated in isolation from the rest of the business, leading to misunderstandings and misaligned priorities. Changes were often implemented without adequate communication to users, resulting in confusion and resistance. The concept of a “change advisory board” was largely unheard of, meaning that changes were often approved without sufficient scrutiny or consideration of their potential impact.

The culture of IT in the 1970s also contributed to the challenges of change management. Programmers were often seen as “rock stars,” individuals with unique skills and knowledge that were essential to the organization. This often led to a lack of accountability and a reluctance to follow formal processes. The focus was on getting things done quickly, rather than getting them done correctly.

Interestingly, the very limitations of the technology in the 1970s sometimes forced a more cautious approach to change. Mainframe systems were complex and fragile, and any change carried the risk of a system crash. This meant that changes were often planned and implemented carefully, albeit without the benefit of formalized processes. However, this cautious approach was often driven by fear rather than a genuine understanding of risk management.

One interesting fact about IT in the 1970s is the prevalence of “cowboy coding.” This term referred to the practice of programmers making changes directly to production systems without adequate testing or documentation. While this approach might have been fast in the short term, it often led to long-term problems, including system instability and difficulty in troubleshooting issues.

Another challenge was the lack of metrics and reporting. IT departments had little visibility into the impact of changes on business operations. There were no key performance indicators (KPIs) to track the effectiveness of change management processes. This made it difficult to identify areas for improvement and demonstrate the value of IT to the business.

The 1970s also saw the emergence of the first database management systems (DBMS). While these systems offered significant advantages over traditional file-based systems, they also introduced new challenges for change management.Changes to database schemas or data structures could have far-reaching consequences, requiring careful planning and coordination.   

The lack of formal training in IT service management was another contributing factor to the challenges of change management. Most IT professionals learned on the job, and there were few opportunities for formal training in areas like process management, risk management, or communication.

The challenges of change management in the 1970s laid the foundation for the development of frameworks like ITIL in the 1980s and 1990s.  ITIL provided a standardized set of best practices for IT service management, including change management.  By defining clear processes, roles, and responsibilities, ITIL helped organizations to improve the effectiveness of their change management practices and reduce the risk of disruptions.   

The evolution of technology also played a crucial role in improving change management. The development of version control systems, automated deployment tools, and sophisticated testing methodologies made it easier to manage changes and reduce the risk of errors.

In conclusion, managing change in IT during the 1970s was a challenging endeavor. The lack of standardized processes, limited tools and technologies, communication barriers, and the culture of IT all contributed to the difficulties. However, the experiences of this era ultimately led to the development of frameworks like ITIL and the advancement of technology, paving the way for the more structured and effective approach to change management that we see today. The “Wild West” days of IT may be long gone, but the lessons learned from that era continue to shape the way we manage change in the digital age.