APS member’s wife has a request to make –

[cambeul41]

This is Mrs. Cambeul41. I sometimes lurk here and often discuss threads with my husband. I have been highly impressed with the breadth of background and quality of thinking of the APS members.

I hope you don’t mind my venturing to ask a big favor of you.  I have been pursuing doctoral studies in industrial engineering at Wayne State University in Detroit and am in the last phase of my dissertation.  I am studying aspects of engineering / technical problem solving. This entails collecting data from technical professionals such as some of you are.  Engineers of any function (e.g., design, civil, hardware, software, testing, systems, manufacturing,  quality/reliability/field service, etc.), as well as IT professionals, would all qualify if they are – or have been in the past – US-based and have a US-based problem solving story to tell.

May I ask you to participate?  The link is provided below.

The on-line survey should take 10 to 15 minutes and contains no questions of a personal nature.  Your answers will be kept confidential, and you have the option to receive a summarized copy of the results if interested.  I would also greatly appreciate your sharing the survey link with other technical professionals that you may know.
 
Your help in my research endeavor will go a long way.  I am hoping that my study will contribute to the enhancement of future work environment for technical professionals.  I will need a large sample size to validate my results.  The larger the number of participants, the more accurate the analysis will be.
Thank you, in advance, for your help!

Survey link:

http://waynestatebusiness.qualtrics.com/SE/?SID=SV_25LipKXFoxO7IwY

Rachel (Mrs. Cambeul41)

(My Wayne State University profile:  http://ise.wayne.edu/profiles/get_bio.php?id=43342)
 

[Hawkmoon]

I hope you don’t mind my venturing to ask a big favor of you.  I have been pursuing doctoral studies in industrial engineering at Wayne State University in Detroit and am in the last phase of my dissertation.  I am studying aspects of engineering / technical problem solving. This entails collecting data from technical professionals such as some of you are.  Engineers of any function (e.g., design, civil, hardware, software, testing, systems, manufacturing,  quality/reliability/field service, etc.), as well as IT professionals, would all qualify if they are – or have been in the past – US-based and have a US-based problem solving story to tell.

May I ask you to participate?  The link is provided below.

Ummm ... Rachel, based on the criteria you cited above I should qualify. I'm an architect with moderately heavy technical experience involving civil engineering. But when I get to the survey, it offers nothing even remotely relating to architecture, architectural (structural or mechanical/electrical) engineering, or civil (roads and bridges) engineering. If it is your intent to include those disciplines, the front end of the survey needs to be revised.

Here's the problem: The page identifying the problem

What was the product?  Choose only one.

    Raw materials
    Semi-finished materials (e.g., steel, chemical formulation, textile)
    Finished goods – hardware only (e.g., mechanical parts, electrical hardware)
    Finished goods – software only (e.g., computer program)
    Finished goods – hardware and software (e.g., cars, embedded systems)
    IT architecture
    All other – please specify:

It allows only for manufacturing engineering, and IT "Architecture" (a term that leaves me, as a licensed architect, cringing).

[Stetson]

Replied based on my last project in redesigning and implementing the entire IT Infrastructure of a casino.

[HankB]

Replied based on my experience with a consumer product designed in USA but manufactured by an OUS ODM.

[brimic]

Replied based on recent project to redevelop a chemical product to solve purity, yield, and cost problems.

[Scout26]

My reply based upon the implementation of new ERP system with a company I worked for a few years back.  

The old system had become somewhat outmoded in that we had "bolt-on" applications that were outside the system.  (For example, to print Bills of Lading, we had ship items within the system, then go "outside" the the system to a separate application and re-enter the information to print BOL's.)

We formed a team from every department within our company and solicited companies to come and present their product to the team.  

After enduring 12 presentations, we invited 5 companies back for testing.  Management insisted we include a 6th of their choosing.

After running months of meetings and testing, the team came to a consensus on a system that truly meet the vast majority of all our requirements.

However, Corporate overruled our recommendation and chose the 6th system. (The one they had insisted we include in our testing.)

It was a disaster.  The system lacked much of the functionality we required.  In fact it was still in development and many functions required for our business, simply did not exist. (E.g. Inventory management was pretty much non-existent.  There was no way to convert raw materials into finished goods, ship or otherwise remove items from inventory.  We had to write BOL's out by hand.  Since I worked closely with purchasing, they complained that there was no ordering functions, they had to calculate everything by hand, and then hand write PO's.)

The reasons why we ended up with a worse system then what we started with.
1.  The accounting folks liked the new system.  It had started life as a pure accounting package.  The software company was developing/expanding into the Manufacturing/Distribution market.
2.  Our IT folks liked them.  Why?  They had gotten a ton of free meals and other swag from this company.  They had "bonded".  (Sadly, our IT folks were the "weak link" in the company.)
3.  Since it was still in development, it could be had for a substantial discount compared to other systems.  Plus they promised to work closely with us to develop the system to our needs.  (Yeah, right )

So in the end all our hard work was for naught.  Our company had pre-chosen the winner.  Our team was supposed to reach the same conclusion.  The sense of betrayal was palpable.  What had been a happy, even fun place to work became a "Us vs Them" warzone.  High quality people were soon headed to the lifeboats.  The company rapidly spiraled out of control and was pretty much sold for it's remaining inventory (at a discount) two and half years later.  

A case study in how not to do it.        

[RoadKingLarry]

Replied based on experiences from a review and rewrite technical manual/maintenance procedures for a submarine based ESM/ECM system.
SPAWARS actually brought in actual technicians and instructors  that had actual at sea experience with the system to write the manuals and procedures. The majority of the engineers that were building the system had never even seen a submarine.

[Hawkmoon]

Since I guess I can't legitimately participate in the survey, here's the poster child for why engineers should stick to engineering, and leave the writing to people who can write: IBM.

Around 1985 or 1986 the company I worked for decreed that all project managers henceforth would compute. Thus, early in the week of Thanksgiving (of whichever year it was) a bunch of large-ish and heavy-ish boxes materialized in my office. The markings suggested that the boxes contained the components of an IBM Personal Computer. The office was closed the Friday following Thanksgiving, so I thought that would be a good opportunity to unpack, set up, and try out the new computer (about which I knew NOTHING -- as will hereinafter be made obvious) without using billable time.

So on Friday I came in and unpacked the infernal machine. This was an original IBM Personal Computer, but slightly enhanced. It had not one but TWO 360-kilobyte, 5-1/4" floppy drives, and 384k (not 256K) of RAM. The monitor was an amber monochrome CRT with a huge 12" diagonal measurement.

The instructions started off well. This was long before anyone thought of just color coding the connectors so the blue plug goes to the blue receptacle, yellow to yellow, etc. But the instructions were clear, everything seemed to be there, and it all went together. I was inestimably proud of myself for (apparently) not breaking it even before turning it on. But the acid test remained -- powering it up.

In those days, IBM PCs came with a setup and diagnostics diskette. After making all the connections, you put the diagnostic floppy in Drive A and ran a check routine. I did that, and I was even happier than before when everything went well and the diagnostic diskette reported that everything was functioning properly. Cool -- time to shut down and go home.

So I looked at the menu on the screen for something -- anything -- that suggested "Turn Off," or "Shut Down," or "Nuke it from Orbit" -- alas, there was nothing suggestive of any of the above. I was a raw rookie and this machine came from IBM, so I assumed that I must have overlooked some obvious prompt. So I ran through the diagnostic routine again to look for it. In fact, I ran through the diagnostic routine four or five additional times before giving up. There simply was NO prompt for "Turn this thing off and go home."

Finally, in an act of desperation, I called the secretary and mercifully I found her at home. I explained where I was and what I was doing, and I asked her if she could tell me how to turn the computer off.

"Sure. Throw the switch."

The engineers who wrote the diagnostic program, and the instructions for it, knew that. They forgot that they were writing for people who did NOT know that. I encountered the same gap a few years later when I was beta testing a new release of PC Tools for Central Point Software. There was some routine in the package that simply did not work the way the instructions said it would. By then I had learned enough that I figured out what was needed and made it work, but Central Point was not receptive to being told that the instructions didn't match the program prompts. "You got it to work, right? So what's the problem?"

AAARRRGGGHHH!

[ArfinGreebly]

Survey assumes more structure than often exists in software development environments.

When I have more time, I may endeavor to repeat the survey for a completely different project in a different region and with a different company, where considerably more structure was involved, there were multiple teams with competing agendas, and a budget in the 7-to-8 figures.

Not tonight though.

[Doggy Daddy]

I encountered the same gap a few years later when I was beta testing a new release of PC Tools for Central Point Software. There was some routine in the package that simply did not work the way the instructions said it would. By then I had learned enough that I figured out what was needed and made it work, but Central Point was not receptive to being told that the instructions didn't match the program prompts. "You got it to work, right? So what's the problem?"

AAARRRGGGHHH!

Gawd!  I used to just love me some PCTools!

DD

[Scout26]

Gawd!  I used to just love me some PCTools!

DD

Yup, reading that brought a smile to my face.

[brimic]

Our corporation has a pretty good project management process to be followed for solving problems or making improvements. Any person from the janitor on up the the Site Director can propose improvements or problems that need to be solved. Once the process concludes, recommended changes have to be implemented. This worked pretty good for a few years, as it forced the hand of Quality and materials syestems to act- both areas are endlessly deep pools of inertia otherwise. The big downside was that Accountants are considered  people too and have run a few 'cost saving' projects of their own

[Tallpine]

The best problem solving process that I've seen is to get rid of the managers so the rest of us can get something done. 

Some of the places that I have worked - if you were trying to produce a baby, they would want to hire two more women so you could get the job done in three months 

[brimic]

Some of the places that I have worked - if you were trying to produce a baby, they would want to hire two more women so you could get the job done in three months

That's exactly what our accountants do.
Problem: our site is carrying too much overhead.
Solution: Have our chemists run 3x as many batches at 1/3 scale, cut the charged labor rate to 1/3, and excessive carpetwalker jobs are justified- well it was a way to put the day of ax swinging off for 6 months or so.
Us morlocks in production are slowing justifying running our batches at optimized scales- the size of batches that our company spent 10s of millions $$s on.

[ArfinGreebly]

[-snip-]

The big downside was that Accountants are considered are considered people too and have run a few 'cost saving' projects of their own

I once worked for an outfit that survived a few "cost saving" measures that originated in the accounting universe.

After a few of those, it became hard-and-fast policy that accounting shall not dictate promotional costs.

When your operation lives and dies by the quantity and quality of your promotional output, "saving money" on that is a Bad Idea.  Improving efficiency?  Sure, absolutely.  "Cutting costs?"  Yeah, not so much.

We also found that "deleting people" (because "people cost money") tended to have long-term bad outcomes.  We subsequently made very effort to keep people.  Why?  Because people make up your intellectual capital.  They also make up a substantial part of your customer relations continuity.

With a little thought, we found we could -- in the majority of cases -- keep the people and keep (or even expand) promotional actions when things got tough.  We gave up other things, and occasionally had to cut salaries, but keeping people made our recovery curve a lot shorter and inspired customer loyalty.

I've never worked anywhere since that solved its "downturn" problems the same way.  Every place since then has subscribed to some variation on the "toss the crew over the side" solution.  Oh, and "cut advertising costs" too.  And every single time the outcomes have (amazingly) been exactly what we discovered all those years ago.

Of course, it helps if you begin with the foundation understanding that "the company is not its staff" because the company is really "the board of directors."  With that as a jumping off point, tossing crew over the side -- and cutting advertising -- makes more sense.  Or at least it seems to make more sense.  And when things end badly, you can always blame it on the economy, since "what we did was consistent with Best Practices."

*Sigh*

[rcnixon]

Look into the Kepner-Tregoe problem solving and decision making process.

http://www.kepner-tregoe.com/theKTWay/WorkingWithKT-TeachYou-PSDM.cfm

I was a support engineer for a large manufacturer of data networking equipment and the use of K-T was STRONGLY encouraged as an aid to the resolution of highly complex end-user problems.

Russ