Got an idea worth working for? A case study.

Written by Mike Hayden

============================================================ Got an idea worth working for? A case study. ============================================================

CONTENTS: 1. Does this problem sound familiar? 2. Have you ever been to a sales "shoot out?" 3. Is this an idea worth working for? 4. But, will I lose this client? 5. Did we do what customers wanted? 6. It all began with that idea worth working for.

As I've said before, businesses don't work by themselves; people work. Andrepparttar thing that makes people work is an idea worth working for.

Here's how this principle worked for my client and me.

============================================================ 1. Does this problem sound familiar? ============================================================

I arrive for my appointment with Carole, a product-marketing specialist who works for their VP of Marketing. Inrepparttar 119471 lobby, we have a brief meeting where she explainsrepparttar 119472 situation.

"Our 800 number is ringing offrepparttar 119473 hook! We can't handle allrepparttar 119474 customer's questions and complaints. We cover everything in our product manuals, but our customers refuse to read them."

"Why won't they read them?" I ask.

"Our manuals were written by programmers and engineers. Our customers are radiologists and physicians and they refuse to read them!"

"Well, I'm sure I could..."

"Wait, there's more. We're designing our new 'flagship' ultrasound imaging system, and we don't want to make repparttar 119475 same mistakes again."

I say, "Good idea! It's always best to develop documentation as you developrepparttar 119476 system."

"I agree," said Carole. "Our last effort was a hasty, last minute compromise - after we had already builtrepparttar 119477 system. Now, we're payingrepparttar 119478 price. This time we're going to do it right. Let's go meet Greg, my boss."

============================================================ 2. Have you ever been to a sales "shoot-out?" ============================================================

We takerepparttar 119479 elevator torepparttar 119480 second floor, where Carole gives me a brief tour ofrepparttar 119481 systems development area. She then escorts me to Greg's plush corner office with its view of Silicon Valley and south to Los Gatos. Carol introduces me to Greg, then tells him about our prior phone conversations and today's brief meeting.

After some cordial conversation, I ask Greg, "Can you tell me a little about your typical sales cycle?"

"Why? I thought you were a technical writer."

"Actually, I've spent a few years in sales and I'm well aware ofrepparttar 119482 need for good documentation when selling. Maybe we can writerepparttar 119483 documentation to help you sell more systems. I assume you'd be interested in that."

"Hmmm..." he said. I could tell he was skeptical. "Well, OK. We take part in what we call a 'vendor shoot-out.' "Our shoot-out isrepparttar 119484 most important part of getting repparttar 119485 order - if we don't acerepparttar 119486 shoot-out; we don't get repparttar 119487 sale. "A shoot-out occurs when all competing vendors bring their equipment to a specific room in a hospital or clinic. Inrepparttar 119488 room, there will be a real (or pretend) patient. We vendors then gather aroundrepparttar 119489 'patient' to demonstrate our equipment to physician and radiologists."

"Brutal!" I exclaimed. "Exactly how does that work?"

"The vendor's technicians take turns showingrepparttar 119490 physicians and radiologists how their system works with repparttar 119491 patient..."

I interrupt with a question; "Dorepparttar 119492 physicians and radiologists get to 'test drive'repparttar 119493 system?"

"Oh, no! The systems are so complicated that we must use experienced computer technicians for demonstrations."

"Are these techniciansrepparttar 119494 same programmers or engineers who developedrepparttar 119495 system?"

"Yes. Unfortunately, they must be there to handlerepparttar 119496 inevitable problems and crashes."

"So, when dorepparttar 119497 physicians or radiologists get to tryrepparttar 119498 system?"

"They don't. No vendor is willing to take that risk because ofrepparttar 119499 possibility of a crash!"

============================================================ 3. Is this an idea worth working for? ============================================================

I ask, "Suppose you wanted to buy a new car andrepparttar 119500 salesman would only let a mechanic take you for a demonstration drive. Would you buy a car that you couldn't drive your self?"

"No, but this is different. After they buy a system, repparttar 119501 winning vendor will give extensive training torepparttar 119502 buyer's technicians who will runrepparttar 119503 equipment."

I respond, "OK, what if your new system were so simple to use that physicians and radiologists could demonstrate it to themselves? Would that be an advantage in selling?"

Are you maintaining your documentation correctly?

Written by Mike Hayden

============================================================ Are you maintaining your documentation correctly? ============================================================

As I've said in many eZines, you must write stuff down.

The other day, an interviewer asked,

"How many pages you written?"

"Somewhere around 30,000 pages delivered, not including thousands of draft pages."

"You must love writing!"

"Not really."

"Then what...?"

"I don't love writing per se. I loverepparttar applications. I loverepparttar 119470 results. In writing, you can create, let's say,repparttar 119471 first level of reality. By writing, you can begin to give intangible ideas form inrepparttar 119472 physical universe.

"Can you imagine how many people discoveredrepparttar 119473 secret of fire and didn't write it down? The news had to spread by 'tribal knowledge!'

"How many times didrepparttar 119474 secret vanish because some fire-novice asphyxiated himself and family? How many times do think some do-gooder banned fire due to its dangers?

"It probably took eons to discover that secret - over and over!

"Eventually, I suppose, someone wroterepparttar 119475 secret on a cave wall or cocktail napkin..."


"Planning to write is not writing. Outlining... researching... talking to people about what you're doing, none of that is writing. Writing is writing." -- E.L. Doctorow


Anyway, when you write stuff down, you'll eventually need to update it. (I'll talk here about large, important documents - Operations Manuals, Technical Manuals, User Manuals, or mayberepparttar 119476 secret of fire and how to control it.)

"Mike, what have you learned overrepparttar 119477 years about maintaining documentation?"

Well, large documentation projects have their own "life cycle." This cycle extends from conception to obsolescence.

When you develop large-scale documents, you'll typically iterate throughrepparttar 119478 following:

1. Requirements. Includes definition, statement of goals, preliminary analysis, functional specifications, and design constraints.

2. Design. Includes outline definition, format definition, etc.

3. Implementation. Requires writing, editing, integration of various components, and proofing.

4. Testing. Includes verification and evaluation againstrepparttar 119479 requirements.


But wait! There's another phase I call Documentation Maintenance! It begins after you deliver your documentation to your user.

You can divide Documentation Maintenance intorepparttar 119480 following steps: ___ Determine need for change ___ Submit Change Request ___ Review Proposed Changes ___ Analyze requirements ___ Approve/Reject Change Request ___ Schedule task(s) ___ Review and Analyze Design ___ Write and Edit ___ Test ___ Verify against Standards ___ User Acceptance


In these steps, I outlinerepparttar 119481 maintenance process, which begins when someone needs a change and ends when your user accepts your changes.

As you can imagine, changing documentation is frequently complex and may involve many people.

For example, imaginerepparttar 119482 task of updating documentation for applications in complex electronics, aerospace, law, medical, insurance, etc. Or, how about updating flight-prep manual for a commercial airliner?

The maintenance process above appears linear. But again, you'll undergo many steps and iterative loops.

For example,

You may need to clarifyrepparttar 119483 Change Request. You may require more analysis ofrepparttar 119484 Design Reviews. You may need to rewrite your Standards Audit. Your users may fail to acceptrepparttar 119485 results, etc.


Someone,repparttar 119486 "Maintainer(s)" must dorepparttar 119487 work.

This Maintainer must make changes withinrepparttar 119488 context ofrepparttar 119489 existing documentation. Maintenance people often find thisrepparttar 119490 most challenging problem.

The olderrepparttar 119491 documentation,repparttar 119492 more challenging and time-consumingrepparttar 119493 maintenance effort. But normally, maintenance takes you less time than development.

Cont'd on page 2 ==> © 2005
Terms of Use