I came to IT a little later in life than many people. I spent the first 20 years of my working life as a Naval Flight Officer flying the mighty S-3 Viking off of Aircraft Carriers around the world in peace and in conflict. I know… You’ve never heard of the S-3 Viking.
Go ahead, look it up.
So the reason I bring up the S-3 Viking is to focus on one of the ways that IT and Naval Aviation are alike. There are actually many similarities; for instance, both are about reading and understanding the documentation and both have a language barrier one must overcome just to read that documentation.
But today I will focus on just what Naval Aviation calls “Crew Coordination.” In Naval Aviation most of your reputation comes from how well you land on the aircraft carrier and your ability to communicate in the aircraft.
I’ll give you an example from June 1995 when I was flying over the former Yugoslavia in support of the UN mission to enforce the Dayton Accords that ended the Bosnian Conflict. I had launched from the USS Enterprise with “Murph” at sunset and our mission was to fly along the coastline in territorial waters at 35,000 feet to monitor various sites in the country. About half way through the flight, a red light illuminated just below the glare shield.
Me: “Number 1 Engine Fire Light”
Murph: “Roger”Me: “ITT 1000 and rising” (This indicated that temperature between the high and low pressure turbines was above normal and rising)
Murph: “I have visual indication of Number 1 engine fire”
Murph: “Throttle Number 1 Engine. (He put his hand on the Left Throttle) Concur?”
Me: “Concur” (Murph moved the #1 Engine throttle to OFF)
Murph: “Fire Pull Handle Number 1 Engine. (He put his hand on the Left Fire Pull Handle) Concur?”
Me: “Concur” (Murph pulled the #1 Engine Fire Pull Handle)
Murph: “Ignition Switch Number 1 Engine. (He put his hand on the Left Ignition Switch) Concur?”
Me: “Concur” (Murph moved the #1 Ignition Switch to OFF)
Murph: “Immediate Action Items Complete”
Me: “Concur. Let’s turn towards Mother and get down to 12,000 feet.”
Me on Radio: “Darkstar, 703, declaring an emergency, #1 Engine fire, RTB, coming left to 220, descending to Angels 12”
The interesting thing about Naval Aviation is that it really didn’t matter too much who I was flying with that night. That conversation would have gone the same way. While doing this, we still had to follow the basic rule of aviation: Aviate,
We ran through several checklists after that, including the rest of the Single Engine Fire Procedure, the Approach Checklist,
the Single Engine Landing Checklist and the regular landing checklist.
We told the Enterprise (Mother) what our problem was and what we intended to do.
Somewhere in there was a discussion of our divert options and required single engine fuel requirements to get to various land bases if required.
Murph flew a colorful single engine night carrier landing that got him some good natured ribbing but we brought the aircraft home – our temporary home, CVN-65, the USS Enterprise. Home to 5,000 of our closest friends!
So how does this relate to IT?
The training we had received gave us a framework for communication and it all starts with the problem statement. I
f you can get this right, you can get home to the carrier or efficiently resolve IT issues.At any organization’s Help Desk, too many tickets show up like this: “Something is wrong with something somewhere.”
That’s when the Help Desk has to contact the end user to determine what the user was doing, what the system was, what the expected result was, what actually happened, what the error message was and what steps were tried that didn’t resolve the issue.
This happens in a project setting as well.
A client may go to their Project Manager and say “a component isn’t working.” And that’s all the PM can take back to the technical team.In an organization where a Help Desk handles 6,000 monthly ticket interactions at all levels, only half of those require going back to the user for details.
That takes just 10 minutes, right?
And that’s 60,000 minutes or 1,000 hours per month of wasted time at the Help Desk.
This 12,000 hours per year is the equivalent of six full time employees per year.
Can your organization afford an additional six employees needed due to a lack of problem statement clarity in the Help Desk process?
Can you afford the extra time and material for a client facing project?
So what’s the solution?
The only way to get at the efficiencies lost is by focusing on getting the problem statement right the first time. The difference between “Number 1 Engine Fire Warning Light” and “Oh $@%*!” can be the loss of an aircraft and its crew.
The difference between “My Outlook 2007 SP2 running on Windows 7 has the message “Cannot connect to Exchange Server” displayed and I cannot send or receive email from my desk in the Jacksonville office” and “Exchange is down” is lost time for both the end user and the Help Desk.
Ultimately, the company wins or loses based on how the company handles this.Strong leadership can change a culture of “Something is wrong with something somewhere” to a culture of good problem definition.
If you run a Help Desk, impress upon your team the critical qualities of a good problem statement and enforce a solid standard. Both in their dealings with end users and Tier 2 and Tier 3 support.
Their reputation with Tier 2 and 3 depends on this.End users can help improve this problem too! As an end user, when escalating an issue to the Help Desk, ask yourself if you are providing enough detail to allow analysts to tackle your issue without needing to come back to you for more details.
This strategy of good problem definition is the foundation of most management strategies. It’s built into the roots of Deming Management, Six Sigma, Agile and Waterfall Methodologies.
Accurate problem statements result in accurate problem resolutions.
This is the core of every successful organization. So, are you a “Number 1 Engine Fire Light” or a “Something is wrong with something somewhere” person in your organization?
Putting the tools into the hands of the right people with the right processes is what drives real success.
The causes of failure in software projects are extraordinarily well documented.
As technology advances, mainframe organizations are increasingly pressed to transition to more modern platforms. Here are some of the most common misconceptions that hinder their mainframe modernization journey.
The cost of not modernizing mainframe systems is generally far greater than the time, effort, and money required to make the transition. Here's why.
As mainframes host mission-critical applications, it's essential to ensure that the modernization process is accurate and causes minimal disruption to business operations. This is where automated migration and testing tools come in.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now