Build

Build turns fragmented knowledge into complete learning systems. It is the project line — defined scope, defined end state, named artifacts handed over at the finish.

The starting conditions this work actually meets

This work rarely begins with a blank page. They begin with material that already exists in a state nobody is happy with, and a date that has already been communicated. The following conditions are the normal ones, not the difficult ones.

• The knowledge is real but scattered — slide decks, PDF manuals, recorded sessions, a shared drive, and two or three people who hold the rest of it in their heads.
• The deadline will not move. An audit date, a product release, an intake cohort, or a regulatory window has already been set.
• Review comments conflict. Three reviewers return three different corrections to the same screen, and nobody has been named as the decision-maker.
• There is an unfinished Storyline or Rise backlog. Some modules are published, some are half-built, and the design intent behind them is no longer written down anywhere.
• The online and classroom versions of the same subject disagree. Learners get different content depending on which route they took, and neither version is clearly the master.
• Assessments exist but do not measure the intended capability. They test whether someone read the screen, not whether someone can do the task.

Each of these has a different cause and a different fix. The first job is to name which one you actually have.

What Build covers

Build is a line, not a single product. Six services sit inside it. This page is the router; each one is described in full on its own page.

• Learning Content Rescue — for when material already exists and has stalled: inventory it, find the duplication and the gaps, and produce a reviewable plan for what to keep, rewrite, and retire before anything new is commissioned.
• Curriculum Consulting — for when the structure is the problem: what should be taught, to whom, in what order, at what depth, and how capability should be evidenced.
• Workforce Training Program Design — for a whole programme rather than a single course: multiple roles, multiple formats, a delivery pattern, and clear ownership of each part.
• Custom eLearning Development — for production: building modules, media, assessments, and packages to an agreed standard from an approved design.
• Accessible Learning Review — for checking existing or in-progress material against agreed standards and returning a prioritised, specific fix list.

Being unsure which of them applies is a normal starting position. Sorting that is part of the review, not a prerequisite for it.

What gets delivered

Build engagements are defined by artifacts, not by activity. Scope names which of the following are included, in what quantity, and to what standard.

• Curriculum maps — roles, objectives, sequence, formats, and assessment points on one page.
• Storyboards — approved before production begins, so that review happens on the design rather than on finished screens.
• Learner-facing modules — eLearning, self-study, or blended, built to the agreed template.
• Instructor guides and facilitation decks — so the classroom version matches the online version instead of drifting from it.
• Job aids and quick reference material — for the tasks people perform after training, not during it.
• Assessment plans and question banks — written against stated objectives, with the intended level of demand made explicit.
• SCORM or xAPI packages — tested in the target platform, not only in the authoring tool.
• Source files — editable project files, scripts, graphics, and design documents.

Source files are handed over at close. The point of a learning system is that it can be maintained after the project ends, including by someone else.

How the work runs

1. Discover — read what exists, work with your subject-matter experts, and confirm the capability required, the audiences, and the constraints that cannot be changed.
2. Architect — set the structure: objectives, sequence, format split, assessment approach, review route, and what is deliberately out of scope.
3. Build — produce the named artifacts against the approved architecture, in agreed increments, through a single consolidated review channel.
4. Validate — check against the objectives: accuracy sign-off, platform and packaging tests in the target environment, accessibility checks, and a pilot where one is possible.
5. Improve — correct what the pilot and first live delivery expose, and record what should change in the next revision cycle.

Where Build fits

• There is genuine subject matter and at least one person who holds it.
• Someone on your side can make and hold decisions about scope and content.
• An end state can be described, even roughly.
• The delivery formats are known, or can be decided as part of the work.

Where Build is the wrong line

• You need the system kept assigned, current, measured, and governed after launch. That is Operate, not Build.
• You have already won the work and need production capacity under your own brand. That is Partner.
• You want a learning platform selected, supplied, configured, or administered. IETERNUS is not an LMS vendor.
• You want large content volume generated automatically with minimal expert review. That is not how this work is produced.
• You want a guarantee of legal or regulatory compliance, or an accessibility certification. IETERNUS is not a regulator, law firm, or certifying body; accessibility work supports accessibility improvement and alignment with agreed standards.
• No source material exists and no subject-matter expert is available. There is nothing to build from yet.

The way in

Build starts with a Learning Systems Review. It examines the material you already have, the audiences it serves, the constraints around it, and the date it has to meet. It returns a scoped recommendation: which of the Build services apply, which artifacts are needed, in what order, and what should be excluded. If the honest answer is that you need Operate or Partner instead, the review says so.

Request a Learning Systems Review.