IM/IT Lifecycle – Co-opting COBIT

In early March, I introduced the Information Management/Technology (IM/IT) Lifecycle Model. Since then I have had a few comments including the question, but isn’t this simply COBIT (or ITIL or other frameworks)? In short, mostly but not entirely.

Before getting to the comparison, for those not familiar with COBIT, the following is the summary definition from the COBIT 5 Executive Summary:

Simply stated, COBIT 5 helps enterprises create optimal value from IT by maintaining a balance between realising benefits and optimising risk levels and resource use.

COBIT 5 enables information and related technology to be governed and managed in a holistic manner for the entire enterprise, taking in the full end-to-end business and functional areas of responsibility, considering the IT-related interests of internal and external stakeholders.

The COBIT 5 principles and enablers are generic and useful for enterprises of all sizes, whether commercial, not-for-profit or in the public sector.

Huh? Actually the definition is not too bad but it is also probably clearer if one goes back to COBIT 4.1. That version had a process model subdividing IT into four domains: 1. Plan and Organize, 2. Acquire and Implement, 3. Deliver and Support, and 4. Monitor and Evaluate. These four domains roughly map to:

IM/IT Lifecycle Steps COBIT 4.1 – Domain
 00.Governance  IT Governance Focus Areas
01. Business Need
02. Budget Review & Approval
 1. Plan and Organize
03. Project Management 2. Acquire and Implement 
10. System Business Operation
13. IM/IT Fleet and Resource Management
3. Deliver and Support
15. Business Need and Salvage
16. End of Life, Version Update, Change in Standards
 4. Monitor and Evaluate 
06. Invoice
09. Project Costs
07. Supplier Inventory, Construction, etc.
11. Recognized & Cost adjustments
12. Depreciation
14. De-Recognition
 Not directly included

The IM/IT Lifecycle Model includes COBIT but is more comprehensive. I believe that the model presents a more logical progression for the business manager to see the flow of events and their roles within. Finally, COBIT infers the accounting functions but does not draw them out specifically. By contrast, the IM/IT Lifecycle Model encourages the business manager, CFO or IT Manager can see the inter-relationships between the operations of IT and the corporate ERP systems that support its operations. 

Finally, this is not an either or discussion either.  I hope to be drawing on COBIT (and other frameworks) as the basis for my deep dives into some of the Steps of the model.  In the meantime, hopefully it is a means by which organizations can see at a glance how their IM/IT investments are fairing. 

Information Management/ Techology Lifecycle Model (revised March 1 2014)

Information Management/ Techology Lifecycle Model (revised March 1 2014)

IM/IT Inventory – Mapping Example

The previous blog introduced the IM/IT Inventory. In this blog, I am going to take my first stab at how the applications are potentially mapped to the Inventory as indicated in the diagram below.

IM/IT Inventory-Model with sample mappings

IM/IT Inventory-Model with sample mappings

At the bottom-left are the applications that are the most general purpose and easy for the user to make configuration changes to. A great example are the office productivity suites such as Microsoft Office. Diametrically opposed are Bespoke Applications that an organization has purposed built. The application in this case may exists only in the organization and may or may not have been written in either a language or manner making system changes easy.

The red box overlaying the model is what I would suggest be included in an IM/IT Inventory. The green braces is the grey zone discussed in the previous blog, whether to include or not these ‘applications’.

Personally, I have built a number of applications that fall into this grey zone. Typically budget and reporting systems, they were fairly sophisticated tools that provided unique organizational value. In future blogs, I hope to drill down a bit more on this area and ask how to measure, report and more importantly – what to do with the information coming from an IM/IT Inventory. As always send me your comments.

 

Inventorying IM/IT in the Grey Zone

Question #2 of the SWOT+4 IM/IT Planning Model asks: ORGANIZATIONAL IM/IT: How can/does/should Information Management/Technology (IM/IT) support or impede what is important to the organization; does the organization have the right IM/IT and if not, when will it get it?

Although there is a lot stuffed into this question, in this blog I want to focus on a small but important part of Question #2, what do you currently have for IM/IT resources?  If you have read my prior blog, you will note that this is an area managed by Step 13: IM/IT Fleet and Resoure Management of the IM/IT Lifecycle Model.

Before dashing off and building new IM/IT resources, should organizations not know what they have in the cupboard to start? Over the past twenty years, I have been amazed at how hard this question is to answer. So, to find the answer, let us define the problem, “what exactly are we counting when we inventory the systems”?

Does the organization count its office productivity software (e.g. Microsoft Office)? If so, how many times should it count it? Once for the organization, once per user or once per every file created? Is a memorandum written in a Microsoft Word file an IM/IT resource that should be inventoried as a resource?

Likely most people would tend to say no to a Word file. Okay, how about a Word Mail merge file that supports an organization’s marketing effort? Perhaps this file has had thousands of dollars of custom Visual Basic scripts developed for it and links and performs unique functions within the organization. Would this Word file now count as an IM/IT resource? This mission critical ‘application’ is now entering the “grey zone”.

The grey zone is when IM/IT resources go from a commodity (e.g. Microsoft Office) to an operational, tactical or strategic resource for the organization. In developing an inventory of applications, the following graphic is my current thinking about what to count, including what I would see as the grey zone.

The Two Dimensions to Measure Which IM/IT Resources Should be Inventoried.

The Two Dimensions to Measure Which IM/IT Resources Should be Inventoried.

The horizontal axis asks the question, what knowledge is necessary to make changes to the application? As you move left to right, there is increasing technical knowledge needed to make a system change. The vertical axis asks the question, is this a purpose built application or one that was created specifically for the organization? Applications at the top are purpose built; those at the bottom are common to any organization or user.

This blog is a teaser and in the next one, I will overlay applications your organization may have lying about on top of the model. Let me know your thoughts, do I have the right measures or are there more than two dimensions that should be measured?

IM/IT Lifecycle – Re-Do

Thank you to those who provided comments on my previous IM/IT Lifecycle Model.  Your collective whacks on the side of my digital head identified a number of areas of improvement.  Thus, this is a Re-Do blog with what I think is a much better model.  Thanks again for your comments!

The previous blog introduced the SWOT+4 Planning Model. The value of the model is the ability to focus on specific elements of IM/IT planning. Once an organization is successful with one part of the model, it can move on to other areas needing improvement. This blog will introduce a tool to evaluate the robustness of an organization’s IM/IT lifecycle. Intended to be an introduction, future blogs will drill down further.

The Role the IM/IT Lifecycle Model plays in the SWOT+4 Model
The Role the IM/IT Lifecycle Model plays in the SWOT+4 Model

One of the first areas of model to evaluate is internally focused on the IM/IT needs and capabilities of the organization. In the SWOT+4 model these are represented by the organization’s IM/IT strengths and weaknesses and specifically questions 2 and 3:

  • Q2. ORGANIZATIONAL IM/IT: How can/does/should IM/IT support or impede what is important to the organization; does the organization have the right IM/IT and if not, when will it get it? (Answered by IM/IT Lifecycle Steps 01 through 16)
  • Q3. IM/IT CAPACITY: How well does the organization DO IM/IT, is it getting better, worse or about the same? (Answered by IM/IT Lifecycle Step 00)

Context for the IM/IT Lifecycle Model

The IM/IT Lifecycle Model is an adaptation of the Asset Lifecycle Model. While the Asset Lifecycle Model focuses on the management of tangible assets, the IM/IT variation is concerned with the acquisition of things like computers and technology systems. The governance, system and audit functions at the bottom of the model answer questions #3, what is an organization’s IM/IT capacity? All the other steps answer question #2, what are the organization’s IM/IT needs and are (or when/how will) these needs to be fulfilled or they support the accounting and reporting functions.

Information Management/ Techology Lifecycle Model (revised March 1 2014)

Information Management/ Techology Lifecycle Model (revised March 1 2014)

IM/IT resources move through the model from left to right and may use more or less of each step depending upon the nature of the IM/IT system. In theory the model applies equally well to both technology (infrastructure, applications) as to information itself (data, reporting, data standards, etc.).

Two steps of note are Step 03 and 13. Step 03, the Project Management Office (PMO) replaces the requirements specification in the Asset Lifecycle Model but is broader and ideally encompasses other steps. For example, a good PMO methodology incorporates procurement processes such as issuing requests for proposals (Step 04), managing resulting vendor contracts (Step 05) and managing the vendor provision of assets, software, licenses or consulting services (Step 07).

Step 13 replaces the asset management function in the Asset Lifecycle Model. It includes in or outsourced functions such as application maintenance or technology production management. In an ideal world, these processes and systems drive the accounting of IM/IT. For example, an application built, capitalized but then abandoned is identified in this Step and communicated to the accounting system for de-recognition or conversely adjustments to the amortization schedule. Step 13 also straddles the central corporate IT and business area functions as it should be a partnership between the two.

Direct Attribute Costs (Step 09) and System Business Operations (Step 10) are purposely overlapped. Direct Attribute costs are the resources the organization brings to bear to implement a system. Examples can include the dedicated project staffing or costs to retrofit a data centre to accommodate new servers supporting an application. System Business Operations by contrast are the costs and effort to commission the system and bring it online. From an organizational perspective, Step 10 asks (and answers) the question, does the IM/IT resource meet the business needs identified for the asset?

Enterprise Resource Planning and the IM/IT Lifecycle

Included in each step are possible metrics as well as the information system such as the organization’s Enterprise Resource Planning (ERP) tool or Information Technology System that may support the step. For brevity, the following ERP components are used:

  • (1. Budgeting): the planning, monitoring and resource allocation functions.
  • (2. Procure to Pay): from requisition to payment including the treasury management functions.
  • (3. Asset management): the receipt, installation, maintenance, tracking and disposal of assets.
  • (4. Accounting to Reporting): the proper accounting, record keeping and reporting (internal and external) of assets.
  • (5. IT Infrastructure Management): the creation, maintenance of servers, networks, security systems, desktop access, operating systems and all components necessary to run one or more applications.
  • (6. Application Maintenance): the maintenance, support, bug/fix, user training, system administration and other functions necessary to maintain one or more applications that support a business process or function.

The purpose of this blog was to introduce the IM/IT Lifecycle Framework and place it in context to the SWOT+4 Model. In future blogs, I plan to drill down on each of the Steps and provide examples of systems, standards and best practices across organizations.

What do you think? Does your organization use a systematic method such as the IM/IT Lifecycle to plan, implement and manage your IM/IT investments? Where do your systems potentially lie within the model? For example, does your organization have a systematic PMO function or do you even know what is in your application fleet? Drop me a note and send me a comment with your perspectives.