Other

As the interviews were quite freeform, proposals for improvement on also a more general level and not specifically related to any of the four main processes were brought up.

Many of them are still applicable to the processes at focus in this study, and even to all processes of the company. A total of five proposals were identified that fit this category.

The proposals as well as their frequencies in different interviews are listed in Table 7 and discussed in more detail below the table.

Table 7 General proposals for improvement and their frequencies in different inter-views.

Proposal Frequency

Regulatory documentation and related requirements should be more present in the development work

2

The document management procedures should be made quicker and more efficient

2

Almost all processes should be optimized for the current situation and number of employees

2

The process updates and optimization should be done in the context of an existing product project to ensure that the updates are valid

1

Process tables with all process steps and required documentation should be created to make them easily understandable and reviewable by employees

1

It was stated in two interviews that one of the reasons why many employees are not very familiar with the regulatory, especially documentation-related, requirements is that the documents are not very much present in the actual development work. For example, a software requirements specification document is made at some point in the development process, but once it is made, it is not returned to later on. Therefore, the interviewees suggested that if the documents were reflected on and referred to regularly in during the project, it would also be easier to keep them updated and ensure regulatory requirements such as traceability in the documentation. This would also support one of the company’s objectives, making the regulations and quality and product management system require-ments a part of the daily work in the company.

Two of the interviewees also pointed out that document management procedures are currently rigid and slow. Creating, editing and approving documents is laborious and in-efficient for both developers and the management. As a solution, it was proposed that the form and structure of documents should be re-evaluated and the approval process streamlined. At present, the regulatory documents are stored in Microsoft 365 Share-Point, a web-based collaborative platform used by the company, but one of the inter-viewees suggested that other storage options such as Git could also be considered. It was also indicated that currently, if developers wish to modify the regulatory documents related to their work, it is always not possible but sometimes requires a middleman to

accept or implement the changes, making modifying the documents quite inefficient and not encouraging keeping the documents up to date in real time. In another interview, it was discussed that the structure of document templates should be optimized in order to make creating documents as easy as possible, and that also the approval procedure with digital signatures should be streamlined. These actions would support keeping all docu-ments up to date and free up time for other tasks not related to document management.

The general status of the processes of the company was discussed in two interviews.

The interviewees agreed that many processes have been created and worked well a few years ago, when there were only a couple of employees, but that now that the number of employees is already closer to 20, the processes should be updated to serve the cur-rent situation better. One of the interviewees’ opinion was that regulation-wise, the pro-cesses are up to date and fulfil the requirements, but that the optimization regarding the actual work described in the processes lags behind. Therefore, almost all of the official processes should be re-evaluated and updated to suit the current situation. In another interview it was pointed out that as the number of parallel projects and products has increased, plenty of overlap has appeared in regard to the product-related and develop-ment work. The interviewee proposed that creating for example an upper-level architec-ture for all software and detecting and removing overlapping stages of work would create a clearer structure for the different projects and reduce unnecessary work.

The updating of processes in general and how the updates should be done to ensure that they are functional and valid was discussed with one of the interviewees. The inter-viewee thought that the updates should be planned and executed in the context of an existing product project, so that it could be verified in practice that the updates actually work and improve the processes in reality. This way, it could also be tested how the process changes can be implemented in the work of the project team members and how they affect the overall workflow and results of the process.

Finally, one of the interviewees highlighted that in general, employees are not very in-formed about the process descriptions. As there is no time for the employees to familiar-ize themselves with the long and detailed descriptions and to interpret what documenta-tion is required from all the process steps, the interviewee suggested that some kind of a simplification of the processes would make it easier for also the employees to ensure that their work complies with the requirements of the processes and that all documenta-tion that should be generated is up to date. This could be implemented for example by making a table of each process with the key activities and required documentation of each process step. As a result, anyone could easily check that all the requirements of the process are being fulfilled in their work. This would also advance the integration of

the QMS and product management system to the daily work in the company. This pro-posal is quite similar as the propro-posal introduced for the software development process for creating checklists for different requirements, but in this case, the idea was to create general-level tables for the processes, while in the other proposal it was suggested that the checklists would be specific for each project and created based on the project plan.

Of course, these general level process tables could also be used to help creating the checklists, for example in determining what documentation requirements should be in-cluded in the checklist.