Estimating Rules of Thumb
This section contains estimating rules of thumb that have been developed at Intelsib. These guidelines can be very helpful when estimating an eCommerce project. Additional information and rules of thumb can be found on a number of eCommerce resources on the KX.
1. eCommerce Survival Guide Rules of Thumb.
The eCommerce Survival Guide provides an excellent diagram with some common rules of thumb that should be used when developing an estimate. The diagram is followed by some bullet point items on estimating.
Figure 1 – eCommerce Survival Guide Rules of Thumb
2. Dot Com Launch Centers Rules of Thumb
These rules of thumb are based on the Chicago Dot-Com Launch Center's experience.
The range for these projects is $4 - $6M. That seems to be the cost a new dot-com is willing to spend on the development effort that gets it to launch. Therefore, the plans aim at that range, reducing scope or making other adjustments if they don't fit. The sum does not cover software purchases (like licenses for Blue Martini, which the Chicago center uses a lot) and other such expenses. It does not apply to any subsequent releases (after the launch) either; we have insufficient experience with those.
3. Blue Martini Implementations
The following numbers have worked well for several Blue Martini implementations.
- A good range for the technology portion of a work plan is 15 to 30 days per web page.
- A good number for the non-technology work is adding 50% to the technology part.
4. Metrics and Values
Distribute the time ratios between the existing constituents of the application given the following rules of thumb:
- Average Days/Page (Design + Build + Test) 52
- Ratio of Build to Design 3:1
- Ratio of Test to Design + Build TBD
- Total Number of Days (Design + Build + Test) 1,046
- Business objects (database tables) (25, 35, 50, 65)
- Interfaces ((50 –100), 200, 350, 500 based on complexity – tech + reusable)
5. Complexity factor
There is no linear relationship between the number of things to achieve to the time it will take to achieve them. The relationship is actually:
Aspects to work with = 2n- 1, where n are the number of thingsyou have to start with
- With one thing - there is only this one thing and it is the only factor to deal with.
- With two things – there is each of the things plus the areas where they overlap or interact, so we have three aspects to deal with.
6. Internet Architecture versus Client/Server Architecture days
Experts felt that the “spread”, or percentage of days per task package, was not significantly different than the spread used within Client/Server Architectures.
However, the experts provided this rule of thumb:
Internet Architectures # of days = Client/Server Architecture # of days * 1.5
7. Coming up with a unique estimating model
Because of a lack of an estimating database within the firm that could capture actual numbers of net-centric project experiences, it is difficult to create and refine an estimating model. However, each project is somewhat different from the next, due to a myriad of factors. Thus, we can get closer and closer to the “right” estimate, but as technologies evolve and clients change, the factors to consider in our rules of thumb must be modified, and in turn, this makes each estimation a unique process.
8. Estimating, planning and resourcing
One definition of estimating is the calculation of the amount of time and effort that will be required per type of resource for each part of the work to be done. Yet, this is an iterative process between planning and resourcing. Therefore, when determining the rules of thumb for estimating, it is necessary to take into account the rules of thumb of planning and resourcing.
There is no rule of thumb for a testing budget in Net-Centric development. Traditionally from client/server the rule of thumb is Testing Budget = 1.5 * Build Time, Net-Centric jobs seems to be hinting that the old test/build rule of thumb yields an excess of testing days because so much unit test goes on as part of the build process.
The things we refer to can be: number of systems to be replaced, number of integrated components, number of business processes to be re-engineered, number of departments involved, number of locations, number of people in a discussion.
Taken from the Net-Centric Experts Workshop Summary