TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I recently submitted a posting recommending the PAR (Problem, Action,
Result) format for creating powerful resumes. In response to several
requests, below are a couple sections from my own resume (done considering
PAR). For reasons that I don't want to get into, I decline to post my whole
resume.
Comments always welcomed!
Thanks,
Tony Markatos
(tonymar -at- hotmail -dot- com)
Note: For those unfamiliar with the PAR approach, its basic format (per
employer) is as follows:
1.) The problem(s) that I faced. This does an excellent job of putting the
action(s)into proper perspective.
2.) The action(s) that I took to solve the problem(s).
3.) The result of the action(s) (quantified if possible).
SAMPLE RESUME - Experience Section
AT COMPANY X
Company had no process in place to create quality Software Requirements
Specifications for their product - a complex medical-provider
payment-processing system. Existing specifications were criptic and
incomplete, making change management for the existing client base very
difficult and costly.
Created data flow diagrams and entity relationship diagrams to rigorously
analize tasks accomplished and data relationships. Used this understanding
to write requirements specifications for the existing client base.
Extensive use made of technical writing principles to make this
documentation very end-user focused. Created documentation that, except at
the detail-level, is very generic - it can easily be edited to create
specifications for future customers. The specs are also used for effective
on-going maintenance of existing installations.
AT COMPANY Y
Company had a complex transportation-industry software product that was
being withheld from market due to a lack of end-user documentation and
numerous quality issues.
Developed data flow diagrams to rigorously analize how the software
functioned. Utilized this understanding to create new and edit existing
end-user documentation. Worked on over 100 individual applications. This
documentation enabled the product to be brought to market.
Developed system-level and module-level functional test cases. Tested the
functionality of all applications. Submitted over 450 software change
requests to correct logical errors and discrepancies between different
versions. Almost 90% of the request were implemented. Over 25% were for
high-priority changes to the system.
Wrote detailed systems-level test procedures (i.e., test scripts) for the
last two versions of the software. Verified the procedures for completeness
and ease-of-use. The procedures are being used to retest the system after
changes have been made, significantly increasing on-going quality. The
procedures are also being used to train new computer programmers on the
system, significantly reducing their learning curve.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com