Skip to main content
main-content

Über dieses Buch

There are two different, interdependent components of IT that are important to a CIO: strategy, which is long-term; and tactical and operational concerns, which are short-term. Based on this distinction and its repercussions, this book clearly separates strategy from day-to-day operations and projects from operations – the two most important functions of a CIO.

It starts by discussing the ideal organization of an IT department and the rationale behind it, and then goes on to debate the most pressing need – managing operations. It also explains some best industry standards and their practical implementation, and discusses project management, again highlighting the differences between the methodologies used in projects and those used in operations. A special chapter is devoted to the cutover of projects into operations, a critical aspect seldom discussed in detail. Other chapters touch on the management of IT portfolios, project governance, as well as agile project methodology, how it differs from the waterfall methodology, and when it is convenient to apply each.

Taking the fundamental principles of IT service management and best practices in project management, the book offers a single, seamless reference for IT managers and professionals. It is highly practical, explaining how to apply these principles based on the author’s extensive experience in industry.

Inhaltsverzeichnis

Frontmatter

Chapter 1. Introduction

When speaking of IT functions, two distinct ones that come to mind: the day-to-day Operations and Maintenance (what I will refer to as O&M), and Projects. O&M, as the name implies, deals with maintaining all of the IT services available, keeping things running, and dealing with the request for changes that are raised by the different users of the IT systems, whether these are purely internal and within the company organization, or external customers. Projects, as implied by the name, refer to new deployments of IT services in the form of systems, applications, and infrastructure. A CIO is expected to handle both, and to know a bit of everything: software, processes, user change management, servers, networking, programming, etc., and he is also expected to know how to handle operations, and handle projects.
Francisco Castillo

Chapter 2. IT Areas and Functions

In this chapter we touch on some very basic aspects that are at the heart of all IT organizations. First, the difference between operations and projects, in terms of the way they operate and the methodologies they use. We look at the roles that typical IT personnel (according to position) would play for both projects and operations, and make a clear distinction on when they should have a role, and when they should not. Next we touch on how strategy differs from operations, not only at the conceptual level, but what this actually means in the day-to-day. As such, we address a common pitfall many organizations succumb to, that of mixing strategy with operations, and that of mixing roles and responsibilities of projects with operations, this sets the groundwork for the discussion on what could be an optimal table of organization for the next chapter. We then touch on the three basic components of all IT operations and projects: systems, processes, and people, define each, as these will be encountered over and over again in all the chapters, in different forms.
Francisco Castillo

Chapter 3. Organization and Human Resources

Parting from the introduction of concepts in Chap. 2, we delve into what is probably the most crucial decision a CIO and IT Manager must make when setting-up his organization: defining the optimal structure. This is crucial as it is the basic underlying layer for all IT processes henceforth, and is usually very difficult to change in the middle of the game. The basic precept in this chapter is that operations and projects have different methodologies, and objectives altogether so that they must in fact be separated and handled by two different teams with totally different techniques. In getting to that conclusion, we first do a review of what a functional organization typically looks like, how a project organization typically would look like, and since most IT organizations conduct both operations and projects, what the combined structure would look like. We then identify the lead personnel positions in this structure based on their intended roles and responsibilities.
Francisco Castillo

Chapter 4. Managing Operations

Operations is the heart of IT as it is the first thing that needs to be addressed: keeping the existing infrastructure and systems running seamlessly to support the business. This chapter first centers on the discussion of Information Technology Service Management (ITSM) which defines the standards, roles and responsibilities of the different IT Operation and Maintenance (O&M) personnel including the Service Desk, Technical Management team, Application Management team, IT Operations Management team, Field Support team, as well as the different heads in this organization which includes the Operations Head and the related Operations Management Office, the Information Systems (IS) Head, IT Infrastructure (II) Head. After defining the different O&M personnel, we delve into the operations lifecycle: planning and design phase, release phase, maintenance phase, and retirement phase. Each of these phases has distinct aspects that need to be taken into account, and repeat in a cycle. Concepts for each phase are discussed including the different type of tickets: incidence, request and problem, how they should be defined, treated and escalated, and how these roll-up to the Service Level Agreement (SLA) that O&M commits to the rest of the organization. Releases are most important to be done correctly, and this brings us to the topic of Configuration Items and CMDB and testing. Under the maintenance phase, requests and incidences need to be addressed, as well as long-term aspects such as availability and capacity management, security and business continuity. The retirement phase is briefly discussed. O&M does not stop there, it also has a link to IT Strategy, and this is discussed in its own section, as well as how to incorporate Continual Service Improvement by means of the PDCA.
Francisco Castillo

Chapter 5. Managing Projects

Project Management is the second most important consideration in an IT organization after running the day-to-day operations. Project management is quite a developed technique in other industries, the same can be applied for IT projects, but one particularity stands out, that in IT, all deliverables are mainly intangible. For this reason, scope management is of primary importance in order to properly manage an IT project, which includes full documentation in the many phases the project goes through: scope preparation, technical and functional design, blue printing, definition of business process, and later on cutover preparation, testing, training, and managing change within the project. Projects also have several dimensions: scope, time, cost, and quality, and it is these factors that the Project Manager needs to handle in order for the project not to run amok. Scope and time management techniques should be used in conjunction with regular monitoring and control procedures, including regular evaluation of risks. Again fundamental to the monitoring and control is the use of standardized tools which help in such an endeavor: computer-based tools for project tracking, an issue registry, a request registry, and the use of a project checklist which clearly delineates all major deliverables of the project. Essential for the learning organization is the knowledge management aspect of a project, which ensures that issues encountered during the project are properly documented and stored in a Document Management System that allows for easy search and retrieval. Lastly, the most difficult aspect to be managed in a project is people, and this is where communication management and people change management come into play. This is both a science and an art that is developed and refined from experience, and we give some guidelines and examples of how they can be addressed.
Francisco Castillo

Chapter 6. Cut-Over into Operations

Cut-over here refers to the transition of a project into operations. Not much has been written about this very critical phase, which usually causes a lot of disruption to the business. It is a difficult phase because it is when normally two distinct and disjoint teams have to work together in transferring an asset from one to the other (project into operations). The first and foremost premise for a smooth cut-over is to involve operations in aspects which they will later on be in charge of maintaining: technical architecture, functional design, and its maintenance, as well as tasks in which they themselves will be involved in during the project itself such as developing interfaces or data migration. It is also important for operations to have a full understanding on the grand vision of the application itself early on, and to understand the details (process, code, and permissions) as the go-live date nears. From the point of view of the project team, several aspects particular to cut-over need to be addressed. First, is the awareness of the users to the upcoming go-live, which may significantly affect the manner in which they work. Other important aspects that need to be coordinated early on with Operations are their particular guidelines, the environments that will be used (DEV,QA) and who will be responsible for releases in/from each, backup and restore procedures, security, as well as escalation procedures. Data migration and data quality are interrelated and depending on the project, may carry a heavy amount of work that need not be belittled, and should be thought of early during the project. Data quality cannot be usually decided upon by neither the project nor the operations team and is the realm of the end users; it is only they that have the capability to validate the data, and therefore, is their responsibility to clean it, which should be done in preparation for the data migration and go-live. A related aspect is that upon going live, some data may not or cannot be migrated and should be manually recreated into the new system, this again requires end-user participation and should be managed early during the project. Lastly, success of the project upon going live depends greatly as well on the ability to resolve incidences as they are being reported by the end users. Crucial to this success is a clear delineation of who is to conduct 1st, 2nd, and even 3rd level support, as well as the escalation procedure process.
Francisco Castillo

Chapter 7. Project Governance

IT Operations governance is mainly defined in the IT operations policy that is regularly managed and updated by IT’s O&M. Project governance however is related to both IT governance and company governance, and defines the control and authority given to the members of each project, and defines the manner and processes in which they are to conform to, usually as defined by the portfolio manager. Both IT operations and project governance are guided by the overall corporate governance and at the policy level, may be captured by ISO20000, ISO9001, and ISO27000 certifications, but these need to be translated to the work instructions that operationalize them. Essential to project governance are how a project is created, the roles and responsibilities of the different project members and how the project is to be monitored and controlled. Risk, communication, and release management are aspects of the project which also need to be defined at the operational level, in terms of how it needs to be conducted. Release management is especially important as usually the project environment being used is also shared with operations, so that roles and responsibilities need to be clear in order to avoid conflicts in the release of configuration items. Other aspects of project governance which usually have to be in sync with operations are code development guidelines, test, training, backup and recovery, security, and service desk usage guidelines. Lastly, due to the changing nature of the project’s requirements, request for infrastructure and scope (change requests) are normal. A clear method for requesting additional infrastructure must be set, as well as the method and approval process for change requests.
Francisco Castillo

Chapter 8. Agile-Scrum Project Management

There has been a lot of interest in agile-scrum project methodologies of late, especially due to the explosion of Apps in the mobile space. In this chapter, we do not attempt to explain how to use agile-scrum in detail, but rather differentiate it from the traditional Waterfall project management methodology so as to understand when each is applicable. After looking at the differences between the two project management methodologies, we discuss briefly the agile-scrum principles of how it works including the concept of stories, product backlog, sprints, the roles of the different team members: scrum master, product owner, developers, as well as, techniques used in measuring the progress of the project: burn-down chart, story points, and velocity. The last part of the chapter analyzes how Waterfall methodology, with a fixed scope and quality, defers from Agile methodology, with a fixed time and cost, and how this defines the type of projects that can be developed using each methodology.
Francisco Castillo

Chapter 9. IT Portfolio Management

A portfolio sits above Operations and Projects in an IT organization. It encompasses all IT operations and projects that are being undertaken by the IT organization in a concerted and coordinated fashion. In order to do so effectively however a methodology must be in place. As such, we introduce the basic lifecycle of a portfolio: portfolio planning and design, assessment and communication, and rebalancing. On top of this lifecycle sits portfolio governance as well as monitoring and control. Each is discussed separately in detail. Portfolio planning and design refers to the process creating and defining a portfolio and its different components. It must be pointed out, that the ultimate portfolio manager in an IT organization is the CIO, and it is she that concerts the creation of the portfolio components, assigns resources and assets, and is ultimately responsible for them and their design. Portfolio components may also have interdependencies between them (projects leading to other projects), so that these may also be managed using Project Management Software tools. Portfolio assessment and communicating phase refers to the manner in which the portfolio components will be measured for relevance in an organization. Traditional measures used such as IRR, NPV, etc., work for more tangible projects and portfolios, however for IT, it is hard to come up with such measures, such that it is really intangibles that become part of their assessment. A technique on how to “measure” these intangibles is illustrated by means of causal relationship to company objectives. Lastly, it is important that these measurements be communicated to the different stakeholders on a regular basis for them to understand the progress. Portfolio rebalancing refers to the reprioritization of components and reassignment of their resources, definition of new, and termination of existing portfolio components due to the ever-changing strategy and priorities and of the organization which defines in turn what IT components should be prioritized. Sitting on top of all this is portfolio governance, which regulates the type of documentation that must be completed for each component, regularity, as well as the required management guidelines: releases, change requests, additional funding, and risk registry. Portfolio Monitoring and Control are the regular activities defined by the portfolio manager so as to be able to monitor and ensure that the portfolio components and are running smoothly, including their alignment to company strategy, timeliness, within budget, as well as being able to deliver their intended benefits. It also discusses the different venues and tools used for monitoring and control, as well as the use of PDCA to continually improve this process.
Francisco Castillo

Chapter 10. Appendix A: Sample Terms of Reference (TOR)

VM (Virtual Machine) Backup Solution
This appendix shows a practical Terms of Reference which may be used as a framework for tendering IT projects.
Francisco Castillo

Backmatter

Weitere Informationen

Premium Partner

BranchenIndex Online

Die B2B-Firmensuche für Industrie und Wirtschaft: Kostenfrei in Firmenprofilen nach Lieferanten, Herstellern, Dienstleistern und Händlern recherchieren.

Whitepaper

- ANZEIGE -

Best Practices für die Mitarbeiter-Partizipation in der Produktentwicklung

Unternehmen haben das Innovationspotenzial der eigenen Mitarbeiter auch außerhalb der F&E-Abteilung erkannt. Viele Initiativen zur Partizipation scheitern in der Praxis jedoch häufig. Lesen Sie hier  - basierend auf einer qualitativ-explorativen Expertenstudie - mehr über die wesentlichen Problemfelder der mitarbeiterzentrierten Produktentwicklung und profitieren Sie von konkreten Handlungsempfehlungen aus der Praxis.
Jetzt gratis downloaden!

Bildnachweise