Why do something as a project?

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen

Why have such a thing as a project, especially with more-or-less the definition as given at page What is a project?

Natural phenomena

I think that projects are 'natural phenomena' within an organisation: Organisations usually have a structure with departments or specialties or whatever (e.g., marketing, HR, product development, finance, whatever) or not (e.g., within single-owned companies?) and that somehow, situations arise where specific results are needed. Maybe they typicially fit within such a department, but maybe not.

When to turn this into a project? When it needs dedication. If the thing that has to be obtained is simple enough, you don't need a project.

Entropy - Fight the chaos

The ultimate answer to the question of why to use project management, is like to so many questions in life: To overcome entropy:

Left to its own devices, our world tends to devolve into chaos, and entropy is a measure of chaos. This increase in entropy is not only the case for thermodynamics, but also for computer security, languages (isolated languages get more complicated, exposed languages get more chaotic), spirituality (it takes more effort to be nice than to be mean and more effort to get up early in the morning, rather than to sleep in) and even to the shirts that I left nicely ironed in their place, last year. And it definitely applies to obtaining complicated and sophisticated outcomes. I never cease to marvel about our world and that stuff so often just works, including the milions of transistors that somehow are involved in making this text appear on this wiki - Like one big conspiracy to defy entropy.

The law of increasing entropy describes that entropy always has to increase. However, this can locally be overcome by adding energy to a system (e.g.: A fridge can create a local cold spot, thereby locally defying the law of increasing entropy, but only if you plug it into the electricy outlet, to compensate for this). To me, this also answers the question whether something should be done as a project or just ad-hoc: When the needed energy is too much to muster ad-hoc.

This also explains why a project is finite in time: Because it takes energy. Just as I switch off the fridge when I go on holliday, it is equally advisable to not maintain a project when it isn't needed anymore.

Too much order?

Is it possible to add to much energy to a system, or maybe equally: To impose too much order?

Hell it is!

This wiki?

This wiki might be a testament to imposing too much order on something. I guess one of the challenges around project management is, to strike a balance between order and resources.

Having too many Trello boards?

There was a time that I had tens of Trello boards. Not coincidentially, this was around the time when I first discovered Trello. And it didn't work: It was too much of an effort to have an overview of all these boards.

Rational Rose

My favourite horror example of persuing too much order:

Around the beginning of this century, I got acquanted with Rational Unified Process (RUP), Unified Modeling Language (UML) and Rational Rose - A software development methodology and some associated mayhem.

I think RUP and associated tools and procedures are a terrible effort to defy entropy:

  • UML is so complex, that you first need a course to be able to understand and draw these diagrams. I was occasionally wandering what would happen in a meeting, if participants would discover that not everbody has the same proficiency in understanding UML. Wouldn't that make some people explode?
  • Participants spend an inhumane amount of time on documentating and 'procedures' than on actually doing the stuff for which they were probably hired, like programming
  • The methodology and control take more resources than the actual project.

And why is this? I think because of a mentality of play not to loose, or loosing control is not an option. Thank God I discovered agile software development methods soon after, where chaos is much more tolerated.


The fun of writing about entropy aside: A more practical answer to why to do something as a project: Because it needs dedication: Without a specific organisation and resources, it won't succeed to obtain the desired results within given boundary conditions.

It's quite similar to working according to a plan: To get from A to B as efficiently as possible.

Projects vs. tasks

When do something as just a task and when as a project? With task I mean just a relatively easy job that would be done by someone who is knowledgeable in that field. E.g., organising a beer party by the 'cantina department' or producing a simple sales overview by someone from the finance department.

For me, I think stuff becomes a project, when I need to take action (especially: Write down stuff) to keep having an overview.

From the examples at Project or not - Examples

  • Snowed-in: It all happened in about 20 hours and we (=my girlfriend and me) could manage it without having to write down stuff → Not a project
  • Cross-sales: This might be closer to a project than the snowed-in example: It requires specific actions from me in order to have an overview and to be able to effectively coordinate it.

When a project is not done as a project?

Just out of curiosity: How does it look like, when something that should be done as a project, isn't done that way?

Simple: It's less effective (including not being effective at all). This is similar to doing someting without planning, eventhough it should be done that way.

Examples of what less effective can mean:

  • It takes more time
  • It takes more resources (including enjoying the work)
  • The end result isn't optimal (E.g.: Feature creep)
  • The project doesn't get deliverd at all.

My favourite example of something that should be planned but isn't done that way: When would you rather service your car? At home, or during the holliday when it breaks down in the desert? - This is probably just as apt for project management.

See also