Using Goals, Objectives, and Assumptions to Model Value (or Not)


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.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.