I have been very happy with the topic of the latest two-thirds of a cast. I still have a little hope that the third part will answer part of my main remaining problem with goal setting, but.... it proves to be extremely difficult for me to set good goals for a development group.
Currently, our R&D goals are expressed as "finish such and so project by ...." or "stay within the budget" I am trying to get more diversity. Our company gets its inspiration from the Balanced Score Card. Every department should try to set goals on each of the four directions: finance, process, client and development.
The problem with setting goals for an R&D department is that each potential goal that we thought of is either too coarse grained, or it does not really express what we want.
An example: "we will submit patent drafts for at least 5 new ideas to our patent lawyers by December 31". I am sure there would be no problem getting 5 new patentable ideas. However, patenting would cost a lot of money, and there is no measurable quantity in the goal that will tell us whether these ideas will deliver value to the company.
Another example: "During 2008, we will finish >60% of all our current development projects on the currently planned time". But how do I convince people to abandon this goal if a company critical project comes in in March that has a much higher priority?
We thought of others. All of the examples we come up with suffer from the "you become what you target" syndrome. And because all the measures we have are indirect measures of success for the development (proxy's that are not reliable enough), or they are trailing our reality by a number of years (successful product introductions take that long to become profitable), they fail to get things moving into the right direction.
I have once seen a repository on the web that registers ideas for Balanced Score Card measurements. There are disappointingly few examples there for R&D. I even read the PhD thesis "Systematic design of R&D performance measurement systems" and gaining only the insight that larger companies also find it very difficult, but have found great value in designing their systems correctly.
Any and all help I could get from the many experts on these forums would be most appreciated.
MT goals for a research and development group
Truly no one can really help you with this except your team, because no one else is familiar enough with your work to set your goals for you. All the rest of us can do is repeat the principles:
* Don't get caught in analysis paralysis: get over the details and just come up with SOMETHING
* Not necessarily achievable
So, my suggestion is brainstorming. Get your team together in a room with an easel and pad of paper + markers and have people yell out ideas for things to set goals for.
Then tear it off and tape it to the wall.
Now use a fresh sheet, and write one of the items at the top and keep the creative inertia going and have everyone start yelling out ways to make the goal measurable. What could be measured?
Then brainstorm the way to base it on time.
Don't do this yourself. If you have directs, you have as big of a brain as all of your directs put together plus you. Reach out to them and have them contribute.
If you want to see buy-in to goals, you'll have never seen anything like people working to goals that they themselves came up with in a brainstorming sessions.
Take what you get from that session back to your desk and get it documented and published.
Things will change, so have another meeting at the end of Q1 to look at the goals and see if any are now obsolete.
Don't get hung up on perfection. Most managers never set ANY goals. If you get some crappy goals set in January and publish them out to your folks with some kind of measurements attached that are time-based in some shape or form, you're doing better than almost everyone else. Most goals really blow and have no time or measure to them... when they even exist.
You are not building a space shuttle. Actually, even if you were building the space shuttle, these goals do not have to fly a precision trajectory - the final product does. Do not mix up the two or assume your people are dumb and will make critical errors without exacting and perfect goals.
Goals just need to exist and serve as a pointer toward better performance.
Just another way to re-enforce communication
I am also struggling with setting G&O for a Software Development team.
G&O are a holy cow, so it is a little hard to criticize them (as I found out on the podcast page).
In my current position I think that G&O will start out re-enforce existing communications.
We have strategic goals defined anyway. We have project plans which implement our goals. When the team gets off track we get feedback. (We also get feedback when we stay on schedule.)
Of course there are "curve balls" which mess up the plan. So we fix the project plan to fit the new goals.
So we have predefined goals, measurement (metrics), and accountability even before we throw in the G&O process.
So what does it add? At the very least it adds communication! For this year I think G&O will be just another way to codify existing practice into another communication channel. And M&M are right when they instruct us to repeat communications on different channels so that the message sinks in.
Maybe in future years we will come up with additional metrics, but for this it will be, "Finish project X according to the schedule."
MT goals for a research and development group
Thanks for the reflections on this so far. We have now listened to the third part of the cast, which also sheds more light on the proxys and on "just doing it", do not attempt to be perfect.
One of the issues with proxys is that they do have to be useful in itself; and not damaging to anything else. We, like Steve, had had the suggestion of adding a goal "finish project X by October 2008". Of course, this goal is achievable. But it may mean that we drop all other projects. All our projects have priorities, so we know what we should work on at any moment in time. A "shadow priority" by setting a goal on a particular project is therefore potentially damaging.
We came up with one more interesting goal: we want to achieve >=80% productive hours by October (i.e. <=20% overhead, reporting, etc.).
I'm still open to suggestions.