IT project management: The standards of change

Reposted from the original article on ComputerWorld UK

IT projects are a vital element in the activities of the IT domain. For a project manager what standards are there to help organise their work and how do they relate to the other IT activities and standards?

The IT domain offers services related to the information used by the organisation. When we look at the internal working of the IT domain there are two important fields of operation. First ensuring the continued availability of services currently offered by IT and used by the business. Second building new services or changing current offerings to keep aligned with the ever changing requirements of the business. Creating new services or changing current services are often organised in the form of projects.

Wikipedia defines project management as “the discipline of planning, organising, securing and managing resources to bring about the successful completion of specific engineering project goals and objectives.”

Pure project management methods

When looking at the above definition for project management it is clear it is not just for IT Projects but applies to any type of project. The second observation is that the goals and objectives are a given in this definition.
When we look at project management an important organisation to start with is the Project Management Institute the Wikipedia page gives an overview of the PMI and their offerings. Note worthy are that the PMI offers certification and owns the Project Management Body of Knowledge (PMBOK). The PMBOK is a world-wide known and accepted standard for project management which offers a common language, structure and definitions for those using the standard. However PMBOK was created as a standard for any type of projects not specifically for IT Projects. As a result it can be challenging to decide what sections are applicable and how they should be used to structure IT projects.

Developed specifically for the management of IT projects is PRojects IN Controlled Environments (PRINCE 2). The Wikipedia page gives a good overview of prince 2. Furthermore the Office of Government Commerce (OGC) maintains the official website for the method. The official website also shows that OGC owns a number of related models such as ITIL (a best practice model to help organise the operational section of the IT Domain).

Since the deliverables of the projects are handed over to this part of the IT Domain alignment between these organisations (and the models used) is important. The strength of Prince 2 is that it offers a lot of help to internally structure IT Projects. Since the OGC is an institute from the British Government it is no surprise that Prince 2 is widely accepted and used in Europe. Even more so it is one of the leading project management methods worldwide.

Critics of Prince 2 say it is too much internally focused towards organising the internal project structure and does not offer enough focus on the interaction of the project with the “outside world” and “what comes next”. Prince 2 advocates counter that the method is OK but that it’s the way the method is used that does not pay enough attention to the outside world. Furthermore that ITIL and Prince 2 are developed, ran and maintained but the same (OGC) institute helps to ensure aligned between the two models which should help to facilitate the hand over from service creation into service production.

Other relevant models for project management

How to organize the interaction between the project (manager and team) and the environment? Depending on the size and nature, a project can have many different external stakeholders.
For a Project Manager stakeholder management is a very important skill. Stakeholder management is all about indentifying those who are affected or who can affect the project, understanding their needs and managing their interests. Unfortunately there is no generally accepted standard approach for stakeholder management. The above link to Wikipedia gives a general introduction and a starting point for those interested in the subject.

ITIL

We identified one stakeholder already: IT Operations, charged with the run and maintain of the deliverables of the IT project. For a project manager who does not like negative surprises at the end of his projects it is good to ensure a basic understanding of what drives this stakeholder. ITIL as one of the leading process frameworks for this stakeholder would help facilitate the relationship. Owned by the OGC (also owner of Prince2) the day to day management of the model is left to the IT Service Management Forum (itSMF).
The ITIL model is the leading process model for the operational management of IT Services. According to critics it is too much focussed on Infrastructure Management and does not pay enough attention to Application Management. With the introduction of ITIL version 3 the model also addresses topics regarding the strategy and design of Services but it still does not address the topic of Project Management.
An even more important stakeholder is the project owner. Somebody (usually in the business) has a requirement for a new or changed IT Service and, just as important, can make available the resources mentioned in the definition of project management. Mismanagement of this stakeholder is arguably the primary reason of IT Project failure. Clear and correct translation of the requirements from the project owner and limitations set by this stakeholder into workable project goals and objectives is a science if not an art in itself.
Business case creation and management is a field of expertise focused on structuring and improving the Project Owner/ Project Manager interaction. Especially with bigger longer running projects, circumstances change over time and the initial owner requirements might change during the course of the project. So Business Case management does not stop at business case creation, continued validation and updating of the business case is also part of this discipline. Since this is a relatively new area of attention there is currently no clearly leading method for Business Case Management. Prince 2 offers some assistance here. So does the ISACA framework for Business Technology Management (ValIT).

ValIT

ValIT uses an angle towards the relationship between the Project Owner and Project Manager different from pure Business Case Management. According to ValIT the relation between the business demand and IT Supply is not just one set of requirements for a new or changed services combined in a single project. The relationship consist of a portfolio of services the IT Domain offers towards (sections of) the business. Given the limited resources of the organisation Business and IT together have to decide how to ensure maximum business value from the IT Portfolio in an ever changing environment.
So not only different (change) projects are competing for the scarce resources but also the funding for the operational services is taken into consideration. The benefit of this approach is that it places the individual project into its contexts towards other IT-related investment categories and thus gives information about the “boundaries” for the project. On the other hand the project manager often has very little influence on the decisions made in the “grant scheme of things”.
Since the definition of Project Management also mentions “securing resources” a project manager should have an understanding of (IT) Portfolio Managementbecause this discipline is responsible for the allocation of resources to projects and other IT-investment categories. Besides the ISACA model already mentioned the OGC has models and methods addressing this field of attention:

• Management of Portfolios (MoP)
• The Portfolio, Programme, and Project Management Maturity Model (P3M3)
• Portfolio, Programme and Project Offices (P3O)

Programme management

Besides projects and portfolios we also recognise programmes. In practice one often finds that organisations call large, influential projects programmes. This would indicate that programme and project management are basically the same.
In theory however there is a clear difference between the two Wikipedia describes it as follows: “Project Management... It is sometimes conflated with programme management, however technically that is actually a higher level construction: a group of related and somehow interdependent engineering projects.”
Without further discussing the distinction between projects and programmes it is important to recognise these two are closely aligned. A Project Manager working in an environment where program management is established should ensure that he has a basic understand of programme management, specifically what the applicable definition in his environment is. The OGC offers a model for “Managing Successful Programmes” (MSP) furthermore the PMBok offers a lot of information about program management.
A special application of programme management techniques are the so called “organisational change programmes” these recognise that when you change one component of the (business) organisation this will impact other components as well. For example if you change a system this will most likely change the way is it is used (the business process) it will affects the users (People), etc.
A business change programme looks at all these different aspects that need to be addressed by as many different projects. These projects are clearly related and might have interdependences. From a manageability perspective however, the program is dissected into multiple better controllable and manageable projects.
The importance (and value) of IT for the correct operation of the business has grown over the decades. This also means that failed IT Projects can have an ever growing devastating effect on the organisation. As a result more and more stakeholders have a growing demand for control over IT Projects. The requirements for control might come from the higher management and/ or enterprise directors (IT Governance), internal or external rules and legislation (Compliance), demand for the management of security and/ or risk (Security and Risk). For the project manager all this translates into requirements to proof he is in control of the project and its inherent risk.
These requirements can differ greatly depending on the size and nature of the organisation and the individual project. These days you find that more and more organisations have an IT general control framework applicable to their IT Domain this framework would most likely also contain general controls for projects. Standards and frameworks used are (amongst others) the ISO 27000 standard for Information Security Management Systems, ISACA’s Cobit and RiskIT.
Part of the stakeholder management required from the Project Manager is to understand who the parties are that require control and what their requirements are. The control models target the complete IT Domain not just the IT Project organisation so choosing with standard(s) to adopt is often decided elsewhere in the organisation.

Organisational and process improvement models

Until now we have looked at the use of standards and the way they impact projects from the viewpoint of individual projects. However standards like CMMi from The Carnegie Mellon Software Engineering Institute (SEI) and Six Sigma (originally developed by Motorola) aim to organise the processes for the complete IT Project Organisation (the section of the IT domain responsible for all IT Projects combined).
These approaches basically try to learn from past mistakes and create and improve the organisation specific Project Management processes for time. For the individual project manager this means he can build on past experiences and does not have to re-invent the wheel for each specific project.
This article does not pretend to offer a complete overview of all models and standards that might be relevant to IT Project Management. Other organisations like ISO, the NIST (from the American Government) and Standards Australia have a wide variety of standards and frameworks which might help organise specific IT Project Management related topics.

It is important to realise: You need a screwdriver if you want to fix a screw but a hammer for a nail. Depending on the issue a nail or a screw will offer the better solution. Understanding the positioning, goals, strengths and weaknesses of individual models is the best way to decide which is most appropriate given the individual situation.

The primary trait required for Governance: Wisdom

Reposted, original on the site of Computerworld UK in August 2010

Wisdom, Solomon recognized its value in the bible. Lao-tzu describes its importance in the Te-tao Ching. But let’s face it: That was then. Wisdom is something for old people who can no-longer keep up with the pace of modern day live. It has no place in the everyday business of our fast moving society. Or does it?
Let’s start with Wikipedia: “Wisdom is a deep understanding and realizing of people, things, events or situations, resulting in the ability to choose....boring, boring, more boring.” No not what I was looking for, even I fall asleep on that one. Further down the page that’s it: “A standard philosophical definition says that wisdom consists of making the best use of knowledge.” Yes, that is what I was looking for. Have you ever noticed that in modern day life we got very good at acquiring knowledge? Understanding how to use that knowledge is a completely different ball-game.
People I talk to from my field of expertise who look at my LinkedIn profile tend to be impressed with my extensive knowledge of the different GRSC models. Having said that, everything is relative: Those not impressed with my level of knowledge (because they know even more) are mostly civil enough not to say so when we meet. Or, even worse, they find me such a dilettante that they do not want to speak with me to begin with. But that’s a different subject. I think I can claim a fair level of knowledge about the GRSC field of expertise. So how about the application of that knowledge? Very often I meet colleagues who just want to apply all they know: Let’s implement ITIL, CobiT or any of the models and/ or standards end-to-end. Without any consideration for the special circumstances of the individual organization their credo is: If the knowledge was important enough for me to acquire, it is important to use aka implement.
In other articles I have used the analogy with a builder: A builder has a tool-box containing all the tools he might need to complete the individual tasks. But no self respecting builder will expect to use all his tools for each task. Knowledge of models and frameworks are just the tools for consultants. If the goal of the task is only the implementation of the tool there is no way to measure if the knowledge was used wisely!
So much about wisdom on an individual level now let us look at wisdom on an organizational level. In the definition it says wisdom is about understanding how to apply knowledge (my slightly adjusted personal definition). It is not exclusively about applying your own knowledge. So for a manager wisdom is about understanding how to apply the knowledge of the entity he manages. The primary task of a manager is to manage: Acquire, combine and facilitate the scarce resources in the entity he manages so they meet the objectives of the entity in the most efficient way. To understand these statements consider the following: A manager who always has a lot of technical (content) ideas is a bad manager. To be able to get these ideas one of two things has to be happening: Either the manager spends his time thinking about content were he should be focussed on creating an environment that ensures maximum performance of his resources (people). Or even worse, he does facilitate his people so they come up with great ideas but then he “steals” them and presents them as his own. Everyday live is not this straight forward but still....
The best managers I know will tell their bosses about the great deliverables (and ideas) of their employees, ensuring the employee receives the credit for the idea. A great boss will give the credit for departmental performance and idea generation to the resources (aka people) it contains. The credit for the wisdom to make maximum use of the knowledge goes to the manager. This might even include the manager’s wisdom to use knowledge from outside his department.
We talked about knowledge and for now associated it with content: In this case knowledge of (expert) models but there is also the knowledge of form. We all know the “teckie” who knows everything there is to know about his field of expertise but there is no way to have a conversation with him because after three words you have no idea what he is talking about. On the other hand there is the “fast talking sales-rep”: Hear him speak and you “get” him. It is utterly clear that his solution is the only possible way forward until... You actually try to follow his suggestion and find he really did not have a clue of what he was talking about. Both had knowledge: The “teckie” knowledge of content the “sales rep” knowledge of form.
On this scale each individual has its own place. Some are better in transferring the message, making others understand even if they might not know the content of the message for a fact. Some people know the answer but are less able to convince others. Knowing where you stand and accepting your limitations is the first step. The next step is the decision to enhance on your weak spots or to accept them and seek a partner that will compensate, like the manager deciding to bring in outside knowledge to assist his department in achieving its objectives.
It is human nature to prefer the company of like minded people. However this might not actually be in your own best interest. A content oriented person might not like to cooperate with a form oriented person however it is here that we see most often that the sum is more than the total of its parts (the 1+1=3 rule).
With organizations it is just the same: People seek to work for organizations were the corporate culture fits their personality. A “black-box” IT department left on its own to do the “really smart stuff these guys do, though I have no idea what it is” attracts “teckie's”. That same “teckie” would most likely not feel at home on a fast-passed, yuppie populated, trading floor were a sharp tongue is a basic necessity to survive. The result is that the company or entity culture (and the kind of knowledge that goes with it) tends to re-enforce itself with the risk of creating serious blind-spots that get worse over time. If you look at the causes of the financial crisis this tendency has certainly played its part.
The governance function should keep oversight over the organization, knowing in which knowledge areas the organization is strong but more importantly were it is left wanting. Understanding the culture and how it is most like to develop over time. Including the consequences this developing culture has on the availability of knowledge and the way it is used by the organization. Finding the blind spots and correcting for them is a primary task of the governance function. Directors do not need the content knowledge to create ideas and generate deliverables. They do need the wisdom to understand how to acquire, combine and apply knowledge (balancing both form and content) so the organization can obtain its goals in an efficient manner.

Governance versus management

Reposted, original on the “IT Governance, the Kapteyn’s view” blog on Computerworld UK in March 2010

Amongst specialists you can find a heating debate over the use of the term governance, the difference between governance and management and how these two fields of expertise interact. Is this just a highly theoretical discussion between different areas of expertise engaged in a “turf war” or is there more to it?

On the one hand Governance is “sexy” and seems to have a high “hype” value. As a result everything seems to be about governance these days, SOA Governance, Security Governance, Architectural Governance. I even read about Data Governance recently. On further investigation most of the times I can find no difference with what used to be called management. It seems these days we govern instead of manage but still end up doing exactly the same thing. Management and Governance, they are just words so if we, as society, decide that what used to be called management now can also be called governance so be it, why should anybody care?

But there is also the other hand, governance already was a subject of interest and expertise before the name got “stolen” to cover everything under the sun. So what is the classical expertise we call governance? Is this just something for the self-proclaimed elite that used the term to distinguish themselves from those involved with “ordinary” management? If so it would be understandable that governance experts grind their teeth when they see they are thrown back into general population since everybody governs these days. However that would just be marketing at work: If you hold a position in a highly attractive market, competition is sure to try and enter. If you have no clearly distinctive offer compared to these new entries, sorry I hope you enjoyed it while it lasted. So this is basically a challenge to the governance expert, show the distinction in a manner clearly understood by your audience. After all it is the audience that is the ultimate judge and jury!

I recently became a member of the ISO JTC1 WG6. For most people that probably does not ring a bell so let me explain. ISO is the global organization that establishes and maintains standards on a variety of topics for instance the ISO 9000 (Quality management systems), ISO 27000 (Information security management systems), ISO 20000 (IT Service Management). One of the newer standards is the ISO 38500 Standard concerning Corporate Governance of IT. Within the ISO Organization the ISO JTC1 WG6 is the committee responsible for the maintenance and ongoing development of the ISO 38500 Standard. The standard interprets the term governance in the classical sense and as a result those involved with the maintenance and continued development of the standard can be categorized in general as governance experts in the classical sense.

As you can imagine the difference between (IT) Governance and (IT) Management is a topic of discussion. I had conversations about this subject with a variety of people (including Mark Toomey, prominent member of the ISO JTC1 WG6). This resulted in the following (personal) view. To manage and to govern are both verbs and the difference between them becomes clear if you start asking questions like who, why and what. Governing is done by (the board of) directors who steer operational managers towards the long term strategic goals by establishing guidelines, principles and direction. Managing is done by the managers who translate these long-term goals, guiding principles and general directions into tactical and operational tasks and targets for their subordinates. As mentioned this is my personal short interpretation. For more in debt “food for thought” I can recommend reading “Waltzing with the Elephant” from Mark Toomey. In this book Mark explores the need for organizations to effectively govern their use of information technology. Although I do not always agree with the author (sorry Mark) the book did help me organize my thoughts and further shape my opinion. Which, in the end, is highly aligned with the ideas described by Mark.

To bring the difference alive you might think of the Volvo Ocean Race. If you are unfamiliar with this event the Volvo Ocean Race is a race around the globe for sailing yachts. The race is divided in a number of legs each taking a number of days or even weeks to complete. The boats compete for each leg and between legs they have limited time to repair/ improve or otherwise change the boat, team, equipment, etc. before they start on the next leg. For the participating teams the race starts long before the starting signal for the first leg. Years in advance the campaign starts by finding the sponsors (and thus resources), designing, building and testing the boat, sails and other equipment. The boat captain is engaged and the team selected. Steering and directing all these activities to ensure there is a Yacht and team willing and able to meet the campaign goals (usually the goal is winning the race) can be seen as Campaign Governance. Once the leg starts the boat captain takes over, using the equipment, knowledge, experience and processes at his disposal he manages the boat towards the target set for the leg. In the course of this action he also needs to ensure he measures and captures performance and control data so the shore crew can identify opportunities for improvement. Once the boat finishes the leg, during the days until the start of the next leg, the governance body sets priority for the repairs, changes and improvements so the boat is best suited for the next leg. Based on the prior performance and changed conditions the tasks and targets for the next leg might need adjustment to ensure the best change to meet the overall goal (winning the race).

In this example the split between governance and management is suggested as preparation versus operation or on the water versus on shore activities. As a skeptic will immediately point out it is not as simple as that. For instance activities like training of the crew during preparation or actual boat building are not considered Governance activities. This is the source of the problem, though most experts will acknowledge there is a difference in the who, what, why and where for governance versus management the boarders are far from clear. The ISO 38500 Standards suggests that governance activities are performed by directors of the organization but also states that in smaller organizations the role of director might be combined with the (higher) management roles. This would mean that governance and management tasks, targets and activities would be performed by one and the same person and would be hard to distinguish in day-to-day practice. It is important to recognize the one cannot effectively exist without the other. For Governance rules and guidelines to be of practical use the management systems needs to translate them into the operational tasks and targets fit for day-to-day use. On the other hand any management systems needs the broad guidelines and direction to give it general aim and focus and set the boundaries for the system. So within the larger organizational design the Governance and Management systems are usually highly aligned and even integrated so the distinction between them can become hard to reckognize.

When I read my own prior articles in the blog “IT Governance: The Kapteyn’s view” (Repost note: All articles have been reposted on the blog: “Governance, Risk, Security and Compliance for the Information Domain”) I find that I as well cover topics that according to the theory are management topics even though the Blog name suggests Governance. So I find I myself am crossing the “boarder” just as easily. Still my justification is that the audience I write the blog for are those interested in Governance related topics. For those steering (governing) the IT domain it is important to have a basic understanding of the issues at management level as well.

This brings me to another question: Why would you want to maintain the distinction between governance and management? As we have seen these fields of expertise are so closely connected that it is often hard to recognize when we cross over from one to the other. When you take one step back however and look at the nature of those who govern versus those who manage there is in general a clear difference in the nature, issues, problems, interests, tasks and targets and sometimes even language of a director responsible for governing the organization and for instance a team manager responsible for setting and achieving operational team targets. Too often those who offer solutions for either field of expertise fail to recognize the distinction and approach their audience in a completely inappropriate manner. Undoubtedly I have made (and probably will make) this mistake from time to time. But then again I am a firm believer in the concept of continues improvement. To better oneself one must be willing to accept mistakes, as long as you learn from them and improve over time! For me the bottom-line would be: Know who your audience is and understand the difference in language, perspective and interests of the different audience groups you are addressing. To identify the different audience groups I find it useful to distinguish between Governance and Management.

Order from chaos

Reposted, original on the “IT Governance, the Kapteyn’s view” blog on Computerworld UK in March 2010

When you listen to organizational, process or governance experts or to IT architects for that matter, you hear statements like “We need to design the process”, “We need to implement control” or “We need to organize governance”. The common undertone is that they need to create order from chaos. An important deliverable to achieve this goal is formalization. In turn this implies that informal equals chaos. We describe how the organization, process and/ or control is supposed to work. And too often you will find that people think that if you commit something to paper that will make it so.

The more advanced students in change management know that the design of the target situation is only step one. Actually changing the organization so the day-to-day practices are aligned with the (paper) design is a whole different ball game. Indeed implementation of organizational changes is an expert discipline in itself. At one time I walked into an organization that supposedly had adopted ITIL a couple of years before. When I spend some time as a passive observer of the practices on the work floor it was all but impossible for me to recognize the ITIL best practices in their daily activities. So I checked with somebody who was clearly doing very useful things but in an organizational manner that was definitely not advocated by ITIL (I will leave it to your imagination to think of an example of what was happening). When I asked him about the ITIL adoption he recollected the project involving busloads of external consultants who kept themselves and everybody else busy for a while. But that project was finished a couple of years ago, they were now an ITIL based organization. When I asked him for the deliverables of the project he showed me a bookshelf and immediately I felt at home. Documentation with familiar process names like Incident Management, Change Management were nicely printed in color. Per process the documentation was at least 50 pages covering each and every possible detail of a possible ITIL implementation. And no, these were not the ITIL books! The documentation contained company logo’s every other page to proof they were company specific. Furthermore when I read the documents every now and then I could find references to the actual company culture and adjustments to fit the specific user organization. But by all means, not too much, this was a vanilla implementation of ITIL. What disturbed me though was the layer of dust covering the bookshelf and all of these pearls of wisdom they contained. When I decided to turn on the thumbscrews a little with my conversation partner he admitted that it could easily be that these documents had never left the bookshelf after the last project consultant put it there. This example shows you what is likely to happen if you forget to implement what you design. You probably think this is highly exaggerated to make a point. This extreme could not happen in real live, could it? The thing is, if you spend more than one and a half decade looking in company kitchens because you are asked to help them improve you get to see things, some of those hard to believe. Believe it or not, I hope the underpinning message is clear for you.

Having learned from this experience we improved the situation. Internal employees got involved with the design of the operational model, they got trained on the outcome became familiar with the documentation content and felt at ease with it. The project however not only had implementation as the primary driver. No, we wanted to integrate control into the operational model. So the CobiT books came on the table and after extensive discussion with stakeholders we decided what the relevant controls were and how they integrated into the process framework. Business-IT Alignment, control design and/or how we decided what the relevant controls were are not the topic of this article but it is fair to say that it was not as easy as this one sentence suggests. The point is that we decided, designed, agreed, described, implemented and all those other nice things we as consultants do. Furthermore we created our deliverables got them accepted by both management and those who should work with the deliverables we finished the project. And while the internal employees waived on the parking lot with tears in their eyes (It could happen could it not?) we drove into the sun-set feeling real good about ourselves. We delivered! The bookshelf was now a documentation room containing a company specific operating model integrating the best of both ITIL and CobiT, covering both process and control. The detail level approximated the level you would expect for an airplane maintenance manual. No aspect was left un-described! Since the success of an organizational consultancy project is supposedly described in the number of pages delivered by the project this project was a huge success: On average more than 150 pages of documentation per process, as mentioned, all discussed, accepted and implemented by the clients IT organization!

Fast-forward, a couple of months , the phone rang. The customer organization had a problem; they were failing control audits left and right. A lot of disagreement of what was done, how it should be done and overall complete inefficiency of the IT Department. On arrival the first observation was that the operational process/ control handbooks had somehow turned into law-books. The world had changed since the project had ended. However since the content of the handbooks had not magically adjusted to fit the new requirements the described operational model and organization were less than perfect for the new environment. Besides since the end of the project those on the work floor had found things that could be improved and even flaws in the designs. Till date I cannot understand how that is possible, external consultants make perfect assessments of the situation and design perfect solutions that are impossible to improve based on real live experience and that are 100% change and future proof, right? Maybe it was because I did not have as much experience then as I have today; that might be why I did not reach that level of perfection in the deliverables. Since those days however I got certified as the wizard of Oz so today…… Anyway, back to the story. IT management had suggested that there was this thing called continues improvement so maybe it was OK to improve the models based on experience and changes in the environment. This suggestion had been met with disbelieve by both audit and the business. After so much time had been spend designing the operational and control model to fit the business requirements they had found this offered an excellent measuring stick to measure actual performance of the IT department against desired performance. Trying to change the model was like trying to change the metric system, you don’t do that! The metric system offers one of a few constants in an ever changing world. Change it and people will lose their last life-line and drown. That agility had been replaced by bureaucracy in the process was initially overlooked. After much debate all involved eventually agreed that continues improvement was a good concept and that higher-level maturity thinking suggests that you pro-actively improve your processes over time to ensure alignment with an ever changing environment. Somebody even managed to argue that the organization was ISO 9000 certified and that one of the core ideas of this standard is that you try to improve quality over time by fine-tuning your operating model based on experience (a concept so out of this world that it can only work on the Starship Enterprise, according to some). Still at the end of all this debate there you have it, the goal of my new project: Create an organization that manages the operating model over time to ensure continues alignment with the ever changing environment and that is capable of learning and improving based on real-live experiences.

This brings us to the first point of this article: If you formally describe something not only do you need to ensure that it is implemented but also that it is actively managed and maintained during operational use. Things change over time, words on paper don’t! The second point for consideration is that the more you formally describe the more you have to manage. Management costs resources. Actively reading the formal description, managing suggestions for change, adjusting the system based on accepted changes, all of this is time and resource consuming. Think of 20+ processes documented with an average of 150 pages per process just reading all that stuff takes days. Managing something like that is not something you do in between, at least not if you take agility and continues improvement serious.

The reason to formally describe is to mitigate all kinds of risks. The risk of confusion because of differences in interpretation, the risk of inefficiency because lessons learned are not universally applied. Compliance Risks because the organization cannot proof they operate in a compliant manner. Business Continuity Risks because vital knowledge is not formally managed but informally kept in the minds of individual employees. Almost all of the negative (and positive) reasons for having an informal organization can be translated in the form of risks. The nice thing about risk is that once identified you normally think about the possible impacts (good or bad) for the organization. As we have seen there is a cost tag attached to formalization not just one time project cost to describe and implement but also continues running cost for operational management. The more detail you want the higher the cost! When we think in terms of risks and organizational risk appetite we can identify were we want to mitigate and how to balance cost of mitigation against the risk reduction achieved. Very often the end-result is that people realize that there is something to be said for a (more) informal organization and that informal is not always equivalent to chaos.

IT Governance and IT Service Management, are they the same?

Reposted, original on the “IT Governance, the Kapteyn’s view” blog on Computerworld UK in May 2009

These days when I look at the information on the internet it seems that the disciplines of IT governance and IT service management are considered to be one and the same. Tools that used to be promoted as IT service management tools suddenly became IT governance tools. ITIL, which I will always regard as "the best practice for it service management", is mentioned frequently these days as an IT governance model.  These examples lead me to the following question: Are IT governance and IT service management one and the same thing? If not, what is the distinction between them, were does one end and the other begin?

To get different opinions for this article I visited the home of the IT Service Management Community: itSMF. On the discussion forum I started a conversation with the title “The difference between IT Governance & IT Service Management”. This sparked a healthy debate which left me with a number of observations. First of all, there is a strong association between ITIL and IT service management on the one hand, and CobiT and IT governance on the other. Very often people do not make the distinction between the field of expertise and the models used by the experts. This might lead to the conclusion: If you know ITIL you are an IT service management expert; if you know CobiT you may call yourself an IT governance expert. Needless to say I do not agree with any such conclusion. Secondly, I recognized a number of the people who got involved with the discussion from my dealings with ISACA. –Members of ISACA and its integrated research think tank ITGI represent many of the leading IT governance experts. The fact that I am not the only person who frequently visits these websites leads me to believe that there are others who consider both expert fields to be closely connected, if not partially overlapping.

The consensus in the discussion, however, was that these fields are not the same. Especially when looking at the focus of IT governance versus service management there seems be a difference. Where IT governance is primarily concerned with facilitating (strategic) decision making, IT service management is more focused on operational excellence of the IT function. The ultimate goal of both disciplines, however, is to maximize the organizational value creation by achieving better business – IT alignment. This is where the clarity ends; when trying to establish the split between day-to-day tasks, targets, goals etc. of those involved in the field of IT governance versus those working in the field of IT service management, any attempt to make a clear split seems to end in differences of opinion.

So far a nice theoretical discussion. However, if I have an organizational issue in my IT function, how does the above help me to decide if I should get help from an IT governance expert or if I should involve an IT service management expert? Clearly it doesn’t. Even more so, I believe the question should not even be raised. If I have a problem with my car, I ask a mechanic to fix it. I do not have to choose between an engine expert or a brake expert. In parallel I would advocate the introduction of IT organizational experts who have a sound knowledge of both IT governance and IT service management. Having a mechanic who can work on brakes and engines alike does not indicate engines and brakes are the same thing. Similarly having an expert who has knowledge of both IT governance and IT service management does accept the difference between them. However it does also recognize that both are part of the same ‘car’. If the car does not drive according to its full potential I do not want an engine expert exclusively looking at the engine; the quick win might be to fix the brake that got stuck.