When introducing PQFORCE to our customers, we typically encounter the following situation: There is an organization with dozens or even hundreds of employees. All of these people have been working according to certain procedures for a long time. There are project managers who plan and control their projects according to methodology X or Y. There are many development engineers. There are many development engineers who do their daily work according to the tasks assigned to them. But there are also line managers who schedule their employees and make sure that they all have enough to do, but not too much.

All of these people have more or less ingrained daily routines. Some have a highly structured process by which they work; for others, each day looks a little different. But all of them would probably speak of a certain routine according to which they work.

The company culture determines the processes

This has to do with the predefined processes as they are (possibly) specified by the management. For example, workflow diagrams according to which the employees have to work. Depending on the work and field of activity, this is of course also necessary - that a rhythm is set and the various functions, i.e. people, work together optimally. Processes in a company also have a lot to do with the culture of an organization. And often the personality and habits of the people behind these processes also play a major role in what a typical daily routine looks like. Who takes breaks when, and with whom? Is someone more of a morning or evening person and comes to work earlier or later accordingly? Such aspects have a great influence on the culture of a company.

Man, the creature of habit

It is precisely such user habits that we often struggle with during system implementation. The tool discussions are crystallized by the habits of the users. "Why can't I move this task here right now?" "Why do I have to enter a planning effort first before I can allocate resources?" These or similar are the questions users ask when we introduce PQFORCE to customers. "Well," you might reply. "Why do you do it differently?" - "Because that's the way we do it." is the answer. And there you have it. It's just the way it's done, out of habit mostly. And not because a process of the company prescribes it in the same way. So it could certainly be done differently.

Such habits are sometimes so strong that companies specify very detailed test cases during system evaluation, which are then to be demonstrated as accurately as possible by the supplier with his system. These test cases exactly reflect the company's processes. This evaluation procedure is not to be condemned per se. It gives the system supplier an insight into the company culture. Nevertheless, in many cases it would be sufficient to ask for the essence, i.e. what the tool should be able to do, and not how it does it in detail. In this way, the system manufacturer can also bring his philosophy of use into play and bring the strengths of his solution to the fore.

Behind a (good) tool there is a philosophy

A powerful tool like PQFORCE now follows a concrete "philosophy of use". And hopefully this is no different for other software systems. When developing such an application, the manufacturer gives fundamental thought to what the system should be able to do (i.e. scope and range of functions) and how it should be operated (operating concept, see also this article). In the case of PQFORCE, we did not do this quietly, but in close cooperation with practitioners from Swiss industry over many years. This has resulted in an optimal solution that fits typical processes in industry. However, it is also clear that compromises have to be made when implementing a user philosophy. This is where configurability comes in, so that the details of the tool can be adapted to the needs of the user. So: tool or process?

When a company decides to implement a tool to increase efficiency, productivity, time-to-market, etc., the following question must inevitably be answered: Are we willing to adapt our processes to the tool or the philosophy of use, or not? Whoever says A must also say B. Whoever introduces a tool must also be willing to compromise. At least if the costs are to be kept low. Then it can only be a standard solution that comes with a predefined philosophy. If you are willing to spend a lot of money and take a lot of time, you can have a tailor-made solution developed. But these times are over in our fast-moving world.

PS: Here's a link to a LinkedIn post on the same topic.