Every project needs well-defined business objectives (see here for the ArgonDigital approach to this) in order to be successful. They are likely the most valuable statements about your project and will make or break your project’s success. The project’s scope flows directly from your objectives. 

If you get your objectives wrong, you get your scope wrong. If you get your scope wrong, you won’t achieve your success metrics. If you don’t achieve your success metrics, you’ll be fired. And we certainly don’t want that to happen.

Business objectives can be deceptively dangerous things, especially if you have too many of them. They can trap you without realizing it: a seemingly innocent-sounding goal may actually lead to counter-productive behavior. If that’s the case, even if your project achieves its business objectives, it may result in the failure of the company as a whole. If a retailer sets a goal of increasing the number of their stores throughout the world to increase their revenue, if they fail to accurately factor in the overhead, the cost of those stores could bankrupt the company.

These company-wide objectives filter down into the business objectives of your software projects.  You must be careful to make sure that you don’t create conflicting objectives. Often, success in one business objective causes failure in another. Increasing revenue is a great objective in many cases, but if you disproportionately increase costs, your project will actually hurt your organization rather than help.

The temptation is to then increase the number of objectives: revenue objectives, cost objectives, profit objectives, and resource objectives. That way you can thread the needle, saying exactly how you want to increase revenues, exactly how you want to reduce costs, and exactly how you want the project to impact profits. However, this approach often backfires. The more objectives you have, the fewer degrees of freedom remain for the system and the users of the system.

This may lead to many can’t-win situations for the system developers and users. If they choose one path, it will accomplish many of the business objectives but violate others. If they choose another path, it will maximize one business objective at the expense of the others. In situations like this, whatever the person does will be considered wrong by someone, and any action, even the best action for the situation, will often draw ridicule, mocking by young children, and severe punishment. Nobody likes being put in no-win situations. And if enough of these arise, people will give up on trying to do the right thing, and just choose the path of least resistance.

A simple example of business objectives gone awry would be for a hypothetical travel booking system:

Business objective #1: Achieve 100% of travel booking through new system.  
Business objective #2: Lower travel costs.

It is easy to see how these objectives could conflict. In order for the objectives to be met, the booking system would have to find the lowest travel costs 100% of the time. If there is ever a situation where the user could find a lower travel cost elsewhere (and there obviously will be), the objectives create a no-win situation. The more objectives and constraints on objectives that you have, the more likely it is for unanticipated situations like this to occur.

As the book the goal The Goal by Dr. Eliyahu M. Goldratt states, the overall objective of every project is exactly the same: to increase long-term profits. That is always the underlying goal of everything that a company does.

Your project is no different.  

Start by thinking of how your project will increase long term profits, and pull your objectives from that. Leave in as many degrees of freedom for human thought and creativity as possible. All your fellow employees are not stupid (or if they are, maybe you should consider changing employers). Don’t straitjacket people from thinking creatively. The system, and your business objectives for the system, should not dictate precisely how the system should be used. Set forth the basic objectives and let the users figure out how to best achieve them, using your system as an additional tool in their arsenal for increasing long-term profits.

Simple rules and fewer rules are generally more effective in achieving an organization’s objectives. Let your business objectives set the ground rules and let the ingenuity of your developers and users do the rest.

As practitioners, it’s easy to feel that we know better than anyone else how to achieve the organization’s goals, and thus over-specify our objectives so that the ignorant masses don’t screw it up. When creating business objectives, it is important to first have humility, and to realize that this project will not have all the answers to the organization’s problems for all eternity. So the best strategy is to design your objectives, and your system, in a way that will maximize flexibility for solving problems that nobody can even imagine yet.