o visit with the new Director to discuss his plans and,on behalf of the staff, pled with him not to delete the IRM Repository as it represented a substantial investment by the company and could be used to interface with his new programming tools. The Director was undeterred and went about his plans. Although his new tools could generate software at an impressive speed, documentation was sacrificed, data redundancy raised its ugly head again, and a rift began to reemerge between the end-users and the development staff. After only a few months under the new regime, the developers found themselves again putting out fires as opposed to upgrading or developing new systems.

CONCLUSION

The roller-coaster ride experienced by the IT department in Toronto has been played out time and again in many other such organizations. It seems IT organizations go through cycles, such as from bad to good, and back to bad again (as in the case in Toronto). Others seem to go from bad to worse; and some from bad to outsourcing. Regardless, the IT staff should be ever watchful of any change at the top and observe the executive's management philosophy

"Its never lonely at the top of an IT organization, primarily because the IT Director is never there." - Bryce's Law

INTRODUCTION

In past bulletins, I have discussed how the corporate culture can be greatly influenced by the "Top Dog," meaning the head of the company. There are also subordinate "Top Dogs" who lead departments and their influence is limited only by what is allowed by their superior. This can be considerable if departments or divisions operate autonomously and inevitably results in subcultures that often operate at odds with the overall corporate culture. This phenomenon is particularly apparent in IT Departments who often have a revolving door policy for appointing managers or directors. This "changing of the guard" can be construed as good or bad depending on the current environment. What is important for the employees in the trenches is how to roll with the punches during this transitional state from one manager to another. Let me give you an example.

INSURANCE COMPANY

Years ago, we were engaged in a consulting contract with a large insurance company located in Toronto. Prior to our contract, the IT department was in disarray. End users weren't happy with their systems, they didn't trust the information produced, projects were late and over budget, and nothing was documented, making maintenance a nightmare. Things were so bad, that the executives were dependent on a certain systems programmer remembering to run the year-end financial reports (usually late). The current IT Director liked to hobnob with the corporate brass instead of his own staff, thereby leaving them in the dark. This helter skelter mode of operation affected harmony in the IT staff who ran around second guessing as to what was to be done. Conditions became so intolerable that the IT Director was finally ousted and replaced by a senior end-user who was also the most vocal critic of the department. Interestingly, he had no prior experience with systems and computing but was bent on cleaning up the mess left by his predecessor. This is when we were asked to come in.

Remarkably, the IT Director didn't find it necessary to fire anyone from the current staff but, instead, instituted a new organizational structure, imposed discipline, and created a quality consciousness. We were contracted to install the "PRIDE" Methodologies for IRM which greatly facilitated his goals.

To overcome his immediate problem of constantly working in a fire fighting mode of operation, his first project was to document the company's information resources, which was no small effort. There was a great temptation by developers to try to correct or improve the existing systems but, based on our suggestion, they resisted doing so since it would have resulted in a never ending project. Instead, problem areas were identified, cataloged, and prioritized. After the documentation project, this listing was used to formulate a systems strategy for improvements.

The documentation project benefited the company almost immediately. First, Operations began to run smoothly and on time. For example, with adequate documentation in place, they were no longer at the mercy of waiting for the systems programmer to run the year-end financial reports. Further, redundant data bases were spotted and merged, thereby bringing consistency to the information being produced. Also, the IT staff's morale picked up noticeably during this period as they now had a sense of direction and were cognizant of the strengths and weaknesses of their systems. Over the next few years, the company went on to conquer several major systems assignments much to the delight of the end-users and executive management.

Inevitably, the honeymoon came to an end when the IT Director announced he was going to retire after many years of service to the company. Unfortunately, he was not allowed to appoint his successor. Instead, he was replaced by a younger manager (30-ish) who was recruited from outside the company by an executive search firm.

The new IT Director was touted as a whizz kid who was intimate with the latest technology and wanted to make a name for himself. To do so, he had to distance himself from his predecessor and began to dismantle the organization and methods, and replaced them with 4GL's and other program generators. The new tools were impressive but the staff became unnerved when the Director disbanded the methodologies that worked in the past, and removed the IRM Repository containing all of the intelligence of the company's information resources.

I had an occasion to visit with the new Director to discuss his plans and,on behalf of the staff, pled with him not to delete the IRM Repository as it represented a substantial investment by the company and could be used to interface with his new programming tools. The Director was undeterred and went about his plans. Although his new tools could generate software at an impressive speed, documentation was sacrificed, data redundancy raised its ugly head again, and a rift began to reemerge between the end-users and the development staff. After only a few months under the new regime, the developers found themselves again putting out fires as opposed to upgrading or developing new systems.

CONCLUSION

The roller-coaster ride experienced by the IT department in Toronto has been played out time and again in many other such organizations. It seems IT organizations go through cycles, such as from bad to good, and back to bad again (as in the case in Toronto). Others seem to go from bad to worse; and some from bad to outsourcing. Regardless, the IT staff should be ever watchful of any change at the top and observe the executive's management philosophy a

our contract, the IT department was in disarray. End users weren't happy with their systems, they didn't trust the information produced, projects were late and over budget, and nothing was documented, making maintenance a nightmare. Things were so bad, that the executives were dependent on a certain systems programmer remembering to run the year-end financial reports (usually late). The current IT Director liked to hobnob with the corporate brass instead of his own staff, thereby leaving them in the dark. This helter skelter mode of operation affected harmony in the IT staff who ran around second guessing as to what was to be done. Conditions became so intolerable that the IT Director was finally ousted and replaced by a senior end-user who was also the most vocal critic of the department. Interestingly, he had no prior experience with systems and computing but was bent on cleaning up the mess left by his predecessor. This is when we were asked to come in.

Remarkably, the IT Director didn't find it necessary to fire anyone from the current staff but, instead, instituted a new organizational structure, imposed discipline, and created a quality consciousness. We were contracted to install the "PRIDE" Methodologies for IRM which greatly facilitated his goals.

To overcome his immediate problem of constantly working in a fire fighting mode of operation, his first project was to document the company's information resources, which was no small effort. There was a great temptation by developers to try to correct or improve the existing systems but, based on our suggestion, they resisted doing so since it would have resulted in a never ending project. Instead, problem areas were identified, cataloged, and prioritized. After the documentation project, this listing was used to formulate a systems strategy for improvements.

The documentation project benefited the company almost immediately. First, Operations began to run smoothly and on time. For example, with adequate documentation in place, they were no longer at the mercy of waiting for the systems programmer to run the year-end financial reports. Further, redundant data bases were spotted and merged, thereby bringing consistency to the information being produced. Also, the IT staff's morale picked up noticeably during this period as they now had a sense of direction and were cognizant of the strengths and weaknesses of their systems. Over the next few years, the company went on to conquer several major systems assignments much to the delight of the end-users and executive management.

Inevitably, the honeymoon came to an end when the IT Director announced he was going to retire after many years of service to the company. Unfortunately, he was not allowed to appoint his successor. Instead, he was replaced by a younger manager (30-ish) who was recruited from outside the company by an executive search firm.

The new IT Director was touted as a whizz kid who was intimate with the latest technology and wanted to make a name for himself. To do so, he had to distance himself from his predecessor and began to dismantle the organization and methods, and replaced them with 4GL's and other program generators. The new tools were impressive but the staff became unnerved when the Director disbanded the methodologies that worked in the past, and removed the IRM Repository containing all of the intelligence of the company's information resources.

I had an occasion to visit with the new Director to discuss his plans and,on behalf of the staff, pled with him not to delete the IRM Repository as it represented a substantial investment by the company and could be used to interface with his new programming tools. The Director was undeterred and went about his plans. Although his new tools could generate software at an impressive speed, documentation was sacrificed, data redundancy raised its ugly head again, and a rift began to reemerge between the end-users and the development staff. After only a few months under the new regime, the developers found themselves again putting out fires as opposed to upgrading or developing new systems.

CONCLUSION

The roller-coaster ride experienced by the IT department in Toronto has been played out time and again in many other such organizations. It seems IT organizations go through cycles, such as from bad to good, and back to bad again (as in the case in Toronto). Others seem to go from bad to worse; and some from bad to outsourcing. Regardless, the IT staff should be ever watchful of any change at the top and observe the executive's management philosophy

ity consciousness. We were contracted to install the "PRIDE" Methodologies for IRM which greatly facilitated his goals.

To overcome his immediate problem of constantly working in a fire fighting mode of operation, his first project was to document the company's information resources, which was no small effort. There was a great temptation by developers to try to correct or improve the existing systems but, based on our suggestion, they resisted doing so since it would have resulted in a never ending project. Instead, problem areas were identified, cataloged, and prioritized. After the documentation project, this listing was used to formulate a systems strategy for improvements.

The documentation project benefited the company almost immediately. First, Operations began to run smoothly and on time. For example, with adequate documentation in place, they were no longer at the mercy of waiting for the systems programmer to run the year-end financial reports. Further, redundant data bases were spotted and merged, thereby bringing consistency to the information being produced. Also, the IT staff's morale picked up noticeably during this period as they now had a sense of direction and were cognizant of the strengths and weaknesses of their systems. Over the next few years, the company went on to conquer several major systems assignments much to the delight of the end-users and executive management.

Inevitably, the honeymoon came to an end when the IT Director announced he was going to retire after many years of service to the company. Unfortunately, he was not allowed to appoint his successor. Instead, he was replaced by a younger manager (30-ish) who was recruited from outside the company by an executive search firm.

The new IT Director was touted as a whizz kid who was intimate with the latest technology and wanted to make a name for himself. To do so, he had to distance himself from his predecessor and began to dismantle the organization and methods, and replaced them with 4GL's and other program generators. The new tools were impressive but the staff became unnerved when the Director disbanded the methodologies that worked in the past, and removed the IRM Repository containing all of the intelligence of the company's information resources.

I had an occasion to visit with the new Director to discuss his plans and,on behalf of the staff, pled with him not to delete the IRM Repository as it represented a substantial investment by the company and could be used to interface with his new programming tools. The Director was undeterred and went about his plans. Although his new tools could generate software at an impressive speed, documentation was sacrificed, data redundancy raised its ugly head again, and a rift began to reemerge between the end-users and the development staff. After only a few months under the new regime, the developers found themselves again putting out fires as opposed to upgrading or developing new systems.

CONCLUSION

The roller-coaster ride experienced by the IT department in Toronto has been played out time and again in many other such organizations. It seems IT organizations go through cycles, such as from bad to good, and back to bad again (as in the case in Toronto). Others seem to go from bad to worse; and some from bad to outsourcing. Regardless, the IT staff should be ever watchful of any change at the top and observe the executive's management philosophy

period as they now had a sense of direction and were cognizant of the strengths and weaknesses of their systems. Over the next few years, the company went on to conquer several major systems assignments much to the delight of the end-users and executive management.

Inevitably, the honeymoon came to an end when the IT Director announced he was going to retire after many years of service to the company. Unfortunately, he was not allowed to appoint his successor. Instead, he was replaced by a younger manager (30-ish) who was recruited from outside the company by an executive search firm.

The new IT Director was touted as a whizz kid who was intimate with the latest technology and wanted to make a name for himself. To do so, he had to distance himself from his predecessor and began to dismantle the organization and methods, and replaced them with 4GL's and other program generators. The new tools were impressive but the staff became unnerved when the Director disbanded the methodologies that worked in the past, and removed the IRM Repository containing all of the intelligence of the company's information resources.

I had an occasion to visit with the new Director to discuss his plans and,on behalf of the staff, pled with him not to delete the IRM Repository as it represented a substantial investment by the company and could be used to interface with his new programming tools. The Director was undeterred and went about his plans. Although his new tools could generate software at an impressive speed, documentation was sacrificed, data redundancy raised its ugly head again, and a rift began to reemerge between the end-users and the development staff. After only a few months under the new regime, the developers found themselves again putting out fires as opposed to upgrading or developing new systems.

CONCLUSION

The roller-coaster ride experienced by the IT department in Toronto has been played out time and again in many other such organizations. It seems IT organizations go through cycles, such as from bad to good, and back to bad again (as in the case in Toronto). Others seem to go from bad to worse; and some from bad to outsourcing. Regardless, the IT staff should be ever watchful of any change at the top and observe the executive's management philosophy

o visit with the new Director to discuss his plans and,on behalf of the staff, pled with him not to delete the IRM Repository as it represented a substantial investment by the company and could be used to interface with his new programming tools. The Director was undeterred and went about his plans. Although his new tools could generate software at an impressive speed, documentation was sacrificed, data redundancy raised its ugly head again, and a rift began to reemerge between the end-users and the development staff. After only a few months under the new regime, the developers found themselves again putting out fires as opposed to upgrading or developing new systems.

CONCLUSION

The roller-coaster ride experienced by the IT department in Toronto has been played out time and again in many other such organizations. It seems IT organizations go through cycles, such as from bad to good, and back to bad again (as in the case in Toronto). Others seem to go from bad to worse; and some from bad to outsourcing. Regardless, the IT staff should be ever watchful of any change at the top and observe the executive's management philosophy as it will impact the corporate culture you are living in. As I mentioned in my bulletin on Corporate Culture, in order for employees to succeed, they must be able to adapt to the corporate culture. This usually means that it will be you, the employee, and not the manager who will have to adapt. But do not despair; let us not forget that the average tenure of service for an IT Director is under three years.

And in case you are wondering, Yes, the insurance company is again dependent on the systems programmer to run the year-end financial reports.

For additional information pertaining to this bulletin, see:

No. 28 - "Understanding Corporate Culture" - June 13, 2005 http://www.phmainstreet.com/mba/ss050613.pdf