Search

Wednesday, December 22, 2010

Wikileaks: Freedom of information versus information privacy

Article reposted from original posting on ComputerWorldUK

The commotion over Wikileaks and Julian Assange is incredible. Even more incredible is the polarisation of opinions you find on the internet. It ranges from “Assange for president” to “Assange the digital Osama Bin Laden”.
Stepping away from the opportunistic rhetoric we should realise that this discussion involves fundamental issues concerning information ownership, information privacy, freedom of information and the way we handle information on the Internet.

I believe that the law should just be the written representation of what we as society believe is right and wrong. So this article is not intended to discuss if Wikileaks and Assange are acting unlawfully and should be persecuted but our beliefs, as a society, of what is right and wrong. In itself the lawfulness is already an interesting discussion since the Internet supersedes any geographical boundaries. So which country law should govern the Internet?

Monday, December 20, 2010

Bonuses and sanctions


In Holland there is a saying: You catch more flies with honey than with vinegar. Indeed if we look at the causes of the financial crisis in a number of cases the drive to achieve the incredible bonuses that are customary in the financial sector seem to have outweighed the sanctions the enterprise risk department might or might not have imposed for excessive risky behaviour.

First of all this shows an underpinning feeling regarding enterprise risk and control: Enterprise risk and control limit the possibilities of "the fast and the furious" to reach for the sky. This feeling that enterprise risk and control only limits the possibilities of the organization to maximize on growth and profit potential is surprisingly common also with people that should know better. Some time ago I had a conversation with an account manager of the management consulting firm I was working for at the time. The customer we were discussing was a supplier of high-tech production tools for the computer industry with a world-wide customer base. The company is a world-wide market leader in its field of business. We were discussing if they might be interested in my particular expertise (IT Governance, Risk, Security and Compliance). I will not soon forget one of the statements my discussion partner made: "This is a fast moving company with a young, entrepreneurial, can-do culture. They have no interest in the control resulting from IT GRSC since it would limit their possibilities to maximise growth and profit." Not his exact words by the way but close enough. Such convictions however are amazing for an account manager of a management consulting firm. What made it worse was that he was also the company director overseeing the consulting business for customers in the production sector. In response I have a question: Why does a formula 1 race car need breaks? Answer: To be able to drive faster. Explanation: No formula one driver in his right mind will drive his car at full speed unless he is convinced he will be able to slow down in time to make the next corner!

These days we look at the causes of the financial crisis and the actions to be taken to ensure it does not happen again. There seems to be consensus that Governance and Risk mechanisms have failed in the financial sector. Regarding the solutions the discussion often turns towards the (according to some excessively) high bonuses customary in the financial sector and the need to limit these. Interesting to notice that the amounts of the employee remunerations are not a primary focus point of any of the Governance and Risk models and regulations I checked (amongst others COSO ERM, OECD Principles of Corporate Governance, Basel II, ISO 38500). The Cadbury report does address the issue but comes with the following statement: "The Committee has received proposals for giving shareholders the opportunity to determine matters such as directors' pay at general meetings, but does not see how these suggestions could be made workable." Do the models and regulations have a blind spot on the issue? One could argue that (IT) Governance and Risk models and regulations do target organizational objectives and since bonuses (in general) are connected to achieving objectives there is a causal connection between the two. However this would not explain why the discussion only focuses on the height of the bonuses. One would expect the discussion to focus on the circumstances under which bonuses are awarded, not primarily the values.


It is understandable how the high financial bonuses are at the core of the public discussion since they speak to the imagination of the public and are sure to create public outrage: "Make so much money for yourself and loose so much money for the rest of the world". To exclusively focus on the amounts keeps it simple and understandable for the general public. For opportunistic politicians and press the opportunity is just too good to pass. Though I do not want to defend the bad apples we should not forget that it was the financial sector that made the economic boom of the last decades possible by creating new financial products that made more investment capital available to a wider audience. It is the COD's that made mortgages more widely available and made home-ownership possible for a bigger percentage of the population. These and other financial instruments that were eventually misused and are partially the cause of the disaster did initially do very good things. As long as the financial sector supported and fuelled the economic boom nobody seemed to care that they made a "good living" for their effort.


There is one reason to discuss the height of the bonuses and this is a basic law of security and control: The higher the possible benefits the bigger the temptation to break the rules to achieve them. As a result a bank is normally better protected against robbery than, let's say, a poor man's home. One response is to try and limit the possible benefits of misbehaviour (lower the bonuses). But it is a fact that the financial whiz kids who earn these incredible bonuses make even more money for their employers and they are in short supply. So unless you want to rethink the fundamental concept of capitalism any solution that might get implemented will go directly against the basic supply-and-demand law of economics (High demand for items in short supply will drive the price up).


There is however another approach. As we noted in the beginning, currently risk management is seen as a limiting factor on maximising growth and profit. The basic attitude seems to be: Don't do it because it is too risky. However an alternative approach would be to make target correction based on inherent risk. We all know this attitude: The better your financial situation and past history the better terms you are offered on new credits (Getting a loan or a new credit card is much more expensive for a person who went bankrupt in the past). In the stock market we expect a better return on investment for venture capital when compared to an investment in a blue-chip fund. As the Greek government learned the hard way in recent days a triple-A rated government bond does not have to offer as much interest as a bond of a less reputable (and thus lower rated) government to attract investors.


Could we use that principle elsewhere? If we look at the Investment portfolio for (IT enabled) organizational investments, for instance, we could look at introducing a risk-rating system for each of the proposed investments. The (financial) goals, for instance the expected return on investment, could be adjusted based on the project risk rating. If we came up with a rating system that factored in the past performance of the key-project personal like project and program managers etc. we could use that as the bases to steer risk-aware behaviour of these people. Risk aware attitudes would translate towards better (financial) goals and targets. Since these targets in general form the bases for the bonuses earned this would mean bonuses are inherently connected towards risk attitude. This is just one example. An risk aware culture that better aligns benefit and sanction instead of perceiving these two as two seperate worlds can be achieved in multiple ways.


Too often I encounter organization with on the one side a focus on performance management, goal setting, monitoring, etc. and this would include the remuneration for good performance. On the other side (in complete isolation) there is the governance; risk and compliance (GRC) function. They are trying to limited the risk exposure and ensure organizational compliance. Operating in isolation from performance management they do not have the "weapon" of remuneration (and bonuses) to stimulate desired behaviour. All GRC is left with is sanctions to stop unwanted risky behaviour. If these sanctions are perceived to stand in the way of achieving the bonus benefits one can clearly recognise the basis for possible future disaster.


Bottom line: There is so much to align, in this case performance and risk management

Tuesday, December 7, 2010

So you think you are compliant

Article originally posted on: Computerworld UK

Remember, risk management does not necessarily mean risk elimination.

Organisational compliance is not a “black and white”, “yes or no” status but a “more or less”, “better or worse” continuous scale. Organisations that are 100% certain of organisational compliance should verify their belief by considering the questions in this article.

First the article title, you might have recognised the reference to a television show called “So you think you can dance?”. I am not a big fan of the show but I love the title. For me it holds both a challenge for the contenders to show “their stuff” combined with a high-level of “who do you think you are to think you are good enough to appear before us?” arrogance. And indeed, as expected, self-appointed experts and has-been celebrities in the jury will cut overconfident no-talent participants down to size.
Too often I have to think about this image when I see (IT) auditors’ fresh out of school present their audit findings passing judgement over the organisational compliance effort. Please do not misunderstand me, there is nothing wrong with the auditing profession as such, but at times we seem to forget that the audit reports describes the auditors’ opinion not the absolute truth.
I have no respect for auditors that think they can pass final (and absolute) judgement on the workings of an organisation based on a two week (or even shorter) audit period. Yes they might be able to find examples of what went wrong in the operations. And a good auditor will be able to form an opinion about the mentality and culture of the organisation in such a time frame.
However a great auditor will be the first to admit that his report is just an opinion. He will discuss his findings with the organisation he investigated and more importantly will have an open mind for arguments that might change his opinion.
Too often the equality between auditor and audited department is gone. It is the same with these talent shows, if the performance is ridiculously bad it might be warranted to put somebody “out of his misery”. However when it comes to judging those that clearly show promise and commitment judges should discuss “opportunities for improvement” instead of passing “final verdict”.
Granted, where the purpose of the audit is to assure compliance with an individual regulation or to issue certification to a standard, the end result will be a pass or fail “bottom-line” statement. My comment is related to the relationship and attitudes during the assurance process to deliver that verdict.

So when assessing the compliance status of your organisation there are a number of questions you should consider. By answering them truthfully you will probably find that 100% certainty of organisational compliance is both impossible and if possible undesirable.
Compliance is a requirement; somebody wants your organisation or department to comply with a set of rules and/ or regulations. For instance the financial administration of an organisation that handles credit card transactions has to comply with the rules set by the credit card companies (PCI-DSS). In turn the administration will have to articulate the security requirements for their relevant IT-services to the IT Department. In the same manner the finance department will react to the Sox regulations (if applicable). The HR and Marketing/ Sales departments might require compliance with Data Privacy regulations. The logistics department may have requirements based on import/ export regulations.
Off course IT itself has to comply with software and hardware license requirements. We have the requirements originating for fire, health and (personal) security. The industry specific regulations for instance Basel II for finance or Hipaa for US Health Care organisations might be an issue. There are local regulations regarding building, parking, signage, etc., etc. Just to name a few.
The list of organisational stakeholders with rules and regulations to comply with is endless. So how sure are you that you know all the compliance requirements you are supposed to meet as an organisation or department? When answering this question it is important to realise: To be 100% certain you know all applicable rules and regulations you would need infinite resources to keep checking with every possible stakeholder.

This is the first compliance risk: Not knowing of the existence of the requirement.

So 100% certainty is both impossible and undesirable since one has or would want to spend infinite resources. The real question then becomes what is your organisational risk posture? How much risk are you willing to accept? And how much are you willing to invest to mitigate the risk of non-compliance due to unawareness?

Most rules and regulations are created with the best intentions. That is, to try and limit the change that an undesirable event or situation occurs. But there are places were rules and regulations are created to support corruption.
The basic idea is that the requirements of these regulations are purposely impossible to meet and the only way not to get punished for non-compliance is to bribe those who create and enforce those rules. I have experienced these situations in the past and basically non-compliance and bribery is an accepted part of doing business in these places. Trying to achieve your goals in a fully compliant manner is a very expensive, inefficient, if not impossible task. Even more so in some cases, where it might put the organisation in an undesirable competitive disadvantage.
These days I see non-bribery policies with more and more (multi-national) organisations some of them active in these kinds of places. In a number of instances I believe the policy is more about “don’t ask don’t tell” than anything else. It is not my intention to advocate bribery but we do live in the real world and an ostrich should not claim 100% certainty of compliance.

Assuming the intentions behind the regulations are good that does not mean the actual requirements are clear. Many laws and regulations are supposed to last over a longer period of time and cover a wide area. It would be impractical to describe the do’s and don’ts for each individual situation and even impossible to predict how the situation will evolve over time. As a result numerous rules and regulations are purposely written with room for interpretation. It is left to the individual judges and juries to fine-tune the rules by creating jurisprudence. But until jurisprudence has been created there is no way to be 100% certain what the exact requirements are.

This is the second risk of compliance, the risk of misinterpretation of the requirements.

It is always good to get assistance of a regulations expert when assessing the requirements of individual regulations. Expert involvement will reduce the risk of misinterpretation. However in a number of cases all an expert can offer is an expert opinion which is not the same as the absolute truth.
Again, risk management offers additional means to manage this risk. The risk avoidance response would suggest you adopt a “worse case” interpretation of the rules and act accordingly. In this case the chances the judge and jury rules the organisation broke the rules is clearly lower than when the organisation “lives close to the edge”. However rules and regulations, by nature, limit the organisational flexibility and agility. They limit the number of possible responses to a given situation. So again, the organisational risk appetite for non-compliance due to misinterpretation is important. In turn this will tell “how close to the edge” the organisation is willing to operate.

Once we know what the applicable rules and subsequent requirements are the daily compliance of the operational organisations is ensured by creating policies, processes, controls and procedures. These tell individual employees how to conduct their tasks and duties so they do not (inadvertently) break the rules. Everybody knows however people can have unexpected behaviour that deviates from the described actions. In this context it is important to realise often such a deviation is for the best of reasons and not always because of ignorance, fault or malice.

So the third risk of compliance is deviation from design/ expected actions resulting in breaking the rules.

By training, testing, coaching, etc. we can mitigate the risk of unexpected/ undesirable actions by man or machine. But again this is a risk: How much uncertainty is the organisation willing to accept? How many resources will the organisation make available to mitigate the risk? With people there is another consideration.
We value the creativity of people, in this context I mean their ability to think of actions and solutions for unexpected situations. But if the situation is unplanned for the reaction as a result of human creativity is clearly unplanned for as well. So the creativity we value so much might easily be at odds with organisational compliance.
The only way to ensure actions resulting from on the spot creativity align with the compliance requirements is to make sure people do not only understand what they should or should not do but also why.
What are the underpinning regulations and requirements? Based on that knowledge those on the spot can than decide on creative solutions that fit within the regulatory requirements. Empowering people with that kind of knowledge means you can enhance the flexibility and agility of your organisation while ensuring a higher certainty of organisational compliance. But again this empowerment can be resource intense so once more the organisation needs to strike a balance between empowerment (lowering the risk of non-compliance) and the cost involved.

What is the consequence of non-compliance?
The moral of this article is that Compliance is a requirement and non-compliance is a risk and should be treated accordingly. In the same way we cannot exclude all risk from the organisation, 100% certainty of organisational compliance is an illusion. Any organisation will have to think about the level of non-compliance risk it is willing to accept.
A popular way to categorise risk is to look at both likelihood and impact. Identifying the sources of uncertainty is the first step to assess likelihood. I have seen strategic statements and policies that claim “the organisation will comply with all applicable regulation” or something to the same effect.
What this statement does not say but what is does imply is “at all cost”. In practise however most organisations will assess the impact of public non-compliance. They will look at possible fines, reputational damage and other possible negative consequences. Even though very few organisations will come out and say it, they will look at the negative consequences of non-compliance before they decide how many resources are committed to ensure compliance (and thus mitigate the risk of non compliance).
At one time I came across a courier that made speed of delivery their unique selling point. They worked for broadcast companies for example. They ensured the fasted possible transfer of physical news footage arriving at the airport to the television studios. Before the digital age, with breaking news, this transfer time was a valuable commodity. So valuable even that the drivers were instructed (never in writing off course) to break traffic regulations in favour of speed and the company would cover the possible fines.
There are very few people that live by the credo that “everything goes as long as you do not get caught”. On the other hand there are very few people that will ensure compliance at all cost. For organisations risk (of non-compliance) is just another risk that they should manage but risk management does not necessarily mean risk elimination.

Thursday, September 23, 2010

The primary trait required for Governance: Wisdom

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

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

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.