• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
How to develop technical manuals
 

How to develop technical manuals

on

  • 326 views

 

Statistics

Views

Total Views
326
Views on SlideShare
323
Embed Views
3

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 3

http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    How to develop technical manuals How to develop technical manuals Presentation Transcript

    • Pappas Consulting, LLC
    •  Survey the Available Resource, Analyze the Physical Article, Analyze the Functional Article, Assess the Content Requirement, Assess the Appropriate Content, Design the Document, Implement Tool Development over Data Mining, Implement the Writing Process based on available engineering and scheduled events, Perform Scheduled Reviews and Validations, Edit and Publish the Final Product.
    •  Assess the available resource.  Drawing Package (As built Drawings, Integration Diagrams, and Functional Flows),  Subject Matter Experts (Designers, Engineers, Maintainers),  Physical Equipment (Article) for research.
    •  Assess the complexity of the article to be documented  Information Discovery: ▪ Count the number of Systems, ▪ Count the number of Subsystems, ▪ Count the number of Line Replaceable Units (LRU), ▪ Count the number of LRUs that require Man-Machine Interface (MMI), ▪ Count the number of Controls and Indicators for each LRU that requires MMI, ▪ Identify the modes of operation for each LRU, ▪ Identify the Functions within each mode of operation for any one LRU.
    •  Develop a Top Down Physical Breakdown (TDPB) of the System and its components represented with an indenture schema.  Associate Attaching Hardware  Associate Cables  Associate Peculiar Support Meta-Data  Associate Research Traceability to the NHA  Associate a coded system for Data Sorts
    •  Perform Task Analysis using the S1000D Task Descriptions (at various levels of information discovery) for each item in the TDPB:  System  Subsystem  MMI Controls and Indicators  Functional Tests and Checks for LRUs with Modes of operation  Operational Procedures  Emergency Operation Procedures  Preventive Maintenance Requirements  Periodic Maintenance Requirements  Repair Actions  Disassembly and Assembly for items that might be provisioned  Provisioning Parts Lists  Special Tools and Test Equipment Requirements  Consumable Material Requirements  Peculiar Tasks as required...
    •  After assessing all possible content objects to be documented, this will produce the Data Module Requirements List (DMRL).  Each item in the TDPB of the equipment should have a set of Tasks associated to it from the DMRL. Using the S1000D, assign SNS (Subject Numbering System) to each task.  This will result in a system of data management whereby: ▪ Content objects can be sorted on task type or functional group, ▪ Content Object complexity can be predicted and assigned a performance weight, ▪ Content objects can be assigned to individuals and performance taken against every aspect of the TM under development, ▪ Content objects will enable the data designer to produce the skeletal XML code required for each content object, ▪ Earned value can be assessed against each Content object.
    •  To discuss system or subsystem functionality it is necessary to interpret and understand the Engineering Functional Flow diagrams. One step toward grouping equipment functionally is to use an S1000D SNS schema on the TDPB. Another technique used to communicate function is to associate cable runs as they apply to items in the TDPB.  Ultimately the TDPB will represent the indentured schema in the vertical plane while the functional relationship between subsystems is expressed in the horizontal plane.
    •  Refine the DMRL using a Level of Repair Analysis (LORA).  Implication: if LORA does not exist, perform LORA. Refine the Failure Mode tasks using the Failure Mode Effects and Critical Analysis (FMECA).  Implication: if FMECA does not exist, perform FMECA. Refine Provisioning Lists using the Provisioning Documentation Analysis (PDA).  Implication: if PCA does not exist, perform PCA.
    •  Using a Content Specification, create the outline of the document. When using XML, create the framed or unframed XML instance. Apply Business Rules to the TM Outline (or XML framework). Crosswalk all of the DMRL coded objects into the Outline (or XML framework). Use single point management of this Outline instance while populating it with content.
    •  Gather resource documentation and place it on a common server location.  Engineering Drawings,  Special Tools and Test Equipment Lists,  Personnel Conduct of Training Documentation (CTD),  Item Unique Identification (IUID) assessment. Create Content Object templates.
    •  Place Task Orders for each DMRL line item on the server for Team Members to work.  Define the Entrance Criteria,  Define the Exit Criteria, ▪ A Spreadsheet Tool works well.  Provide the specification Resource,  Provide GFI,  Provide the content template.
    •  Based on the scheduled development of engineering subjects produce the work schedule for writing content objects. Assess milestone development against the document that supports a review cycle.  30% typically exhibits the content data structure, the outline of subject matter, and all of the written administrative content derived from Business Rules and Regulations,  70% typically exhibits the 30% criteria and 50% of the predicted page count,  90% typically exhibits a complete TM minus engineering changes that have occurred throughout product development,  The 90% product should support the Validation and Verification of the product against the actual equipment,  Preliminary Draft typically exhibits a complete manual ready for Editor Review,  Final Draft removes all of the preliminary markings and is attached to the DD-250 for delivery.
    •  Hire Technical Writers that can...(satisfy your requirement). Hire Illustrators that can...(satisfy your requirement). Hire a Data Designer that can...(satisfy your requirement).
    •  Implement the plan for technical manual development:  Assign Tasks,  Collect Page counts and progress weekly,  Update the EVMS database weekly,  Ensure team members have what they require to perform to tasks. Schedule program events for reviews.  Perform reviews as scheduled. Successfully complete the project under budget and within schedule. Have a party!
    •  Over the past 15 slides several things were going on all at once; or at least staggered in parallel:  Project planning and management,  Data Design of the specified content,  Content Development,  Provisioning,  Illustrating the manuals. It is necessary to permit the engineering product to drive these efforts when TM development occurs during development of the engineered article.
    •  The blow by blow litany of tasks to perform above only represents the end result of any one thing that must be achieved. The true nature of the beast is one that requires leadership and planning as well as, senior skill sets to guide the team in technical agility. All of which is supported by various skill levels (dependant upon who is available today). This complex skill set represents the performance model for your team. Whatever the skill mix of your team, it will equate to "how many hours per page" you perform. Therefore it is imperative that a knowledgeable writer (who has engaged at least 5 or more full programs) estimate the hours for such an undertaking. A very skilled team may operate at 5 hours per page while a newly incepted team engaging a learning curve may take 10 hours per page. An unskilled group may easily burn 16 hrs/page. Efforts that also require the Logistics analysis could require an additional 8 hours per page. These estimates of course are subject to the skill level and mix of your team as well as, the level of complexity and available resource.
    •  Basic TM Approach (loosely on the 38784) for a Maintenance Manual. Broad System Description.  Type of system and it’s function,  The elements used to implement the system (aircraft, Ship, Truck),  Common resources: ▪ Documents, ▪ Materials, ▪ Support Equipment.
    •  Physical Description.  System Description of overall equipment placement,  Equipment locations (LRUs). ▪ Supporting tables, ▪ Supporting Figures.  Controls and Indicators. ▪ Supporting tables, ▪ Supporting Figures.
    •  Theory of Operation. Functional Description.  Electrical power distribution. ▪ Primary Power Source, ▪ Power Conversion, ▪ AC Distribution, ▪ DC Distribution, ▪ Emergency Power System,  Control Distribution for each Mode and Function. ▪ Signal Flow Discussion.
    •  Procedures.  Auto Test (BIT/BYTE),  Manual Test. Fault Isolation.  If/Then Logic. Remove/Replace. Disassembly/Assembly. Repair.
    •  Diagrams.  Block – Electrical,  Elevation –Installation. Illustrated Parts Breakdown.  Illustrated breakdown of each provisioned item,  List of equipment coded out with ordering information. ▪ Stock Numbers, ▪ Parts numbers, ▪ SMR Codes.