Research, Development and Testing Services

01Purpose and scope

• This manual supports the course Research, Development and Testing Services. It is written for practitioners who scope, run, or manage investigations, product or method development work, and independent or contracted testing for clients or internal teams.
• The manual covers how this work is usually organized: defining the question, designing studies or builds, running tests, interpreting results, and handing off findings. It describes typical deliverables such as study protocols, prototype reports, test certificates, technical memos and data packages.
• Practice varies widely. A university laboratory, a contract testing organization, an engineering group inside a manufacturer, and a software quality team each work differently. This manual gives a common structure and notes where those settings diverge. It does not replace the approved procedures, contracts or specifications that govern a particular project.

02Core principles

• Start from the decision the work must support. Research that does not inform a choice, and tests that do not answer a defined requirement, consume budget and produce findings nobody uses. Before any bench time is booked, the sponsor should be able to say what they will do differently depending on the result.
• Separate exploration from verification. Early development is allowed to be messy, with rough prototypes and shifting hypotheses. Verification work should be planned, controlled and repeatable, with acceptance criteria written down before data is collected. Mixing the two produces results that look rigorous but cannot be defended.
• Keep traceability. Each requirement, test case, sample, instrument reading and conclusion should link back to a source. When a reviewer asks where a number came from, the answer should take minutes, not days.
• Be explicit about uncertainty. Report measurement error, sample limits, and the conditions under which a result holds. Overstated confidence is one of the most common reasons a sound study is later distrusted by the people who must act on it.

03Planning and preparation

• Identify stakeholders early. The sponsor sets the question and budget. The technical lead owns method choices. A quality reviewer checks the plan and records. End users or customers define what success looks like in practice. Where regulation applies, a compliance contact should be named before work starts, not after the first problem.
• Define scope, deliverables, schedule and resources in a short written brief. Scope should state what is excluded as clearly as what is included. Deliverables should name formats, such as a protocol, a raw data archive, a summary report and a recommendation, along with who receives each one.
• Choose tools and standards deliberately. Requirements management software, version control for code and documents, a laboratory information management system, and a calibrated instrument register are common. Well known references include ISO/IEC 17025, which sets general requirements for the competence of testing and calibration laboratories, ISO 9001, which describes a quality management system, and good laboratory practice principles for nonclinical safety studies. Check which of these, if any, apply to your work and read the current text rather than relying on a summary.
• Make sizing decisions with stated assumptions. For comparative studies, a power analysis or a similar calculation can show roughly how many units or replicates are needed to detect a difference of interest. Write down the assumed variability and effect size. Larger samples cost more and take longer, while small pilots can mislead if they are presented as conclusive.
• Recognize how context changes the plan. Medical device development requires design controls and formal risk files. Consumer electronics testing often follows the customer specification and internal reliability targets. Academic research depends on ethics review, peer scrutiny and publication norms. Build vs. buy and in-house vs. contract decisions also shift cost, control and confidentiality. Where rules depend on jurisdiction, confirm the current requirements with the authoritative regulator or standards body.

04Recommended workflow

1. 1
   : Write the question and the decision it serves in a one-page brief, and have the sponsor sign or approve it. If the sponsor cannot name the decision, pause and clarify before continuing.
2. 2
   : Convert the brief into requirements or testable hypotheses. Each one needs an acceptance criterion or a clear way to refute it. Mark any item that cannot be measured with the available methods so the gap is visible.
3. 3
   : Draft the protocol or test plan. Include the method, instruments and their calibration status, sample or unit count, environmental conditions, positive and negative controls, the data to be recorded, the analysis approach, and stop rules for safety or invalid conditions.
4. 4
   : Review the plan with a reader who did not write it before any work begins. Record comments, the responses to them, and the final approval with names and roles. Changes after this point go through a formal change process.
5. 5
   : Run the work in controlled batches. Log deviations when they happen rather than reconstructing them at the end. Keep raw data unedited, and store corrections as annotated entries rather than overwrites.
6. 6
   : Analyze the results against the predefined criteria. Report failed, inconclusive and unexpected results as plainly as the passing ones. If the analysis plan must change, document why and who agreed to it, and label any exploratory analysis as such.
7. 7
   : Issue the deliverable, archive the complete data package, and hold a debrief with the sponsor. Capture decisions, open questions and the next recommended step so the work does not restart from zero later.

05Quality checks, risk controls and compliance

• Build quality checks into the work rather than adding them at the end. Typical controls include instrument calibration, reference materials, control samples, blind or coded samples where bias is a concern, repeated runs to estimate repeatability, and a second analyst for key calculations. The mix depends on the method and the consequences of error.
• Useful indicators include repeatability and reproducibility from replicate runs, deviation rate per batch, percentage of results with complete traceability, rework rate, and on-time delivery against the agreed schedule. Targets should be set per project and per method, not borrowed from another context. A target that is easy to hit but does not reflect the decision is of little use.
• Identify hazards and risks at planning time. Chemicals, high voltage, pressurized systems, biological material and heavy loads each need specific controls and training. Data integrity is a separate risk. Many laboratories use the ALCOA principles, meaning records should be attributable, legible, contemporaneous, original and accurate. Hazard analysis methods such as failure mode and effects analysis are common in engineering work when the cost of a failure is high.
• Compliance obligations vary. Studies involving people require ethics review and informed consent under local rules. Some technologies fall under export controls. Contracts often specify confidentiality, intellectual property ownership and publication rights. Testing for safety, medical, legal, tax or financial purposes is high stakes. This guidance does not replace qualified professional judgment, approved procedures or required authorization, and for jurisdiction-specific rules the current text from the relevant regulator or legal authority should be consulted.

06Collaboration and documentation

• Define roles in writing. A typical project has a lead who owns the plan, a test engineer or technician who runs the work, a data analyst who checks calculations, a quality reviewer who confirms records, and a sponsor representative who accepts results. Small teams often combine roles, but the approval authority should still be stated.
• Core documents include the protocol, the electronic or bound laboratory record, a change log, deviation reports, the test or study report, and an archive index that explains where raw data lives and how long it is kept. Reports should state the method, sample description, conditions, results with uncertainty, limitations and conclusions, in that order.
• Handoffs are where knowledge is most often lost. Moving work from a research group to a development group, or from a test lab to a manufacturing site, calls for a short transfer document, a walkthrough of the method with the receiving team, and a joint review of the first batch. Keep these handoffs short but mandatory.

07Measures and continuous improvement

• Track a small set of indicators that reflect the decisions the work supports. Choose measures such as on-time delivery, deviation rate, rework, and the share of results that met the predefined criteria on first review. Too many metrics take time to collect and rarely get read.
• Hold a short review at each project milestone and a fuller review at closeout. Ask what assumptions failed, which steps caused delays, where records were hard to find, and which controls caught real problems. Feed the answers back into protocol templates, checklists and training rather than leaving them in a closing file.
• Accept trade-offs. Tighter controls add time and cost. Faster schedules raise the chance of rework. The right balance depends on how costly a wrong answer would be and how reversible the decision is. Document the choice so later reviewers understand why the work was done the way it was.

08Common mistakes and how to prevent them

• Scope creep is common. A sponsor asks for one more condition or one more material, and the protocol quietly grows. Prevent this by routing every addition through the change process with a note on schedule and budget impact.
• Setting acceptance criteria after seeing data is a serious error. It makes results look favorable when they are not. Write criteria into the approved plan and refer back to them during analysis.
• Undersized studies and single instruments are another frequent problem. A result from one machine, one operator and one batch rarely generalizes. Add replicate runs, a second operator or a second instrument where the decision warrants it, and state the limits of what was tested.
• Reports that omit negative results or hide measurement uncertainty damage trust. Include failed runs, deviations and their effect on conclusions. A clear statement of what the data does not show is often more useful than a confident but fragile claim.
• Treating a prototype result as evidence of production capability is a costly assumption. Lab conditions, hand-built parts and expert operators differ from routine manufacturing or field use. Label prototype findings clearly and plan a separate verification step before scaling.

09Practical checklist

• Confirm the sponsor, the decision the work supports, and the approver for each deliverable.
• Write scope, exclusions, deliverables and schedule in a signed brief.
• Draft the protocol with method, instruments, calibration status, sample size, controls and stop rules.
• Set acceptance criteria before any data is collected and record who approved them.
• Check which standards, contracts, ethics rules or regulations apply, and confirm current requirements with the authoritative source.
• Log deviations as they occur and keep raw data unedited.
• Analyze against the predefined criteria and report failures and inconclusive results in full.
• Archive the complete data package with an index, and hold a debrief that records decisions and open items.

★Learning sources

• Micro Degree: Research, Development and Testing Services
• Micro Degree: Leadership and Team Management
• Micro Degree: Business Intelligence Management
• Micro Degree: ESG Advisory Services