Evaluating Project Tradeoffs: Some Guidelines for Success

Anyone familiar with PMI principles knows the triple contraint of time, cost, and scope, and the fact that it can be used when negotiating tradeoffs. You're probably also familiar with additional tradeoffs, such as quality/grade, risk, customer satisfaction (if that's even a variable), etc.

When negotiations come to a grinding halt, we also have some other proven tools to keep in our back pocket, including:

• Fast Tracking (doing some tasks in parallel that would usually be done sequentially, which of course should be used carefully since it can add risk)
• Crashing (loosely defined as analyzing alternatives to compress the duration for the least amount of additional cost, but typically interpreted as adding resources or forcing overtime, which carries risk and adds more cost than people realize)
• Time-boxing (reducing functionality for the first release and moving it to a future release)
• Problem solving (i.e. considering other approaches to solve the root problem)

In my experience, the two methods that work best by far are time-boxing and problem solving, usually in that order, and often in combination. I also find that time tends to be the most frequently stated hard constraint, with scope and even cost somewhat more flexible (although the requester rarely admits that).

Usually, scope is the most flexible (some argue over semantics of scope vs. features/functions, vs. deliverables vs. sphere of implementation, but I tend to lump it all under "scope").

And of course, when it comes to overarching priorities, I always fall back to my own tried and true "two-sentence principle", which I stated a few weeks ago:

Speed is more important than cost. And success (in whatever form that takes) is more important than speed.

In countless IT projects, these guidelines have served me well. I'd be curious about others experiences when making tradeoffs, especially in other industries.