1

The LogistaVolume 7, Issue 4 | December 2017

CONTENTS

Pitfalls of Developing Logistics Product Data [& how to avoid them] (P. 2)

Warning: Confirmation Bias at Work (P. 6)

Staff Member Spotlight: W. Ben McKenzie (P. 7)

Dear Readers,

It’s hard to believe we are approaching the end of another year. We have had the privilege this

past year to work on many exciting projects with customers across the United States – including

developing Logistics Product Data on Navy radar systems, performing product support analysis for

a prominent Army engine program, and accomplishing reliability analyses on a Coast Guard C4

system. What makes ALE such a unique company is the variety of projects, scope, and valuable

experience gained on each program which allows us to better integrate processes and identify

synergies. We are thankful and honored that you continue to think of ALE to fill your life cycle and

specialty engineering needs.

This issue of The Logista includes two articles on very different but practical topics. The first pro-

vides tips for avoiding the five biggest pitfalls in developing Logistics Product Data. The second ar-

ticle discusses the human factors issue of confirmation bias, which is present in everything from

reading the local newspaper to reading system requirements.

We wish you and your families a wonderful holiday season and a new year filled with peace and

happiness. Thank you for your continued readership and business.

Happy Holidays,

Renee and Joe Coogan

CAGE code: 1Z220 | Dun & Bradstreet: 16-125-2218 | NAICS: 541330, 541614, 541715 | WOSB | Seaport-e Prime Contract Holder

ALE Central Ohio Office: 6797 North High St, Suite 324, Worthington, OH 43085 | P (614) 436-1609 | E staff@ale.com

ALE Gulf Coast Office: 4850 Gautier-VanCleave Rd, Suite 3, Gautier, MS 39553 | P (228) 522-1522

2

1. CONFIGURATION CHANGES ANYONE?

Every Logistics Analyst knows a system has a configuration which is the basis of their logistic work. The system configu-

ration identifies the systems, sub-systems, and piece parts to be addressed. Imagine performing the majority of an LPD

analysis using a specific configuration only to receive an e-mail from the customer stating that the configuration has

changed. Anyone that has experienced this scenario knows that it can be complicated dealing with reworking your

analysis to develop LPD for the changed entities and update any data indirectly impacted. These configuration changes

can be voluminous or minute – but no matter the size, your analysis must be updated to ensure the proper support

arrangement.

As you know, and as can be expected, the rework involved in updating LPD can get expensive. So how can you stop (or

limit) these negative impacts that system configuration changes have on LPD development?

Communicate with your customer! Come to an agreement on a specific system configuration down to the revision

level of the piece parts. At first this may seem like an obstacle in negotiation, but it’s actually within the best interest of

both your LPD team and the customer. Agreeing on a system configuration for LPD development allows your LPD team

to work uninterrupted on the system as a whole. There will be no reworking of the analysis due to changing system

components or “creep” due to the addition of components. Locking the system configuration for the customer ensures

no extension of deadlines and keeps the project on budget. An agreement on the system configuration should be sold

and viewed as a win-win for you and the customer.

2. KEEP YOUR EYE ON THE MAINTENANCE CONCEPT (AND THOSE SMR CODES)

As an LPD analyst, you live and die by the Maintenance Concept, which defines how and where a system is maintained.

Source, Maintenance, and Recoverability (SMR) codes are standardized codes (contained in the LSA-024 report) that

(Continued on page 3)

Pitfalls of Developing Logistics Product Data [& how to avoid them] By Zach Pusnik

Have you ever had a project you were working on get cancelled? Have you ever received

a revision to a project that you were working on that left gaping omissions? Have you

ever been asked to produce a report with source data that is not sufficient? Have you

ever longed for a different software tool to accomplish a task at hand? Or felt burnt out

scouring through endless engineering drawings for data? Today, my fellow logistics

analysts, I would like to take a couple minutes of your time to explore how to avoid or

mitigate these pitfalls in a Logistics Product Data (LPD) development environment.

3

represent the maintenance concept. It is not uncommon while working an LPD program for a customer to want to make

changes to SMR codes. Changing the SMR code requires changing the maintenance concept too. When the maintenance

concept is changed you are effectively changing every aspect of LPD for that item. Labor tasks, provisioned parts, sup-

port equipment, and tooling are just some examples of LPD entities that need reviewed when a maintenance concept or

SMR code change occurs.

So what’s the best tactic to minimize changes to the maintenance concept and SMR codes when your analysis is under

way? Again, good communication and partnering with the customer during an initial review of the source data and

maintenance concept is a key to solidifying the path forward. It is critical that the maintenance concept is analyzed and

any inconsistencies or suggested changes are surfaced, discussed, and accepted by the customer before proceeding any

further with the LPD analysis. Likewise, SMR codes must always agree with the maintenance concept. You cannot

change one without changing the other. When the maintenance concept is agreed upon so are the SMR codes.

Agreement on the maintenance concept and SMR codes keeps the LPD project on time and on budget for the customer.

Additionally, an agreed upon maintenance concept allows analysts to work more efficiently through their analysis

because they don’t have to back track and rework a previously completed entity due to changes in the maintenance

concept or to SMR codes.

3. THE 4 CERTAINTIES IN AN LPD ANALYST’S LIFE: DEATH, TAXES, CHANGE, AND INADEQUATE SOURCE DATA

LPD can be generated or reviewed on a system at various times during a system’s lifespan. You’ll receive a wide variety

in the type and quality of source data. You can expect to receive engineering drawings, BOMs, technical manuals,

assembly test procedures, even that occasional unofficial “official” assembly procedure or parts list. With all these

sources of data, what revisions or versions of them do you use for analysis? What do you do if you can’t find the infor-

mation you need to complete part of your analysis?

The first thing that you can do to address inconsistencies in source data is to adapt your mindset to the fact that your

analysis is only going to be as accurate and thorough as your source data. Don’t get stressed out over your source data

because it is usually beyond your control. Leverage constant communication between the LPD Team Lead, Project

Manager, and Customer to resolve missing or inconsistent source data. Discussing the impacts that inadequate source

data will have on the timeline or results of a deliverable often motivates the customer to get you the data you need to

complete an accurate analysis.

When dealing with discrepancies between multiple types or revisions of source data, it is best to pick the most current

or latest version of engineering data to shape your analysis. The latest revisions will most accurately display the current

configuration, maintenance concept, and piece part information of the item or system under analysis. Using legacy

versions of LPD data leads to rework so watch revision letters on drawings!

A final suggestion you can use to mitigate source data concerns is to pay attention to notes on engineering drawings and

in technical manuals. These notes often are the source data you are looking for. Drawing notes, in particular, provide

(Continued from page 2)

(Continued on page 4)

4

information on attaching hardware, repair equipment, repair standards, part numbers and even describe repair or

assembly procedures! The devil is in the details, and those details are the drawing notes.

4. FINDING A BETTER WAY THROUGH LOGISTICS PRODUCT DATA TOOLS

For every task there is a best tool for the job. In the world of LPD development, there are many adequate free and sub-

scription-based tools. A couple of the free tools include PowerLOGJ-2, an LPD database software system managed by

the U.S. Army’s Logistic Support Activity, and an online search system for piece part information called “PubLogFLIS,”

which is managed by the Defense Logistics Agency and the Federal Logistics Information Service. Free tools can be ade-

quate for your LPD needs but may not be the most efficient tool for the job. Free services often lack configurability,

stability, and ease of use which leads to inefficiency when researching and documenting LPD data.

There are a couple of subscription-based commercial LPD tools that provide benefits not available in their freeware

counterparts. Many commercial database systems feature modules that allow you to configure your data to different

logistic standards like GEIA-STD-0007 and MIL-STD-1388-2B. This benefits data importation as you can set up excel

spreadsheets with logistics data in 2B and 0007 format, load it into the database, and have the data stored and dis-

played correctly in the database. The database interface also allows you to simultaneously enter LPD information for

an item while entering item repair tasks. This is accomplished by providing multiple linked windows for simultaneous

data entry. This means you can enter support equipment information, and spare part information much more effi-

ciently than by manually navigating to each of these LPD database entities and then manually entering the correspond-

ing information as you have to do with the free tools.

Subscription based defense parts and management systems contain a wealth of logistics and provisioning information

for piece part items. One of the subscription-based system’s main advantages over free tools is that you can import a

list of items into the software to be looked up all at once. Most free tools can only look up items on an item by item

basis. Subscription-based systems typically offer more comprehensive information about piece part items than their

free counterparts. While there is a cost associated with subscription-based tools, the increased efficiency and im-

proved quality can quickly help the systems pay for themselves.

5. FLAT OUT, BURNT OUT.

Experiencing periods of burnout is common for a logistics professional in such a detailed analysis environment. Consist-

ently spending full days visually traversing engineering drawings, technical manuals, BOMs, and computer screens for

months on end will have an impact on your accuracy and your efficiency. With all that black and white it’s easy to mis-

read a part number or SMR code. This feeling of “burn out” can also negatively affect the morale of your LPD team. So

how can you stay fresh when slugging through the information jungle of an LPD project?

Combat LPD burn out by giving your eyes a couple breaks during the day. Take 5 minutes to focus on a newspaper,

magazine, or digital article on your smart phone. A change of topic, some screen color, or a different screen size can

help your mind and eyes feel refreshed. Get up out of your seat and take a quick stroll around your floor, up and down

some stairs, or outside (if the weather permits). Walking gets your heart rate up, the blood flowing, and helps combat

(Continued from page 3)

(Continued on page 5)

5

that feeling of sleepiness that seems to sneak up on you after a good lunch. Last but not least, go out to eat. (Or see if

you can get your LPD team together for a lunch outing.) A change of scenery with some teammates is a good way to

get people smiling again and gets you away from your desk for an hour. Just don’t get too greedy utilizing these

strategies…

BONUS TIP: SKILLS TO LOOK FOR IN LPD ANALYST CANDIDATES

LPD is a unique and peculiar field. Most colleges don’t have a major for it, in fact they don’t teach it at all. So where do

you go to find LPD Analysts? One strategy to finding solid LPD Analyst candidates is to look to the skilled trades or

mechanical engineers. Having a mechanical background coupled with hands on experience building or repairing

mechanical systems are strong assets that an LPD candidate should possess in their work history. Often candidates

with this type of experience can read engineering drawings, understand diagnostic flow charts, are experienced with

assembly and technical manuals, are familiar with hand tools, and have a developed mechanical aptitude. Pursuing

candidates with a skilled trade background also allows you to customize and diversify your LPD team. For example in

the Aerospace and Defense industry you’ll need a wide range of analysts with experience working on “air frames to

powertrains,” and that’s nothing but “the hull truth.” Look to ship yards, Army depots, and Air Force depots for techni-

cians that have repaired the systems, or similar systems, that your LPD team is tasked with analyzing.

Don’t forget to look at civilian maintainers either, as aerospace and defense systems often closely resemble their

commercial counter parts. Finding the right person to become an LPD analyst is not an easy task, but looking for indi-

viduals that have repair experience or design knowledge commensurate with the systems your team regularly

performs LPD analysis on will give you an edge in producing efficient and accurate LPD analysis.

(Continued from page 4)

Efficiently producing an accurate LPD analysis can be tedious and exacting work. Chang-

ing system configurations, maintenance concepts, inadequate source data, inefficient

logistics tools and associate burnout are constant enemies in the LPD development envi-

ronment. I hope this article has provided a basic but entertaining look at some of the

most common pitfalls facing LPD development teams and has provided some common

actionable solutions to mitigate them. Keep logging!

ABOUT ALE’S LOGISTICS PRODUCT DATA EXPERIENCE:

ALE has an excellent reputation for providing deliverables that exceed the expectations of our customers and leader-

ship of the critical programs they support. Our PSA and LPD deliverables consistently display an exceptional under-

standing of the application of TA-STD-0017 and GEIA-STD-0007, and their MIL-STD-1388-1A and MIL-STD-1388-2B

predecessors. We were one of the first users of Integrated Support Systems (ISS) SLIC and SLICwave® logistic data-

base software and led the implementation of the MIL-STD-1388-2B version on the USAF F-22 program (which was the

first major program to implement the -2B standard). We have developed comprehensive logistic databases for over

20 programs and have trained Government and industry in PSA and logistic database development.

6

Two news headlines from different sources on a single

political story: One screams of scandal, trouble, and the

end of the world; the other paints a completely different

picture – it’s hard to believe they are talking about the

same thing. How does this happen? Well, we can blame

outright advocacy journalism for some of it. But as one

who has relatives in that profession, I’m convinced that

most journalists genuinely believe themselves to be ob-

jective purveyors of information. Instead, I think that the

political polarization so prevalent these days can actually

be quite instructive as an example of one of the most

potent foibles we humans possess: Confirmation Bias.

Confirmation Bias is the tendency of a person to (1)

search for, (2) interpret, and (3) recall information in a

way that confirms one’s preexisting beliefs. In school, we

were cautioned about this when learning how to deal

with information. But most of us have long since for-

gotten about it, now that we are older and theoretically

wiser. However, it is important to be reminded of confir-

mation bias’s existence because its effect has very real

impacts. On the business side, it influences how we re-

view requirements, how evaluators assess deliverables,

and how the end customer makes business decisions. At

the user and maintainer level, it influences how technical

manuals and user interfaces are perceived and how fail-

ure causes are identified.

Let’s break down the three main confirmation bias types:

(1) Selective Exposure, or Search Bias. This is a pref-

erence for seeking out information that confirms one’s

hypothesis. Our bias affects our search – where we look,

what sources we consult, what we consider worthy of

investigating or talking about. We look for what we want

to find, and we don’t look for what we don’t want to

find. But are we trying to build a court case? Or do we

seek objective information? If so, do we limit ourselves

to just those information sources that see things as we

do? Peer review of technical papers exists for a reason.

(2) Selective Interpretation, or Interpretation Bias.

Confirmation bias affects how we perceive and interpret

information. Two people can come away with very differ-

ent takes on the same information or situation. Are we

able to understand how a reasonable person can come

to a different conclusion than our own? Do we even try

to see it? We should be most wary of things that appear

to feed our preconceived notions because we are already

eager to accept them unchallenged. This is especially

true when we read and interpret program specifications.

We immediately come to the conclusion that we “know”

what the customer wants.

(3) Selective Memory, or Memory Bias. Confirmation

bias affects what we consider worthy of remembering. I

can barely recall what I ate for breakfast, but my wife can

remember what clothes I wore to an event a decade ago.

Some things are more important to her than to me. That

goes for other things as well. Do we recall more readily

facts that support our beliefs? Of course we do. Are we

less tolerant of defects in an opposing theory than we

are of defects in the theories we support? You bet!

Confirmation bias can also lead to tendencies like:

Polarization of opinion

The persistence of discredited beliefs

A preference for early information

Illusory association between events (Continued on page 7)

Warning: Confirmation Bias at Work

By David Aurand, Quality Manager and Human Factors Sr. Systems Analyst

7

Now, I can’t say that biases are always bad. One’s bias

may be what allows a person to see opportunities where

others see only problems. Here’s a quote from LtGen

Lewis B Puller, the most decorated Marine in US history:

“Alright, they’re on our left, they’re on our right, they’re

in front of us, they’re behind us. They can’t get away this

time.”

But one could just as easily imagine a scenario where an

overly optimistic bias might lead to disaster (paging Gen-

eral Custer . . .).

And there is a difference between Bias and Convention.

There is no objective reason why an Australian couldn’t

view the world like this if he or she wants to:

Fortunately, there are conventions in place that facilitate

how information is communicated.

There is no cure for confirmation bias. As humans, we are

stuck with it. The best we can do is to be aware that it

exists, and do our best to compensate.

(Continued from page 6)

To learn more about any of the articles or the topics

discussed in The Logista, please contact us directly at

staff@ale.com and connect with us through social

media!

WWW.ALE.COM

S TAF F M EM B ER S P OT L IG H T

W. Ben McKenzie

Mr. Ben McKenzie is

a Logistics Analyst,

Technical Writer and

a certified NAVSEA

Reliability-Centered

Maintenance (RCM)

Level II developer in

Acquisition Logistics

Engineering’s Gau-

tier, Mississippi office. Before joining ALE over six

years ago, Ben served in the US Navy operating and

maintaining gas turbine propulsion systems on Navy

ships, including hydrofoils, destroyers, cruisers, and

hovercraft, and as a certified instructor. This exten-

sive hands-on experience with Navy ship programs

has benefited ALE and our customers through incor-

porating operator and maintainer perspectives into

our logistics products.

Among Ben’s areas of expertise within ALE are

Maintenance Planning, Logistics Product Data (LPD)

database development, provisioning, and technical

manual development. Recent projects that he has

made significant contribution to include RCM and

Technical Writing for a landing craft and mainte-

nance task analysis on a distress C4 system. Ben is

also certified as a NAVSEA Reliability-Centered

Maintenance (RCM) Level II developer.

Ben resides in Ocean Springs, MS and enjoys golfing,

camping, fishing, and garage tinkering.