Got an idea worth working for? A case study.

Written by Mike Hayden

Continued from page 1

"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'rerepparttar 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?


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

"Your 800# is ringing offrepparttar 119471 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 standrepparttar 119472 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" withrepparttar 119473 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 promotedrepparttar 119474 idea thatrepparttar 119475 new system should be designed fromrepparttar 119476 outside-in by USERS -- not fromrepparttar 119477 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 userepparttar 119478 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 operaterepparttar 119479 system because they employ radiologists to do that. All doctors want isrepparttar 119480 data (images) for analysis. However, we knew that doctors had strong buying influence... and if they could get a "hands-on" demo duringrepparttar 119481 "shoot-out," they would be more likely to buy it.

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

In 2 weeks, we developed tremendous inertia and excitement.

Overrepparttar 119483 next several months, we had frequent meetings with product designers and medical professionals. We brainstormed ideas forrepparttar 119484 user interface, and howrepparttar 119485 documentation might streamline user learning.

As I documentedrepparttar 119486 system, I tried allrepparttar 119487 emerging features as a "dumb user." Hence, I found many bugs and discovered ways to streamline and simplifyrepparttar 119488 user interface.

Sure,repparttar 119489 programmers and engineers resisted changing repparttar 119490 hardware and software. Yes, we worked long hours. Yes,repparttar 119491 Configuration Control Board had to approve repparttar 119492 system and my documentation. And finally, everything had to be FDA approved. But, we metrepparttar 119493 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. Andrepparttar 119494 thing that makes people work is AN IDEA WORTH WORKING FOR.

Best Regards, Mike Hayden Principal/Consultant Your partner in streamlining business. 2004 Mike Hayden

Mike Hayden is Founder/CEO of Senior Management Services and the Documentation Express in Silicon Valley, California. Mr Hayden is the author of "7 Easy Steps to your Raise and Promotion in 30-60 Days! The book that smart bosses want their employees to read." ISBN 0-9723725-1-2. More articles at

Are you maintaining your documentation correctly?

Written by Mike Hayden

Continued from page 1

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:


Let me explain...



"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-tunerepparttar 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" is when you adaptrepparttar 119470 documentation to changes inrepparttar 119471 user environment. Environmental changes are normally beyond control of repparttar 119472 writer and consist mainly of changes to:

Rules, laws, and regulations that affectrepparttar 119473 documentation. Typically you must quickly make these changes to meet dates established byrepparttar 119474 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,repparttar 119475 maintenance may have less impact. If not,repparttar 119476 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" 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 whenrepparttar 119477 writer does not fully understandrepparttar 119478 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 torepparttar 119479 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 berepparttar 119480 result of negligence or carelessness, they are usuallyrepparttar 119481 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 beforerepparttar 119482 project begins.

Mike Hayden Principal/Consultant Your partner in streamlining business.

Mike Hayden is Founder/CEO of Senior Management Services and the Documentation Express in Silicon Valley, California. Mr Hayden is the author of "7 Easy Steps to your Raise and Promotion in 30-60 Days! The book that smart bosses want their employees to read." ISBN 0-9723725-1-2. More articles at

    <Back to Page 1 © 2005
Terms of Use