Setting objectives provides you a means of measuring the impact of certain decisions in a project. A key aspect of a SMART objective is establishing a target for the objective: what should the measure be in order to call your efforts successful?. To establish that target you have to make a specific number of assumptions. These assumptions represent the uncertainty you face at the beginning of the project. It’s very helpful to note what these assumptions are, so that you can then go about validating those assumptions and revise your expectation of the final value of the objective. It’s best to keep track of those assumptions in such a way that you can identify what effect a change in some assumed value has on the target. You then deliver features in a way that validate assumptions and then put you in the position to realize those assumptions.
This approach is called a business value model, and is described by Chris Matts and Andy Pols. You’ll notice this article is from 2004. If it’s such good advice, why isn’t everyone doing it? I think it’s because people knew that they should establish objectives that are SMART, and that they should note their assumptions, but don’t really know how the two go together. Of course living in a glass house, I shouldn’t throw too many stones. We didn’t do this with the submission system itself. We do, however, take this approach with the broader conference, which the effort to build the submission system is a part.
As we plan the Agile Conference overall we build the budget for the conference in a rather intricate spreadsheet that is setup to allow the planning team to tweak several different values and gauge fairly quickly the impact of a change in the environment on the overall financial health of the conference. This is what Matts and Pols were thinking of when they talk about the business-value model. Don’t just say, “The conference will bring in $50,000 (I made that number up)." Say, "The conference will bring in $50,000 based on these assumptions." After this, setup a model, as simple as possible but no simpler, that allows you to change the values of those inputs to see the impact on revenues.
We were lucky with the submission system. While we didn’t explicitly identify business goals and objectives, we inherently knew the relevant decision filters that allowed us to build a useful system. Not all teams are as lucky, although many test fate and do not establish goals and objectives. Or when they do, they do not create a business value model that allows them to reevaluate the value provided by the project on a regular basis.
Establishing business goals provides you decision filters for selecting what aspects you work on. Does a feature help you get closer to a particular business goal? In this case, do it before others. Identifying objectives and the assumptions underlying them provides you an objective way to measure whether the result of your project will actually get you closer to what your are trying to accomplish as well the impact your various assumptions have on reaching that objective.
I’ll admit, not all projects require business goals, objectives, and business value models. The larger the investment in a project, the more that is at stake, the more helpful establishing goals and objectives and building the business value model can be.