How to apply cause and effect diagrams in IT and Software Development

Cause and effect diagrams, also known as Ishikawa diagrams, are one of 7 basic tools of quality. You won’t see them used very often in software development or IT projects though they should be. So today we’re going through what cause and effect diagrams are, why they’re useful, an example diagram, and case studies.

What is a Cause and Effect Diagram?

A cause and effect diagram is drawn by starting with the effect that is being produced. This could be a bug or a problem or some other issue with the software or IT project.

Then the individual or, preferably, the team comes up with possible causes. This list of causes is investigated, one at a time, and sub-causes are determined.

If there are no sub-causes, then it’s likely that this wasn’t the actual cause of the effect. If there are sub-causes, and sub-sub-causes, then you’re on the right track and will find the actual cause of the effect.

The Usefulness of Cause and Effect Diagrams

Cause and effect diagrams are useful because they let you list out all the causes that you and/or your team can think of.

People will usually start with one or two causes and investigate those, and then find more causes if those first few causes were not at the root of the effect. This approach is not as effective as the cause and effect diagram approach because it can mean wasted time and energy when the causes aren’t the root cause of the effect. In an IT environment or software development project, it can mean debugging for hours and getting no closer to a solution.

Peer Review of Causes

Having a team think of possible causes is similar to the concept of peer review in software development projects. Where one person thinks of a few causes, another person will think of different causes. This gives a broader range of causes to investigate. Some of the causes can be eliminated as other team members may have already investigated them and found them to be dead-ends. Listing causes together as a team can be a great exercise in collaboration.

Creating a History of Causes and Effects

If cause and effect diagrams are stored in the organizational knowledge base can help in the future. If an effect sounds similar to another one, such as two bugs in the same component, the causes could be similar as well.

Using Industry-Wide Common Causes as a Starting Point

Common Causes in the Marketing, Services, and Manufacturing Industries

In the marketing industry it is common to start with a set of common causes (8 P’s):

  • Product/Service
  • Price
  • Place
  • Promotion
  • People/personnel
  • Process
  • Physical Evidence
  • Publicity

In the manufacturing industry, they start with these causes (5 M’s):

  • Machine
  • Method
  • Material
  • Man Power/Mind Power
  • Measurement

In the service industry it’s common to start with these causes (4 S’s):

  • Surroundings
  • Suppliers
  • Systems
  • Skills

Common Causes in the IT and Software Development Industries

In the IT and software development industries, a list of common causes has not been developed. They are MVPS for IT and MCPS for software development. They focus on the key causes such as Vendors or Code that are highly likely to be the cause of issues. They are compact (there’s only 4 of them) and quick way to get started with using cause and effect diagrams.

MVPS: IT Project Causes

Figure 1. Cause and effect diagram for I.T. issues starting with MVPS (Material-Vendors-People-Systems) causes.

On IT projects these are good starting points for causes (MVPS):

  • Material (includes hardware and software)
  • Vendors (such as hardware/software vendors)
  • People (your team members, coworkers and other stakeholders)
  • Systems (used to control and manage IT functions)

MCPS: Software Development Project Causes

MCPS Software Development Problem
Figure 2. Cause and effect diagram for software development issues starting with MCPS (Method-Code-People-Systems) causes.

For software development projects, this set of common causes is solid foundation to investigate (MCPS):

  • Method (include software development life-cycle, QA process, agile methodology, SCRUM methodology, Waterfall)
  • Code (the source code and related artifacts such as packages and libraries and frameworks)
  • People (your team members, coworkers and other stakeholders)
  • Systems (the systems used for development, releases, deployments, testing)

Example Cause and Effect Diagrams

Example Cause and Effect Diagram
Figure 3. an example of a Cause and Effect Diagram, also known as an Ishikawa Diagram

In the example diagram we state what the problem is. The team lists out three possible causes. Then we explore three possible causes. We start with Possible Cause #3 and find two sub-causes, neither of which are the root (or actual) cause of the problem. The team investigates both Possible Cause #1 and #2 simultaneously and immediately determines that Possible Cause #2 is a dead-end. More sub-causes are brainstormed and investigated and finally the root/actual cause is determined.

Case Studies

When I have my software developer hat and work on IT projects, I sometimes have to search for the cause of a bug in the software and fix it. This requires using a root cause analysis to first find all the issues contributing to causing the bug, and then fixing them all either by writing more code, writing more tests, changing the design of the software.

But before I can determine the cause and fix it, I have to figure out what the possible causes are. By using a cause and effect diagram, I can list out all potential causes and investigate each of them and eliminate them until I get to the real cause. It may sound tedious but it’s the only way to be sure that some causes were not prematurely eliminated.

We use the MVPS and MCPS common causes as starting points in these case studies.

Low Developer Velocity

The following is a cause and effect diagram where the problem is low developer velocity. The software development team as a whole is taking longer to ship working software. By using MCPS (Method-Code-People-Systems) as the starting causes we can dive deeper into the sub-causes.

Low Developer Velocity
Figure 4. Potential causes of low developer velocity on a software development project.

Do remember that the causes are possible causes. Some of them are not causing the problem. In other cases the causes are contributing but can be ignored because they are low risk for the project. Every software development project is different and each problem can have one or many causes.

Let’s say we are exploring the “Development servers are down” cause under the Systems cause. We could split that further into checking whether the problem is with the internet connection to the servers, the firewall rules, domain name issues, hardware problems, billing issues, and so on. Before we investigate those potential causes of the development servers being down, we first check if they are in fact down. If the development servers are up, we can eliminate this from the list of causes of low developer velocity.

“Too many meetings” can be a real issue for mid-to-large sized companies and for enterprises. Checking the work calendars of coworkers, team members, and other stakeholders can quickly determine whether “too many meetings” is the cause of low developer velocity.

If everything is going right, many of the potential causes will be eliminated and you will quickly narrow things down to a few causes. Investigate and document them thoroughly and you will be prepared for future issues that are similar.

For a startup, “too much technical debt” could be the root cause of many software development problems. At first the velocity of the team in a startup will be high but as the startup grows, the technical debt will catch up to the team and slow them down. Eliminating technical debt should always be a priority, but when trying to improve velocity, a more nuanced approach is required. What are the potential causes of technical debt? Moving too fast, poor architecture decisions, outdated technology, little or no testing, and so on. Again, most of these potential causes will be eliminated as causes of low developer velocity.

Server Procurement Takes Too Long

It can take too much time to procure a server. This is a common I.T. issue for organizations that are not using cloud server infrastructure. In rare cases, this problem also exists in cloud-using organizations but it is very rare (and mostly a matter of giving the right authorization/permission to the I.T., devops and development teams).

In the following diagram we start with the MVPS (Material-Vendors-People-Systems) causes since this is an I.T. issue. The potential sub-causes will be different for different organizations but you should notice a few that exist in your organization if you are not using cloud-based server infrastructure.

Server Procurement Takes Too Long
Figure 4. Potential causes for server procurement taking too long on an I.T. project.

Let’s take a look at some of the potential causes. Procurement is not automated will typically be the cause in non-cloud organizations. In places where procurement is automated, server procurement time drops dramatically. In one case I’ve seen a 3 week procurement time drop to 2 days.

In a development agency, server procurement may take too long because the vendor’s billing process is convoluted or because clients do not want to pay for the server yet or because many approvals are required for procurement. For example, procurement approval could require project manager, account manager, IT and client sign-off because it affects the work schedule and what and when the client is billed.

Let’s say that “client is not willing to procure the server yet” is an extremely likely cause of our problem. What are the causes of this? The client may not have budget for the server until after a certain date or project milestone; the client is unsure of the success of the project and whether it will be launched and may not need the server at all; the client is not technical and does not see the need for a server yet; the client already has their own servers; the client does not want to use our private cloud infrastructure; the client does not want to use public cloud infrastructure; the client wants to build their own server infrastructure; the client wants to determine all the hardware/software specifications of the server which takes time. We could go on and on and in a real-world scenario, your team can brainstorm more causes and work together on eliminating these potential causes as the source of slow server procurement.

Applying Cause and Effect Diagrams

As the IT and software development industries mature, you will see more and more quality control tools used. Cause and effect diagrams are the best first step to using other quality control tools since determining and fixing the causes of problem effects are something that developers, devops and IT teams do on a regular basis.

I hope the above diagrams and common causes serve as good starting points for investigating the causes of issues. The MVPS (Material-Vendors-People-Systems) common causes for IT projects MCPS (Method-Code-People-Systems) common causes for software development will cover many of the causes of problems in the IT and software development industries.

MVPS and MCPS can be used to introduce the cause-and-effect diagram tool to the IT or software development team. Using a cause and effect diagram will have an immediate positive impact on productivity and increase organizational knowledge in order to prevent further issues.