Fundamental Conceptions Of Information As Applied to Identity Logistics – Chapter 5. © Carlos Trigoso 2012-2013
Surveying the Landscape of Failure
This is perhaps the most difficult chapter of this book, not because of the theories involved, and also not because it reveals conceptual problems in the Security disciplines (which we have covered to some extent), but because it looks into the greater problem that is at the bottom
– not of our thinking, but of our practice.
I refer to the delivery of IT and security solutions, at a project or portfolio level (IT programmes) where the problems I see are most relevant. The context is the interaction between the IT department experts and teams and the business units they work for. Here the IT teams and specialists are the service suppliers, and the business departments are the clients or consumers of the service. This distinction was not there all the time: the idea of the IT departments as suppliers of a service is itself the product of history, of the interaction with business processes and requirements along the last half of the 20th century. I think that the development of strong process-orientated doctrines as ITIL and BS7799 and COBIT all correspond to this experience, i.e. to a concerted effort to bring order and control to the interactions between the IT sphere and the business stakeholders and clients of IT.
Simultaneously we have seen the development and consolidation of pure project management disciplines like the PMP, PRINCE2, and others, and design and governance methods like TOGAF. All of this is obviously positive and signals a gradual maturation of the IT management-related practices. I have always encouraged their study, while at the same time cautioning about the proliferation of methods and tools, and also the incompleteness of some of these in respect to Security concerns. A greater concern though is that no matter how many of these methods are implanted and detailed, the history of IT project and programme delivery is a history of failure. To be more precise, this is a history of the “management of failure.”
There should be no confusion regarding what to expect or think of Project and Programme management, both in the public and private sectors. There are different drivers–“value for money” in the first case, and “profit” in the second— but when it comes to IT initiatives, Programme and Project management are identical in their approach. In my experience, Security projects, including Identity management, are similar in this respect.
In a recent article in CIO Update, Jeff Montefortei summarised the standard project approach very well: “At the most basic level, the objective of managing an IT project portfolio is performing a business case and return-on-investment (ROI) analysis for all proposed projects. Because the focus is on investment and return, the project portfolio governs and includes current and requested IT projects intended to improve or grow the business. […] The desired
result of maintaining a project portfolio is to align the technology investment funds, the IT resources, and the IT project work with organizational business priorities. Each project is scrutinized for the ROI it can bring the organization, how it supports the current priorities of the company, and how much potential risk of failure is inherently associated with the project.”
All IT and Security managers and experts will recognise this approach, but also vouch for it, as we have learned in decades of work that there must be “alignment” with the business objectives. All the methods mentioned before are, in fact, ways to “align” IT with the project delivery process and the overarching organizational objectives. This certainly sounds obvious to everybody but why was and still is there a need for alignment? Is this a problem specific to IT? Has it been resolved?
To answer the first question, I believe that this is not a problem specific to IT or Security management in particular. It can be seen in all areas of technology as applied to business operations. The effort to “align” technology to organisational processes and value-driven controls is older and wider than those applied to IT. On the other hand, the results of this pressure towards alignment were particularly poor for decades and hence IT has stood out as a problem area. Perhaps this also explains the variety of methods and “standards” that have been developed to refocus IT in the mould of business and organisational objectives.
The problem has not been resolved, though, and this shows in the project failure statistics that are well known but rarely spoken about in our industry. Michael Krigsman quotes an interesting study by Genecaii in his ZDNET columniii: “Most significantly, the report describes a highly negative situation in which most respondents expect their project to fail before it even starts!” For example, 78% of the respondents, out of a total of 596 business and it professionals, believe that “the business” (code word for business management or business unit leads) is “usually or always out of sync” (meaning out of sync with the IT teams and experts). Krigsman highlights that 75% of the respondents “admit their projects are usually or always doomed from the start.”
“Doomed from the start” – a phrase that seems almost too harsh, and one that an objective observer may feel is not warranted – is nevertheless appropriate according to my experience across the IT professions and in Security and Identity management in particular. For example, in 2002 I made my own analysisiv of hundreds of Security projects in Europe while working for a major hardware and software vendor and found that over 70% of the software projects had experienced large delays leading in many cases to suspension or cancellation. To my surprise, only a small percentage of these problems were caused by software or hardware errors. The main cause of failure was generally “lack of alignment” between the business goals and the delivery of technical capabilities. I would not have seen Krigsman’ s article as meaningful if it had not had relevance for my own experience, and I challenge any IT or Security specialist that may read this to deny that it is the case that we are swamped by project failures and lack of valuable results.
Personal experience—even if it is extensive– or references, even if these are from keen and reputable observers of the Industry, like Krigsman, can be disputed by questioning the definition of project failure- for example by asserting that a project is not a failure if the project manager or the business unit cut it short just in time to avoid losses. Some diversion is also caused by the notion that business should tend to “fail fast” in a trial and error process, while progressing towards some target. All of that is fine and makes sense if you move within the rules of the permanent conflict between “the business” and “IT” – that is, if you accept that there is a gap, and that it is perhaps the mission of the Programme and or Project manager to cut the wings of some incurable IT technologists who want to spend money without end.
Is this a realistic picture of what is happening? Programme and Project managers are somehow heroic business-orientated people who stop the abuses of so many IT dreamers? Or, is it the case that, as we say in our profession: “the business does not ‘get’ technology.” My answer is that there is no innocent party in this case, and that both those who ‘get’ IT and those who don’t are complementary actors in the story. In other words, the misalignment is real. The reader should remember that everything that is applicable information technologies is also valid for Security and Identity management, with special characteristics that I will highlight towards the end of this analysis.
Decade after decade we have seen statistics showing the problems in IT delivery. Some of the older sources, like the 1995 Chaos Reportv (Standish Group), reveal 31.1% of projects will be cancelled before they get completed, and 52.7% of projects will cost over 189% of the original estimates. These figures have been criticised by academics and industry experts. For example Laurenz Eveleens and Chris Verhoefvi, of Vrije Universiteit (Amsterdam) reject the classification and estimation assumptions of the 1994vii Chaos survey which “reported a shocking 16% project success rate, another 53% of the projects were challenged, and 31% failed outright.” It is important to note that these figures (as all the Chaos report statistics) refer to software implementations. The authors challenge the report’s definitions of successful, challenged and impaired projects.
Eveleens and Verhoef write: “[…] Standish defines a project as a success based on how well it did with respect to its original estimates of the amount of cost, time, and functionality. Therefore, the Standish “successful” and “challenged” definitions are equivalent to the following: Resolution Type 1, or project success. The project is completed, the forecast to actual ratios (f/a) of cost and time are ≥1, and the f/a ratio of the amount of functionality is
≤1. Resolution Type 2 or project challenged. The project is completed and operational, but f/a
< 1 for cost and time and f/a > 1 for the amount of functionality.”viii
This challenge is justified, as we would also expect that the success or failure definitions could handle all possible cases, including those where the project is within budget but is nevertheless “challenged” in terms of functionality. Regrettably the study by Eveleens and Verhoef shows its own limitations when they declare: “In reality, the part of a project’s
success that’s related to estimation deviation is highly context-dependent. In some contexts, 25% estimation error does no harm and doesn’t impact what we would normally consider project success. In other contexts, only 5% overrun would cause much harm and make the project challenged. In that sense, there’s no way around including more context (or totally different definitions) when assessing successful and challenged projects. However, the Standish definitions don’t consider a software development project’s context, such as usefulness, profit, and user satisfaction.”
That, sadly, leads the researchers into a peculiar path of trying to determine “forecast bias” and trying to assess factors that correct the bias in the forecast, by which then they obtain lesser failure rates. This is not what we, the IT and Security practitioners would consider a good approach to replace the original Standish reports; it even reveals that probably many organisations are “forecasting” delivery costs inaccurately! At the same time, what do we make of a project where the costs have a 25% deviation? Should we consider a 15% deviation as “best in class” as the authors suggest?ix Yes, more “context” is necessary, but the lack of appropriate measures for “usefulness, profit and user satisfaction” is an obstacle, and this has not been addressed by this study or other critics of the Standish Group work and similar reports. How are the Programme and Project managers going to address usefulness and satisfaction if it is not backed by standard, organisational quality controls, as there is no universal quality measurement? How do we measure for example an Identity management solution? Does it contribute to user satisfaction or should we focus on data availability? How are the programme and project managers going to judge delivery costs if not by numerical comparison of cost projection and aggregated real costs? Organisations may differ in their cost forecasting methodologies, but is it not always the case that there are organisational biases in forecasting that can’t be reduced to some standard?
So when we read estimates or judge our own experience in respect to project success we are not doing a mathematical calculation but a subjective judgement, already specific to the context (i.e. the organisation being considered) and not trying to formulate a general law. In reality, the Standish Group and other organisations have done a great service in focusing attention to poor results in project delivery. While other researchers’ results are different in the detail, the overall difficult and concerning situation is the same.
People should certainly be careful when quoting the Chaos report or similar studies, considering that these are mostly surveys or based on limited samples of the IT industry project landscape. It should also be clear that we are seeing aggregate data, and very different questionnaire techniques which may not lead to “scientific” results, but it is also true that almost any survey and any study of this matter brings up alarming results, and this after decades of development of the methods supposedly driven to avoid this kind of failure. In this respect, the words credited to Martin Cobb, Chief Information Officer of the Branch Treasury Board of Canada Secretariat, still stand unchallenged: “We know why projects fail; we know
how to prevent their failure, so why do they still fail?”x Moreover, there are many other
sources that point in the same direction. Let’s look at some here:
· A study by Dr John McManus and Dr Trevor Wood-Harper of the British Computer Society covering years 1998-2005 and 214 information systems development projects in Europe found that only one in ten projects could be considered successful, i.e. not over budget or unable to deliver required functionality.xi
· Joe Harley, the Chief Information Officer at the Department for Work and Pensions (UK), revealed that “only 30%” of technology-based projects and programmes are a success – at a time when taxes are funding a £14bn spend annually on public sector IT.xii
· A KPMG study in 2005 showed that “A quarter of the benefits of IT projects are being lost by organisations across the globe because of management failures during a project’s lifecycle […] KPMG International’s survey of 600 organisations across 22 countries revealed that 86% of respondents reported the loss of up to a quarter of their targeted benefits across their project portfolios. Nearly half of respondents reported at least one project failure in the past year, an improvement from KPMG’s 2003 survey where 57% experienced one or more project failures in the previous 12 months.”xiii This reference is relevant as KPMG reports that success is being defined in terms of business benefits delivery instead of using only time and budget parameters.
· Chris Sauer, Andrew Gemino, and Blaize Horner Reich found that one third of IT projects fail.xiv The researchers interviewed project managers, instead of business executives, as the Chaos Report did, leading to different failure rates overall. The authors write: “Surprisingly, we found that one-quarter of projects underperform however small their size. Even projects with budget less than £50,000, effort less than 24 person-months, duration shorter than six months, or team size of less than five experienced 25% risk. There is a significant level of risk regardless of size.”
· A study of 100 Fortune 500 companies by Keith Ellis, IAG Consulting,xv in 2008, notes that “68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group’s projects were “runaways” which had any 2 of: taking over 180% of target time to deliver; consuming in excess of 160% of estimated budget; or delivering under 70% of the target required functionality.”
· Scott Ambler, writing about a sample of 203 projects in Dr Dobb’s Journal, states that “According to the 2010 IT Project Success Survey, our success rates are: Ad-hoc projects: 49% are successful, 37% are challenged, and 14% are failures. Iterative projects: 61% are successful, 28% are challenged, and 11% are failures. Agile projects: 60% are successful, 28% are challenged, and 12% are failures. Traditional projects: 47% are successful, 36% are challenged, and 17% are failures.”xvi It is important to note that Ambler’s focus is strictly on software development projects.
These are only some examples of a vast number of sources of very different theme and quality, but all pointing in the same direction discussed here: it can be asserted with great certainty that the status of programme and project delivery is problematic and requires further investigation.xvii
Above all, considering the variability between sources, the limitations of the surveys in size and quality, and the diversity of areas covered, it is decisive to focus on the types of problems detected. In other words, while it will be very difficult to get a complete quantitative understanding of the problem, or a common measuring technique, we can have a view of the common causes of programme and project failure.
The Causes of Failure
Perhaps the best summary of these causes was published by the British Computer Society in the study cited above.xviii Their classification is very detailed, so we will centre our attention on the “key reasons” for project cancellation:
• Business strategy superseded
• Business processes change (poor alignment)
• Poor requirements management
• Business benefits not clearly communicated or overstated
• Failure of parent company to deliver
• Governance issues within the contract
• Higher cost of capital
• Inability to provide investment capital
• Inappropriate disaster recovery
• Misuse of financial resources
• Overspends in excess of agreed budgets
• Poor project board composition
• Take-over of client firm
• Too big a project portfolio
Together with these factors, the authors of the BCS study also list management and technical reasons, among others the following:
• Ability to adapt to new resource combinations
• Differences between management and client
• Inappropriate architecture
• Inappropriate coding language
• Inappropriate technical methodologies
• Inappropriate testing tools
• Insufficient domain knowledge
• Insufficient end-user management
• Insufficient reuse of existing technical objects
• Insufficient risk management
• Insufficient software metrics
• Insufficient training of users
• Lack of formal technical standards
• Lack of technical innovation (obsolescence)
• Misstatement of technical risk
• Obsolescence of technology
In the whole, McManus and Harper seem justified in writing in their conclusions a harsh assessment of the situation: “On examination of the project stage reports it became apparent that many project managers plan for failure rather than success. If we consider the inherent
complexity of risk associated with software project delivery it is not too surprising that only a small number of projects are delivered to the original time, cost, and quality requirements. Our evidence suggests that the culture within many organisations is often such that leadership, stakeholder and risk management issues are not factored into projects early on and in many instances cannot formally be written down for political reasons and are rarely discussed openly at project board or steering group meetings although they may be discussed at length behind closed doors.[…]One of the major weaknesses uncovered during the analysis was the total reliance placed on project and development methodologies. One explanation for the reliance on methodology is the absence of leadership within the delivery process.”xix Let’s see other classifications that are equally relevant. In a study by PM Solutions,xx the researchers found that the main causes of failure were:
· Unclear requirements, lack of agreement, lack of priority, contradictory, ambiguous or imprecisely defined
· Lack of resources, resource conflicts, turnover of key resources, and poor planning
· Tight schedules, unrealistic and overly optimistic goals
· Planning based on insufficient data, missing items, insufficient details, and poor estimates
· Unidentified risks, assumed but not managed
Overall, I find that this list precisely suggests the type of problems indicated in the BCS study, hinging on lack of business (not IT) leadership of the delivery process. If we judge this by the more or less standard success criteria defined by J. Kent Crawfordxxi in his book The Strategic Project Office,xxii we have a better grasp of what is going wrong as we could rewrite these criteria for a large number of organisations as follows:
· The organisation’s strategies are not executed according to plan
· The organisation’s shareholders are not satisfied with the IT investment/benefit ratio
· A large percentage of the IT projects are not completed on schedule and on budget
· The IT project internal clients are not satisfied
· Project resources are not allocated optimally
· IT projects are not aligned to the organisation’s business strategies
· The organisation does not work on the right IT projects in a significant number of cases
In essence, my point is that we are looking neither at IT or Programme Management failures. As the BCS study says, actually we are seeing an excessive reliance on “management processes” if not even “anticipation of failure.” On the side of IT, we know that it is not a matter of refusing alignment with the business, a goal that is now very entrenched in every segment of the IT professions. Contrary to this, frustration in the IT and expert teams stems from a general lack of communication and leadership at an organisational level.
The Office of Government Commerce (OGC, UK) has summarised the causes of project failure as follows, pointing again to issues rooted in lack of leadership and failed business and IT alignment:xxiii
· Lack of clear link between the project and the organisation’s key strategic priorities, including agreed measures of success.
· Lack of clear senior management and Ministerial ownership and leadership.
· Lack of effective engagement with stakeholders.
· Lack of skills and proven approach to project management and risk management.
· Too little attention to breaking development and implementation into manageable steps.
· Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).
· Lack of understanding of and contact with the supply industry at senior levels in the organisation.
· Lack of effective project team integration between clients, the supplier team and the supply chain.
In other words, IT Programme and Project failures are organisational failures not peculiar to the IT areas themselves, but more prevalent in these. Although this discussion has taken many pages, I think it was necessary to set the stage for what follows.
IT and Information Security as Business Sub-Systems
I believe that nobody would be surprised if I said that the explanation of these issues lies in seeing IT –and IT Security within it— as a sub-system of the organisation. This must be refined and explained to understand that the term sub-system does not mean here that IT is “part” of the organisation. I go further in saying that IT security is not part of IT either, and this requires even more explanation.
As I wrote in previous chapters, Identity management is dependent on Security initiatives; Security, in turn, is dependent on IT and IT is dependent on Business programmes, but being dependent on something does not mean “being part of it.” Strictly a part of a whole implies some form of inclusion, while my contention is that neither IT nor IT Security are “part” of the business in this sense. In other words, these are not included in business models or operations. In my view, IT operations are a sub-system only in the sense that our processes and activities are coupled or linked to business operations, but both realms are self-contained and are different communication systems.
Not only the conceptual differentiations of one and the other system are separate, but there is in fact no common language across the boundary between these two areas. Even more, if we look into the IT departments themselves, we will see various sub-disciplines that do not share the same distinctions and conceptual frameworks. I put special emphasis on Security and Identity but it is clear to me that other areas can be equally investigated as having a closed language and specific self-referring processes which are foreign to the other areas in the organisation.
It would be an error to consider that this state is the product of some confusion or lack of understanding. Quite the contrary, most of the issues revealed in the failure statistics can be seen as inevitable effects of the interaction of these separate, self-contained sub-systems.
Either when the exasperated IT experts declare that the business does not ‘get’ technology or when the business lead stops listening to an IT department that does not ‘get’ the business goals, what we should see there is not a failure in communication, but the normal state of communication between these parties. This “normal” state is generally one of “hostile cooperation” and lack of common goals.
As Will McWhinneyxxiv explains, we (the organisation’s actors) create a large part of our problems and issues in the act of trying to resolve them, and our efforts yield unintentional results. I think that this is meaningful in more than one sense. For example, a deeper understanding of the permanent misalignment of IT and Business would lead to new success criteria, where a solution would be measured by the degree “in which it frees the organisation from one or another side of the dilemma it does not create new problems,” according to McWhinney.
This is insightful, because problems are solved with resources (as every programme manager knows), but then the attempts to solve problems involving teams and individuals who hold different world-views leads to new problems. So for example the adoption of IT technologies in organisations, initially intended to solve administrative or production problems, in all cases leads to new unexpected issues across the organisation. It is not as the techno-optimist would say that the systems were not properly designed or were delivered late, but that the systems could not be delivered much better in any case.
This is not a pessimistic view though. Excellent delivery is possible but it will be the exception, not the rule. At the basis of this understanding is the notion that every aspect of an organisation is contingent (i.e. not necessary or predetermined), but dependent on the correlations between the organisational actors, as shown by the German sociologist Niklas Luhmann.xxv
The attempt to solve a problem involving people who hold different perspectives creates new problems, as McWhinney says, and the organisation becomes a self-generator of problems. The contingencies of human organisations and communication sub-systems become inevitabilities of conflict and failure. It is not true that projects are “doomed to failure” from the beginning, but it is true that most IT projects will fail or deliver the wrong solution at the wrong cost and at the wrong time.
Looking towards other areas of the organisation, we can see that there are also inevitable frictions between its sub-systems and the “external” consultancy organisations that are hired to support various activities. This is a critical point of the systemic view of the organisation. In the same way as individuals are not “part” of societies (in the Luhmannian sense), they are also not part of other sociality levels, i.e. “lower” levels of human organisation and communication structures between individuals and groups.
Between these units, each of which has an “operational closure,” there is no transfer of meaning or “information flow.” As a consequence of this discontinuity, there is a need for paradoxical action and the use of interactions or “couplings.” It is this we should seek when aiming at excellence in delivery, and not just compliance with specified processes. In other words, excellence is achieved through the contradictions in the organisation, and not through the elimination of these contradictions.
In the terms that I have been proposing for the articulation of Security programmes, excellence in delivery is achieved through the correlation and contraposition of disparate but complementary goals of each of the perspectives: Direction, Selection, Protection and Verification. Here, the role of the business which I labelled as the “missing discourse” in Chapter 1 pertains to the perspective of Direction. It is therefore essential to assume as a fact that the disciplines of Direction are contradictory with those of protection (generally aligned with the techno-centric emphasis of the IT departments).
Ultimately the cause of these contradictions is none other than the constant progress of division of labour within the organisation, which is itself a product of capitalistic development at economic and social levels. These differences within differences are specialisations of groups and opinions (which I call “perspectives”), and consist of logical derivatives of communication sub-systems within the organisation. This allows us to understand too that periods of rapid change such as the one we live in, with the continuous adoption of technologies by business organisations, create a permanently unstable ground. Business seeks mobility, investment agility, cost reductions, globalisation of markets, and in this context they test and adopt any mechanism, any technology that may enable some advantage in the market. Not all technologies succeed in this sense, and also competitors adopt the same differentiators successively reducing the initial advantage. In this way, the cycle of technology adoption –leading now towards IT outsourcing and cloud-based computing—does not settle down.
New technologies also suit an increased, in many cases global, mobility of personnel and consumers. All of which leaves the IT organisations behind, always chasing the next move by the business. Can IT deliver? Can IT be secure in this context? In everything we have covered in this chapter we find multiple circles of causes and effects that superficially look like a tendency towards failure in IT Programme and Project delivery, but are really an inevitable consequence of the bounded interaction, the contradictions between the various sub- systems of the organisation. These contradictions show in paradoxical results, when the IT departments “fail to deliver” or when IT security creates new probabilities for insecure information management by opening more and more channels in the desperate attempt to “serve the business.”
Security and Identity Investment Decisions
If we review retrospectively the IT press for the past two decades, we see how opinions have changed. What was the main problem being discussed in in IT Security in 1995? What was the
main solution? If we focus on investment levels for example, we notice that for about half that period the predominant opinion was that the Security investment levels were too low. In the second half the opinions tended to be IT investment levels were rising quite fast and probably were reaching a plateau. There were the usual alerts about small and medium-sized organisations where Security investment was deemed still to be too low, but the consensus was that large organisations were spending between 8 and 12 per cent of their IT budgets in Information Security.
Paul Strassman,xxvi a long-time researcher in IT security from the point of view of corporate management, even alerted his readers that exceeding 10 per cent of the IT budget might indicate poor investment criteria and bad results. Along the period reviewed, there was a consistent effort from the side of the industry and even academia to substantiate investment in security. It seems to me that this effort was successful in demonstrating that investment levels were “too high” by focusing on showing problems in the “return” of Security investments. Several theories arose, but the dominant one was the so-called “risk-based security investment analysis,” which I have discussed in previous chapters.
It is almost impossible to find a critical view of risk-based analysis, outside of the works by Donn Parker,xxvii Gurpreet Singh Dhillon,xxviii and James Backhouse.xxix Nevertheless, the dominance of risk-based Security –which corresponds to the prevalent techno-centric perspective – is not absolute, and along the entire period it is possible to find other paradigms at play. This has been shown by Dr. Elspeth McFadzean, Dr. Jean-Noël Ezingeard, and Professor David Birchallxxx in an important study on research paradigms in Security and Governance. The authors use the well-known Burrell-Morgan paradigmatic model which has been very successful in Sociological research.xxxi
I am concerned here with the dominant paradigm, which I classify as “mechanistic,” not because I seek a “paradigm shift” from this towards any of the other fundamental perspectives, but because I want to promote competition and co-operation of the four key Root Metaphors (in the terminology of Stephen C. Pepper). It is my opinion that the lack of balance, competition and cooperation, the deeply-rooted presumption that the only mechanism is a valid computer science and information technology approach, has had a harmful effect on our profession and all types of organisations.
Once we move away from the idealistic conceptions that seek some form of pure “communication” between the various aspects of the business and understand that each paradigm is represented by a closed sub-system as explained in previous sections, we have more chances of achieving solutions that represent the correlated interests of these groups and tendencies. It would be a benign assumption that these perspectives should be purposefully combined; avoiding for example the unilateral sway of the techno-centric Security “Protection” approaches; but this would not be realistic. A better take on this matter recommends a combination of cooperation and competition, and hopefully not “hostile cooperation” which is the status we have now.
In an extreme form without competition and control from the other perspectives, any one of them degenerates into a formula, a fragmented view of reality that is not capable of holding the organisation together. For example, the mechanistic paradigm in security will insist on “protecting information assets” and “establishing a perimeter protection” around these, when the other tendencies of the organisation call for wider circulation of information and do not operate within “perimeters” anymore. On its side, the “Direction” perspective, unable to compete and cooperate with the others, will continuously miss investment opportunities, thereby producing the usual silo-orientated approach that we see in so many organisations where each business unit operates almost a private IT environment.
We have seen already how risk-based Security has serious limitations, but we can add to these even more. A key one is that risk-analysis cannot be extended to the whole organisation. Consider for example how difficult it would be to blend into one risk framework valid Security issues as different as compliance (associated to the Verification perspective), user access control (pertaining to the Selection perspective), and trust management (addressed by the Direction perspective). If even within the “attack and defence” logic of the mechanistic paradigm it is impossible to calculate objective probabilities, consider the meaninglessness of trying to “calculate” risk values for a combination of the four fundamental paradigms at play in organisations.
This has immediate relevance for Programme and Project delivery as it refers to the notions of alignment and business objectives. Information security expenditures can be considered as being part of business investments when they enable processes, when they help complete value chains, open markets, deliver services and goods; but seen from a different perspective, they are operational expenditures and similar to building maintenance or office overhead outlays. A detailed analysis of any Security investment rapidly leads to seeing them as having multiple direct and indirect, as well as financial and non-financial, results or “impacts.”xxxii
 |
Four classes of benefits of Identity Management solutions
Therefore Security programmes and expenditures contribute to the overall returns on capital allocations, but there is no ROI or “return on investment” for Security allocations per se. It is still fashionable to speak about ROI on Security as experts try to adopt and mimic the “language of business,” but this is a fruitless effort to date. This is only the product of our training, whereby we have learned that we have to be aligned with the business leadership and teams, but we fail because we adopt that language while still talking to ourselves and see only the side of risk avoidance (i.e. protection) and ignore the risk-taking side, which is the realm of Direction and the discourse of the Master.
For sure, there are some important interpretations of this, more or less useful for project financial justifications, but this falls into the trap of positioning Security again as expenditure, a pure cost, unrelated to the business and aiming at most at some cost-savings or cost avoidance. From the strict point of view of capitalist microeconomics it is not possible to derive capital returns from Security expenditures. Hence Programme and Project management will operate “by the book,” “align with the business” and still deliver poor results. Or, as the BCS report remarked: “manage for failure.” Helping to compose the problem, the IT and Security experts will happily sign off the project deliverables, without knowing what value is being delivered for the organisation, insisting, as we always do, on the mechanistic protection of “information assets” – but these have no value unless they are trusted to others and not only “protected.” The effect of these misunderstandings and obscure “collaboration” in failure is enormous, as it settles the organisation in year after year of dreary routines and underachieving teams.
The Value of IT
Matt E. Thatcher and David E. Pingry describe the current situation as follows:xxxiii “Although profit-seeking firms continue to invest in information technology (IT), the results of the empirical search for IT value have been bafflingly mixed –leading Nicholas Carr and other leading pundits to argue that IT has become a commodity input that, from a strategic standpoint, doesn’t matter.” According to Carr, “It remains difficult if not impossible to draw any broad conclusions about IT’s effect on the competitiveness and profitability of individual businesses… companies continue to make IT investments in the dark, without a clear conceptual understanding of the ultimate strategic and financial impact.”xxxiv This is one more indication of how different reality looks when seen by people who research the industry as a whole and how practitioners see the things from the “inside.”
Thatcher and Pingry study IT investment with a strange differentiation between “design tools” and “production tools.” I believe that this subdivision comes from an overestimation of the software development industry model. More important is that they compare results of investments considering monopolistic and competitive markets, digital products and traditional products, and conventional measurements of costs and profitability. Thatcher and Pingry show that in a competitive market, even if IT investment directly improves the cost
efficiency of a firm, the business value “as measured by profits, productivity, and consumer value […] is constrained by the market structure.” In other words, in a context where IT and all related investments are becoming a commodity input, the “benefits” generated by these areas can be estimated only –if at all—in the context of the general profitability of the business or organisation.
Thatcher and Pingry write: “In the absence of collusive behaviour the firms will compete in product quality improvements but will be less able to gain competitive advantage and improve profitability. In fact, given that IT is a commodity available to all firms, firms are compelled by strategic necessity to compete in product quality improvements in this case. According to Clemons,xxxv the idea behind strategic necessity is that “instead of becoming a source of lasting competitive edge, most strategic information systems become new and essential aspects of doing business… that is, profits will be competed away. Since the key resources of management information systems (MIS) applications are commodities available to all competitors, all competitors with similar MIS strategies can develop similar systems and benefits such as reduced costs or improved service.”
And they conclude: “The major objective of individual businesses is to generate profits by reducing production costs, improving product quality, improving firm productivity, and increasing consumer value. Much of the IT literature is focused on empirically examining ways IT investments may accomplish these goals. However, while it may be necessary for firms to pursue IT investments due to competitive pressures, strategic necessity, or firm survival, our work demonstrates these same IT investments may not result in improvements in traditional measures of business value. Our work adopts the view of IT as a commodity input where investment in IT does not, in and of itself, create a market advantage for any one firm.”xxxvi
I believe that this research supports my suggestion to look at the interplay of all the factors in the organisation and stop searching for a “return” of investment of security. A well- informed business leader will only laugh at the suggestion that a particular technology will bring some “benefits” in and by itself; but also we should laugh at the views that this opens, when we see that so many IT and Security projects are cancelled we will understand why this happens and not complain absurdly that the business does not ‘get’ technology. In fact, what we call “the business” or “management” definitely understands that technology is either an instrument of capital, or it is not, even at the expense of any Security.
Identity Programmes and Projects
Identity management falls into this context obviously on the side of IT itself. Nevertheless, it does so in an even more contrived position than other segments of the technology services. This is because Identity management is the least technological of all these specialities and the one that impacts more business activities more directly. As I will show in later chapters, Identity management solutions cover all forms of benefits and impacts in an organisation: direct and indirect, financial and non-financial. It is particularly important to see that none of the other investments in technology reach completion with an input of the Identity
management disciplines. Either in terms of access control or user enablement, there is an essential relationship between the technology itself and the user of the technology. A technology only delivers value if it is exploited by direct and indirect users, inside and outside the organisation.
Hence the importance of Identity management for any Programme and Project in all types of organisations. The problem is though, that this relevance is not reflected in how Identity management is delivered at present. What I have seen in hundreds of projects across Europe in the past 13 years is a vast landscape not of “failed” projects (as other IT experts may want to recognise), but a vast lack of Identity management projects. In other words, Identity management is absent from all major IT transformation programmes and initiatives. It is not the case that there are failed Identity projects. There are many, but there are more programmes that just don’t have this component. If we used my perspective model to describe the situation, we would say that these Programmes and Projects lack the Selection perspective.
Identity management requires an enterprise-wide focus so that it can interact adequately with the rest of the organisation. The Identity management solutions must be based on a “circle of trust” encompassing the four perspectives discussed in several parts of this book. These, as the reader may recall, correspond to the disciplines of Direction (Trust Definition), Selection (Trust Allocation), Protection (Trust Enforcement) and Verification (Trust Monitoring). In this framework, the Identity management domain has to be conceived in terms of Trust Allocation and based on the Selection disciplines (also called “trust establishment” in my work). For this reason, every IT Programme and Project should specify tasks and ownership for these areas, considering these as foundational disciplines for the rest of the Security areas of concern. We will see in the next few chapters how Identity management needs to adopt a quantitative method to obtain an appropriate place in the organisation.
 |
i J. Monteforte, “De-Mystifying PortfolioManagement” , http://www.cioupdate.com/print/insights/article.php/3432721/De-Mystifying-Portfolio-Management.htm ii http://geneca.com and http://www.genecaresearchreports.com/index.html
iiiMichael Krigsman, http://www.zdnet.com/blog/projectfailures/research-75-percent-believe-it-projects-are- doomed/13016
iv Carlos Trigoso. A call for Level 4, IBM Corporation internal communication, 2002
v Chaos Report, Standish Group,1995
vi L. Eveleens and C. Verhoef , “The Rise and Fall of the Chaos Report Figures,” IEEE Software magazine, 2010
vii Chaos Report, Standish Group, 1994
viii Laurenz Eveleens and Chris Verhoef , “The Rise and Fall of the Chaos Report Figures,” IEEE Software magazine 2010
ix Laurenz Eveleens and Chris Verhoef, “The Rise and Fall of the Chaos Report Figures,” IEEE Software magazine 2010. See also: http://www.guerrillaprojectmanager.com/the-chaos-report-myth-busters
x Martin Cobb, (1996).”Unfinished Voyages: a follow-up to the CHAOS Report,” Standish Group Report, http://www.standishgroup.com/sample_research/unfinished_voyages_1.php
xi J. McManus and T. Wood-Harper “A study in project failure,”
http://www.bcs.org/content/ConWebDoc/19584
xii Cited by Ted Ritter in “Public sector IT projects have only 30% success rate,” http://www.computerweekly.com/blogs/public-sector/2007/05/public-sector-it-projects-have.html xiii Cited by Katharine Hollaway in “KPMG highlights IT project failures,” 2005 , http://www.accountancyage.com/aa/news/1769596/kpmg-highlights-it-project-failures
xiv Chris Sauer, Andrew Gemino, and Blaize Horner Reich. “The impact of size and volatility on IT project performance,” 2007
xv K. Ellis, “The Impact of Business Requirements on the Success of Technology Projects,” IAG report, 2008 xvi Scott Ambler citing results of his research in http://www.drdobbs.com/article/print?articleId=226500046&siteSectionName=architecture-and-design xvii Additional sources: http://www.theregister.co.uk/2002/11/26/it_project_failure_is_rampant/print.html
http://www.it-cortex.com/Stat_Failure_Cause.htm#The%20Bull%20Survey%20(1998) xviii J. McManus and T. Wood-Harper “A study in project failure,” http://www.bcs.org/content/ConWebDoc/19584
xix J. McManus and T. Wood-Harper “A study in project failure,”
http://www.bcs.org/content/ConWebDoc/19584,
xx Cited by M. Krigsman : http://www.zdnet.com/blog/projectfailures/cio-analysis-why-37-percent-of-projects- fail/12565>
xxi J. Kent Crawford’s page at PMSolutions: http://www.pmsolutions.com/blog/authors/j-kent-crawford/
xxii J. Kent Crawford. The Strategic Project Office, CRC Press. 2010. Crawford’s criteria are:
• The organization’s strategies are executed according to plan.
• The organization’s shareholders are satisfied.
• The organization is financially successful.
• Projects are completed on schedule and on budget.
• Project customers are satisfied.
• Project resources are allocated optimally.
• Projects are aligned to the organization’s business strategy.
• The organization works on the right projects
xxiii NAO-OGC “Common Causes of Project Failure,” http://www.dfpni.gov.uk/cpd-coe-ogcnaolessons-common- causes-of-project-failure.pdf
xxiv W. McWhinney, “Paths of Change: Strategic Choices for Organizations and Society,” 1992.
xxv Niklas Luhmann, “Soziale Systeme,” 1987
xxvi Paul A. Strassman, “The Business Value of Computers,” Information Economics Press, 2990
xxvii D. B. Parker, “Fighting Computer Crime: A New Framework for Protecting Information,” 1998
xxviii G. A. Dhillon, “Interpreting the Management of Information Systems Security,” University of London, 1995 xxix J. Backhouse and G. Dhillon, “Structures of responsibility and security of information systems,” European Journal of Information Systems, 1996
xxx Dr.Elspeth McFadzean, Dr.Jean-Noël Ezingeard and Professor David Birchall, “Anchoring Information Security Governance Research: Sociological Groundings and Future Directions,” Henley Management College, 2004. http://www.information-institute.org/security/3rdConf/Proceedings/9.pdf
xxxi G. Burrell and Gareth Morgan, “Sociological Paradigms and Organizational Analysis,” 1979
xxxii I use this image when explaining the need for quantitative and qualitative measures of the value of Identity management.
xxxiii Matt E. Thatcher and David E. Pingry, “Modeling the IT Value Paradox,” Communications of the ACM,
August 2007
xxxiv Nicholas Carr. IT doesn’t matter. Harvard Business Review, May 2003 and Nicholas Carr, “Does IT Matter?
Information Technology and the Corrosion of Competitive Advantage, Harvard School Press, 2004
xxxv E. Clemons, “Strategic necessities,” ComputerWorld, 1988
xxxvi Matt E. Thatcher and David E. Pingry, “Modeling the IT Value Paradox,” Communications of the ACM, August 2007