Reno, NV    +1 (800)0 621-0871

Go back


Budgeting and Estimating Software Projects

  |  April 1, 2011

Agile and Responsible Development

When prospective clients approach us to contemplate a web or mobile software development project, after establishing it is within our capabilities to produce, usually the first thing they want to know is how much it will cost and how soon we can get it done.  Completion dates are a function of team velocity and scheduling which in turn depend on our availability and workload and the anticipated pace and length of expenditure and of course the scope of the project.  In this article, we will discuss what goes into determining the cost of software.

Budgeting and estimation of software projects is difficult for the inexperienced and can seem frustrating or opaque for the uninitiated.  Software can be infinitely improved and endlessly customized.  Even a small system can vary greatly in cost based on the complexity involved, the features that ultimately comprise the product at maturity, and the level of “finish” or polish.

A software asset is a living thing and the word “done” only applies when the asset or codebase moves into a mature or maintenance phase or reaches the end of its useful life.  Often the true complexity entailed in a software asset is not revealed until the thick of development.  The ultimate feature set and design can change up until the moment the system is released to the public or to its users.

Professional practitioners of the craft, over the last decade and a half, have adopted a broad category of methodologies known as “Agile” through which they accept and seek to address these realities of software development.  Different styles of Agile recommend their own techniques for estimating in the form of planning games and exercises.

The type of software we develop at AELOGICA is often smaller in scale and of a more speculative, innovative or highly-styled nature.  Some well-known agile planning and estimating techniques suitable for larger projects are difficult to adopt in their original form for the distributed, outsourced development service we provide.  Thus we incorporate these techniques while continually refining our approach based on the best practices of our industry, as well as our experience with what works and what does not.

We seek to not only to “be agile” but to be responsible partners with our clients in executing their software plans.  Robert C. Martin, a leading light in our industry and one of the founders of the Agile movement, refers to this approach as, “Responsible Development.”

How Much Should You Spend?

Before trying to determine the cost, it is appropriate to determine how much one ought to spend in general terms.  What size of investment does the project justify?  How can funds be spent wisely, early in the life cycle of the project to maximize the value created and accelerate the return on that investment?  This can lower the risk and possibly justify further investment.

Lean Startup Feedback LoopPrior to embarking on a software development project, the motivation for development should be clear and the financial model or business model behind it should justify the expense of creating the software asset.  When developing a new product for an unproven market, it is essential to keep the cost under control and do only what is necessary to prove the market and move the business to the next stage.  Much more on this topic can be gleaned from the materials and ideas associated with the Lean Startup movement made popular by Eric Reis. @leanstartup

The anticipated value of a software asset to the business or project sponsor should be many times its anticipated cost of development and ample funds should be available at the different stages to ensure successful delivery.  We advise going back to the drawing board if the anticipated value is within an order of magnitude of the estimated cost or if funding is insufficient to complete an initial release or Minimum Viable Product. (MVP)

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers [users] with the least effort.

What Makes a Software Asset Valuable?

  • actual users or paying customers
  • users who want to use the system
  • someone who is willing to pay to see it used
  • working code on a stable deployment environment or distribution platform
  • good test coverage
  • planned features or enhancements based on actual feedback with financial justification
  • developers and designers who understand the business and the code behind it
  • a functioning team and good relationships surrounding the project

What Detracts from the Value of a Software Asset?

  • lack of feedback or market response
  • users abandoning the system or resisting adoption
  • technical debt (the accumulated compromises made during development to meet short-term goals)
  • departure of key developers or disbanding of the team

What Are Some of the Risks of Software Development?

  • The anticipated market does not exist or users fail to adopt
  • Technology risk  (it doesn’t work as envisioned or is too expensive to maintain)
  • Cost exceeds available funds

All of these risks represent the potential for wasted effort and wasted money.  As responsible developers, we seek to minimize these risks as much as possible, as quickly as possible.

To lower the risk of wasting money, we want to create as much value as possible early on in the asset life-cycle.  There are technical aspects to this but the business side and the decisions that drive development often dominate the technical.  Technology risk or failure in itself is rarely the cause of a project failure.  In our technology choices, we prefer open-source solutions and we look for broad acceptance of individual components and tools among the leaders in our community.  We follow the best conventions and accepted best-practices as much as possible.

While we are not business consultants, as responsible partners in the process we perform an important role in helping minimize non-technical risks which can lead to projects under-performing or failing.  We do this by clarifying features prior to developing them and we endeavor to help our clients uncover the justification for individual features to ensure we maximize the pace of value creation.

“Ok, so how much will it cost?”

It is rare to find a client that is not cost-sensitive or for whom other factors completely trump cost.  Everyone wants to know what it will cost.  To get a handle on overall cost, it is necessary to produce an estimate.  Intellectual labor is the main driver of cost and therefore cost is a function largely of developer time.

Only an experienced developer, working with a familiar technology stack, can tell how long it will take them to develop a particular feature with any accuracy.

Accuracy increases as experience within a particular project, technology stack and team increases.  Accuracy decreases when estimating how long it will take another team member or pair to build the same feature.  Consequently, it is very important to engage the developers who actually will do the work in the estimation process.  This should be done in an ongoing basis through the life of the project such that after several iterations, the estimates for pending and planned work increase in accuracy.

Any estimation entails a degree of uncertainty.  However, these uncertainties can add up to a large variability as many features are incorporated in an estimate up front.  Accuracy at the high resolution of a single feature, does not always translate well to accuracy at a high level total.  For example, a feature estimated by one person may be developed by another as team composition varies.  Often decisions taken early on will affect the time it will take to do something later but if the estimate is not updated to incorporate this new information, the project may be off track without anyone knowing.

When looking at a project that may take two months, without rigorous and expensive up front analysis, even a somewhat experienced developer can be off on his or her total estimate by as much as a factor of 2!  This is true despite a great deal of accuracy on individual items.  Getting within 20% of an estimate can often be considered fairly good.

This is disconcerting to clients accustomed to purchasing other services or products with a fixed cost.

There are a few options for dealing with this situation:

1) Do not estimate the whole project in detail. Simply identify an MVP and allocate a fraction of the overall budget to build that.  It should be almost embarrassingly simple but contain the most important elements of the full system.  A reasonable amount of estimation can be done to ensure the MVP can be built in the general range of the amount budgeted for it.  The smaller and simpler it is, the more reliable this estimate becomes.

2) Perform limited estimation and then use arbitrary, unrealistic and un-competitive padding in the estimate.  Insist that it is non-binding and costs will change.

3) Dispense with “agile” and perform an expensive, up front analysis phase, and use iron-clad contracts and strong project management to ensure nothing gets built that wasn’t estimated and incorporated into the contract.

Many of our projects may not support heavy project management, nor are clients willing to spend a significant percentage of their budget up front, just to receive a detailed estimate, and then once started, give up all control over the final appearance or feature set.  In our experience, limited estimation with padding sets a project up for a host of problems including mismatched expectations, hidden sub-projects and delivery risk.  We prefer option 1).Minimum Viable ProductLet us review an example.  Suppose you have $50,000 to build a product. Budget $15,000 for a very simple MVP and build that.  Spend 20-30% of your overall funds to get an MVP.  Once you have traction, market feedback and a track record with the team, you can decide how or when to spend the rest.  Even if the worst happens and the MVP approaches 50% of the total funds available, due to changes or unanticipated complexity, you still have a viable product in your customer’s hands, possibly earning income, and you still have half your budget left.

Be up front and honest with your developer about your total budget.  Ask the developer what they can deliver for 20-30% of your total funds available and try to figure out if you can assemble an MVP out of that.  You will gain their respect and create a trust that is the beginning of a responsible partnership.  You may find that by starting from a limited budget and working backwards with a trusted developer, you are better able to pare down the feature set and arrive at a truly minimum viable product, while at the same time setting the stage for healthy growth and a long term relationship.

Keeping Costs Down

There are a number of things both parties can do to help keep the costs low and avoid waste.

The Customer’s Role

What can a customer do to help hold down the cost of software development?

  • Be available to the team for a 15 minute standup at a fixed time every day or every other day
  • Do not wait more than 24 hours to accept/reject delivered features
  • Be clear when reporting a bug or rejecting a feature about the reason and steps for reproducing
  • Decide up front on a reasonable level of polish or finish for the User Interface (perfection, however desirable, is expensive and usually not necessary)
  • Have a wireframe or user interface sketched out before going into detailed design
  • Avoid insisting on a particular technology or tool against the developer’s wishes
  • Clearly specify any quantifiable performance criteria if applicable (# of concurrent users, minimum response time for key operations, etc.)

All of these steps aim to minimize the amount of re-work and time-consuming round-trip communications.

Maximizing developer efficiency and avoiding re-work are both essental to keeping cost down and the responsibility lies on both ends of the relationship.  No request or change is “free” nor should it be.

Developers slow down and get stuck when they lack clarity on what must be done.  As much as possible, you do not want them to waste time trying to guess what you meant or making inaccurate assumptions while waiting for a return email that may take 12 hours.  It may take a little adjustment for non-developers to acquire the level of specificity that developers expect but diligent attention to this will reward you with efficiency and cost savings and a better overall result.

The Developer’s Role

We have taken a number of steps to remain competitive and we continually strive to increase our efficiency.

  • We have quiet project rooms where a team can work in the same room for efficient communication
  • We use the best tools and techniques for the type of software we create
  • We develop on Macs so we don’t have to fight our machines
  • We operate in a lower cost, top-tier world city with an abundance of highly skilled developers
  • We pair-program to avoid getting stalled and avoid re-work  (more on this in a separate post)


Hopefully this article takes some of the mystery out of the process of procuring custom software development services.  If you are contemplating a web or mobile software project, we invite you to contact us.