Recommendations to improve efficiency in the context of quality.
This document provides recommendations to improve company efficiency and so its quality.
It is mostly written in the present time to prevent using constructs as “should have”, “must have”,
“could have” or “should have had”.
As the company grows the need for structure is apparent since a department does not exist
out of a single person anymore. Information and request for information need to be shared
among departments and cross company.
Areas of efficiency improvement:
There are many types of communication each with advantages and disadvantages.
Asynchronous communication prevents staff from shifting focus and being more efficient in what they do.
Communication where decisions are made must be documented and so accessible by current or future members.
Procedures on handling company communication is documented in a QA work-instruction.
A meeting is verbal and thus synchronous communication where all participants need to be present at the same time.
A meeting without a agenda is per definition a brainstorm session and therefore not efficient.
To make meetings efficient an agenda is mandatory and sets the boundaries about what is to be discussed.
Minutes-of-meeting are mandatory so that decisions are well documented and available for all meeting
and project members. The context of a meeting is always project.
When external company meeting members are present they receive a copy of the MOM (PDF) as well.
E-mail communication is only to exchange information externally and is never be a means to archive
project information. The information is only available for the individual receiver.
Project members can not access the information.
In order to make the received information available for others the only important e-mails are saved
as document is the designated folder in the project folder.
Subjects are always prefixed with a project numbers to provide context and traceability.
Other additional numbers for more context are advised.
Microsoft Teams 365 is a way to have discussions like a meeting but asynchronous which members can
add comments or ask questions in several topic channels.
Each channel name has project number to establish the channels context and boundary so that decisions made in
the discussions are documented in the appropriate project directory and available for the project members.
Internal company website/wiki to make general company information easily available and searchable.
The GitLab provided wiki does not provide the required features and is there for unsuited for this task.
Software from MediaWiki provide open source software that is used by WikiPedia has all features like
content indexing and version management. WikiPedia has proven itself through the years.
Questions are asked but not registered or documented most of the time.
To efficiently handle questions in the company true ticketing software is required.
Unlike question asked in e-mail a ticket keeps popping up until answered.
The tickets/questions are assigned to a group of staff members (i.e. department) rather than
to an individual staff member. This is to improve efficiency and tickets are handled even when
a staff member is out of commission through sickness or a vacation for example.
Tickets must be able to be postponed its due date into the future and not thus not visible
in the current active list to promote efficiency in handling unresolved tickets.
Tickets are linked to projects so that all unresolved tickets of a project can be listed to improve efficiency there as well.
In short a ticketing system has the features:
This means that tickets are visible for all groups that the member is part of.
Projects provide a context for all the work done in a company.
Projects are used for registering worked hours and is a context for storing information in the form of documents.
This requires a well documented directory structure on a fileserver.
This is provided as QA work-instruction and is easy accessible to company staff (i.e. Intranet/Wiki).
A Project Initiation Document defines the project scope, management, and overall success criteria that
the team can go back to during the project.
It contains the basic information of the project such as context, scope, team, and collaboration.
It is equally important as an internal guide and for external stakeholders.
A solid start to a project is key, no matter how small or large a project is.
A Project Initiation Document helps guide the team early on – to a successful project start without
creating too much extra work upfront.
The PID can be a living document that the team can fall back on.
It also provides a safeguard if there is a change in resourcing or new team members are brought on
to the team and is an ideal starting point for ramp-up.
The Project Initiation Document (PID) is the first basic step to ensure your project sets off
on the right foot. It sets the tone, context, expectations, and constraints.
QA work-instructions for all departments are essential to improve efficiency.
It provides staff the guidelines to operate within the department.
QA work-instructions for the company as a whole is efficient.
New staff members are up-to-date after reading it.
work-instructions are easily available as a document or through the company’s intranet.
work-instruction are living documents and changed when needed.
The instructions are written in such a way that staff is referenced by function and not by name.
The company has work-instructions on about everything that is regularly done or used.
Topics dealt with in the work-instructions are:
The QA department has a work-instruction which deals with:
The software department has a work-instruction which deals with:
The embedded department has a work-instruction which deals with:
The system administration department has a work-instruction which deals with:
The assembly department has a work-instruction which deals with:
The sales department has a work-instruction which deals with:
The logistics department has a work-instruction which deals with: