Thoughts on process improvements and process defining mechanism

Working inside an ISO 9001:2000 certified organization sharpens your awareness of one uncomfortable truth: a process documented in a binder and a process actually lived by a team are rarely the same thing. The certification describes the former. The latter is what determines whether software ships.

The distinction worth drawing first is between a process and a practice. A process describes methodology—the steps, the gates, the artefacts. A practice is what people actually do on a Tuesday afternoon when there is a deadline and ambiguity. Most process improvement initiatives focus on the documentation and leave the practice untouched.

Software development, broadly, moves through recognizable phases: requirements, design, coding, testing, release, maintenance. Every team knows this. The question is never whether you have these phases; it is whether the process you have defined makes moving through them easier or harder.

Three qualities separate processes that teams adopt from processes that teams tolerate.

The first is natural integration. A good process does not feel imposed from outside the work. It fits the way the project actually flows. When people have to context-switch into “process mode”—filling out forms, attending status rituals that produce no decisions—the process has become a parallel activity rather than a support structure. The test is simple: does following the process help you do the work, or does it interrupt it?

The second is self-adaptivity. Software development is fundamentally empirical. You cannot fully understand a problem before you start solving it. A process that assumes complete upfront knowledge is brittle by design. Useful processes are self-corrective—they include mechanisms for examining what happened, updating assumptions, and adjusting behavior. Agile methods formalized this instinct, but the underlying idea predates any methodology.

The third is enhanced communication. Process should clarify who knows what, who decides what, and who needs to be informed about what. It should make roles legible and responsibilities concrete without turning coordination into bureaucracy. When a process improves the signal-to-noise ratio in a team’s communication, people follow it voluntarily.

The failure mode is common enough to name: organizations treat process definition as a compliance exercise, optimize for auditors rather than practitioners, and end up with documentation that describes an idealized team that does not exist. The real team develops informal workarounds, and the gap between the written process and the lived one widens.

The alternative is to treat process as a hypothesis—something you design, deploy, observe, and revise. That orientation keeps processes honest.