Who is to blame when a security breach occurs?

Last month, I wrote about how it is impossible to make software systems 100% secure. Essentially, companies trying to secure their systems should constantly be asking themselves whether spending extra money on security is worth mitigating the risk of a breach. When a breach does occur, though, people inevitably look for someone to blame. It's usually the CIO who gets blamed (and often fired). But is this reasonable? After all, the decision to spend more money on innovation and less on security is a business decision, not a technology one. So the answer is: it depends largely on the culture of the company.

To help describe company culture, I will again leverage a framework developed by two Harvard Business School scholars that defines the levels (or stages) in which manufacturing interacts with the business, which I have adapted for IT. Here is a summary:

• Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
• Stage 2: Externally Neutral (Parity with Competitors, or IT as a Service Provider)
• Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
• Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

I'll ignore Stage 3 here because it is not sustainable, but we can safely examine the cultures of the other three environments and how they pertain to blame when a security breach occurs.

Stage 1

If a company is in Stage 1, it is inclined to think that anything that goes wrong with anything technology-related is clearly IT's fault. In this case, though, nothing could be further from the truth. A true Stage 1 leadership team wouldn't have given the IT security staff enough resources to adequately secure the systems, since security is more of a risk mitigation activity than one that directly improves profitability. By placing the IT staff in a position to fail, the leadership team should take the blame for any failure. 

Stage 2

Based on my experiences in Stage 2 environments, business leadership and IT leaders probably haven't had a conversation about the risk/reward balance inherent in any discussion about how much money to spend on security. In such an environment, IT is focused on providing the services that the business requires, and the business leadership is content letting IT handle all of the "technology problems". Any discussions about the business drivers behind IT priorities are indirect at best.

Even though the communications about security issues are indirect, one can usually tell where the business priorities lie based on the tone of the communication between business and IT. If the business is excessively focused on cost-cutting or innovation, security is going to be neglected. If the signals the business leadership team is sending to the IT team are balanced and rational, then it is primarily the technology team's responsibility to ensure that infrastructure needs, such as security, are being adequately addressed.

Stage 4

In a Stage 4 environment, since IT is an integral part of the business leadership team, all parties should have agreed to resource allocations between innovation and security. Therefore, the entire business shoulders some of the blame for a security breach. This can be especially true if the leadership team (including IT) decides that cost-cutting or innovation is more important than security at the moment.

It is worth noting that there can be valid business reasons for focusing at any given moment on innovation or cost-cutting at the expense of security. It is not a wise business decision to neglect security in the long run, however.

Final Thoughts

You probably noticed that I didn't go into detail about whether the rank-and-file IT workers should be blamed. Yes, individual workers make mistakes. But companies with healthy cultures, i.e. Stage 4 companies, tend to hire better individuals and put them in situations in which they can succeed. In these situations, it is more likely that a security breach is caused by reasonable differing priorities or an honest mistake than by a fire-worthy incompetent decision. Conversely, companies with unhealthy cultures, i.e. Stage 1 companies, generally can't hire good employees, so replacing bad employees with other bad employees won't help the situation. Only fixing the culture will fix the issues.

When Technology Acts as a True Partner to the Rest of the Business

This is the fourth in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I talked about four different levels (or stages) at which IT can interact with the rest of the business:

• Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
• Stage 2: Externally Neutral (Parity with Competitors or IT as a Service Provider)
• Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
• Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

In previous posts, I talked about how Stage 1 was not a stage that a functional company would find itself in, how Stage 3 was inherently unstable, and how Stage 2 is a comfortable place for both business leaders and IT, but limits the potential of your business. Today I'll go over Stage 4. Wheelright and Hayes called this "Externally Supportive", but I'll change this to "Technology as a Partner" in my discussions.

In the Technology as a Partner model, the IT leaders would truly be partners with the rest of the business in their shared goal of maximizing the business value. In other words, the IT leaders would be equally responsible as the business leaders to create and cultivate visions for new technologies that would enable the business to succeed. In fact, a true Stage 4 organization wouldn't separate IT vs. business leaders - they'd both just be "leaders". Both groups would be responsible for keeping up with the latest business and technology trends, although everyone would have their own perspectives.

To make this work, you need to have a large amount of communication and trust between different groups within your organization. This requires an entirely different management approach than is expected out of a business in the other three stages. To further clarify this difference, here is a chart of skills needed as defined by the authors of the original article:

Alternative Views of Work Force Management (Exhibit 3)
Stages 1, 2, and 3: Traditional, Static	Stage 4: Broad Potential, Dynamic
Command and control	Learning
Management of effort	Management of attention
Coordinating information	Problem-solving information
Direct (supervisory) control	Indirect (systems and values) control
Process stability/worker independence	Process evolution/worker dependence

One more that I would add is that Stage 1, 2, and 3 employees focus on finishing tasks, where Stage 4 employees focus on accomplishing goals.

Companies whose technology team is a true partner to the business have several significant advantages over its competitors:

• Business-savvy IT professionals and IT-savvy business professionals can understand how to extract value out of new technologies much more quickly
• High trust in employees makes it easier to implement Agile (as opposed to the pseudo-Agile that's popular today), leading to a higher project success rate
• Greater responsibility for individuals means younger employees have a greater chance to develop their leadership and management skills
• Lower requirements for micro-managing employees leads to more productive managers
• Stage 4 companies attract better employees

I could go on, but you get the idea. If you want to be a truly successful company, you need to strive to make the technology team true partners of the business (Stage 4). How do you get there? Unfortunately it's not a quick or easy path, but my next four blog posts in this series will attempt to answer that question.

Other posts in this series:

May: Levels of function (and dysfunction) IT can have with business

June: Why Stages 1 and 3 are not viable long-term stages

July: IT as a Service Provider May Be Bad for Business

August: When technology acts as a true partner to the rest of the business

September: How IT professionals can be their own worst enemy in achieving Stage 4

October: How your Stage would affect your management practices

November: How your Stage would affect your hiring practices

December: How can an organization reach Stage 4?

5 reasons for IT project failures aren't IT's fault

I've been involved in a number of IT projects in my career, ranging from overwhelming successes in every sense of the word, to projects that came in a full 100% over budget, to projects that came in on time and on budget but didn't meet the business needs. Most of the articles that I read about IT project failure focus on IT. This is understandable, since by definition, IT is involved in every IT project failure. But when an IT project fails, there's usually plenty of blame to go around. What are some reasons that these projects fail that aren't directly related to IT?

Lack of shared understanding of the project goals

It is tough enough getting business leadership and IT on the same page as to what should go into a software product, where compromises should be made (in quality vs. cost vs. time-to-market), etc. This becomes infinitely more difficult when the individuals on the business team cannot agree to what the product should be. Minor disagreements are normal, and every good IT manager plans for them. But major disagreements can doom a project before it starts. In my experience, the two major sources of these types of conflicts arise when:

• The business stakeholder leading the project only has a vague idea what the project's goals are
• Multiple business stakeholders leading the project have conflicting ideas as to what the project's goals are

The second scenario is less challenging to fix - in this case the stakeholders would need to choose a leader to represent the group and find ways to appease everyone. While this won't solve all issues, it will simplify communication and clarify the vision. It's tough to rescue a project in the first situation, though. In this case, it's often best to stop the project, or start over with clearer goals.

Slow feedback

By far the most common reason that I've encountered that IT projects run long is that the business leaders directing the project are slow in giving feedback. When feedback is slow in one particular area (i.e. what to do with one particular feature), or when feedback is slow about minor details (i.e. what exact wording should go on a button), the software delivery team can usually work around it. But when feedback is consistently slow, or feedback is slow in a particularly critical area, the IT team either has to start pushing deadlines or has to start making guesses as to what the functionality should be. If the IT team is making guesses, you'd better hope that they thoroughly understand the business need behind the system being created, otherwise expect moderate to severe budget overruns as their decisions are removed from the system.

Inability to differentiate "need" from "want"

The average business user would be shocked at the complexity that is present in even the most simple-seeming software product. On top of that, the more complex the business need is, the disproportionately more complex the software needs to be to support it. The best way to combat this problem is to keep the software as simple and small as possible, then build on it as time and budget allows. When business leaders cannot differentiate the things that they must have in order for the project to be a success and the things that they would like in order to make the project better, uncontrollable scope creep occurs and the project never gets finished.

Inability to talk conceptually

Until businesses get smart and start hiring IT personnel who have a deep knowledge of the business they're supporting and business leaders who have a reasonable understanding of the technology they're using, we're going to have a gulf between the vocabulary and understanding of the business leaders and the IT staff that support them. The level of difficulty will vary depending on the skills of both the business leaders and the IT staff. To simplify the discussion, I'm going to define some terms that describe the levels of understanding that business leaders can have about their processes and IT:

• A leader has deep project-level understanding if they are a subject matter expert and have experience/skills in envisioning how their processes could be simplified by software.
• A leader has subject matter expertise if they understand both how their business works and why the processes are the way they are, and can communicate their understanding to others. They don't, however, have the experience or skills to know how specifically how software can fix their problems.
• A leader is a figurehead when they neither have the understanding of their own business processes nor have an understanding of the benefits and limitations of software. (Note, a person who has an understanding of their processes, but cannot communicate them to a non-expert such as IT, might as well be a figurehead for the purposes of an IT project and will be treated as such here.)

I will also draw on a previous post to describe IT's understanding of the business:

• A Stage 2 IT leader will be a technological expert who focuses on delivering what the business team asks for.
• A Stage 4 IT leader will be a technological expert who has an understanding of the business and focuses on delivering a solution that meets the stated business needs.

To show what kind of effect this can have on your project's chances of succeeding, here is a chart that shows my experiences with skill levels and project success. (Note: all cells assume that the IT staff is competent with the technology they're using.)

	Stage 2 IT	Stage 4 IT
Deep Understanding	The business leader will lead the project, and the project will generally run smoothly	Expect success
Subject Matter Expert	Expect a product that is delivered late and/or over budget, as there will be a lot of trial and error during the development process, but the product should eventually meet the business needs	Expect the IT team to lead most aspects of the project and that the business leader will focus on ensuring the details are right
Figurehead	Expect failure	Expect the project to go sideways as poor communication derails the effort

Note that the best chances for success lie when someone, either the business leader or IT, has an understanding of both the business process and the underlying technology. Without that, the ability to communicate both the how and the why of the business processes at hand become vital to the project succeeding by any definition.

Lack of focus

If you try to make a little bit of progress on everything, you won't make significant progress on anything. Yes, there are a lot of areas that need to be improved, but you will be significantly better off by getting one problem fixed then moving onto the next rather than trying to solve everything at once. There is a balancing act that must be done here. If you try to proceed with too many ideas at once, the project will stall and die. If the business leadership tries to be too hyper-focused on only one or two needs, they risk losing the enthusiasm and support of the people who will use the software.