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
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.
