There are two instances that you ' l l want to be concerned about trade-offs:
■ When you need to meet a deadline and you' re a little behind schedule
■ When you see an opportunity to make a slight change in operation that will result in an improvement in expected outcomes
It' s important to be able to recognize when you can propose trade-offs to stakeholders in order to help the project meet its proposed outcomes or possibly even exceed expected goals. Wouldn't it be great, for example, if during a project you realized that by simply performing a task a slightly different way, you could reduce the amount of time the task took, perhaps significantly, thus saving the project some time?
Understanding when to propose trade-offs means that you need to recognize the constraint driver for the project. You wouldn't likely, for example, propose a reduction in the time element of a task if time wasn 't the chief constraint of the project. Instead, you' d look for ways to trade-off something in the tasks that met the chief constraint. If quality is the chief constraint, perhaps you could make sure that developers double-checked their loops, F/THEN/ELSE, and CASE statements twice before compiling the module. This way you might save some time when a QA person revisits each line of code. Or, perhaps you could start each new module with a "tailgate" session in which developers talk about their intent with a module. If more people understand the intent of the developer toward creating the module, perhaps a glitch can be avoided.
Was this article helpful?