Feb
2011
Incompleteness of Technology Projects
I am sure that everyone is talking about the unusual snowfall this winter, roof collapses, school closings and all that. Someone I know mentioned that he knew it was way too much snow when, after he cleared the snow in his roof, he stepped right into the mound of snow he had cleared. Picture that!
Luckily, technology is well advanced now that many of us are able to get a lot of work done from home during days such as today – no meetings. Unfortunately I had a couple of meetings that I could not skip today, so I drove to work. My attempts to take the car out from the parking spot failed this morning (2/2/2011) and needed a lot of help to simply get it back into the parking spot. I was able to get it out in the afternoon. Then, my attempts to try to steer the car up a steep driveway in the evening was not successful, so I parked right in the middle of the driveway. Even worse, trying to reverse the car didn’t work well – the car got stuck in a snow bank and needed a LOT more help to get it out. Should have stayed in the apartment and worked!
OK, enough of snow talk. I want to talk about how the successful technology projects are never complete. I refer to this as “Forever Beta” along the lines of the Google philosophy. The only “finished” technologies are the ones that are badly designed and rarely used so they die a slow death. And MIT Libraries have a “Beta Graveyard” to collected those that died.
Technology project requests come in many ways, both organized and unorganized. In case of software projects, those who are actually writing the systems would like as complete a description of the project as possible up front. The requestors, in many instances try to oblige, but, except in a few cases, it is hard. So, what happens is the so called “scope creep”.
Part of the project gets completed and is reviewed by the requestor. At this point, a couple of different things can happen. Depending on the level of enthusiasm of the programmer, s/he offers other options to make the product better; or the requestor sees many possible ways to enhance the product that s/he never thought of before. Either way, this results in more work and an extension of timeline. And no one likes to extend the timeline!
Generally (please note that this is a gross generalization!), the so called 80-20 rule applies here too. There is an exponential decrease in interest when the project crosses a particular threshold (dependent on many personality dependent factors). Everyone wants to see the product they have been working out the door! But, it gets stuck because the expectations of requestor and the developers don’t match.
This is why I favor the incremental approach which is based on the fact that no successful technology solution is ever complete. Despite all good intentions of analysis, design and testing, it is impossible to anticipate all different ways in which the solutions are used. This is why all successful technology solutions continue to improve with newer versions. Remember that I use “successful” and not “good”. Not all successful technologies out in the market are necessarily good ones!
We are going to begin practicing this from this point on. This does not mean that we will rush a solution with bugs out the door and inconvenience the larger population. It simply means releasing a product with well tested and fully functional smaller functionality and building more functionality as we move along.
Take a look at the Mobile Apps that we rolled out – we could have waited until we had a more comprehensive list of apps before we rolled it out. Instead, we were able to roll out some small number of very useful applications. Over a period of time, we will hear from users what additional apps will be useful, build them, test them and roll ’em out.
I have heard that one of the reasons for not taking approach earlier is because of the “Wellesley Culture” which does not favor this approach. I think it is important for us to show through examples why this is a favorable, better and sustainable approach and the community will understand and embrace it. Based on conversations I have had with some, I believe that they are ready for it. It is also the case that this is the standard operating procedure in the technology industry. Some like Google do it a little more aggressively and others like Microsoft do it less aggressively based on their respective user community’s tolerance for this.
In the next few weeks, we will roll out “beta” versions of a few applications including a slightly revised online directory and a version of online course listing. We will provide a way for the users to send us comments on how to improve them, based on which we will continue to refine them…