SEER for IT: The Making of a New Product and Lessons learned
Measurement certainly requires looking to the past to learn of the future. But there is a huge amount to be learned from the lessons learned themselves. Looking back on the SEER for IT development there are several lessons learned that go beyond just the measurements.
Background
The SEER for IT (SEER-IT) concept began about 5 years ago when a major customer came to Galorath and asked us to build a model for capturing the non-software portions of an IT system. They had a model they offered to Galorath as a starting point. As the red tape of transferring the IP to us dragged on and that model we realized we better do this on our own.
We assigned the problem to one of our chief engineers could not get his arms around it. He accomplished little. We assigned part of the model development to a major university. They did some interesting work but their concept of schedule (getting thinks done) and ours were completely different.
Then our most senior modeling team came together and came up with a plan… They hired 9 contract researchers to augment our staff. They decomposed the problem of modeling IT and gave each of these researchers an area to research. Each researcher was located near a major library and was an Internet search guru. Simultaneously we approached customers who had the IT problems and were given data from them. A product roadmap was produced.
Our senior developers met to define the development approach. The development entailed defining the parametric relationships and data model as well as building the software application. (In parametric modeling it isn’t just throwing a bunch of developers on a problem. Analysts develop parametric relationships and data models that are developed) The approach was to be an incremental development implementing models as the math was finished and program infrastructure to support the models, as there were lags in the math specs.
Relatively early in the development a major customer expressed an urgent need for using SEER for IT and asked if they could use the work in process. We agreed. There is nothing better than real users to provide feedback. We were concerned about using software before it was completely tested. There were some hiccups but this worked out well.
Lessons learned
When customers are involved product requirements evolve even with sound specifications up front: The customer (who was fantastic) requested a number of items that were planned in future releases in release one. We modified the roadmap and met many of their requests. This caused a delay in release 1.0, but provided functionality earlier making later releases less dramatic. So if you look at the metrics on their own the product missed schedule. If you look at the functionality that was delivered in 1.0 as well the performance looks much better. On top of the items that were pulled from later on the road-map we added a number of items that we had not thought of…. such as estimating organic versus contractor work separately. This made the product stronger and has been sought after by other customers as well.
Make sure the definitions of “alpha” and “beta” is understood by all:We have some pretty industry standard definitions of alpha and beta. Unfortunately these definitions were not always consistent with the customer expectations for software we had handed off to them. Again they were great. But there were some bumps in the road. Also for measurement we don’t count an alpha handed off to a customer as a completed product item.
Bottom line: SEER-IT is a much stronger product due to the customer interaction. Even though we are the estimating company and we didn’t meet our initial estimates the product benefited from this.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Related posts:
- Step Nine: Document Estimate and Lessons Learned
- Experience Is What You Get When You Didn’t Get What You Wanted: Lessons Learned Review For Estimating
- The Value of Lessons Learned In Improving Estimates
- Acquisition Reform (WSARA) Webinar Discusses Lessons Learned and Way Forward
- Data Collection & Normalization Briefing 2009
Comments
Leave a Reply