August 2014

Estimation Process (part 2), The Interview:  The estimation interview is the most critical step in your estimation process.  While these interviews will often end up with a half-dozen or more participants, you’ll quickly find that the interview is really a discussion between you and one or two people that have a good handle on the business requirements to be addressed by the project.  I like to begin by having them explain the purpose of the project, in their own words.  (If they can’t clearly and simply explain why the organization should be doing this work, then the project is not ready to be estimated.)  You should ask questions about the goals and objectives until you understand general scope inclusions, exclusions, the estimation purpose.  You’ll then want to ask some targeted questions to help you prepare the estimate.  These questions should expand on, clarify, or supplement the written material that you’ve already read.  When you’re asking questions, you’ll normally focus on one general estimation area at a time.  For example:
 
Infrastructure:  Tier level, rough idea of expected loading, number of environments, and database to be used if known.
 
Boundaries: Inclusions, exclusions, external interfaces, and external applications that may need regression testing.  In a general sense, where are the areas of greatest work for this project?
 
Applications: Applications to be installed, modified, or replaced; roles and responsibilities; and warranty, maintenance and operations expenses that should be included in the project budget for a transition period.
 
High Level Object (HLO) Deliverable Components:  These are quantitative lists of work products to be created, modified, or tested as part of this effort.  Common examples include internal interfaces, pages, reports, batches, workflows, configurations.  The specific list of components will be selected based on the HLO catalog(s) that you are working with.  Don’t include work that will be covered elsewhere (e.g., under ODCs (below)).
 
Conversion:  Conversion strategy, and for data to be converted, number of databases, tables, fields, and master records (e.g., customers).  Data quality if known.
 
Other Direct Charges (ODCs):  ODCs other than infrastructure as covered above.  Typical examples include travel, application license costs, and vendor firm fixed price bids for configuration and installation of their software.
 
Risk: Contingency, profit (for commercial bids), mitigation costs, areas of greatest uncertainty, and management reserve.
 
Wrap Up:  Any areas of work that will be required but that are not covered above?  Any unique aspects of this project that will impact on productivity or cost either positively or negatively? 

 
[Reprinted with permission from: “RETURN ON INVESTMENT (ROI) IN SOFTWARE PROJECT MANAGEMENT TOOLS AND SOFTWARE QUALITY CONTROL,” Capers Jones, July 2014.  Full article available on http://Namcookanalytics.com]

 
Software development is a troubling technology. Software is custom designed, hand coded, and therefore highly labor intensive and error prone. As a result large software projects are among the most expensive and troublesome undertakings of any commercial product. For example, large software systems cost far more to build and take much longer to construct than the office buildings occupied by the companies that have commissioned the software. Really large software systems in the 250,000 function point size range can cost more than building a domed football stadium, a 50-story skyscraper, or a 90,000 ton cruise ship.
 
Not only are large systems expensive, but they also have one of the highest failure rates of any manufactured object in human history. The term “failure” refers to projects that are canceled without completion due to cost or schedule overruns, or which run later than planned by more than 25%.
 
The author often works as an expert witness in litigation for software projects that were either terminated due to cost overruns or did not work properly when delivered. Depositions and discovery documents in these cases reveal four endemic problems:

1. Poor estimation practices before the projects began.
2. Poor quality control practices during development.
3. Poor change control practices during development.
4. Poor status tracking by managers during development.
   

Thus the combination of poor quality and poor project management is the cause of far too many software failures in the modern world.

 
Budgeting for Travel:  Travel costs are a significant expense that is often neglected when estimating.  It’s almost impossible to predict the exact number of trips required, days needed on-site, number of travelers, and so on.  You might be tempted to write your request for proposal with a stipulation that you will not pay for travel costs, thinking that will solve the problem.  But those costs will still be present, they will just be buried in the fees charged.  ExcelerPlan allows you to budget for travel costs using a trip-build up; as a percent of labor costs; or as a fixed budget per hour.  You can (and normally should) calculate travel separately for in-house staff, on-shore contractors, off-shore contractors, and consultants.  For early stage estimates, a fixed budget per hour will generally work the best.  See the Tips and Tricks in this issue for some hints about selecting the correct budget per hour.