“A hunter that is worth his salt does not catch game because he sets his traps, or because he knows the hunting routines of his prey, but because he himself has no routines. This is his advantage. He is not at all like the animals he is after, fixed by heavy routines and predictable quirks; he is free, fluid, unpredictable.”
Carlos Castaneda

Journey to Ixtlan

Process vs. Project


I feel its important to recognize the gross and subtle differences between engaging a project and creating a process within a business operation. Often times the choice is made based on prejudice and/or existing circumstances which dictate a default choice. Maybe we need to give this some thought?

In my mind a project is a relatively (when compared to a process) short lived entity – largely due to the fact that it generates a perception that it will end with clear results. I feel that these two qualities are the reason “Projects” are rather popular. The fact that a project has an end gives a sense of control, and the promised results hint at a certain carelessness about what goes on during the project – because in the end we will have the desired results (does the phrase “I don’t care how you do it – just get it done” ring a bell?). Whether or not this approach is healthy in its own right – warrants a wider discussion (though my experience is that the “project” concept is generally unhealthy and debilitating for organizations).

The concept of process is, in my mind, a much wider perspective and leaves much open (which is maybe why it can also be experienced as intimidating). I feel that the two most prominent qualities of a process are that it is on-going (open-ended in time) and therefor probably also an evolving entity. It seems to leave space (and time) for the path itself and not only the results. It hints at a higher level of commitment and at higher costs (in time, energy, money, etc.) – something that requires more consideration.

I realize that in reality – most activities contain a mix of qualities from both projects and processes. Reality tends to gravitate toward getting things done (and that is a blessing) – a project can have a quality of process and vice-versa. The choice between the two reflects a perception about the workings of the world rather then an approach to work. Therefor, I feel that the choice of project or process orientation can tell us something about state-of-mind – both on a personal and organizational level.

Knowhow vs. Results

The holy grail of a project is usually the results – preferably ones that are measurable, quantifiable and politically correct. They are comfortable because they transport responsibility to some-one else. Much can be invested in choosing the right “someone-else” but in the end the responsibility will be passed on. That “someone-else” will in the end be required to deliver the expected (agreed?) results.

Alternatively a process, though it may seem to have much in common with a project, will require at least one more layer. This layer will deal with the question of how to go about doing the work? The answer can be as simple as reassigning an employee or as complex as introducing a new discipline (along with everything that entails: skills, people, methods, mentors, etc.) into the organization. This activity is very different from the project – since it requires choices that directly reflect the organization’s culture. The new “process” can inherit the organization’s culture and it can challenge it to evolve.

A process leads an organization through a process of learning while a project bypasses it.

Rigidity vs. Adaptability

The nature of expectations from a project tend to make it a rigid construct. It is usually founded on agreements (whether inside the organization or with external partners) in which two (or more) parties define their expectations (usually for results – payment against delivery). Mutual agreement is reached when one set of expectations is aligned with another. This alignment is often (especially with large projects) a challenging prospect. Once it is reached – there is little motivation on either side to change it. Change is usually requested when one or more parties realize they will not be able to deliver the expected results (and you can guess what motivation the other party will have to accomodate that).

A process, on the other hand, is by it’s nature a learning mechanism, it takes time to develop expectations. Time is required for the organization to master the process and become adept at it. During this time the organization learns what (and how and when) can be expected from the process so that progress is gradual and changing. As the mastery of the process matures so are the expectations from it – a kind of organic growth (first you learn to walk then you try to run). This organic process fosters adaptability – expectations are aligned with (and even derived) from what can be reasonably achieved.

From Project to Process

Projects have a bad reputation – the odds of success are usually not good. What often happens when projects start to waver is that there are invisible forces that try to transform the project into a process. The odds of a successful transformation are not good UNLESS the transformation itself is acknowledge as a process.

For example: if you (Company A) initiate an outsourcing software development project (with Company B) in which the requirements change (this has been known to happen with software products) and you realize that this is going to take longer (and more money) then was planned – what to do? What may possibly be required is that the partnership with Company B be completely reassessed. The partnership may be extended over a longer period of time, with different budget/payment mechanisms and flexibility to accommodate change in requirements. Is this beginning to sound more like a process then a project? Company A will need to acknowledge the internal organization needs of Company B, Company B will need to understand the customer-facing requirements of Company A, both will need, out of a mutual respect and understanding, to formulate a longer partnership, with information exchange mechanisms, expectation matching tools, dynamic scheduling & budgeting, etc.

Given the past record of projects – it is highly likely that many projects eventually face the need to make the shift to process. For this shift to succeed a process awareness is required from all parties – this is a foundational shift – it will usually take time (more then anybody is willing to give it – but no use fighting it, it will take its time), it will require mastery to achieve (outside consultants can be of help), it can rock some foundations and will often reshape people and organizations – it should not be taken lightly.

This entry was posted in Business, outside. You are welcome to read 1 comment and to add yours
  • Outside

  • Subscribe via Email