Process and Principle

In almost all software project effort, there will be talks on process, RUP, XP and others. The reality is no single project strictly follows any defined process. When projects fail, not following a standard process is usually cited as one of the reasons. On the other hand, if projects success, there may be a sense of failure in those process people. We often see project managers conflict with technical teams on if a project life cycle phase should be carried out according to a predefined process, or on whether or not a particular operation is compliant with a predefined process.

Those are all unfortunate situations.

General business world has seen the processes become problems again and again. Once successful enterprises are lost in processes. When business conditions change, they start to struggle with out-dated processes and forget the fundamental purposes for a business’ existence and operation. What underlies the Theory of Constraints as described in The Goal is really the following observation: once successful processes start to do harm to the essence of business.

This process-oriented style of management thinking can also explain why people from large enterprises usually destroy instead of help promising startups. Those people often implement what they learn from the operation of large enterprises and try to set up all kinds of processes. Processes are the only things of substance. What they fail to realize is that a process works only in its context. If the conditions are not ready, the process has to be reexamined. However, typical of entrepreneur environments is that even the conditions are only at the emerging stage and just to become stable. In such situations, processes may just mean obstacles, and ad hoc is probably the best.

The solution from great business leaders to this process problem is: lead by principles. This should also guide software project teams.