Good software delivery is not only about whether the final code works.
It is also about whether the right requirements were understood, whether changes were controlled, whether the result was properly verified, whether problems were dealt with openly and whether each project improves the way the next one is delivered.
LiteByte uses ISO 9001:2015 as a reference framework for the way we manage quality across our organisation and software delivery.
ISO 9001 is a Quality Management System (QMS) standard. It uses a process-based, risk-aware approach built around planning, delivery, evaluation and continual improvement.
For LiteByte, that creates a simple principle:
Understand what we are promising, control how we deliver it, verify the outcome and learn from the result.
Requirements before development
Quality starts with understanding what the client actually needs.
Before committing to delivery, we establish the relevant requirements for the product or service.
That can include:
- the client's stated requirements;
- delivery and post-delivery expectations;
- requirements necessary for the intended use;
- applicable legal or regulatory requirements;
- acceptance criteria; and
- requirements LiteByte considers necessary for successful delivery.
ISO 9001 requires organisations to review these requirements before committing to supply a product or service and to make sure they are capable of meeting them.
The objective is straightforward:
the client, delivery team and reviewers should have the same understanding of what successful delivery means.
Quality is planned, not inspected in at the end
Testing cannot compensate for unclear requirements or uncontrolled delivery.
We plan the stages, responsibilities, reviews and evidence appropriate to the project before simply starting development.
Depending on the engagement, that can include:
- requirements review;
- architecture and design review;
- implementation;
- verification;
- validation;
- release review;
- client acceptance;
- and post-delivery support.
ISO 9001 specifically requires appropriate planning around design and development, including responsibilities, reviews, verification, validation and the evidence required to show that requirements were met.
Verification and validation
Building something correctly and building the correct thing are not always the same.
We distinguish between:
Verification
Did the output meet the defined requirements?
and Validation
Does the finished product actually work for its intended use?
That distinction is particularly important in software.
A feature can technically match a specification while still failing to solve the client's actual problem.
ISO 9001 explicitly treats design review, verification and validation as distinct quality activities.
Changes are controlled
Requirements change. The important thing is that the consequences are understood.
Software projects evolve.
New information appears.
Priorities change.
Users provide feedback.
Technical constraints are discovered.
ISO 9001 does not require projects to remain frozen.
It requires relevant changes to be reviewed and controlled.
For LiteByte, material changes should make clear:
- what changed;
- who approved it;
- which requirements are affected;
- whether acceptance criteria need updating;
- and whether other technical, security, privacy or AI assessments also need to change.
The standard specifically requires changed requirements to be reflected in the relevant documented information and communicated to the people affected.
Risk-based delivery
Some things are more likely than others to stop a project succeeding.
We use risk-based thinking to identify factors that could prevent the intended outcome or create an opportunity to improve it.
At project level, that might include:
- unclear requirements;
- client dependencies;
- approval bottlenecks;
- critical third-party services;
- tight migration windows;
- specialist knowledge;
- or significant delivery constraints.
ISO 9001 deliberately allows flexibility here. Its guidance explains that the standard does not require every organisation to implement a heavyweight formal risk-management methodology solely for QMS purposes.
The purpose is to think ahead, not create paperwork for its own sake.
Suppliers remain part of our delivery
Outsourcing part of a service does not outsource responsibility for the result.
Modern software depends on external providers.
That can include:
- cloud infrastructure;
- software platforms;
- specialist subcontractors;
- third-party APIs;
- hosting;
- and other service providers.
ISO 9001 requires organisations to determine appropriate controls over externally provided products, services and processes according to their potential impact on the final result.
Where an external dependency is material to delivery, we consider whether it is suitable for the role it performs rather than treating every supplier as automatically equivalent.
Release requires evidence
“Looks finished” is not a release criterion.
Before delivering or releasing work, we verify that the planned requirements and acceptance criteria have been addressed.
Depending on the project, that evidence may come from:
- functional testing;
- quality assurance;
- security testing;
- performance evidence;
- accessibility testing;
- AI assurance;
- privacy/security reviews;
- client acceptance;
- or other specialist controls.
ISO 9001 requires planned arrangements to verify that product and service requirements have been met before release.
When something does not meet requirements
Quality management should make problems visible, not hide them.
ISO 9001 uses the term nonconforming output for something that does not meet an applicable requirement.
That might mean:
- a failed acceptance test;
- a missing requirement;
- a release that does not meet the agreed outcome;
- or another material deviation from what was specified.
Where this happens, the issue should be controlled.
Depending on the circumstances, that can mean:
- correcting it;
- preventing release;
- informing the client;
- or obtaining explicit acceptance of an agreed exception.
ISO 9001 requires nonconforming outputs to be identified and controlled rather than simply treated as complete.
Fix the cause, not only the symptom
A defect and a process failure are not always the same thing.
Sometimes the right response is simply to fix an isolated problem.
But when the same type of failure is likely to recur, we look at the underlying cause.
ISO 9001's corrective-action process includes:
- reviewing the problem;
- determining its cause;
- considering whether similar problems could exist elsewhere;
- taking appropriate action;
- and checking whether that action was effective.
That helps turn problems into improvements rather than recurring project history.
Customer satisfaction matters
A technically complete project can still fail to meet the client's actual expectations.
ISO 9001 places significant emphasis on customer focus and requires organisations to monitor customers' perceptions of whether their needs and expectations have been fulfilled.
For LiteByte, useful evidence can include:
- client acceptance;
- project feedback;
- support issues;
- complaints;
- post-delivery discussions;
- and other signals about whether the delivered result genuinely achieved the intended outcome.
The objective is not to create a survey for the sake of having one.
It is to understand whether our delivery process is producing the result customers actually need.
We retain what projects teach us
A good lesson should not disappear when the project closes.
ISO 9001 specifically treats knowledge gained through experience, including lessons from successful and unsuccessful projects, as organisational knowledge that should be maintained where necessary.
Where a project reveals something genuinely reusable, we feed it back into areas such as:
- engineering practices;
- scoping;
- testing;
- estimation;
- deployment;
- supplier selection;
- documentation;
- or client communication.
The aim is simple:
the tenth project should benefit from what we learned on the first nine.
Continual improvement
A quality process should not remain unchanged simply because it has been documented.
ISO 9001 operates around the Plan–Do–Check–Act cycle: plan the process, perform it, evaluate the results and use what was learned to improve it. The standard's own QMS model shows planning, operations, performance evaluation and improvement working as one continuous system.
It also requires internal audits, management review, corrective action and continual improvement of the effectiveness of the Quality Management System.
For LiteByte, quality management therefore means more than delivering individual projects well.
It means making the delivery system itself better over time.
ISO 9001 and software quality
ISO 9001 and ISO/IEC 25010 serve different purposes.
ISO/IEC 25010 helps us define what quality means for the software product itself: areas such as reliability, performance, security, maintainability and usability.
ISO 9001 helps us manage the organisational and delivery process used to achieve the agreed result consistently.
The two complement one another.
Our other specialist security, privacy and AI frameworks operate in the same way: their detailed technical evidence can support the wider quality-management process without reproducing the same controls in multiple places.
What alignment means at LiteByte
LiteByte uses ISO 9001:2015 as a reference framework for its quality-management and delivery practices.
That means we aim to:
- understand requirements before committing to delivery;
- define what successful delivery looks like;
- plan appropriate reviews and verification;
- control material changes;
- manage important external dependencies;
- verify requirements before release;
- record and address material nonconformities;
- learn from customer feedback and project outcomes;
- and use those lessons to continually improve the way we work.
The goal is not more documentation.
It is a more consistent delivery process with clearer requirements, better evidence and fewer repeated mistakes.