The cornerstone of successfully establishing and completing any project or program is a rational cost and schedule estimate. These estimates are the basis for trade-off studies and management decisions regarding realistic project lifecycle planning. Cost and schedule estimates are appropriate at any lifecycle level (conceptual, pre-proposal, proposal evaluation, start of development, in-process or post-mortem). An estimate is useful at any point during a project or program for the purpose of verification of scope, quality, cost and schedule performance. Cost estimating activities include: • Independent estimates • Contractor evaluations • Proposal evaluations • Post-mortem calibrations • Organization calibration • Cost-to-complete estimates • Cost estimation seminars and workshops

RULES OF THUMB and such:

Here are some well-known rules of thumb in the cost and schedule estimation world. One is that the average programmer produces 100 lines of code per month. Another is that by taking the cube root of the lines of code and multiplying by 3, you can estimate the basic schedule of a project in months. For example, a project estimated at 100,000 lines of code (LOC) would take approximately 1,000 staff months (100,000 divided by 100). The cube root of 1,000 is 10, and multiplying this by 3 equals a nominal time schedule of 30 months. (Again, these are very rough rules of thumb —and good software developers will have more accurate and validated rules for their particular organization. Still, as general rules of thumb, they have been independently discovered and validated many times). These rules of thumb can be used to establish a rough estimation of man months and time, given a reasonably good estimate of code required. One premise of these rules is that the cited nominal schedule cannot easily be shortened. The multiplier 3 used in the example varies among schedule estimation experts. However, most experts agree that anything below a multiplier of 2.25 creates an impossible schedule. In other words, if you know the line-of-code estimate of the project, it is relatively easy to establish a minimal schedule, which according to leading experts, cannot be lowered. This permits a relatively easy idiot test of the schedule. The remarkable thing is that many projects do not have rough estimates of LOC (or function points, or some other size measurement), and therefore cannot justify (or even explain) their schedules. If your project has a schedule (and delivery date) dictated by anything other than a reliable (size, schedule, and cost) estimation method, then you are likely to have an impossible schedule. Just because the software is needed by a certain date does not imply that it can be ready by that date. Develop an understanding and respect for the complexities of software development. This understanding is invaluable in comprehending the challenges of software estimation. Have you ever noticed how simple things are, if you are not the one actually doing the work? While remodeling their house, the wife of one of the authors considered many of the tasks associated with the remodeling as simple, little projects. Such simple, little projects included moving a load-bearing wall and extending an exterior wall to make rooms larger. The author's wife could not understand why the project schedule and budget were so large. These are, after all, simple, little projects! Simple —but only in the mind of a person who does not understand the principles of construction and will not be doing the work. Software development is like this! Program/project managers and customers of software-intensive systems need to understand that software development is not a simple, little project. Estimates and schedules developed using sound software estimation processes and approaches should be respected by managers and customers alike, and not randomly adjusted due to whims and desires of external influences. As a final note, Brooks Law [4] (which paraphrased, says that adding additional people to a late software project only makes it later) does not just apply to adding people. Reorganization, changing contractors, or reassigning personnel in a late project will most likely not improve the situation. However, it will provide a convenient excuse for management when things start to fail! When the schedule starts to slip in a major way, there exist only two viable solutions. First, change the schedule. Second, reassess the requirements and provide less functionality. Of course, a poorly designed system that is into development or testing cannot easily have functionality removed without major recoding. Therefore, often the only viable solution is to change the schedule.

End Context from CrossTalk

Independent software development cost and estimation services are available from MMB&T. Over thirty years experience in software development, development management and software project management with software firms, retail industry, manufacturing, city and federal government.

 Project experience with DoD systems, inventory, sales, material management, financial management and forecasting software development. Mainframe, client-server and n-tier, mini, and micro systems development experience using a variety of technology solutions such as COBOL, COBOL II, RM-COBOL, DELPHI, PowerBuilder, JAVA, Oracle, Microsoft Visual Basic, Jdeveloper, DHTML, XML, ASP and Oracle Developer products. Accumulated software project development metrics based on over 1200 projects will  provide baseline metrics for our estimates. CMM/SEI and PMI life cycle approaches used for almost seven years. Top-Down, Typical Project, Bottom-Up, Function Point and CoCoMo II employed for estimation types. Six Sigma is also employed, as well as, Business Analyst approaches learned from IBM, Microsoft and Advanced Strategies, Inc. to provide unique insight into development solutions. 

We can provide a detailed cost estimate, optimum expectations and variances, preliminary Microsoft  Project plan, and other valuable project  information to help you make decisions on software development projects as an independent, outside source.  We can also provide an independent objective review of existing project estimates as an added outside "set of eyes".

The more information you can provide, the faster a quality report on the cost, time, resources and risks involved can be provided. If you have developed a software requirements specification we can use that documentation as the basis for the estimation of cost, time and resources required.   

The basic information needed for us to provide our service is:  

• Documented systems requirements specification (SRS)
• Known language(s) and platform(s) to be used for development 
• Intended platform/environment(s) for production release
• Software development team members (number and type), their skill levels and associative salaries (for costing tasks)  
• Target start and/or completion date (for example, mandated by law) or optimum deliver options based on a starting date

The fee basis for this service is $30 per hour direct labor charge, plus materials as required (eg. copy counts of products to be delivered). 

Provide us a description of the project, what information you have as described above, and we will promptly respond to your inquiry with an estimate of the cost involved for us to be engaged to help solve the software management decisions. Submit your software development project estimate analysis request to us at  info@mmbandt.com. Please refer to PM20001 in the subject line of your request.

If you are advancing the retainer in response to your inquiry, please use the following:

Return to software page