How do I know how much to bill and how long a software development project will take, before analysis?

Question

In software development we usually do a analysis phase where requirements are taken, user interfaces are designed (for software with ui), etc. After the analysis phase you know what to do, and you can estimate (aprox.) the effort and the cost for the future tasks. But usually I noticed in some companies, the analysis phase is done after the project was already sold. But I don't know how can I negotiate a budget (more profits) and time with just a project charter or a simple analysis, at least for a complex software product. It is usually the way software development deals are done? Or is it just a bad practice? If you can share, how do you estimate budget and time for the first negotiation with the client.

Answer 1

One thing that makes software projects special is that once you have fully analyzed everything, you are basically done with the job. Of course you can't afford to do this as long as it is unclear if you will get the job.

Therefore it is normally required to take the risk and make a quote with very little knowledge. Often it is possible to compare the complexity of the requirements with a project you have already done to get a rough estimate.

There are a few ways to reduce the risk:

1. Convince your customer to treat the analysis and specification as a separate project producing a detailed specification and maybe a prototype as output. Then get feedback from your customer and estimate the implementation. This is still very close to waterfall but offers some additional options if the estimate exceeds budget

   • Adapt the scope by removing less important requirements.

   • If the customer decides to abandon the project you still get paid for what you have done so far.

   • The customer has the option to let someone else do the implementation.

2. Use an agile development method and proceed in small iterations. Don't plan and estimate an iteration before the previous one is finished and you got feedback from the customer.

I agree that it can be difficult to convince customers with a waterfall/fixed budget mindset to proceed in any of these ways.

Answer 2

As others have said, it's at least partly guesswork, though your guesses should be based on (hopefully extensive) previous experience. If you remain totally clueless, but nevertheless interested, offer to do the job on an hourly basis rather than as a fixed price contract. But if you do things right, fixed price can end up much more lucrative (I'd ballpark by a factor of three on average) than hourly. Moreover, even though they end up paying more, clients often end up happier -- they had a known up-front cost.

But one additional thing I can tell you for absolute sure -- no guesswork required. On any non-trivial project, the users/clients/etc are going to change their minds, have new ideas, etc, etc, before you cutover to production.

Some developers get very upset at this absolutely inevitable development. But it's really a good thing. Only a client who's a complete idiot will have no new/changed/etc ideas as he reads functional specs, plays with prototypes, talks to users, just sits and thinks, etc, etc. And all that just helps you eventually deliver a better system. Development is, by its nature, a moving target. Don't be mad, be prepared.

But clients have to be prepared for the extra delay and cost of their new/changed ideas. Check that they either already are, or else explain the facts of life as gently as possible. I have a gentle saying to introduce such conversations, that I'll share with you here (but don't tell anybody else): it's "TTT" meaning Things Take Time. Cute enough so it's not intimidating (say it with a smile), but helps get the overall point across at the beginning of a discussion.

And during development, when the inevitable changes are requested, the most sensitive discussion is negotiating corresponding contract changes (meaning more money). Clients will inevitably begin by explaining to you how what they're now asking for is actually already in the original contract. About 20% of the time they'll have an arguable point. Make sure you recognize those occasional occasions, and be more than forthcoming when they occur. But about 80% of the time they're blowing smoke (you know where:), and you have to be firm yet friendly -- good client relationships are everything. Everything. Everything. That's why I started this paragraph by emphasizing "the most sensistive discussion". You've got to get paid, but you can't make clients angry about it.

Sometimes the requisite time isn't budgeted for, or blows a deadline, etc. In those cases, and really in all cases, your functional spec should have a section more-or-less titled "Planned Revisions for Release 2.0". Indeed, sometimes stuff you'd planned for Release 1.0 end up in that section.

Answer 3

Completely analyzing something before starting work on it is very hard, if not impossible. Trying will cost a lot, and will likely lead to analysis paralysis. On the other hand, committing to a project with no plan at all is a recipe for disaster. I don't know why some companies seem to gravitate toward one extreme or the other. It certainly takes all the joy out of software development.

If you're not experienced in making time and cost estimates yourself, you can lean on the combined experience of the development team. This implies that you will not give the client an estimate at your first meeting.

1. Discuss the basic requirements with the customer. Brainstorm two lists: requirements for version 1.0, and nice-to-haves.
2. Run both lists by the development team, or at least the more senior developers.
3. As a group, make rough time estimates for each item. The developers may tell you that some of the requirements are going to be very difficult, or that some of the wish list items are trivial.
4. Note whether any items are likely to depend on other items.
5. Present the lists to the customer and let them decide which items they're willing to pay for.
6. Incorporate the list items into the contract.