دانلود کتاب مدیریت فناوری اطلاعات

In 2011 I started my career as CIO of a large Philippine company, during that time, the first thing I wanted to do was to set the organization right, in terms of its structure, as well as processes, as this would set the pace for the many years to follow. Got it wrong, and I would have to live with that mistake for many years. What was clear to me at that time is that there were two very different components in IT: strategy, which is long term; and tactical and operational concerns, which is short-term. One cannot do without the other, and I was expected to address both, knowing in fact that I only had a very limited honeymoon period in my hands. I could not address long-term without fixing the operational issues first, and yet, strategy would always be in the back of my mind.

The other very apparent difference for me was that of managing operations vs. projects, and I wondered if what many companies were doing at that time was right: that of mixing resources to do both. So I did what I usually always do when unsure, which is to research to support some of my suspicions, and I came out relatively empty handed. Yes, I was already aware at that time of some of the industry standards, but these were high level and difficult to interpret, and, worst of all, I did not have any time to actually execute them. And so, I did the next thing I would usually do, which was to roll-up my sleeves, put on my thinking cap, and try to dissect and understand what really would make sense. This was the start of my practical experience that is reflected in this book.

The book starts with just that: discussing the ideal/suggested table of organization in an IT department, and the rationale of why I have reached such a conclusion. It separates distinctly strategy from day-to-day operations, as well as projects from operations, the two most important functions of a CIO. It goes on, discussing the most pressing need: that of managing operations in Chap. 4. This chapter is based on some of the best industry standards and their nomenclature in the field, with a difference: I try to explain exactly what each party is to do, and how it should be done at a very practical level. The theory exists out there, but how to make it practical is a different matter. For in operations, once the structure is correct, the next challenge is how to handle tickets (e.g. requests and incidences), which are the basic day-to-day of the operations team. This means how to record changes, escalate them, address them, test them, release them, and possibly roll them back if neces-sary. This brings us to the typical lifecycle for operations’ services: Planning & Design—Release—Maintain—Retire. Each of these phases has its own distinct aspects which should be monitored and managed, including availability and capacity management. Operations are also linked to IT strategy, and we discuss when this strategy translates to a project, or to operational changes, and if the former, how these project(s) link to operations.

Chapter 5 discusses projects, the other lifeline of IT, and in this chapter we make a marked distinction between the methodologies to be used in projects with that to be used in operations. It is not recommended to mix these, and as such discuss IT project management in detail. We first start with the basic project management principles, but zero in on the way these general principles are to be used in IT projects. IT projects are perhaps one of the most difficult projects to manage because they deal only with intangibles. Furthermore, the people that usually define the success of a project are the end-users which the CIO has no control of, but who must influence using some special people skills (so-called change management). We spend time discussing some of the most critical parts of IT projects: analysis, design, the cut-over period, the go-live and support phases. Each of these requires its own particular documentation and techniques. Included in this chapter is a discussion on some of the most failure prone components of a project: customizations, testing and people change management.

Documentation is discussed at length for both operations and projects, because adapting to the waterfall standard of project methodology, it is really the lifeline for IT to be sustainable, as well as projects transferable to operations.

What I also learned during my stint as CIO was that the cut-over from projects to operations was many times the most critical. People from these two distinct teams did not like to talk to one another, but is necessary for the sustainability of the service that has just been designed. Likewise I searched for material and found very little on this subject, so I decided to develop our own guidelines and procedures, these are shared in Chap. 6. Starting with a discussion on the typical different environments (development, testing, training, production), and then aspects which seem like common sense and are usually taken for granted, but are actually very much project-specific: backup and restore procedures, release management procedures, data migration, data quality, interfaces, and most importantly, roles and responsibilities of operations, project personnel and third parties during the go-live and support phase. We have come up with a checklist of tasks to be undertaken before the go-live to increase its probability of success, which have been refined throughout the years, the basis for this chapter.