Kent McDonald writes that identifying objectives and the assumptions underlying them provides you a way to measure whether the result of your project will actually get you closer to what you are trying to accomplish, as well as the impact your various assumptions have on reaching that objective.
We all have things that we know we should do that we don’t. For me personally, two of the biggest are to exercise regularly and eat lots of fruits and vegetables. I know these things are good for me. I know that I would feel better and potentially live longer if I do; yet I don’t. I run into this same situation when working on software development efforts. Most recently when working the Agile Alliance Conference Submission System I did not explicitly identify the business goals we were trying to meet and the objectives we were using to measure progress toward those goals. In other words, as a team we did not explicitly discuss what value the system was supposed to deliver.
Business goals express why we’re taking some action; what we’re trying to accomplish when we are done. In this sense, they provide some very helpful information for making decisions. When we started the effort to replace the existing submission system in the fall of 2012, we did not explicitly state any goals other than to replace the existing submission system with a new one, a common occurrence in system-replacement situations. The trouble is this type of goal does not provide a lot of useful information. From this we didn’t know what need the system was trying to satisfy, so we didn’t have any guidance into what the new system should or should not do, other than assuming that we wanted the new system to do everything the old system did, which is not necessarily the best course of action.
Reflecting back on it now, the submission system supports the business goal of creating a program for the agile conference that is for the agile community and by the agile community. I had this business goal inherently in mind in the fall of 2012 when I started working on the effort to rebuild the submission system. I never explicitly communicated this goal to Brandon and Darrin, the other two working on the submission system, but because Brandon had been involved with submission selection before, he inherently understood why we needed it.
As a result of this implied understanding, we worked with some decision filters, although we never explicitly wrote them down. We knew that, overall, the submission system had to support the session-selection process and that we needed to have the ability to accept session proposals and allow people to review them by the beginning of December 2012 for the Agile2013 conference.
We also had the previous submission system to reflect on and to act as guidance for possible functionality. This turned out to be a blessing and a curse. It was a blessing because it provided us with a good basic understanding of what we needed the system to do, but we also had to make some decisions about features that didn’t carryover to the new system. We used the decision filters to disregard, or at least delay, features that did not directly meet the decision filters.
Most project teams aren’t that lucky. They usually have more than three people, and they usually aren’t all aligned with what they are supposed to be doing. The act of explicitly discussing and, most importantly, agreeing to the business goals and the corresponding decision filters is essential to a successful project. Without that shared understanding, team members make decisions based on their perception of the business goal which may or may not accurately represent what the actual business goal is.
For example, I once worked with a team doing a commission system replacement. I asked the members of the team to individually describe why they were doing the project and got eleven difference answers ranging from improving the maintainability of the commission system to completely overhauling the commission process. Needless to say, before we identified this difference in perception, the team members were making decisions that took the project in several different directions.
Another thing we didn’t do with the submission system is establish objectives. In effect, this meant that we had no way to measure how well we met the business goals that we didn’t define either. I could say that we discussed the matter in depth and determined that objectives were not necessary for this particular project, but I’d be lying. We just didn’t do it.
Had we actually established objectives, they could be to:
1) Gather a sufficient number of session proposals, let’s say enough to have an acceptance rate of 20 percent, which is roughly 1050. (We ended up having 1110) and
2) Have a specific number of reviews per submitted session, let’s say three, which resulted in a total of 3330 reviews (We ended up with 2,911).
The system itself is not completely responsible for meeting those objectives. The number of sessions is heavily dependent upon who chooses to submit, and in fact some of our policies work against getting a specific number of submissions. (Each person can only submit four sessions). From the review standpoint, getting a number of reviews is heavily dependent on the effort of nearly 100 volunteers who have to read through session proposals and provide feedback. This is the case with many projects. The IT portion of the project, or the project itself, does not entirely dictate whether a goal is met, but can influence progress toward it.
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.
