I got this question from the SI617 – Choice Architecture course that is treating me as one of their case studies in what can go wrong in decision making. It is always great fun reading their papers at the end of the semester that talk of the kinds of mistakes I made in decision making and the sources of the errors in my judgement.

Here is her question:

I was wondering during the transition from Sakai 1.5 to 2.0, you stated that “we truly had time to start the Sakai 2.0 effort from scratch.” My question is that what enabled you to accurately estimate the available time for the transition? (Factors, how did you weigh, past experiences? What do you think it was the % of success?, etc)

Here is my answer:

Thanks for a great question that makes me think. I am not sure the context where I might have said “we truly had time to start the Sakai 2.0 effort from scratch.”. I was never sure that we would have time to get it done until we were actually done.

I don’t really keep too close track of time estimates of work. I think that is a waste of time except at a very high level. I look for a couple of things:

(a) Is something possible / feasible or not? If something is impossible then it cannot be done in an infinite amount of time. If something is possible – then often it can be done surprisingly quickly. Just get started and do it instead of wasting time estimating out how long it takes. If it needs to be done – just do it.

(b) Does something have to be done in one giant blob or is there a way to structure the effort so that each interim version of the product is functional. If you design software and manage projects so they are always “working” and all you are doing if you have more time is “make them work better”, then you always have a safety net if you run out of time.

My trick is that I change the requirements to meet what is doable. I meet as many requirements as I can until it is impossible to do so.

In September 2004, I had no idea if a rewrite was possible and had no idea how hard it would be. By November 2004, I knew the rewrite was feasible and that we would have something that met the basic requirements for Sakai 2.0 in about 2 months. During December 2004 and January 2005 we sprinted as fast as we could to see how the basic low-level parts would come together. By Feb 15, 2005 I was very confident that we would have enough in Sakai 2.0 so that we would not have to retreat. The only question between February 2005 and March 2005 was how much would we get re-written and how much of the Sakai 1.5 stuff would we just have to plug in to the new framework. By the end of March and during April, we quit building new stuff and started plugging the old stuff into the new stuff (we still call this legacy code). We code-froze the old+new combination early May 2005 and delivered it mid-June 2005. I used up every minute and every resource I could to deliver as much as we could without taking too much risk.

I don’t try to plan or predict too much. I design plans to be flexible and adapt as time passes. I also try to get slightly ahead in timelines so we avoid dropping quality to meet a deadline. I always want to drop or delay requirements to comfortably meet deadlines and keep quality high. I also get really defensive when the project is a little ahead of schedule and some management-type tells me to expand scope. Expanding scope when things need to be winding down is a tremendous risk. I usually shout at those people.

This often puts me at odds with traditional management-driven project management styles that cram as much in until the last minute, regardless of quality and then hope that you catch all the mistakes in QA. QA is not magical. QA timelines are set based on an assumption that the software being passed to QA is reasonably high quality. If management forces lousy code in up to the last minute to make themselves look good on paper, they give QA an impossible task. And make it so that it is not possible to deliver quality on time.

When people are depending on a project to deliver a quality product on time, my first goal is always to reduce risk and my second goal is increasing feature set.