Saturday, April 30, 2005

The Project Triangle of Death


This is the first one in a series of posts on principles of IT project management from the customer perspective. The idea is to make my painful experiences public so others could avoid them. Here we go, stay tuned for more.

The Triangle of Death, part one.

If you have ever participated in a software (or, in fact, almost any other) development project you have probably made acquaintance with the fearsome creature that gave this post a name.
The Triangle of Death or ToD consists of Resources, Time and Functionality. These parameters of a project are obviously tightly interconnected and interdependent although these relations are often neglected, especially by management. One could imagine this triangle as three poles with a length of rope tied around them. If you move one of them, the rope pulls the others along or allows for others to move. Let's define the vertexes in a bit more detail
  • Resources. By that we mean all kinds of resources available to the project. They include money, people, computers and so on and so forth. Basically everything that can be used to achieve the goal. By removing or adding resources the course of the project can be altered so either more functionality can be implemented (more people do more work) or the same amount of functionality can be implemented in a shorter amount of time (more people complete work faster). Bear in mind that these relations are not that strict. Often adding more people to a project makes things even worse and there are tasks that just take time (think of letting concrete harden)
  • Time. It's obvious, isn't it? Every project has deadlines and more often than not the extent they are followed is the main criterion for evaluating a project's success. If we give the team more time, they can get more work done. If the deadlines are cut, more resources are needed or the functionality is compromised. Again, these relations are flexible to some extent so giving a project a infinite amount of time does not guarantee they can build you a rocketship
  • Functionality. Ultimatively, no project is set up to burn a pile of money or give a group of people something to do. Well, that happens, but not that often :) Hence, a IT project must deliver a set of functionality at the end of the day. One should not think of the functionality in its narrow sense of summary of capabilities of a piece of software. Rather, every piece of output including documentation, changes in processes or even amount of customer satisfaction should be considered as functionality produced. If more functional burden is added to a project, either more time or more resources are needed to produce it and vice versa
Now knowing the components of the ToD it's time to ask "what's the point?". These relations are obvious enough (although often ignored) to be treated as common sense. It's true, of course. Worth to consider, however are some conclusion that can be drawn from these associations I'm trying to bring here.

The uncertainty principle
If one component of the ToD is uncertain, so are the others. The rule is not binary and a more correct wording would be "no components of the ToD can be more strict than the others". People perfectly capable of understanding that one can not go anywhere without knowing where to go in everyday life try to set strict deadlines and resources to projects with more than fuzzy functional requirements. The reason is, probably, that functionality is really difficult to describe throughly. Even estimating time and resources going to describing of the functionality requires specific skills and experiece. So you better make sure everybody inside the project and everybody counting on it have a good understanding of what is going to be produced. Otherwise bitter disappointment and/or heavy punishment will certainly follow.

Besides functionality that is extremely easy to get communicated in a fallacious manner, resources are also often misunderstood. The project manager, naturally, expects everybody to participate in the project full time and probably more. This is also calculated into the project schedule. People, however, have a myriad of other responsibilities and tasks to handle besides the project and have their direct boss giving them additional tasks in the worst case.

Here we go again

what is this about blogging that makes it so hot? Even me, who in the course of 10 years of more or less professional web building have not managed to create let alone update a personal web site, am blogging now.
Actually, it's my second attempt. The first one had three posts and was in my MSN Space. Kind of neglected that, after a while: too crublesom to log in to and no nice way to refere to it. MSN 7 is not yet widespread enough, anyway.
So, back to blogging. It seems that a surprisingly wide group of people has discovered a taste for writing. I don't think so may of us actually enjoyed writing essays at highschool but all of a suddeln there are blogs everywhere. Maybe it's just the ease of it? Or a strange flavour of exhibitionism? dunno, gotta be a psychologyst to figure that one.
The scale of blogs is rather surprising, too. They range from my own random thoughlets to comprehensive reviews of a specific matter as this really cool discussion of the XA protocol (found here) shows.
Which one is it gonna be for me? I could do some picture blogging (although I keep a up-to-date collection of my best pictures at the Home for Professional Amateurs). Also, there has probably been enough traumatizing project management and architectural experience in my life to produce some experience blogging. Or maybe start posting my Polar excercise files to start my own training blog? There is no way of knowing. It's probably gonna be a mix of those. So, if you happen to read this (beats me, how you got here, by the way) and can remember the URL, welcome back!