A Process should be Reuse of Best Practices

In many engineering companies the processes are being considered as too much paperwork or even project cost overhead. The engineering processes should be an expert guide for the engineering projects. Reflecting the past projects' experience into the processes may be a good idea.

Did you ever hear a team saying: "If we have to follow the processes we have to add extra effort to our project estimation."? Instead processes should prevent expensive mistakes and thereby help the teams in getting more efficient. Therefore processes should navigate the teams through a project, instead of hindering them from doing their job.

Formally "a process is a set of recurrent or periodic activities that interact to produce a result" (see >Wikipedia<). For a production line the process can clearly predict what should happen when, and it is easy to measure and optimize those processes. Project processes need to be different to production processes, because every project is different, while every produced product of the line is hopefully exactly the same. Don't take team members for fools. Instead support them in becoming top performers.

Therefore development processes of projects (e.g. for creating systems of software, hardware, mechanics) should reflect the experience of previous similar projects, ideally by reusing their best practices. Today almost no project has to start from scratch, because nothing is completely new. If it really is, we look at disruptive innovations and research, which still reuse proven basic principles.

Therefore we should collect new best practices from successful projects, generalize them to base practices, arrange them within the existing processes, and thereby offer them to new projects. The teams then can >decide to select< what really helps them. This makes organizational learning from personal learning and vice versa. This also establishes a systematic continuous process improvement.

When the "best practices" from the successful projects are generalized to become "base practices", then usually the abstraction level rises and the real doing gets lost. That is why we often say that processes rather describe "what" should be done, while methods, guidelines or how-tos describe "how" it should be done. Thinking in these levels can help to keep the processes handy, without loosing the real expert practice, that also might differ from product to product (remember: each project still is somehow unique).