A couple of things happened to me in the past week that made me think a little about expectations and how they change over time and how these have led to some pretty significant scope-creep in my life
(1) My nearest and dearest has gotten bored with the Minivan. She wants a car. When we bought this particular vehicle our needs really were very utilitarian, we had (still have) two young children, needed the extra space and enjoyed the fact that you could almost move house with that thing along. Hence, new car.
(2) I have gotten annoyed and upset with my current laptop, its a very fine laptop, will do everything that any sane person would want it to. I however, want it to do the work of two (or three) computers at the same time (literally) and use VMWare to do it. At first, the laptop did it admirably, but now I find myself saying "hold on while I switch to the other machine" way to often. Hence, new laptop.
But anyway, the point here is that both of our expectations have changed over time, ironically, 2.5 years for both, that have made the existing solution unworkable or impractical for whatever reason. So does this mean that when we start a huge capital project in our business, that we should do so fully expecting that it's not going to be in place very long? And if thats truly the case, what can we do to mitigate the huge costs and reduced ROI's that would result?
With my laptop, it would have been nice I could have added memory or updated the processor (I did add a bigger hard drive, but the other two are already maxed out). With the Minivan, it would have been nice if GM had put in the magical convert to 4 door car feature, but they didn't, so nothing I can do there.
However, if you start a technology project, I would recommend you take a good hard look at the technologies and methodologies that you put in place. Here are some ideas:
- Build in plenty of access points and interfaces into the design where you can touch the solution to tweak or update the data down the line.
- Use open standards wherever possible, so that you can add other third party systems down the line.
- Use inter-changeable parts for the critical and major subcomponents (read Objects, XML and Web Services in Software Development), so that you can modify individual internal components without having to rebuild the entire system.
- Normalize the major components (databases, communications systems etc.) with your own code, so that you can switch them out if you need to.
The list is endless, oh and please excuse my own cartoon at the top, but you get the idea.
