Projects are multi-dimensional. These dimensions push and pull on each other till the eventually, the project gets done. The trade-offs between features, schedule and budget are always present. Being aggressive on one or two leads to compensation by the third. Being aggressive on all three is unrealistic since all projects have constraints (e.g. there is not an infinite bucket of money). There is an optimum mix. Your job is to find it.
Features
Marketing plops on your desk their requirements document. It is chalked full of must have features — all of which are required for success. Wrong. There is always a minimum set of features that are must haves. Chances are, the initial list is a wish list not a must have list. Make your life easier. Push back on features. Don’t be a Dick about it. Just get justification for each one in a calm, rational way. This will pay huge dividends once your project starts.
Schedule
Schedules are a funny thing. On the one hand, you need them because without a deadline, nothing gets done. On the other hand, setting them boarders on a random number generator. The first step to schedule rationality is to figure out when it really needs to be done. Not when marketing or management wants it done but when it really needs to be done. Nine out of ten times, those two dates will be different. You really can’t blame management for wanting the new gizmo ASAP. After all, the sooner it’s done, the sooner you can sell it. Right? Well, maybe. Outside constraints may effect your ability to roll out a product. Understanding those constraints will set the real end date. Make sure all those assumptions are contained in your schedule. Theoretically, schedules are set in concrete once features and budget have been settled. In reality, schedules fluctuate as needed to compensate features and the budget.
Budget
Budget’s are just evil. Trying to figure out the exact cost of your project is a lesson in futility. This does not mean you just blow this off as unmanageable. Quite the opposite. Knowing where the money goes is vital to the inevitable question “Can you pull the schedule in with more resources?” or “How much would it cost for this feature?” Being budget savoy does not mean you take CPA classes at night. Rather, you need to understand what your budget is buying you. The ability to trade this off with features and schedule gives you the best shot at meeting expectations. All projects, no matter how vital to the company, have budget constraints. So, don’t just spend money like it’s water. Apply restraint even when given more resources. Sometimes, adding additional resources will end up slipping your schedule initially. Realize that you need to know what additional resources will buy you.
Trade-offs
Lets say you are working on a brand new gadget that will change the world (all such gadgets do initially). The schedule is aggressive because management wants it out quick due to competitors. You have a fixed number of staff. Management has now constrained your solution space to what features can be completed given the time and resources you have. Remember, your team can only work so hard. Aggressively scheduling them with insane work hours will just burn them out and create a poor product. In this case, the best course of action is to prioritize each feature as critical for the initial release and what can wait for rev 2.0 (or 1.1 or whatever). Getting the initial feature set correct takes real effort not just from development but also from marketing. Marketing will always want more features in less time. Your job is to say no. Each feature must be justified given the constraints you are under.
Another way to look at this is on the features side. Lets say there is a well defined feature list that cannot be compromised. You have the same resource constraints as before. What do you think will suffer? Since there is only so much a team can get done in a day, then the schedule will suffer. It just has to. Remember, the trinity needs to be conserved.
Way too often, you will be confronted with completely unrealistic features, schedules and budgets. In these situations, it is best to right hard to narrow down the features to a reasonable set. Doing this allows you to maximize the productivity of your team and sets the proper expectations. Don’t be tempted to just agree to unrealistic expectations once beaten down by management. It does no one any good. In the end, the project takes what it takes, given the features and budget available.
Management will always try and push you to do things better, faster and cheaper. That is a good thing. The bad thing is to sacrifice the sanity of your team or product. Remember, all three dimensions of a project tend to conserve themselves. Being aggressive on one will compromise the others. You just can’t get around that.
Additional Resources
Great Article on Bits, Features and Truth over at Rands in Repose. It also nails the whole challenge with sorting out all this crazy innovation and product stuff with these lines:
“The best Gantt chart only tells you half the truth about the schedule; the most complete marketing requirements document can never describe why a feature is compelling; and the most detailed technical specification will never tell you what makes for beautiful code.”
