I need a price
Look at the bigger picture and collaborate, or fail
We all know the problems associated with fixed price, fixed scope contracts for software projects. Yes, there are alternative ways to run a software project, but sometimes you just need to quote a single price. Perhaps you need to secure internal budget or maybe you're a consulting company bidding for work. Either way, getting the cost wrong can have some huge consequences for everybody involved. Let's imagine that you *do* need to provide an estimate of the effort required to deliver some software. Sounds technical, let's ask the developers.
More often than not, asking software developers to produce estimates as the basis of a fixed price, fixed scope contract is a really bad idea. You see, we software developers tend to have a very technology-centric view of the world. We spend most of our days staring at code in our IDEs and we like to talk about things like classes and dependency injection and refactoring and automated testing and a whole bunch of other deeply technical stuff. There's nothing wrong this, and if you're not thinking about these sorts of things then you're probably in the wrong job.
Step back to see the bigger picture
The problem with software developers costing up software projects comes from not leaving that world behind and stepping back to see the bigger picture. If you're trying to cost up a project while having discussions about the number of fields on a user interface or whether the data should be stored as XML or broken out into a full relational model then you're going about the estimation process in the wrong way.
Sure, these things do become important at some point in time, but they probably don't make a great deal of difference in the grand scheme of things. What does? It's the major architectural drivers ... the functional requirements, the non-functional requirements, the constraints and the principles. Instead of thinking about the details, you need to be asking questions like...
- What are the major drivers for the software? What problems is it solving? If it's replacing an existing software system, what's wrong with the old one? What are the benefits delivered by the software?
- Are there any inter-system interfaces? What are they? Who owns them?
- Are there non-functional requirements (e.g. security, audit) or constraints (e.g. regulatory) that will prevent the system from going live?
- What technologies are already in use and what technology choices do we realistically have given the environment?
- Who will be operating, supporting and maintaining the system in the future? What sort of skills do they have?
- etc
These sorts of questions will help you comprehend the size and scale of the software project much more than understanding how many columns you need to store the data.
Most requirements documents are inadequate for estimation
Most of my career has been spent in a consulting environment and I've seen my fair share of requirements specifications over the years. Without doubt, I can say that none of them have been good enough to produce an estimate from. Look at it from the other side of the coin. Imagine you have a vision for a software project that you've been living and breathing for a few months. You think about it, you talk about it and you visualise it with colleagues. Then, in order to engage a development team, you open up Microsoft Word and start typing up a requirements document. The thing is, the reader probably doesn't have the same amount of context that you do. Those one-liners you've used to describe the major features are likely to seem ambiguous to people that haven't lived and breathed the vision like you have. Customer collaboration over contract negotiation anyone?
Put simply, it's unrealistic to expect somebody to produce a cost estimate from a few pages of "requirements", particularly since that document normally doesn't include all of the other essential information about the environmental constraints, policies, technologies, etc. If you find yourself in the position of having to provide a ballpark estimate, especially if it's going to be used as the basis for a fixed price contract, the best piece of advice I can give you is to collaborate. Grab a room with a whiteboard, invite some of the key stakeholders and use this as a forum to understand the vision. Oh, and don't forget to get those risks, issues, assumptions and dependencies out into the open.
