Feature-Technology And Failure Points Analysis - Structuring a Product Software troubleshooting process

In my previous article “Building up your career path” I said that one should ever stop learning and a technical example was shared for a better understanding of the topic.

When I was writing the technical example, I stopped myself from going deeper into the Product Software troubleshooting analysis and it motivated me to start a new article.

I’m going to describe “Hector’s troubleshooting method: Feature-Technology And Failure Point Analysis (FTAFP Analysis)”.  Who knows? Maybe one day it will become famous.

Step 1. Have a good understanding of what the issue is about.

A common question a Senior Support Engineer can get is “What do you think about this issue?” After thinking and sharing some possible theories, I normally ended my answer saying something like: “please, go back and talk with your customer and get a clear understanding of what the issue is about”.

Never try to fix something you don’t understand. It’s important that both, your customer and you, are on the same page all the time.

Step 2. Identify the issue within the Software Product

The easiest way to describe a Software Product is a piece of programmable code grouped by features and technologies within a defined functional scope. From a diagram perspective, it looks like:

Software Product

-         Feature 1 --> o  Technologies

-         Feature 2 --> o  Technologies

-         Feature 3 --> o  Technologies

In Corporate software products you should normally find architectural diagrams of it. These will help you to understand the overall product operation flow and identify what product feature is related to a specific issue.

Step 3. Don’t look at the Product feature itself, look at the technologies it uses

Once you identify what feature or features might be affected by an issue, it’s time to create a Feature-Technology Analysis Diagram:

Feature 1 

-         Technology 1 (Product Code Language – Java, Javascript, Python, Perl, etc)

-         Technology 2 (Connectivity level – is a Database used? Are centralized authentication tools used? Is DNS resolution used by this feature?)

-         Technology 3 (Product User Interface – What is the expected behavior? What is the current behavior?)

Step 4. Identify each technology common failure points.

Before jumping to conclusions, it’s important to identify each technology common failure points.  This way, you will be able to determine which failure point could be more related to the Software Product issue.  Now your FTAFP Analysis Diagram will look like:

Feature 1

-         Technology 1 – Product Code

o  Common Failure Points:

§ Product Variables

§ Product Parameters (Configurable options).

§ Compilation errors (Code issue)

§ Broken Code

§ Fake log messages

 -         Technology 2 – Database

o  Common Failure Points:

§ Network Connectivity

*     Firewall (Ports)

*     DNS Issues

*     Network Port already in use

*      Lack of connection

§ Database Service down

Step 5. Formulate your theories

Now you have a visual map of the most common failure points of your product feature(s). Next you need to start thinking of possible root causes for the Software Product issue. Here you will need some analytic skills and technical experience in order to discard the technologies that are not related to the issue. 

On the other hand, sometimes, you might be forced to test all possible failure points due to the problem complexity. 

The FTAFP Analysis will help you to organize your investigation and save time. It can also help you to create out-of-the-box solutions due to your understanding of the Software Product and its technologies.

If during your investigation you find a knowledge gap, for example, you are not able to identify a failure point in a technology, it means you can’t formulate theories yet, so it’s time to investigate more about the technology and how the Software Product uses it.  You don’t need to invest a day in a new technology investigation. You can ask your peers or look for someone inside your organization with that knowledge (which at the same time will help you with your people networking), or you can do a quick navigation on the Internet to get the technical knowledge you need to understand how that technology interacts with the Software Product Feature.

Step 6. Test your theories.

Once you have identified the best possible failure points for the product issue, then you are ready to test your theories. 

As an Engineer, testing something could be your first instinct, but doing it without a good analysis and/or investigation could generate a significant delay in your troubleshooting resolution time.

The FTAFP Analysis will show you the correct path to verify your theories in an organized way.

Step 7. Identify and involve Stakeholders in time

Most of the time you will need someone else’s collaboration, especially from the customer side. For example, if your theory indicates that the problem could be caused by the Database, then a Database Administrator will be needed. Or maybe if the problem is caused by a Network issue, then a Network Administrator should be invited to a conference call.

You also need to recognize your limitations and if Senior levels in support should be required as well.  The tricky part is to engage them early in the process, but with a good investigation background that justifies their participation.

Step 8. Document your results

I think I can write another article regarding this step. Let’s summarize it. Don’t look at the resolution notes as your enemies.  It’s the other way around, they can be your best allies for future references. I would recommend a few things:

-         Make it easy to read – Simplify the technical details

-         Explain the root cause - Recap your theories and test results

-         Describe the resolution steps you did.

Step 9. Share your knowledge.

Many support teams have their own wiki or document repository, don’t be shy and share your findings, your workarounds and your methods. Write as many documents as you can. I assure you that by sharing your knowledge you will become a team leader faster than you realize.  Also, your notes and shared documents will help you to create good quality training for new people (even customers). You can also use them to address future questions of your peers.