The bad news is that project management requires tradeoffs. Nobody particularly wants to admit to this, and people occasionally go through all kinds of contortions to avoid admitting this. But the fact of the matter is that the world we occupy is subject to real limitations.
The Triangle
In project management, a very helpful way of characterizing this is the “triangle”. Depending on which version you’re looking at, the 3 vertices of the triangle are:
- Good, Fast, Cheap;
- Quality, Timeline, Cost; or
- Product, Timeline, Cost
The basic idea is that, as a client, you get to hold onto up to 2 of the corners, but you have to give your development team at least 1 corner—preferably 2 (we can always dream, right?).
Some examples:
- You can decide that you have to have Features 1 – 37 and the project must be complete by December 1. But in that case, you have to let the development team have latitude with the cost. We might have to staff more people than is ideal, for example.
- You may decide that your budget is not a dollar more than X and the project still must be complete by December 1. In this case, the feature set needs to be negotiable / flexible.
What about the case where you want Features 1 – 300 at a cost of $249?
If your development team is “holding” the timeline corner of the triangle, the “solution” is that at that cost and feature set, you’ll have to wait until exactly what you want comes out as software you can buy off the shelf. And that, unfortunately, may be 5 (or 25) years from now.
“OK, what if I need it yesterday?”
Now, it should be said that timelines also cannot be arbitrarily short. Projects have an optimal staffing configuration. A 150 hour project for example, probably shouldn’t have more than 1 developer staffed on it. You could staff 10 developers on it, but it certainly won’t get done in 15 hours of calendar time. That’s because with every person you add to a team, the costs of communication go up exponentially.
If you remember your junior high math, the number of handshakes in a group of N people is:
N (N – 1) / 2
That is, each person shakes hands with every other person, but person A shaking hands with person B is the same as person B shaking hands with person A. Notice how there’s an N2 component here—thus the exponential increase.
It’s a simplification, but a formula like this also describes the number of possible lines of communication within a project team. The more staff on a project team, the greater the communication overhead. The optimal staffing configuration gives you a reasonable timeline without blowing up the costs as a result of this overhead.
You can keep adding staff to shorten timeline. But, at a particular point, a project can’t be made any shorter at all—attempting to shorten it by adding staff on instead results in lengthening the project because the effect of communication overhead overwhelms the benefit of one additional person’s productivity.
Hmmm. What’s the good news?
The good news is that one of the key things that we’ve learned about developing software is that constraints can be beneficial. When the constraints are too severe (timeline too tight, budget unreasonable, feature set out of proportion), you can put your team in a position where delivering is impossible and attempting to do so is therefore demoralizing.
However, reasonable constraints help to focus the team and focus your product. Rather than throwing the kitchen sink into a product, reasonable constraints focus you on high-priority functionality and are a guard against wasted effort:
- Which features will satisfy 90% of my audience?
- Which features can 90% of them live without?
Web development is a partnership. What you are looking for is not the firm that promises that you can hold all three corners of the triangle—you’ll find that instead of good, fast and cheap, you invariably end up with cheap, bad, and ugly. That’s not a long-term sustainable scenario for anyone.
Instead, look for the firm that will recognize the realities of Web development and partner with you to get you where you need to go.
