• 14 Aug 2026, 07:06 AM

10 Common Mistakes OEMs Make During IETM Development and How to Avoid Them

An Interactive Electronic Technical Manual for Defence and Aerospace OEMs provide much more than simply a digital version of a technical manual. A high-quality IETM combines technical information, maintenance practices, parts details, illustrations and other digital features in a structured way.

However, the success of an IETM project does not depend only on the IETM software or development team. The quality of the OEM's technical data, documentation processes, project planning and coordination with the IETM developer can significantly affect the final deliverable. In some projects, mistakes made during the initiation phase will later lead to a lot of setbacks, inefficiencies in operations as well as other difficulties in the verification and approval processes.

For OEMs planning an IETM project, understanding these common mistakes can help reduce risk and create a more effective technical documentation workflow.

Here are 10 common mistakes OEMs should avoid during IETM development.

IETM development rarely fails because of the software alone. In many projects, delays and rework begin much earlier with incomplete technical data, unclear standards, changing requirements or weak coordination between the OEM and IETM development partner.

1. Starting IETM Development Before the Technical Data Is Ready

One of the most common mistakes is beginning IETM development while the underlying technical documentation is still incomplete or undergoing major changes.

An IETM development team depends on accurate source information. This may include:

• Technical manuals
• Operator and maintenance manuals
• Illustrated parts information
• System descriptions
• Maintenance procedures
• Troubleshooting procedures
• Schematics and drawings
• Parts lists
• Specifications
• Safety information
• Fault codes
• 2D and 3D illustrations
• Approved revisions

How OEMs can avoid this

Before the work gets underway, OEMs should determine which technical documents are fully approved, which are being modified and which are still pending. In short, process of checking the documents and keeping control of the revisions allows the IETM development team to work with the right reference material, which is a key.

2. Treating an IETM as a PDF-to-Software Conversion

There is a commonly held belief that to develop an IETM all one needs to do is convert existing pdf manuals into some software application. An IETM is, in fact, designed to facilitate the access, navigation, and utilization of technical information.

With reference to the requirements of the project and the level of IETM, various features which can be included in the solution are:

• Structured navigation ·
• Search
• Hyperlinks and cross-referencing
• Interactive graphics
• 2D/3D visualization
• Troubleshooting information
• Parts information
• Multimedia
• User access control
• Bookmarks and notes
• Version management
• Interactive procedures.

How OEMs can avoid this

At the planning stage, define what the IETM needs to accomplish for the actual end user.

The objective should not simply be: "Convert our manuals into an IETM."

Instead, ask:

"How should a technician, operator or maintainer find and use this information when working with the equipment?" That change in thinking can significantly improve the final product.

3. Not Defining the Required IETM Level and Applicable Standard Early:

IETM projects need clear requirements from the beginning.

The manufacturers may have to comply with specific standards for defence documents, project specifications, or customer requirements. In Indian Defence projects, JSG 0852 is significant for IETM development, whereas in some aerospace projects or international projects, standards such as S1000D may be required.

The required IETM level and applicable documentation standard can influence:

• Content structure
• Navigation
• Database architecture
• Authoring methodology
• Multimedia requirements
• User access
• Validation
• Publishing
• Delivery
• Future maintenance

How OEMs can avoid this

Before selecting an IETM development approach, identify:

• The required IETM level
• The applicable documentation standard
• Customer/tender requirements
• Required deliverables
• Deployment environment
• Security requirements
• Validation and acceptance criteria

Code & Pixels existing IETM resources discuss Indian Defence documentation standards, including JSG 0852, as well as other technical documentation standards.

4. Providing Incomplete or Inconsistent Technical Information

The quality of an IETM can only be as good as the technical information behind it.

Information used by the OEMs can come from multiple teams:

• Design
• Engineering
• Production
• Quality
• Maintenance
• Documentation
• Testing
• Procurement
• Subsystem suppliers

When different teams provide information using different terminology, document versions or part references, inconsistencies can appear.

How OEMs can avoid this:

Create a controlled source-data process before and during IETM development. Version control is a crucial aspect.

A good workflow should identify:

Source → Review → Approval → IETM development → Validation → Release

5. Underestimating the Importance of 2D and 3D Visualization

Modern systems can be quite complicated. For a technician or maintainer, understanding of any individual part can be difficult just by reading the text. Through well-designed visual communication, one can understand:

• Equipment layout
• Component location
• Assembly relationships
• Disassembly sequences
• Installation procedures
• Part identification
• System architecture
• Maintenance procedures

Depending on the project, 2D illustrations, schematics, animations and 3D models can significantly improve the usability of an IETM.

How OEMs can avoid this:

Determine the visualization requirements early.

Ask the following questions:

• Which equipment requires 3D visualization?
• Are existing CAD models available?
• Which illustrations need updating?
• Which maintenance procedures benefit from animation?
• Which components require exploded views?
• What level of interaction is required?

Modern IETM platforms such as Quantum TechDocs support multimedia integration and 2D/3D visualization capabilities for complex technical documentation.

The objective should not be to add 3D simply because it looks impressive. It should be used where visualization genuinely improves understanding.

6. Treating Validation and Quality Assurance as the Final Step

Validation should not be something that happens only after the entire IETM has been developed. An IETM can contain thousands of individual pieces of information, links, references, illustrations and procedures.

Minor mistakes may greatly impact usability, such as:

• Broken links
• Incorrect cross-references
• Missing topics
• Incorrect part information
• Navigation problems
• Inconsistent terminology
• Incorrect illustrations
• Missing procedures
• Revision mismatches

How OEMs can avoid this:

Validation should be incorporated throughout the development lifecycle.

A structured QA process can include:

Content validation

Is the technical information accurate?

Structural validation

Is the content organized correctly?

Functional validation

Do search, navigation, links and other features work correctly?

Visual validation

Are graphics, tables and illustrations displayed correctly?

Usability validation

Can the intended user find and understand the required information?

Final acceptance testing

Does this finished IETM satisfy the agreed project requirements?

7. Designing the IETM Around the Technology Instead of the End User

An IETM may contain advanced features, but those features are useful only when they solve real user problems.

The primary users may include:

• Operators
• Technicians
• Maintainers
• Engineers
• Supervisors
• Training personnel

Their primary objective is usually simple:

Find the right information quickly and perform the required task correctly.

If the interface is complicated, navigation is confusing or search results are poorly organized, even technically advanced software can become difficult to use.

How OEMs can avoid this:

Design important workflows around actual user scenarios.

The IETM should ideally help the technician move efficiently through:

Equipment → System → Fault → Troubleshooting → Procedure → Required Part → Related Information

So, it is important to think about the user centered design while developing IETMs, instead of thinking after the program has been created.

8. Failing to Plan for Future Revisions and Updates

Equipment does not remain unchanged throughout its lifecycle.

Design changes, component changes, software updates, engineering changes and even maintenance could all be relevant for technical documentation.

If an IETM is developed without considering future revisions, updating it can become unnecessarily difficult.

How OEMs can avoid this

IETM projects should include a strategy for:

• Version control
• Content updates
• Revision history
• Reusable content
• Document/module management
• Change tracking
• Revalidation
• Future publishing

Using a modular approach makes it easier to change documents since only separate pieces of information need to be updated instead of the whole document. Modern IETM publishing platforms can also support modular content management and version control.

9. Selecting an IETM Vendor Based Only on Development Cost

Cost is naturally an important consideration in any project. However, choosing an IETM development partner purely on the lowest quotation can create risks later.

A couple of firms may provide similar results while differing greatly in terms of their:

• IETM expertise
• Defence documentation experience
• Standard compliance
• Technical understanding
• QA processes
• Visualization capabilities
• Software architecture
• Security
• Update mechanisms
• Long-term support

A lower initial cost can potentially become a higher total cost if the project requires extensive corrections, redevelopment or difficult future updates.

How OEMs can avoid this

When choosing an IETM developer, make sure to consider the full lifecycle of your project.

Ask potential vendors about:

• Previous IETM projects
• Applicable standards
• Development methodology
• QA and validation
• Security
• Deployment options
• Update mechanisms
• Technical support
• Visualization capabilities
• Previous experience with similar equipment
• Project references

For Defence OEMs, actual project experience can be particularly valuable because IETM requirements are closely connected to the equipment, documentation standard and customer requirements.

Code & Pixels published project portfolio includes IETM work across missile systems, naval systems, UAVs, radar and other defence equipments.

10. Not Defining Acceptance Criteria Before Development Begins

Acceptance criteria is one of the most neglected aspects of an IETM project. If the OEM, customer and IETM development partner have different expectations about what the final product should contain, disagreements can appear near project completion.

Before development begins, define measurable expectations for:

• IETM level
• Applicable standard
• Content coverage
• Navigation
• Search
• Cross-referencing
• Multimedia
• 2D/3D requirements
• User access
• Security
• Deployment
• Validation
• Documentation
• Revision management
• Final deliverables

How OEMs can avoid this:

Create an agreed project specification and acceptance checklist before development begins. This gives everyone a common definition of "complete."

Why OEM and IETM Development Partner Collaboration Matters:

An IETM project becomes more effective when both the OEM and development partner work jointly and do not function as independent groups.

The OEM understands the equipment, engineering information and operational requirements.

Meanwhile, IETM developers are proficient in the way information is structured, digital publishing, software functionality, visualization, navigation and documentation workflows

Combining these expertise areas is a way to create a truly useful IETM, rather than just a compliant one. This is particularly important for complex Defence programs where documentation may span multiple systems, subsystems and maintenance levels.

Conclusion:

When technical data, standards, software requirements and user expectations are not aligned from the beginning then IETM project can get quite complicated.

The good news is that a lot of the issues are preventable.

OEMs can cut down the amount of non-productive work by making sure that relevant technical information is collected, requirements are determined, the right visualization method is chosen, users are engaged, proper audit process is established and a qualified IETM development vendor is selected. Most importantly, an IETM should not be viewed simply as another project deliverable.

For Defence and Aerospace OEMs, that difference in perspective can determine whether an IETM becomes just another software deliverable or a genuinely valuable tool for operators, technicians and maintainers.

Planning an IETM Project?

If you're an OEM preparing an IETM for a defence, aerospace or complex engineering program, Code & Pixels can help you assess your technical inputs, documentation requirements, IETM level, visualization needs and development approach before authoring begins.

Discuss your IETM requirements with our team.

Learn More or Request a Demo

Website: www.codeandpixels.net
Email: ietm@codeandpixels.net
Phone: +91 98495 27706

GOPI KRISHNA GUDIVADA       Leading the R&D and Project divisions at Code and Pixels and Digital Teacher, driving innovation in e-learning, IETM software, and Defence documentation solutions. With 23 years in content development and 15 years in Defence technical documentation, I bring deep expertise in designing and implementing IETM solutions aligned with JSG 0852 and S1000D standards. Passionate about creating world-class digital training systems for the Indian Armed Forces and advancing the standards of e-learning in India.

____________________________________________________________________________________________________________________________________

Frequently Asked Questions

1. What are the most common mistakes OEMs make during IETM development?

The most common mistakes include starting development before technical data is ready, treating an IETM as a PDF conversion, not defining the required IETM level and applicable standard, providing inconsistent technical information, delaying validation, overlooking future revisions and selecting a development partner based only on cost.

2. Why should technical data be ready before starting IETM development?

IETM development depends on accurate and approved technical information such as manuals, maintenance procedures, drawings, parts information, safety information and approved revisions. Starting with incomplete or frequently changing data can lead to rework, inconsistencies and delays during validation and approval.

3. Is an IETM simply a PDF converted into software?

No. An IETM is designed to provide structured access to technical information through features such as search, navigation, hyperlinks, cross-referencing, interactive graphics, troubleshooting information, parts information and interactive procedures.

4. When should validation and quality assurance begin during IETM development?

Validation should be incorporated throughout the IETM development lifecycle rather than being treated as a final step. It can include content, structural, functional, visual, usability and final acceptance validation.