Monthly Goals

Software teams should use a monthly goal system. On the 1st of each month, the team delivers the result from the previous month's work and immediately decides what to do for the next month. The managers consult the team to find what they prefer, consider the long-term goals of the group, and weigh in a variety of intangible factors like what's most exciting. The outcome is the monthly goal, a one-sentence theme for the next month's work. This is then published to the workers and to interested parties within the company, and work begins.

Why Does it Work?

This system works on several levels. First, it provides focus to the group. Because the goal is so simple, everyone on the team knows all the time how his/her work fits into the big picture. A good goal can be visualized, so everyone can imagine how their part will fit into the whole. When the work is done, the worker can point to the result being distributed and say, "I did that". To some degree, the worker means the whole result, not just his/her part. This feeling of personal ownership of the group's result is an important motivator.

Second, the monthly goal gets the group in the habit of meeting schedules. Individuals learn that there really is such a thing as a hard schedule date, and that if they promise a feature by that date they must deliver or they miss out on being part of the result. This teaches many valuable skills to the team members, like planning for mistake-correction time.

Third, monthly goals give a tangible and measurable result. The common practice of making goals is to say "we are 6% done with each of 20 tasks, therefore we are 6% done overall" is ineffective. The problem is that it's impossible to judge what 6% done really means. Or 10%, and particularly 90%. It's a cliche that when someone says a subtask is 90% done, usually that really means 50%. The only numbers that really mean anything are 0% and 100%, everything else is too hard to measure.

So our method is to instead say "we have 100% completed 3 of the 20 tasks". This is measurable, it's relatively easy to determine that those 3 features are indeed completely done. The end result can clearly demonstate the completeness of the features that were implemented, and management can see that they really are done.

Fourth, the method of picking the monthly goal right after finishing the previous one gives the team lots of flexibility. Projects that plan too rigidly for the future can't adjust to the actualities of changing corporate direction that exist in high-tech companies. The managers may have thought about possible monthly goals, but one isn't chosen until the last possible moment. This means that the team can change direction within 4 weeks without any loss of efficiency. The longer-term plan has to remain loose and somewhat unpredictable anyway, because no one can really predict accurately as much as 3 months ahead on a high-tech development schedule. There are just too many unknowns and plan changes. The monthly goal system works within that reality.

How Does One Do It?

There are several key aspects of the monthly goal method that we've fine-tuned over time to give the most benefits. The reasons were outlined above, here's the recipe:

Choosing the goal

What's a good goal

Distributing the goal

Doing the work


A. Cockburn, "Unraveling incremental development," Object Magazine, pp. 49-51, Jan 1995. 49-51. A pithy description of the advantages of incremental development.

G. Head, "Six-Sigma Software Using Cleanroom Software Engineering Techniques," HP Journal, Vol 45 No 3, June 1994. Has a small section on short-interval scheduling.

Substantive changes:
    March 2, 1996: created.
Copyright © 1996, Steve Colwell, All Rights Reserved
Home page