Search

Thursday, August 26, 2010

Aligning information supply and demand

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

Business - IT alignment, when you read the articles written on the subject it turns out most of the time they focus on alignment between business and IT on a strategic level. But alignment between the two on tactical and operational level is just as important. So how about the Information Supply and demand relationship?

For some reason when we talk about IT we all seem to focus on the T of technology instead of the I of information. But at the end of the day what the IT-domain delivers to the business is information. One of my business customers translated it real nice (though very blunt): “Don’t talk about your technology-gizmo’s those are your (IT department) toys. For me to run my business I need you to deliver the agreed information according to the required specifications”. So Information not technology is of interest to this business executive. When we look at the quote a bit further we see the business (executive) demands information and wants the IT-domain to supply it (according to specifications). So there you go: The Information Supply and Demand relationship.

The first thing to realize is that the demand side of this relationship is not situated in the IT-domain but in the business domain. Here we find the first challenge. In the earlier posting on the Blog called “Business-IT alignment, a bad term (part one)” I already wrote “I have never seen an organizational chart were there was one organizational entity marked ‘business’ as opposed to an entity called ‘IT’.” Basically: THE business does not exist, in most organizations it is a complex set of departments with different information needs from each department. The article concludes the time of the one size fits all IT-approach is over for most organizations. The IT-domain should start looking at its core product (information services) with a marketing approach: What is the market? What are the market segments? Who wants what product (in this case information)? What are the required specifications for the product (think in terms of confidentiality, integrity, availability, etc.)?

If you made it this far reading this article and are still interested I would like you to think a moment about the current status in your organization. Are you confident that the demand side of clearly segmented? The information needs are identified per segment? Are the requirements for each Information type clearly defined? If you can confidently answer with yes, congratulations you are among the happy few! If the answer is no it is important to realize alignment goes both ways: If there is misalignment it might just as well be that the demand side of the Information relationship is chaos. Before a business manager starts complaining that “the IT department does not understand his needs” he might take a moment to see if he himself understands his needs and has clearly articulated them.

If you find the status of your IT-demand organization has room for improvement were should you start to improve the situation? Well the first step would be to identify the information-market segments. As most organizational models and experts will tell you information is one of the core production resources. Operational production is organized (formally or informally) in business processes. So if you want to know your (segmented) information requirements start looking at the business processes. For each of the steps of these processes you should be able to identify what information is needed to efficiently complete the step and what the secondary requirements for that information are (in terms of confidentiality, integrity and availability). When the basic structure for your information demand is clear you could think about building an Information demand organization. This helps to ensure a more structured approach towards information demand both on an operational, tactical and a strategic level. If you want to know how such an organization could be created, have a look at the BiSL model. Available from the ASL BiSL foundation, this is one of the few models that I am aware of focused on the information demand organization. The fact that the BiSL is in the public domain makes it easy to use it as a starting point.

All this on the IT Governance Blog, what is the connection? First of all some definitions (as I use them) to ensure common language, I have learned use of different definitions is the most common source of misunderstanding. The IT Domain is the organizational entity responsible for the Information supply side of the relationship. It includes the internal IT Department and any third-party suppliers involved in the creation of the Information Services. This is basically the complete IT supply chain. Information (demand) management is the management on the demand side of the relationship. As such it is very closely related, if not part of, the business (processes). There is confusion on this topic in real life; I also see definitions were Information Management is accountable for the complete Information supply and demand relationship, not just the demand side. Though this might seem as a slight (semantic) difference it is important for the mandate of the Information Manager: Does he just have authority for the business (supply) side of the relationship or is he also in charge of the IT (supply) domain? I hope you appreciate that makes for a substantial difference. As long as everybody agrees on one or the other in your organization both can work depending on your organizational structure.

I am a member of the ISO JTC1 WG6 Committee which is responsible for the maintenance and the continued development of the ISO 38500 standard on corporate governance of IT. One of the discussions I have with other committee members is about the scope of this standard: What does the standard govern? Though I personally find the statement could be articulated clearer, the consensus in the committee is that the standard concerns itself with the Governance of the Information Supply and Demand Relationship. So both sides supply AND demand, not just the IT Domain but Information (demand) management as well. Since (as we noticed earlier) most of the time information demand management is organized in the business domain this immediately goes to show that IT Governance is not just for the IT domain but business executives should be involved as well. But then again I am not the only one that is trying to get that message across. To reduce the confusion it might be better to start talking about Information Governance (or corporate governance of Information). But then again I guess that would just add to the confusion instead of reducing it, so better not introduce a new term.

This brings me to the next observation, within the C-suite the logical primary contact for issues concerning IT governance is the Chief Information Officer (CIO) this makes him responsible for the complete information supply and demand relationship, not just the IT Domain. So the role of CIO is not equal to the role of head of IT even though both roles are often combined in one function. When you look at the mandate of many CIO’s these days you will find that they are actually head of the IT department, not CIO (according to this definition). But what’s in a name? One last observation, do you ever look at publications (print, internet or otherwise) directed at CIO’s? Have ever noticed how 90% of the content of these publications is basically about Technology and almost none of it is focused on Information? Talk about misalignment, I guess information is just not “sexy” enough!

Hail the almighty business case.

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

These days if you want to gain access to investment funds you better be able to create a good business case. The marvels of the business case are many. Opportunities are quantified while all (relevant) aspects are captured in a structured manner. This means we can easily compare and prioritize, etc. etc. How did we survive before the invention of the business case? Or are there possible down-sides to this powerful tool?

First of all let me stress that I think the business case is a very potent and powerful tool. The whole concept of project and program portfolio management would be very hard to implement without a tool to ensure you can compare like-for-like. Furthermore the use of business cases ensures that people with “a brilliant idea” sit back and reflect for a moment and are forced to look at their idea from different perspectives (financial, economical, risk, strategic, etc.) before they start wasting other peoples time pushing clearly flawed ideas. But as with most tools in live that which can bring good can also be used for evil. The value of quantification has its limits. To proof a point the following example. If statistics is not your strongest point please bare with me, you will probably be amazed at the conclusions achieved. If you do not believe me when I say that everything in the example is statistically and mathematically sound ask an expert to verify. Of course there is a catch which I promise to explain at the end of the article. Here goes:

In a Casino one of the games is roulette. As part of roulette you can make a bet whether the next number will be red or green. Since there are just as many red numbers as green numbers on the roulette wheel changes are exactly 50% that either red or green comes up. The exclusion is the number zero which is black. However in some casinos, if zero comes up bets on green and red “ride” this means no loss and no gains and the bet stays on the table for the next round of the roulette wheel. As a result, for the purpose of this Business Case there is no influence from having the number zero.

I know of a system to play roulettes which will give you an incredible Return on Investment (we are talking double digit percentages) at a given (known) investment with a negligible risk of loss. Interested? You start playing by betting your base amount (let’s say 5 Euro) on either red or green. If the bet wins you won 5 euro and the cycle ends. You start a new cycle. The change of winning is 50%. If you lose you double your bet in the next round so now you bet 10 euro. If you win in the second round you have won 10 euro but since you lost 5 euro on the first round your net winning is (again) 5 euro. Winning concludes the cycle. You start again with a new cycle by betting 5 euro. The change you lose two times in a row, however, is 0,5 (50%) x 0,5 (50%) = 0,25 (25%). This is a basic mathematical law of change. Still there is a good chance you lose two times in a row, if so again you double your bet for the next round (so this time to 20 euro’s). If you win in the third turn your net gain is 5 euro (20 – 10 – 5 = 5). The changes of losing three times in a row 0,125 (12,5%) = 0,5x0,5x0,5. I hope you get the picture: You keep doubling your bet when you lose until you win at which point you always have a net return of 5 euro. The system only has one risk and that is that you run out of money and cannot double your bet anymore. In that case you will not be able to recover your previous losses and basically you will be bankrupted. But we saw that we can calculate the changes of a series of consecutive losses and that the change is getting smaller and smaller (1 round 50%, 2 consecutive losses 25%, 3x 12,5% etc.). So by ensuring we have enough capital available we can mitigate the risk to an acceptable level. The change (for instance) that you lose 17 times in a row (the residual risk factor) is 0,001% which I will hold is negligible small (especially if you compare it to the risks on the stock market). So if you ensure you have enough investment capital to keep doubling your bet 17 times you can accept the residual risk. We can calculate that your investment capital needs to be euro 655.355. With this capital you will make a return of 5 euro per cycle (ROI: 0,0008% per cycle). Is that all? That is not very impressive. Not yet! If we assume that it takes 2 minutes to play a round on the roulette table (place the bet, roll the ball, collect the losses and pay the winner) we can calculate the average time it takes to play a cycle. Rules of change tell you that on average a winning cycle (the number of times it takes before you win the 5 euro’s and start over) contains 2 rounds. So you will be able to play an average of 15 cycles per hour winning 5 euro each cycle that means you win 75 euro per hour. If we than assume you play 8 hours per day, 200 days per year you will have won 120.005 euro per year. This translates to a yearly return on investment of 18%. So if you have 655.355 euro’s in the bank and find a 0,001% change of loss acceptable start playing, a yearly income of 120.000 euro’s will be yours. How is that for a business case?

If you accept that all figures used are correct the conclusion seems warranted. I wonder if you have spotted the “catch”. In short the moral of this example is something my statistics professor used to say: With the right data set I can proof anything! This is the first risk of using business cases, it may offer false security. By using a lot of numbers the business case looks really sound, only a subject matter expert (in this case I would expect a risk expert of mathematician) will be able to identify the logic flaw.

A second issue is the use of assumptions. My business case contained the assumption that it takes 2 minutes to play a round on the roulette table. If I recalculate based on an adjusted business case of 5 minutes per round one can only play 6 rounds per hour and thus win “only” 48.000 euro’s per year (a yearly ROI of 7%). Though still not bad there is a substantial difference. So some assumptions can have major influence on the final conclusions. Very seldom do I see business cases that clearly identify the assumptions. It is even more rare that an explanation is given of why the assumption is quantified on the value as presented. Finally it is extremely rare that the consequences are calculated should the assumption be wrong. If information is present it should be available in the risk section of the business case since wrong assumptions are basically a risk. I have read business cases that reached quantified conclusions that were quoted in 3 decimals (look at my residual risk factor). Thus suggesting a very high accuracy of calculation. However in one particular case it also contained a completely unfounded assumption that was hard to pick up on. When I adjusted the assumption “downward” by only one percent the business case conclusion changed from a profit at a healthy return on investment into an unrecoverable loss. I cannot but wonder if the writer did not knowingly manipulated his figures to reach the desired conclusion trying to hide the “weak” assumptions. It happens and to me that kind of behavior boarders on fraud: Willingly leading people to make bad decisions by supplying untrustworthy information and presenting the information as “sound” for personal gain. That type of use of business cases is evil.

Which brings me to the third flaw of business cases. Not all benefits and or (business) value is easily quantifiable. I have been known to say that I can quantify anything should you want me to and I will. I will just make ever bigger assumptions. In business the example often used is the value of advertising. What is my return on investment on advertising spending? This is one of the hardest things to quantify but it can be done. I will give you an example of how one could quantify (with imaginary figures): A full page add in a daily newspaper costs 10.000 Euros (imaginary fact) the paper has 10.000 subscribers (imaginary fact) and is read by, on average, 2 people per delivery address (assumption) this would give an exposure to 20.000 people. 5% actively notices/ reads the add (assumption) that would mean 1000 readers. If 1% would be interested in my product (assumption) I would have reached 10 potential clients. I sell, for instance, cars at a 1000 euro profit margin (imaginary fact). That would mean I break even if every potential customer actually bought the product (assumption). As most people would agree the added value of such a quantification is basically zero since it is just a bunch of assumptions stacked on top of one another.

For some things quantification is just not worth the effort. For instance I tell you that you should buy suntan lotion because the sun is hot and you run the risk of sunburn. Would you ask me for a business case to justify the investment against the possible pain and agony of having to walk around with a burned skin? If so my response would be that any quantification is just a stack of assumptions and thus offers phony security. Would you than conclude that you will not consider the suggestion because if it cannot be quantified it cannot be real? When it comes to investing in things like (IT) Governance, Risk, Compliance, Security and Control I encounter that line of thinking almost on a daily bases! It even went as far that these days we are trying to accommodate this drive for quantification by models like Return on Security Investment (ROSI). Using the business case tool to create barriers against valuable investment proposals just because it is hard to quantify the (business) value is using a perfectly good tool for evil!

PS

I promised to tell the catch of my business case. As every risk expert (should) know, to assess risk you should not just look at the probability but also to the impact. In this case: The changes of losing all the investment money because there is no more money to double goes down with larger “pockets” but if the risk does occur the amount of money lost increases just as fast. In the example: If the investment money is only 5 euro the change is 50% of going broke the risk value, change x impact (5 x 50%) = 2,5. With investment money available for 17 rounds this value calculates to 5. When you build a spreadsheet (as I have) showing investment requirements and residual risks for different cycle lengths you will find this value starts at 2,5 and increases towards 5 which it approaches ever closer. I learned from experimenting that the value approaches your starting stake so if you start the cycle with 10 euro it closes towards 10, etc. I could probably explain that if I sat down for it but since it is of no particular importance for this story I will leave that for the mathematicians amongst my readers. To try and explain in a different way: I have a risk of losing euro 655.355 while winning 5 euro per cycle. I would have to play 655.355 / 5 = 131071 cycles to recover the lost investment should the unthinkable happen (18 consecutive losses) since the average number of rounds per cycle is 2 this would mean the roulette table has turned 131071 x 2 = 262142 to win that much money. If you have played that long the change of the unthinkable happening is that much greater. If you wait long enough every risk bigger than zero (no matter how small) will occasionally happen. Unless, off course, you avoid the risk all together (do not play the roulette). I hope this makes sense otherwise just trust me, the system doesn’t work!

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.

What doesn’t make you stronger might kill you

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

I was reading John Thorps Blog entry “Getting Information Management Right” and read that Gartner predicts that the amount of Enterprise Data will grow by 650 percent in the next 5 years. The article makes a number of excellent points and kept me thinking. But back to the 650 percent, it is not like this is a new development. The amount of data we store (both private and for business) has been growing explosively the last decades.

You do not explain the dangers of overweight to an audience of starving people. Not only is it tasteless but chances are you will find you have a less than captive audience. So the topic of this article is only of interest to those who are not completely starving for information. To stay with the analogy a moment longer, in famine areas of the third world there is virtually no discussions about junk-food since everything is better than starving. It is only when we reach the higher levels of the Maslow’s pyramid that we start to question the quality and necessity of our food and drinks. So the first conclusion: If you, at times, wonder what the added value of all that data/ information is that is so readily available these days you are no longer starving for information. In fact in the “information first world” we run the risk of drowning in all data that is available to us. For these organizations it is no longer about the quantity of data and subsequent information but about the quality.

To establish which world your organization belongs to it is important to recognize a fundamental truth: The primary purpose of enterprise information is to support decision making. No matter how interesting or special you might find a certain bit of information, if it has no (possible) influence on your actions and/ or decisions it is not relevant for your role in the organization. This would basically be junk-information; it might taste good but has no nutritional value. So quality information is not just trustworthy but, just as important, relevant. Good information will support decision-making by bringing down the “guess factor”. The “guess factor” plays part in almost all decisions we make. It is rare that we have all information available at top quality level when we make decisions. We assume that the information we have is correct. We make assumptions about the thinks we just do not know. Since it is the nature of an assumption that it might be false each new assumption increases the risk connected to an individual decision. So now we can assess our informational demand: If we take the importance of the decision under consideration and we look at the risk appetite of the organization we can establish which assumptions we can leave as such and when we want to mitigate by gathering additional information. Since making additional information available will cost resources (money) this gives a nice trade-off: The cost of quality information relevant to the decision versus the level of risk associated to the decision.

Enough theory let’s bring this back to day-to-day impact. We can turn the theory around and assess the actions and decisions made over a certain period of time. If we were to ask a cross section of organizational personnel to look at the last, let’s say, 10 decisions they made. Did they feel they had the necessary information to make good quality decisions? Was the level of risk due to assumptions in line with the importance of the decision? Did they feel confident in the outcome they reached? If not, why not? Was there too little information? Was there too much with the result that the important stuff got buried? Was the quality of information trustworthy? These and other questions will give you insight in the status of your information management from the demand side. We can go one step further and ask those interviewed if they knew where to get the required information. Was it easy to find and access? Could they find somebody responsible for the information? Could they find help to get questions answered? Would they know what to do when their information requirements changed over time? These and other questions will give you insight in the supply side of your Information Management. Doing this on different levels of your organization for decisions of various levels of importance will give you a good overview of the challenges you face. The connection with actual decisions will also tell you if the cost of all this information is in line with the risk reduction achieved. In this context it is good to remember that continued bad-decision making of lower impact decisions at lower levels of the organization might “kill” the organization just as much as one “bad call” on board room level. On the other hand you would not be the first to learn that the cost of acquiring, storing and supplying all this information is completely over the top compared to the nature of the risk it mitigates. Often a “best guess” will do the job just fine.

Risk, risk and more risk

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

When I look at the world today it seems everything is about risk these days. Data breaches left and right (your private data is continually at risk). Systemic risk and failed risk management is what caused the financial crisis. Earth quacks, tidal waves, forest fires, global warming, HIV, Mexican flue are threatening humanity. The current state of the economy is threatening the IT budgets and as a result my job as an IT Consultant is at risk. There is a risk of a new wave of regulations in response to the world-wide need for governments to bail-out private enterprise. As a result the lack of IT risk and compliance expertise is a risk. Or am I just paranoid?

First of all there is a saying that goes “the fact that I am paranoid does not mean that I am not being followed”. Secondly if you do a more objective assessment of the situation it does seem that the term risk is used more than before. Google always offers a good opportunity for fast research so here goes: the term risk gave me 52.000.000 hits compared to governance which gave “only” 10.400.000 and compliance 22.200.000 hits. On the other hand, to give some perspective, security gave 102.000.000 hits and sex 98.100.000. So what does that proof other than that security is more interesting than sex and the fact that you can statically proof anything with the right data set? Actually, very little. But it is not about hard fact but about perception. I attended the ISACA Information Security and Risk Management conferences (both the North American edition in Las Vegas and the European conference in Amsterdam) and the general feeling I got from the presentations is that these days it is customary to translate our issues into risks. Lack of expertise and tools in an organization is a risk for information security, lack of compliance is a risk for the license to operate. On the other hand compliance with the regulations has the risk of organizational complacency “if we comply with the rules we must have covered all risks”. If you believe that you might want to look outside on Christmas evening, maybe you will see Santa Claus fly by in his sled.

A second indicator: I am always scanning the job and assignments market and given my expertise I use search terms like Governance, Risk, Security, and Compliance. I have clearly noticed that in the last half year we are looking for IT Risk experts more than before compared to the other terms. So my conclusion: the age of governance and compliance is over, welcome in the era of Risk!

Those who have read my articles before will have probably guessed my real conclusion: Risk, the buzz-word for 2010 happy New Year! So besides the fact that all GRC consultants, managers, experts, etc. will have to re-write their CV’s to give their Risk expertise a more prominent place is this a bad thing? Contrary to popular believe IT managers and corporate purchasers are not complete idiots so they will soon recognize the IT suppliers that try to sell last year’s products under the new “hype” label. My prediction for 2010: A number of the products that were “must haves” to achieve governance and compliance nirvana in the last decade will become absolutely vital if you wish to achieve risk management bliss. The problem is that as a result organizations might totally disregard “risk” since it is just hype. As usual, however, this hype is based on real challenges that require adequate attention. Failed risk management was one of the causes for the financial crisis and the subsequent economic down-turn so we might better do some of that “continues improvement stuff” and analyze what went wrong and see how we can improve it. On the positive side the risk-hype could create a common language to compare our issues: If we translate all our issues (business and IT alike) into the risks they may pose for the organization it will become much easier for top management to compare and prioritize them. But then again, I spend every Christmas evening outside hoping to finally get a glimpse of Santa Claus.

Sourcing strategy – end-to-end or aligned

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

Some time ago I came across a question from Réal Rousseau on the itSMF Discussion Forum. After we discussed his initial question for a while we came down to the following underpinning issue: When you look at the IT Supply chain most services offered to the business are built by combining products and services from different organizations. For instance, a message service will combine at least a workstation service, a network service, a mail server service, WAN service, internet access service and maybe services like PDA/ Smartphone or mobile computing. These days no organization that I know will build, run and maintain all parts of this end-user service in-house (I do not think it would even by possible if you wanted to). So not only do different departments within the organization need to work together to create this business service, but there also has to be operational alignment with third parties. The question Réal and I were discussing is: In this complex, multi-organizational spaghetti would the ultimate goal be to create an end-end process model or just align the individual links. With one overarching (end-to-end) process model the designs of the internal operations of each link is adjusted to fit the tasks, activities and goals described by these end-to-end processes. The alternative would be to allow each organization in the chain to have their own internal operational process model and just ensure the operational alignment in the cooperation between these organizations. For alignment you ensure the output from each individual link matches the input requirements from the next link in the chain. In this case the way the output is created is not a topic of interest. The individual links are seen as just as many black-boxes. I have seen this discussion in different forms within different organizations.

But before we get further into this question, what does this have to do with (IT) sourcing strategies as the title suggests? You may have got the feeling from the opening paragraph that this article would turn into a highly technical discussion of different IT operating models and forms of process-cooperation, but that is not the point of the article.

An essential part of strategic thinking is to understand the consequences your choices of today will have for your options in the future. As I learned from the discussions with R̩al and others there are pros and cons for creating one process model for the complete chain were each link just conforms and finds its place in the bigger picture. This is the same for the alternative where each link organizes its own (internal) processes Рin this case, special attention should be paid to the alignment of the contact points between the individual links. If you are interested in discussing further, let me know and we can get a conversation started.

For most professionals, however, this discussion is completely academic. To be able to establish an end-to-end process framework for the complete supply chain you need to have one dominant link in the chain that can act as the “director” of the end-to-end model. If you look at the production supply chain from Dell or Wal-Mart, say, it is clear who is in the driving seat for the end-to-end chain. On the other hand, many organizations have a sourcing strategy that dictates that suppliers of equal size or stature are preferred. Since this will help to ensure adequate share of mind from the supplier (the supplier should not be much bigger) and stability (the supplier should not be much smaller) this is often a sound strategy. However if all links in the chain are of equal size it might be hard if not impossible to find the dominant link that can act as the director for an end-to-end process/operational model. For most of us the supplier portfolio is a given that you do not change in the short term.

So that’s the answer: Look at your current supplier portfolio. If you can identify a potential dominant link in the chain you might consider building an end-to-end operating framework, directed by this link. If you cannot find a clearly dominant link, each link should decide for itself how to organize its operation and each interaction point should be aligned by the parties involved with the individual contact. That sounds nice and responsive and is probably the only viable solution for most organizations. However, for organizations who want to be “master of their own destiny” and thus have decided that their (sourcing) strategy is important to be able to actively plot and navigate the course of the organization: Your IT Sourcing Strategy – more consequences than meets the eye!

Rules, Standards and Models

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

Is there really a difference between rules, standards and models, and does it matter to IT governance? From 28-30 September I attended the ISACA Information Security and Risk Management Conference in Las Vegas. I shared my ideas on integration of the IT governance, risk, security and compliance functions. More importantly for this article, I had the time to attend presentations from other experts in the field. This gave me a number of new insights; “good stuff” for future articles. One of the presentations was titled “Harmonization of Standards” by Todd Fitzgerald. Todd is a well known figure in ISACA circles and I attended his presentation with serious expectations. As in the past, I was not disappointed. During his presentation Todd made one remark that stuck with me. He basically said that there is a lot of discussion about the difference between rules, regulations, standards and models and that in his opinion the difference was academic and of no particular interest in real life. I have seen a similar attitude with tool vendors. It is not uncommon to read claims like “tool X describes CobiT, ITIL, ISO 27000, SOX, PCI, etc.” or something to that effect. Basically I think that treating rules, standards, and models as more of the same is wrong and here comes the reason why. But first, to Todd: if I misunderstood your comment - my apologies.

These days organizations, including their IT departments, have to comply with a multitude of rules and regulations. Looking at the regulation ‘spaghetti’ allows three questions when addressing any (new) regulation:

1. What is the subject of regulation? For instance SOX is concerned with the financial information submitted to the Security Exchange Committee; PCI is concerned with protecting information regarding Credit Card transactions.

2. What are the compliance requirements? What is it I need to do, stop doing, control and/ or measure so I can claim compliance?

3. How does the regulator want me to assure compliance? For top level management to assure compliance with performance controls, it might be enough for lower level managers to fill out a self-assessment questionnaire. SOX, on the other hand, has very strict requirements for proving compliance; this includes sample-based testing of controls, internal and external audits.

The first question is important for a number of reasons. The subject of control will help us establish the primary accountability in the organization: if the financial data is the subject, the finance department would logically be accountable for achieving compliance; if data privacy of personal information is the topic of interest, the sales/marketing department might be accountable for customer information; if it concerns data privacy of employee data, it might be the responsibility of HR. The second example shows that regulation might apply to different types of data owned by different stakeholders in one and the same organization. Failure to answer the first question will have obvious consequences: without a clear subject of regulation it will be that much harder to establish ownership and compliance accountability. This in turn might lead to vague or non-existent business sponsorship for the effort to achieve compliance. Since almost all compliance efforts involve implementing unpopular measures and controls without clear sponsorship, any effort to achieve and maintain compliance can easily turn into an unachievable up-hill battle.

Furthermore if we do not know the subject of compliance the only way to ensure we cover all that needs to be covered is to apply our measures “across the board”. For a small company without the resources or organization to manage a differentiated control approach this is not an issue. But let’s assume a global corporation wants to do business in the middle-east. Within that region there are a number of countries that are the subject of stringent EU and US export regulations. If the organization has no idea which resources, processes, information, etc. are actually used in this region they would have no alternative but to apply all the export controls to the entire organization. This in turn would probable cripple the ability of the organization to conduct business competitively elsewhere in the world. Conversely, a properly conducted compliance effort can actually offer competitive advantages since it will allow the organization “to go and conduct business were the competition just cannot follow”.

Once we answered the first question the second question is ‘what are the compliance requirements?’ This is when the difference between rules and models becomes most apparent: rules set requirements. To keep the primary accountable satisfied we need to prove we meet the requirements. Trying to do so means that we need to design and implement a solution. For the design of these solutions we might use a model or best practice. For standards it depends on the way we use them. If a stakeholder decides it is important to comply with one or more standards (and maybe even get the compliance certified), the standard, in effect, becomes a rule. On the other hand we may want to use the standard as a starting point to achieve compliance with other regulations. For instance ISO 27000, as a standard, can be used as the basis of the IT General Control framework needed to achieve SOX compliance. In this example ISO 27000 implementation is not the requirement or goal it is just a tool to meet another goal.

The third question makes the difference between rules and models even more apparent. Use of a model should never be the goal, just the means to an end. The answer to the question ’did we meet the goal?’ will tell us whether we implemented the model correctly. For compliance to (internal or external) rules and regulations, however, it should be clear upfront how the organization is supposed to proof their compliance with the rules. As many organizations have learned, the assurance requirements for the regulations might lead to a different solution. SOX, for instance, has very strict assurance rules which includes sample-based testing in many cases. When sample-based testing is required it is often worthwhile to build automated controls where proof-of-control execution is automatically generated and stored for easy access by the control testers when the time is right. If on the other hand a management assessment is considered adequate assurance there might not be a business case for automating controls.

So, on the one hand, given the growing complexity of the rules, regulation, standards and models jungle out there it becomes more and more important to clearly split between the rules and regulations that tell us what we need to accomplish. On the other hand the models, best practices, examples, etc. can guide us in designing solutions that actually meet those compliance requirements/ goals.

Compliance for outsourcers

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

This evening I attended a round table session organized by the Dutch chapter of ISACA. Antal, the presenter, did his best to show how compliance can influence the outsourcing relationship. At the end of the presentation Job, the host, concluded that this was a complex subject and that more time could, and should, be spent explaining all possible consequences. Antal, Job: sorry but I disagree with that conclusion.

Compliance is a requirement and non-compliance is a risk. In a demand-supply relationship (a.k.a. customer-supplier relationship). As the demand partner, the customer is accountable for identifying both his requirements and his risk acceptance levels. In case of compliance the customer should identify:

  1. Which rules and/ or regulations apply to the service agreement
  2. How he wishes to be assured about the compliance with the individual rules
  3. What is his risk acceptance level of non-compliance

There are many rules and regulations in this world SOx, Hipaa, PCI, Information Security (compliance with internal rules and regulations is just as much compliance as compliance with external rules), Data Privacy, etc. Compliance requirements form part of the integral requirements set that the customer hands to the service provider; this accountability cannot be transferred. In the same way, the method of assuring and reporting the compliance status forms part of the compliance requirements. Working with an outsourcing partner does not make a difference on these points. And then there is the third point: acceptance of the non-compliance risk. In theory, if we had unlimited resources we would be able to completely mitigate risk so there is no residual risk. In practice, the best (and probably only) way to achieve this is to stop all activity of the organization (i.e. go out of business). So it starts with your cultural attitude towards risk. I was working for a financial institution during the SOx glory days and their attitude towards compliance could be described as follows: “We are a financial institution. The trust of our customers, based on our reputation, keeps us in business. SOx compliance failure is not an option.” And believe me they put their money where their mouth was; I was very impressed with that effort. Another company, also on the SOX compliancy ticket: “Our reputation with the financial world has been tarnished because of mistakes we made in the past. We will use SOx to show and prove that we have learned from our mistakes and (if possible) wipe the slate clean.” And again: “SOx compliance failure is not an option, we do not even want it to be a close call”. They also backed that statement with the necessary resources. On the other hand, there is the story of another financial institution. That story is written in a Dutch Book called “De Prooi”(The Perfect Prey). It is about the Dutch ABN Amro bank, a global bank that struggled and was finally sold in parts. From a governance perspective this is an absolute “must read” in my opinion. Amongst others because it describes how mistakes in governance, risk and compliance management were amongst the root causes of the failure of what was a great institution.

In this book it is described how the Bank had a “cavalier” attitude towards compliance and after repeated warnings they were punished by the US financial authorities. The point I am trying to make is not that you should do everything to comply, but to think: What is the risk, what is the cost of non- compliance? In money, reputation, etc. But this is nothing new; these are the questions you can also read in “Risk Management for dummies”. However, you are not supposed to think it, let alone say it, but at times it might be worth taking the penalty for non-compliance since the cost of achieving compliance is ridiculous compared to the penalty. I have never heard it stated but I have seen situations where the organization was clearly non-compliant (and that fact was known to those who should take action) yet it was decided that no action would be taken. When the cost of compliance is internal to the organization (even if it is another department) most people understand this trade-off and will act accordingly. But somehow when a third party is responsible for remaining in-compliance the customer often forgets: Compliance costs money! Since third-party outsourcers are not in business just for the fun of it, they will transfer the cost of compliance to their customers. If they don’t it is even worse, they are likely to go out of business. So from the perspective of the demand side: be clear in what you want regarding compliance for your service, why you want it and do not go overboard, every extra costs money!

Now to the supply side. As with any good outsourcing deal the customer should clearly specify what he wants, not how the supplier is supposed to provide it! If I walk into a car dealer, do I get to tell the dealer how to run his business? Can I order the manufacturer to build his assembly plant in a certain manor? Not exactly, I can tell him for example that the car should meet the European Union road-safety regulations as I want it delivered in Europe and I want to drive it there. When I walk into an US car dealer, that might pose a problem for him. Chances are I am the first customer ever to ask him that question, so if he decides to take my order he will have to investigate what the rules are and figure out how to change the car (and the service that goes with it). If he has to go through all that trouble just for me, it will be very expensive. This is where a smart outsourcer can make a difference: If you have a lot of customers all wanting cars for the European Union, you might set-up a special assembly line just to comply with those rules. Once you have done that, you walk over to the European authorities and get a seal of approval for the complete assembly line. As a result you do not need to prove compliance for each individual car produced. The tool to achieve this for an outsourcer is called the SAS 70. The external auditor of the outsourcer supplies a statement that the outsourcer has implemented sufficient control to meet named control objectives. If the control objectives the regulator wants the customer to meet are amongst those on the named list of the SAS 70, he may use that statement as proof of compliance towards his external regulator. A SAS 70 expert might have issues with my layman’s explanation of a SAS 70, but in broad lines that’s how it works. So if you are considering outsourcing your Compliance sensitive services, look for a partner that already has knowledge and experience with the regulations you need to comply with; you might be able to achieve considerable economies of scale and thus cost savings.

Business-IT alignment, a bad term (part two)

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

In part one I discussed the first reason why I do not like the term ’business-IT alignment’. The term suggests that business is one homogenous entity with clear and consistent requirements for the IT domain, which in my experience it is not. The second reason I dislike the term is that it suggests an “us against them” mentality between business and IT that is common and (even worse) found acceptable in many organizations.

Too often I read articles or hear conversations where it is suggested that IT should have an extraordinary position within an organization. In my opinion IT is just another member of the corporate family. In any family the members are unique in their specifications, issues and relations with other family members. However when a family member is no longer considered part of the family structure but tarnished with the ’special position other than the other family members‘ brush you know you have a problem.

To me that is what business – IT alignment suggests. We have all these departments who cooperate together as ‘the business’ and then there is IT; the unloved, unwanted, misunderstood corporate member, not part of the business ‘in crowd’. If this sounds familiar and the accepted situation in your organization then consider the following.

For those in the IT domain: when the business is given the choice of IT service supplier the most important advantage the internal department has over an external third party provider is its intimate knowledge of the corporate business. If the IT domain places itself outside the corporate family this differentiator is diminished. If this is the (accepted) situation, then consider outsourcing the IT department. In which case IT can at least offer the corporation economies of scale by joining another IT focused family were it does feel at home.

For those outside the IT domain, it can be compared to living as a family. Since you live so close together, you get to know all the issues, problems and specialties of the other family members. You also learn about aspects and habits you do not like. Small irritations that get blown up over time because of the intimate relationship are often the cause of these fights. So you might decide to break up the relationship in favor of a new one at arm’s length; like getting a third party provider for your IT services. But do you honestly believe that since your partner is now so far away you do not see ‘the wrinkles and flaws’ they do not exist? As the Counting Crows (or Joni Mitchell for the older generation) say: “you don't know what you got 'til it's gone”.

So what is the message of this article? First of all stop fighting and blaming, accept that perfection does not exist. Secondly start on the path of continuous improvement to try and achieve a harmonious relationship between the different corporate family members. This way the business – IT alignment is an intermediate goal at best and corporate integration of IT is the ultimate target.

Business-IT alignment, a bad term (part one)

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

The summer is always a nice time to step back and look at what you are doing. While I enjoyed the nice weather in the south of France and watched my kids play on the beach I thought about why I dislike the term ’business-IT alignment’. I know, I am a workaholic: you should not spend your summer holiday thinking about these kinds of things. I just like my work so there you go…

So I dislike the term ‘business -IT alignment’ and this is mainly for two reasons. In part one I will discuss the first reason: the term suggests that the business is one consistent entity that can easily be represented and is consistent in its requirements, demands, needs etc. I have never seen an organizational chart were there was one organizational entity marked ‘business’ as opposed to an entity called ‘IT’. I have seen however names like ‘Sales/ Marketing’, ‘Logistics’, ‘Finance’, etc. All of these entities combined we call ‘the Business’. We look at all the requirements of all these entities and if we have our house in order we combine them into this thing called the ‘IT service portfolio’. In case the organization has not adopted the service oriented approach we might call it the ‘IT application portfolio’. But in most cases we will identify a limited number of services to be used by multiple business entities. The requirements for each individual service will be a combination of all the requirements from the different user groups. Not seldom will you find that one or more user groups do not see any connection between their personal requirements and the combined end-result. Of course this triggers reactions like “IT doesn’t listen to my requirements” and “IT doesn’t understand me”. For good reasons this approach of un-differentiated products (or services for that matter) was advocated by Henry Ford when he said: “Any customer can have a car painted any color that he wants so long as it is black”.

Let’s face it, it worked for Henry Ford…..in 1909! If you walk into a Ford dealer these days you will quickly learn this dogma was dropped somewhere along the line. On the other hand it is suggested that one of the reasons General Motors is in so much trouble these days is because the endless variation of brands, types and features they offer in their cars makes it impossible to achieve the economy of scale an organization of that size must achieve in order to effectively compete.

So what is the lesson for the IT domain? Well, basically the era of one-size fits all has passed, customers and end-users are so accustomed to getting products adjusted to their personal requirements they will no longer accept the undifferentiated approach of most IT departments. If I want to buy a PC for personal use I go to the Dell site and can get it chipped and tuned anyway I please and indeed even in multiple colors these days! If I then turn to my corporate IT department and get to hear that I cannot have the application I clearly require because it is not in the standard configuration my thoughts are clear: inflexible, doesn’t understand me, stone-age and a few more negative ideas about IT will enter my mind. However, before we now instruct our IT departments to start saying “Yes, sure whatever you want” we do need to realize there is one thing worse than saying no: not being able to deliver on our promises!

So have a look at the dogmas and structure of your IT department and bring it into the 21st century. Variation of services to meet the needs of your individual customer is the new reality. But before you start the internal marketing campaign, you should organize the department so it can actually deliver in this more complex environment.

The IT Supply Chain

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

One of my favorite books is The World is Flat from Thomas L. Friedman. In this book he describes a number of technological developments and how they lead to globalization. Though you might disagree with some of his conclusions, the (technological) developments are undeniable and so is the general trend towards globalization. What the effect of the current financial/ economical crisis will be on this trend is uncertain, but if we steer clear of the threat of protectionism this trend will probably continue. One of the driving forces for globalization he describes is ‘supply-chaining’. According to Wikipedia, “A supply chain is the system of organizations, people, technology, activities, information and resources involved in moving a product or service from supplier to customer.” This brings me to the topic of this article: the IT Supply Chain.

One economic rule says that a specialized economy where entities use their resources to produce goods and services that they can produce efficiently, and then trade the surplus for items they need but that others can produce more efficiently, will have a larger overall production than an economy where each entity produces everything it requires by itself. This is the underpinning argument for globalization advocates; global trade will benefit the entire world in the long run. This law however also applies on a much smaller scale: for each required product or service, an organization needs to decide to “make or buy”. Often buying will be more efficient but will have a number of negative side effects (including risks) that the organization needs to be aware of and manage. For example the product/ service offered by an external party might not fit the organizational specifications 100%. Furthermore there is always the risk of a supplier defaulting on his promises. All this should be reflected in the corporate sourcing strategy which sets the rules and guidelines for the “make or buy” decision process and for deciding on who should be an external supplier or partner. In turn the corporate sourcing strategy should be “operationalized” for the IT function in the IT sourcing strategy. For the clarification of this term please read the article “Operationalizing” strategic goals in this blog. Examples of guidance from the IT Sourcing Strategy might be: IT technology systems, services and/ or knowledge that are part of the Corporate Unique Selling Points shall be developed, run and maintained in house. We want to work with a limited number of (preferred) IT suppliers. We always want to work with the best of breed technology that matches our requirements; who supplies that technology is a secondary concern. As these examples already show, some of these strategic statements might be mutually exclusive, so it is important that an individual organization really looks at its culture and requirements when developing its sourcing strategy. This also means that an (IT) sourcing strategy is as unique as the organization it was developed for.

If we have a good overview of the IT services required by the business and how they can be broken down into their sub-services (IT systems, infrastructure, components, etc.), we can apply the sourcing strategy to each of the components and describe the overall IT supply chain for the complete set of IT services offered to the business. Not only does this help decide on the internal structure of the IT function, but more broadly, it shows the complete IT environment including the external suppliers and partners, their importance, risks, etc. Once we have an overview, we can start managing it to improve efficiency, effectiveness, performance. We can look at the IT-related risks, not just for the internal function but for the entire environment, and manage it. Basically we can apply all knowledge and experience available on the topic of supply chain management to the IT environment of the organization.

One of the most important rules of supply-chain management is to ensure a common language, with well defined terminology, to be used by all parties in the supply chain so to minimize the risk of misunderstanding. This drives the development of open standards for a wide range of topics, ranging from technical specification for the smallest components to standard government approaches towards import duties etc. In the same way, open standards for IT organizational models would help to improve the efficiency and effectiveness of the IT supply chain. If we have a common understanding of the basic definition, goal, purpose of the incident management process, say, it will be that much simpler to transfer the operational maintenance of IT systems to an external partner (outsourcing), should this be in line with the sourcing strategy. It will make the IT supply chain more flexible and agile to change should circumstances require it. This is one of the reasons why I advocate the closer alignment (if not integration) of the leading IT Organizational Models (ITIL, CobiT, ISO 20000/ 27000/ 38500, etc.). Having said this, I subscribe to the view that “on implementation a model should be adjusted to the need of the individual organization not the other way around”. As a result, each individual implementation of any of the industry standards might differ from one organization to the next. So as usual a careful balance has to be struck between customization versus standardization, also when designing and implementing IT organizational structures according to industry standards and best practices. Both the internal organizational situation and culture and the external IT environment relevant to the organization should be considered. A well established and managed supply-chain is so much more than the sum of its parts, as Dell and Walmart show.

My kingdom for a scrammer

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

Each builder knows tools are not the goal they are just the means to an end. After talking to his customer the builder knows what the goal is. He looks over the situation, decides what the solution should be and if he needs screws he reaches into his toolkit and picks up a screwdriver, and if a nail does the trick… you guessed it, a hammer.

Models are like tools: not the goal, just the means. In the past if you needed to implement IT control, get a copy of CobiT; if you were working on operational IT processes, ITIL was the answer. Life was so nice and simple in those days. Overtime CobiT developed from just control objectives into a more comprehensive model including domains, processes, control objectives, maturity, etc. It became clear that slowly but surely an overlap started building with that other well established model for IT Organizations (ITIL). So the first mapping table was created and it became obvious that certain differences in definition were going to create problems for organizations wanting to adopt both models (the different definitions of problem management according to CobiT 3 versus ITIL v2 is a clear example here). The introduction of CobiT 4 cleared the way of further alignment of both models and the new mapping table shows that the alignment of both models is now indeed more straight forward.

Enter ITIL v3. ITIL, which has its origin as a model for operational run-and-maintain processes, sees the light and introduces new material looking at full-lifecycle management of services (including strategy). Furthermore ITIL introduces thoughts about business – IT alignment intended to ensure maximum value of IT services. Topics such as strategy and business-IT alignment were considered the domain of IT Governance (i.e. CobiT) so the models come even closer together.

To get back to our example of the builder and his screw and nail. What would happen if new developments in building technology led to a new way of fixing things that integrate the best functionality of screws and nails (let’s call it a ‘scrail’)? Do you think the producers of screwdrivers would keep pushing the use of their tool to use when working with scrails while the producer of hammers advertises hammers as the better tool? I hope not. I would hope the producers come to the conclusion that if screws and nails can merge into a product that combines the best of both designs, so should the tools designed to work with them. The new tool could be a ‘scrammer’!

So ISACA and itSMF, can we have a joint taskforce with the assignment to create ‘COTIL’?

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.

G R C, where did the S go?

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

The Blog post “To GRC or not to GRC, that is the question” looked at the integrated function of IT governance, risk and compliance (GRC) and why it is logical to combine these functions. The article ended with a question: “Why not integrate even more functions?” To answer that question we now look at integrating the ‘s’ of IT security.

IT security is often regarded as the dusty IT department living in the IT-dungeons. Concerned with the latest virus information and hack-attack news, it investigates how to adjust the firewall settings to minimize exposure to any such new threats. Basically, highly technical expertise, disconnected from the real world spending time thinking of things that users ‘should not do’ or things that ‘cannot be done’ because of security risks. And really how risky can it be if everybody does it? As always Dilbert has a brilliant character that portrays how many people see the security function and those associated with it. The character is called Mordac, the preventer of information services, which sums it up really nicely. As the saying goes, ‘there’s no smoke without fire’ so IT Security is probably (partially) to blame for this image problem.

Though this might be how the function is perceived there are forces at work to change this image and positioning. This new IT security function can be defined as ‘the function responsible for discussing the information risks with the information owner and designing, implementing and assuring the risk responses for the IT domain’. This definition suggests it is about informational risk management. It is about alignment with a stakeholder (the information owner) who resides in the business in most organizations. It positions the function not in the ‘IT dungeons’ but as an expert partner to the business information owner with knowledge and advice on how to safeguard the all important corporate information assets. This makes it part of the business IT alignment challenge we hear so much about. With new positioning and goal for the function it immediately becomes clear that integration with the IT GRC function should be considered. Instead of talking about the IT GRC function we might think about creating a GRSC function. There is one problem, we love our acronyms to have three letters; GRSC has four! Not to worry, we can apply a trick: Just rename IT Security as IT Operational Risk Management - this nicely distinguishes the new (existing) function from the dusty old image anyway. Now you can capture it under the ‘r’ from risk. A TLA again, problem solved. It works but in practice people tend to forget that security is supposed to be an integral part of such a GRC function. Furthermore, the security people feel unappreciated. So personally I would advocate giving security its rightful place under the sun and recognizing that in most organizations IT security was around before the GRC hype started. At the end of the day all these dust gathering activities will need to find their place in this new function (what IT security used to do wasn’t all that bad). Credit where credit is due: GRSC, Governance Risk, Security and Compliance.

I can almost hear it: “Why not leave well enough alone?” Let the security nerds play in there dungeons and I will create a nice new hype function called GRC. That sounds much better when I discuss the state of the world with my fellow management friends on the golf course or over a glass of Chardonnay. And indeed, you are right it is easier to explain. But be warned, you are heading for trouble and here is why. An important part of the work of the IT GRC function is to design, implement and assure control over the IT domain. To this purpose the function discusses the requirements of different stakeholder groups (IT-management, legal, financial etc.), combines the outcome and translates them in a set of controls for the IT domain. These (IT general) controls should be understandable and achievable for the different operational IT departments. Guess what, this is exactly what IT security (new style) will do. In some organizations a basic truth is forgotten: the security function should not invent security controls by itself, instead the security controls should be the appropriate response to the IT security risk as identified together with the information owner. Too often you will find a disconnection between IT security and the business owner of the information. IT security single-handedly decides what the security controls are for the IT functions. In these cases IT security might easily be perceived as ‘uninformed of the business requirements‘ and ’unwilling to work towards business requirements‘. If this is the case you should think about transforming your function into the new style anyway. When doing so you might as well integrate the IT GRC function in one go. When looking at the day to day tasks and activities of both functions there is much overlap. Integrating the functions offers the opportunity for efficiency improvement.

The next example shows the problems you might encounter if you keep two separate functions. It describes a real situation for an unnamed organization. The organization is subject to the Sox regulation and a couple of years ago it had to proof compliance for the first time. Organized by the finance department this resulted in a worldwide (business driven) program to achieve SOX compliancy. Since SOX has direct requirements for the IT domain the program also included a stream focused on this domain. Those involved with this stream noted that in the IT domain there already was another worldwide program to implement a new IT security standard (transforming the IT security function towards the new position as described above). Combining those two (control oriented) programs was considered but since both programs were on a very tight time schedule it was decided to leave them separate. From a project perspective this made sense and indeed both achieved their project goals. This is when the trouble started. Although for different regulations, both programs aimed for sustained compliance of the IT domain. So both functions independently created a run-and-maintain organization with the assignment to ensure continued compliance with their respective control framework. As a result IT operations had to comply with two different IT-control frameworks, each asking for different ways to prove compliance and both using audits as a means to double check. In practice this resulted in some (high-profile) IT shops being audited up to five times per year. For those on the work floor it was very clear that each auditor often asked the same questions. The time, effort and resources spent on assurance were considered unsustainable. So a new project was started to integrate the IT GRC and IT security function. However the IT organization, tired of anything to do with control, resisted the changes from the integration effort. Even though they were intended to improve efficiency and reduce the impact of the control requirements on the day-to-day operation. So what went wrong and how could it have been avoided? By the time programs were started (especially the SOX program) they were so urgent that any effort to integrate them would have caused unacceptable delay. Besides developing and implementing the SOX control framework, a new run and maintain organization was also created instead of transforming the already available (IT security) operational organization. The latter was considered too costly and time consuming to fit the SOX timetable. Furthermore the IT security function was already being transformed as part of the IT security program which complicated the issue. This newly envisioned run-and-maintain organization should have been in place before either program started. Basically the programs should have been in charge of describing what control objectives should be met - and by which section of the IT domain. The IT GRSC function should have designed the (integrated) IT control response in answer to those requirements. Given the nature of the IT security function at the time it was not considered capable of performing that role.

Looking at the current economic situation, it is foreseeable that a new wave of regulation is on the horizon (see the article “Weathering the financial crisis, other challenges for IT Governance are glooming on the horizon”). Though we do not know what the actual regulatory requirements might be it would be prudent to start building the (integrated) GRSC function. This way, once the requirements are known, the GRSC function has a clear view of the controls already in place and has the agility to react fast and appropriately to make the necessary adjustments. Last minute reactions under time pressure tend to be very costly. A timely investment in a fit-for-purpose IT GRSC function can start by looking at opportunities for efficiency improvement with current IT controls (thus creating an immediate return on investment) and will most likely pay for itself with the savings on compliance programs for future regulations. As Sun Tzu wrote in his classic on strategy (The Art of War): “Thus, though we have heard of stupid haste in war, cleverness has never been seen associated with long delays.”

To GRC or not to GRC, that is the question

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

Don’t you love the use of abbreviations? Often before you learn what the abbreviation stands for you have to read to the end of the story completely dazed about what it is the writer is trying to say. So let’s not do that: GRC stands for Governance, Risk and Compliance. These three functions are important to all organizations. Wikipedia define GRC as ‘an increasingly recognized term that reflects a new way in which organizations can adopt an integrated approach to these three areas.’

So the first question is why we would choose to integrate these three? To answer this question we should explore the individual function and try to identify the way they are connected.

Let us start with IT Governance. Since IT Governance seems to be in “hype mode” everything is about governance these days. Googling ‘IT Governance returns almost 1.1 million hits. What’s wrong with just managing something? But that’s a topic for a different article. Important here is that so many opinions are bound to result in difference of opinion and confusion. To cut through the chase, the definition I adopted: “IT Governance is the discipline concerned with strategic decision making for the IT function”. Normally I like Wikipedia as a source of independent definitions but this time I think they missed the point: “IT Governance ..., is a subset discipline of Corporate Governance focused on information technology (IT) systems and their performance and risk management.” This suggests performance and risk management are the goals of IT Governance were I would claim they are just the means; strategic decision making is the goal.

To be able to make decisions first we need context, this is where we find strategic alignment with corporate governance. Contrary to popular belief the IT function is not an island but an integral part of the organization so any strategic decisions concerning IT should be made within the confines of corporate strategy. One of strategic goals inherit to every organization is ‘to comply with all applicable internal and external rules and regulations’; however this might not be articulated or even recognized in some organizations. I can already hear some readers say: “Every organization?” Yes each and every organization, the trick is the word ‘applicable’ (or ‘relevant’ in the Wikipedia definition). Even if the organization under consideration is an extreme ‘crime syndicate’ that does not accept any form of external regulations there will still be some form of internal rules to comply with otherwise it would not be an organization but just anarchy. This is where we find the connection with (regulatory) compliance. According to Wikipedia: “Regulatory compliance describes the goal that corporations or public agencies aspire to in their efforts to ensure that personnel are aware of and take steps to comply with relevant laws and regulations.”

So now we have context, next we need to identify the players, places and timing in the decision making process: ‘Who has the power to decide on what? Who is Involved? Is there a formal time and/or place for discussing, concluding, communicating on the strategic decision topics?’ Identifying, describing and communication this structure is part of the governance discipline and does not have an immediate impact on the connection between the function. Still, it is an important aspect of IT Governance and as such worth mentioning.

Next we need information; -to make a good decision you need to have good quality information available. If I were to approach anybody with the statement: “I have a project. Are you willing to invest?” how many people would feel comfortable making a decision? Even in this example you have some information available: I am asking, you might or might not know me and as a result you will place the request in a certain context. If I asked you in a dark alley waving a gun I bet I would get more positive responses for instance. So we need information, the first information requirements tends to be financial information: “How much money do you need? For how long? What is the financial benefit?” I will answer you with two alternatives: First, I need 10,000 (Dollars, Euro’s, Yens, any currency) just for one night and I expect to be able to pay you 15,000 back tomorrow. The alternative: I need 10,000,the return on investment is 3% per year and after 10 years you get the money back. Would you feel comfortable making a decision based on this information? Some people would but the quality of the decision would be poor at best since we did not discuss the risk involved. In the first instance I will take your money, go to a casino, play black on the roulette table and hope for the best. In the second option I bought US Government Bonds. This example goes to show something every financial investment expert knows by heart: expected/ acceptable return on investment depends on the level of risk connected to the investment. So the quality of the decision will dramatically improve if relevant risk information is available during the decision-making process. Thus the connection between IT Governance and risk management as a source of risk information.

So there you go, (IT) Governance Risk Compliance is highly connected and indeed these functions should be aligned if not integrated to ensure we create a quality strategic decision making process. But it does not end here. An earlier article on this blog ‘“Operationalizing” strategic goals’ describes the next steps to ensure these decisions actually result in organizational actions so it does not become a ‘strategic goal for marketing purposes’ (See the article). It is part of the IT Governance objectives to oversee and govern this part of the decision cycle. To achieve this objective the IT Governance discipline uses means such as Performance Management and (Financial) Control which brings us nicely back to the definition of IT Governance by Wikipedia.

In the introduction I highlighted why we would choose to integrate these three functions implying that there are more questions to ask. And indeed, the second question would be: ‘why not integrate even more functions?” Coming up, the answer to that question. Watch this space!