There is a popular myth that the estimating problem in software development starts with comparing software development to bridge design and development. This lays the groundwork that software development is not the same as any other engineering discipline and estimating can't be done for software projects
That some how the project paradigm is excempt from the Five Immutable Principles of every other project domain. These immutable principles are:
- Do we know what DONE looks like in units of measure meaningful to the decision makers? These measures are effectiveness and performance. The Measures of Effectiveness are operational measures closely related to the achievement of the mission or operational objectives evaluated in an operational environment, under a specific set of conditions. The Measures of Performance characterize the physical or functional attributes relating to the system operation, measured or estimated under specific conditions.
- Do we have a PLAN - not a schedule, but a strategy - to reach this done state in a logical sequence of work activities? This sequence delivers the needed capabilities to support the mission or business case to maximize the ROI for each capability.
- Do we have some understanding of the RESOURCES needed to execute this plan? These resources include staff, facilities, money, tools, environments all needed for success.
- Have we identified all the uncertainties - reducible and non-reducible - that will create risks to our success?
- Have we established some form of measures progress toward our goal in units of physical percent complete?
If we are building bridges the answers to these questions are pretty clear. We are bending metal into money in ways well established from the past. For software project, these questions still have clear and concise answers, although the answers are developed not from blueprints, but from other means.
Economics of writing software for money
If we accept these immutable principles of project success there are few other immutable principles of business and the management of a business that writs software for money. Either internal projects, where funding comes for the company, or external projects where the money comes from a customer.
- All value is exchanged for the consumption of time and money.
- This value cannot be assessed in the absence of knowing the cost to produce that value
First let's look at Barry Boehm's seminal work Software Economics. Some have suggested this idea is outdated. They would be wrong, especially since that suggestion - being wrong - is not backed by any experience or reference of managing the balance sheet of for profit software project. Internal projects where the cost and cost perfomance is outside the persons management responsibility doesn't count.
Show me the money (that you have been held accountable for)
And by accountable I mean, you lose you job or are reassigned when things go bad financially.
Now with the advent of agile software development, Barry's concepts from long ago need to be updated for iterative and incremental development. Barry by the way instituted the Spiral method in the DOD, replacing the Waterfall method, An recently instituted the evolutionary method replacing the spiral method, starting with Section 803 of the National Defense Authorization Act.
Core business processes are still in place, not matter the software development methods. Those processes haven't been overturned by agile or any other process. We still exchange money for value. The rate of that exchange must be a positive ratio
Value / Cost > 1.0
must be positive if we expect to stay in business for long. Monetizing value is many times difficult up front. Monetizing the work effort may appear difficult to some, but in fact it is not as difficult as it appears. There are many tools, processes, books, training, professional organizations that have field proven solutions to estimating and managinf cost in the software development domain.
Back to the Future on Estimating Software Development Cost (and Schedule)
- The estimates aren't for the developers, although development management is a crticial user of the estimates, and the developers are critical contributors to the estimates. The estimats are for the business and the decision processes made by the business. Business takes funds and turns them into products and services. Bending metal into money is a common phrase in the hardgoods business. Bending software into money works for the software development (for money) business (internal or external).
- Developers are closest to the work, but they are not likley the best at estimating the work. Not because they don't know what needs to be done. If they don't know what needs to be done, they'll produce bad estimates.
- Decisions on how to spend the companys money start and end - in any profit focused company - with when will we earn back our investment?
- What's our profit margin?
- What's our ROI, IRR, Breakeven day, Analysis of Alternatives?
- What staffing impacts will result from starting this project?
- When will this project complete, so I can know when the spend profile and staffing burden will change
- What's the expected completion date so we can transition to the business, and then transition to operations. So we can know when to change what we are doing to the new operations doing.
- Knowing the costs of products or services provided in exchange for money is the basis of any business strategy.
- People give you money
- You expend effort (cost)
- The difference yuo keep, minus your overhead, fringe, and benefits.
- If you wait till the end to do this calculation, it's too late to change the course of your efforts.
This approach comes from early in my career. A time when Barry Boehm worked at TRW, along with me and 1,000's of others. My boss, took us young guns aside one day and gave us his standard speach on a pay day Friday.
Everyone take out you pay check. Look in the upper left corner. It says Bank of America and TRW and the branch address. That's NOT where the money comes from to pay you. The money comes from the US Air Force (TRDSS was our program). They pay us to deliver the Statement of Work items for the amount of money we said we woudl on the date (more or less) we said we would. Keep doing that - within the allowable variances - and you'll keep getting those check you can take across the street to deposit in your account.
Customer provides money to do the work needed to provide value. In the TDRSS case, provide the internet in space. When the cost of providing the value exceeds the budget for providing the value, we loose money and likely go out of business.
Not knowing when you're headed for trouble on cost, schedule, or techncial performance is simply bad business. So having an estimated performance target to steer against is mandatory for business success. It can't be any cleared than that. Without that steering target your project is open loop management and you'll be in the ditch before you can steer away from the ditch.
