You think that this blog title is bad? Be thankful that I didn’t try something like: “There’s No Obit For COBIT.”
Anyways, today sees ISACA (an international professional association for IT Governance) release COBIT 5 – the latest version of its internationally recognized “Business Framework for the Governance and Management of Enterprise IT.”
“COBIT 5 builds and expands on COBIT 4.1 by integrating other major frameworks, standards and resources, including ISACA’s Val IT and Risk IT, ITIL (“the IT service management best practice framework”) and related standards from the International Organization for Standardization (ISO).”
“I remember when I lost my mind” … oops that’s Gnarls Barkley. I should have started with … I remember when software asset management (SAM) was on my radar as an IT service management (ITSM) practitioner. It was circa 2003, and my then employer was scared to death of the implications of non-compliance. We did some ground work but IMO it somewhat “died a death” when we realized that we had no idea where all the purchase records were – let’s assume they are all compliant now. Since then I have viewed SAM as just being on the to-do list for far too many organizations, never quite making it into the realms of actual “doing.” Sad but true.
Thankfully, however, my first three months at Forrester is changing this opinion – as 30% to 40% of my client inquiries relate to IT asset management (ITAM) and SAM (if you are interested the other 60% to 70% relate to ITIL adoption, process improvement, and ITSM tool selection – there’s a lot of tool replacement going on). SAM is rising from the ashes of its compliance era, in many ways this time “it’s all about the Benjamins.”
I say "finally" because most of the ideas for these documents were collected during the research Diego Lo Giudice and I did for Forrester's EA Forum 2010, nearly one year ago. If the ideas are quick to come, they sometimes take a long time to be realized in a document! I apologize to the customers who were waiting for the final document.
The goal of this collection of documents is to demonstrate typical EA involvement in IT governances — an area that is usually more or less "beyond" EA's scope. We also said in the EA Forum presentation that these potential involvements are not mandatory and highly depend on your particular EA objectives. EA involvement in IT governance should remain in line with the recommendation we made in Forrester report "Avoid The EA Governance Versus Agility Trap" and in which we still continue to believe: Governance is a lever to obtain nonshared (or even diverging) objectives. When objectives are shared, then governance is not required, and the approach should remain agile.
Mike Gilpin poses this question in the most recent post to his blog. This question was sparked at Forrester’s Business Process & Application Delivery Forum during a conversation during the session “Using The Next Generation PMO To Promote Innovation.” What’s interesting is that the question came from an attendee -- presumably aligned with their firm’s PMO -- who said that in their firm, strategic investment planning is led by their enterprise architecture team, which is responsible for the strategic planning and business architecture processes.
There are multiple ways to come up with the “best answer” to this question. Nigel Fenwick discusses the answer in terms of the CIO’s responsibility to own strategy development -- and the coordination of functions necessary to carry out strategy. I’d like to answer this from the perspective of “what does it take to have an effective strategic investment planning process?”, examining the value the EA function and the PMO can provide.
My colleague Craig Symons, who is Forrester’s expert on IT governance, defines effective governance as ensuring the best answers to these questions:
There has been a lot of negative press and commentary regarding the recent Queensland Health Implementation of Continuity Project (SAP HR and Payroll), which recently experienced a very public failure as many employees were not paid due to multiple points of failure in the project. The recent Auditor-General's Report on the process is damning, spreading the blame across multiple agencies and the systems integration partner, IBM. I make no claims to be familiar with the intricate details of the process, but I have read the report and feel I have a clear understanding of the (many!) points of failure.
While this project did seem to be a monumental failure, I would suggest that we consider two important facts: