PQFORCE is used daily by many users in diverse customer environments and at numerous locations. PQFORCE is used to plan projects, search for and allocate resources, manage absences and much more. Each user has different functions and data views in their role. So it is only logical that ideas regularly arise on how to make the application even better, even faster, even more user-friendly. How should we as a supplier deal with this?

At INTRASOFT, we maintain a very direct line to the customer. For us, customers are not simply abstract, paying entities, but a multitude of individual users with individual needs. Especially in the current phase of market development, we take such customer needs very seriously. But what does that mean in concrete terms?

Let's simply take a look at our development process. Basically, we develop PQFORCE as a standard product along a release path. There are no customer-specific branches (see also this article). New PQFORCE releases are developed every few weeks - depending on the scope - and made available to our customers. The development of a release takes place along the following phases.

Capturing requirements: In the beginning is the idea

New requirements almost always stem from user ideas. Our principle here is: Only those who use PQFORCE on a daily basis can really determine what is still missing or how even more could be taken out of the application. We take these ideas and wishes on board - typically within the framework of pilot projects with customers. This is the time period in which a select team of pilot users uses PQFORCE and tests the best possible application for the customer. We are present at such pilot projects on site, train and advise the users, listen attentively and thus pick up new ideas. Such ideas are then entered into a list. In there they are formulated as so-called business requirements as solution-neutral as possible in the form of use cases.

Consolidation & prioritization: Broadly applicable solutions for all customers

In this phase, the large pot of new requirements is carefully examined. Individual requirements are formulated as solution-neutrally as possible, and in some cases also grouped and consolidated. Then, from the large list, a package is put together with those requirements that will be implemented together in a new release. Concrete implementation proposals are also worked out. These can be screen designs, for example, which represent a GUI to be revised. Such implementation concepts are developed with a high degree of flexibility and sustainability in mind and, if necessary, also submitted to the customer (idea provider) for review. The goal here is always not to create a precise solution for one idea provider, but rather a solution that brings added value to all customers, is "suitable for the masses" and flows into the standard.

The list of business requirements and the package of requirements to be implemented are comparable to the product backlog or sprint backlog from the agile development methodology Scrum. In contrast to Scrum, however, the product owner does not decide alone, but always in communication with the relevant customers. We regard our customer base as an extended circle of product owners, so to speak. In order to satisfy the different and sometimes contradictory demands of the customers regarding urgency, a lot of tact and good communication is necessary on our part, and on the part of the customers it also requires a willingness to compromise and understanding. The latter can always be found, however, because our customers receive new features as part of the normal subscription fee for the standard product and do not pay extra for them.

Development & Testing: The concrete implementation is timed

This is a purely internal phase in the development process, i.e. without customer involvement. The new release is now effectively implemented by the development team. This is where the further development of PQFORCE takes place in the narrower sense. A concrete schedule with three key dates is defined for this:

• Provision for internal testing(Release Candidate)
• Provision of the stable release for marketing and sales(Release for Marketing)
• Provision of the stable release for productive customer use(Release for Production)

These three deployments typically take place on a weekly basis. This high rhythm is possible because we strive to define regular and rather smaller releases. This way, our customers benefit from a continuous development with manageable innovations. In this way, we can continuously adapt PQFORCE to new requirements and keep our finger on the pulse of time.

Release Build & Deployment: The delivery takes place promptly

The release for production is finally generated in a final build process and rolled out to the various production servers. Shared cloud customers are automatically provided with the release on the previously announced date. Customers with dedicated servers or on-premise subscriptions will receive the release at their preferred time. The corresponding release notes are communicated to all customers in good time.

The delivery closes the circle from the original user idea to the final implemented feature within a few weeks!