Confessions of a researchaholic

Managing project is a huge topic that involves multiple aspects. This post focuses on one specific aspect, on how to manage and ensure progress. To me this is the most important aspect, because a project that is not done is worth nothing.

My strategy is very simple: use schedules to manage progress.

\paragraph{What}
Here is a quick example.

First milestone demo: October 17, 2012.
(A milestone is a demo that can show the project (1) is of SIGGRAPH potential and (2) is likely to be completed.)

Demo production (assuming we have 3, each with complete and concrete descriptions):
. Demo 1: November 1, 2012.
. Demo 2: November 16, 2012.
. Demo 3: December 1, 2012.

First complete paper draft: December 17, 2012.
(SIGGRAPH is not just about getting things done; it is a refinement progress towards perfection. My hope is to have a one month margin, even though few of my projects, mostly first authored by myself, have made this.)

SIGGRAPH 2013 deadline: January 17, 2013.
(Hard deadline; everything has to be done before this.)

\paragraph{How}
The schedule should be drafted, usually by the first author student, in the beginning of the project, and constantly updated and maintained throughout the project progress. All team members will look at the schedule and agree with its content.

The most important part is to make sure you actually meet your schedule. Do not let anything slip. Otherwise, it will not work.

Of course, research, or any project, can and will bump into unexpected snags. It is also not possible to accurately predict the amount of time needed for every item. The key is to keep the schedule as accurate as possible. For example, if you originally think demo 2 above will take only 2 weeks but it ends up taking 3 weeks, you should question whether you are too optimistic about your schedule and allocate more time for other items.
(If you find yourself not being able to meet the deadline, it means you probably have to speed things up by either working harder or working more efficiently. But the good thing is that you realize this early rather than late.)
As you become more experienced, you will also become more accurate in managing and predicting schedules. Without this practice, you will less likely learn this very important life skill.

I guess it probably very hard to fully comprehend what I mean here. If you are my student, you will learn this through a lot of practice with me.

\paragraph{Background}
I learned this through my NVIDIA days. One thing I find particularly proud about NVIDIA is that to my memory *not a single product* has ever been delayed during my stay. This was in sharp contrast to ATI, the (then) fierce competitor to NVIDIA, which (for reasons I do not know) constantly bumped into product delays. The rest is history.

The way the NVIDIANS did it is like this. Everybody and their brothers used schedules to manage progress, and slipping a milestone is considered a more serious crime than shooting someone. The CEO dropped in group meetings constantly and unannounced, and called out those responsible for delays. (Trust me, you will prefer being shot rather than getting called out.)

I like to list one most important thing I learned with every one of my jobs. And for NVIDIA, it will be project management. I do not think I will have learned this if I started as a professor immediately after school.