"Wow! Of course! But, I don't see how..."

"Let's not worry about how now, but let's set this as a goal: 'A system so simple that even a doctor can use it!'"

"Wait," he said, "I'm not convinced you're one to do this job. Truthfully, we're looking for a radiologist who's familiar with ultrasound technology, someone that has worked with doctors, hospitals, and clinics. "I feel that only a radiologist could write documentation for our exotic new system. We'll keep you in mind..."

============================================================ 4. But, will I lose this client? ============================================================

I say, "I understand your concern. May I speak frankly?

(Yes.)

"Carole mentioned that you have many radiologists working here. Yet, your company delivers documentation that doesn't serve your customers.

"Your 800# is ringing off hook with needless questions and complaints... You don't need a radiologist to write your documentation; you need an expert high-tech writer.

"As I've told Carole, I have experience in biomedical applications. Tell you what. Let me show you what I can do in just two weeks. If you're not satisfied with what I produce, it won't cost you a penny."

"But, but I don't see how..."

"Let me worry about how. Do we have a deal?"

I stand there silently waiting for his response. I'm thinking I've really blown it! I've insulted his employee-radiologists and doctors in general.

I watch him agonize over his decision. I can't stand silence, but I keep my mouth shut. Carole smiles, but I'm sure she's wondering now...

...Finally, he says, "OK, I'll give you two weeks. I guess we have nothing to lose."

============================================================ 5. Did we do what customers wanted? ============================================================

I began interviewing designers, radiologists, and a few of their customers. I discovered nothing "wrong" with old system. It did what it was designed to do.

But, intricate complexities required users to endure extensive training. Plus, THE DOCUMENTATION HELPED ONLY EXPERTS!

Thus, customers were totally dependent on service engineers and expensive customer training.

To marketing, I promoted idea that new system should be designed from outside-in by USERS -- not from inside-out by engineers.

This was a switch. Formerly, they had to market whatever engineers created.

We immediately conducted brainstorming sessions with customers andpotential customers. We quickly discovered what USERS wanted, which had a positive impact on design standards.

I was surprised when they decided to use motto, "So simple that even a doctor can use it!" Of course, we used our motto only in-house. But, it gave us all an "idea worth working for."

Everyone knew that most doctors would seldom operate system because they employ radiologists to do that. All doctors want is data (images) for analysis. However, we knew that doctors had strong buying influence... and if they could get a "hands-on" demo during "shoot-out," they would be more likely to buy it.

Plus, we found that doctors loved fact that we were thinking of them.

In 2 weeks, we developed tremendous inertia and excitement.

Over next several months, we had frequent meetings with product designers and medical professionals. We brainstormed ideas for user interface, and how documentation might streamline user learning.

As I documented system, I tried all emerging features as a "dumb user." Hence, I found many bugs and discovered ways to streamline and simplify user interface.

Sure, programmers and engineers resisted changing hardware and software. Yes, we worked long hours. Yes, Configuration Control Board had to approve system and my documentation. And finally, everything had to be FDA approved. But, we met delivery date with a system "so simple that even a doctor can use it."

It all began with that idea worth working for.

Businesses don't work by themselves; people work. And thing that makes people work is AN IDEA WORTH WORKING FOR.

Best Regards, Mike Hayden

mailto:Mike@SeniorManagementServices.com Principal/Consultant Your partner in streamlining business. ©2004 Mike Hayden

Your development effort may span several months. You may schedule PERFECTIVE maintenance in cycles of one to six months. But, you may require CORRECTIVE maintenance within hours.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Functionally, you can divide documentation maintenance activities into three categories:

PERFECTIVE, ADAPTIVE, and CORRECTIVE.

Let me explain...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PERFECTIVE MAINTENANCE

"Perfective maintenance" is when you make changes, insertions, deletions, modifications, extensions, and enhancements to improve understandability or maintainability.

You generally do Perfective maintenance because you have new or changing requirements, or you may need to fine-tune documentation.

Fine-tuning is an excellent way to introduce a new writer to your documentation. This will reduce your chance of serious errors later.

Both failures and successes of your documentation require Perfective maintenance. If your documentation works well, users want more features; if your documentation works poorly, you must fix it.

When you perform Perfective maintenance on poorly written documentation, you can dramatically reduce resource requirements by making your documentation more maintainable.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ADAPTIVE MAINTENANCE

"Adaptive Maintenance" is when you adapt documentation to changes in user environment. Environmental changes are normally beyond control of writer and consist mainly of changes to:

Rules, laws, and regulations that affect documentation. Typically you must quickly make these changes to meet dates established by rules and regulations.

Equipment configurations, such as, new computers, new terminals, local printers, etc. Usually, you want to take advantage of improved features and/or pricing. You normally perform this maintenance on a scheduled basis.

Data formats, file structures, etc. You may require extensive maintenance if these items were not properly designed and implemented. If you can isolate changes to specific modules, maintenance may have less impact. If not, effort can be both lengthy and costly.

System software, operating systems, compilers, utilities, etc. In these cases, you usually perform maintenance on a schedule.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CORRECTIVE MAINTENANCE

"Corrective Maintenance" is when you must fix errors - sometimes immediately.

Generally, you'll find three types of errors:

Design errors.

These errors include incomplete or faulty design because of incorrect, incomplete, or unclear descriptions, or when writer does not fully understand user's needs.

Logic errors.

Often, logic errors occur when user instructions and/or unusual data combinations are not tested during development or maintenance. These errors, usually attributable to designer or previous maintainer, include invalid assumptions, tests, instructions, or conclusions, or faulty logic flow, and incorrect implementation.

Writing Errors.

The writer causes these errors. These errors include incorrect implementation or design logic, or incorrect use of special terms. While these errors may be result of negligence or carelessness, they are usually easiest to fix.

NOTE: Many managers consider maintenance to include changing specifications or adding new capabilities.

Fascinating stuff, eh?

============================================================ 5. Call to Action ============================================================

As I've said before, I'm a fanatic about documenting business processes.

Find out for yourself! You have nothing to lose.

Together, let's document what you want, how you want it, and when you want it. We will discuss various creative approaches before project begins.

Mike Hayden Principal/Consultant Your partner in streamlining business.