Fixed Bid vs. Agile
On the other hand, we're still left with this huge gap. On the one hand pretty much all of the smartest developers I know concede there is simply no way to accurately predict the effort required to complete a non-trivial software project. That maps exactly with my experience. While I continue to remove variables, tighten my contracts, more carefully set expectations and develop systems to cut the cost of changes, I still have issues accurately estimating projects - even after completing over 400 over the last ten years.
On the other hand not only do all of my clients want a fixed bid/fixed scope contract, but most all of the people who I'm bidding against will provide one.
Much of this is a function of education and selecting better customers (both of which I'm working on) and techniques like Software Product Lines can be used to manage the risk in providing a fixed bid on projects within known domains (as they can radically cut the cost of development and change, provide more detailed default documentation, make many tasks configuration, increase the profit margin of development and so on). That said, it can still be frustrating trying to balance the recommended approaches in much of the XP and Agile literature with the expectations of many of the smaller clients I still work with and the programming shops who are more than willing to provide fixed price quotes.
I guess it came to a head when I read part IV of the book which is a worked example for a simple e-commerce store with a basic catalog, cart, checkout, and wish list along with some basic my account and reporting features. The estimate was something like 50 ideal days with the programmers estimating one ideal day per 2-3 actual work days (which I get).
So assuming $80/hr, 8 hr days and 1 ideal day per 2.5 programmer days that is a billable cost of $640 x 50 x 2.5 or $80,000 excluding sales effort, project management, support, training, look and feel or content entry. It would depend on how you did those other items, but that wouldn't leave much change from $120-$150k for a simple commerce site which (even if I had to code from scratch) I'd see as a 2-3 man week project at the most (programming only).
What are your thoughts? Do you provide fixed bids? If so, how do you handle things like "dark matter", rounds of revisions and unreasonable clients? Do you sell agile/iterative development successfully to unsophisticated business owners when competing against fixed bid/scope quotes? How? What are the benefits that they buy?
And would it take you 50 ideal days to build out a simple e-commerce system or do we need to introduce these guys to a more productive programming language fast :->
Any input appreciated.
I'll gladly chime in on this one having spent a little time delivering agile projects recently and also working on more traditional fixed bid projects. I think all developers are by nature people pleasers: we want people to like what we do for them and we like to tell them what they want to hear. If a client says I want a guarantee that a project can be done in x hours at an agreed price, most developers crumble and agree.
The client is usually asking because they either have no experience buying a programming project or they have had a bad experience because a project went off the rails. In my experience projects go off the rails because of bad project management skills, poor estimation process or a lack of discipline. Poor estimation is either a lack of experience in estimating or a lack of experience coding a project of the scale. I see it time and again that development teams don't start with a testing plan, let alone include the tests they intend to perform in the project plan and estimate.
Clients who think buying custom built software is as simple as shopping for a tin of beans rarely make good clients so we as developers and project managers or salesmen need to show them early in the sale that we are experts in our domain and have the ability to adapt to theirs. The agile development process begins in the sale, not once you've bid the project out at x dollars.
The conversation begins for me with talking about the overall scope of the project to establish where to begin the project and agreeing on a suitable first iteration. If the e-commerce site is the goal then a first iteration has to focus on designing the product detail pages since the rest of the site is built around that goal. Gain agreement to build the working HTML prototype so people can hammer out the details while you just have tags to content with. Add the AJAX and graphical trimmings to make sure they are certain how it is going work. This phase is drastically simpler to give a ballpark estimate on and because you hammer out all the details of this phase in the context of the complete project your team are learning about the nuances of the project. There is nothing you will learn about the end project that will surprise you if a client has been working with a good prototype with their products and categories instead of lorem ipsum. Having a successful phase 1 like this leads you to a good working relationship with your clients from the outset.
The second phase of implementing screens your client has agreed on and likes becomes much easier. You know exactly how many templates you are building and whatever your chosen CMS or e-commerce package it becomes much easier to build reliable estimates for this phase of implementing the HTML in CF. If you are rolling your own templates, surely it's just a query to get the data for the page (4 hours?), work the data you get back into the right shape (2 hours? ) and then reworking the HTML code to use the processed database values (4 hours?) so 10 hours per unique template, plus some overhead? Wrap up phase 3 with the implementation of the CMS details to get the products, phase 4 to work with the shopping cart, phase 5 is data entry and acceptance testing, phase 6 is load testing and phase 7 is planned maintenance to handle parking lot items and bugs.
I realize that is quite a big rant but your post triggered some latent passion about the subject of selling software and educating clients. My bottom line is that a client has to understand the nature of iterative development and it is my job to help them understand. If they ultimately reject the idea of software development as a partnership I won't work with them because I personally need the satisfaction of a client that the site was done well and we worked well together. As one very smart mentor once told me, you should enter every potential client meeting thinking "I don't HAVE to do this website". Your happiness, sanity and reputation has to be a factor in accepting a client.
Adam "High Horse" Howitt
I am convinced that agile is the best way to develop software of pretty much any size. What I am not convinced to is that many projects can be sold as agile. If I run a sporting goods store and I want to sell stuff online. Four people bid on the project. Three are nice, simple fixed bid quotes for (say) $20,000-$40,000 from companies who have built many websites. One is from a guy who says he can tell me either what it'll cost or what I'll get but not both. Chances are I'm going to buy from one of the first three, no?
I certainly have problems selling Agile to unsophisticated business users. For a long time I always used to think that the reason I couldn't estimate software accurately was because I didn't know enough about it. I've now done over 400 projects, I lecture and write on requirements and have read most of the popular books on the subject and I now understand that accurate estimation isn't a solvable problem in the general case. The problem I still have is that I find I have two types of clients - those that are open to agile and those that are not. Obviously I can just move towards working with the better clients, but do you have any insight into selling agile in a competitive solution where the competition is offering a fixed bid and the purchaser has no experience in purchasing software and not much interest in learning more about it?
I do have some thoughts on selling agile against fixed bid but I'd love to hear your thoughts.
Again, the issue is that if you say "I'll be done in 2-6 months" and I say with my best salesmans smile that I will be done in 8 weeks, I'm gonna get the deal assuming I appear to be credible - especially if I tell them exactly what it will cost upfront. And once I have the deal I can take longer or make it up in change requests. I know that, you know that, but if the customer hasn't been through the process before, they don't know that.
I can think of a bunch of "spoiler" questions you can suggest the client asks about what happens about all of the details that weren't fully specified, but if I was the guy selling the fixed bid project I could bat those aside pretty easily.
So I guess my question would be "in a competitive solution against credible fixed bid bidders and with unsophisticated buyers, how do you sell an agile proposal successfully"?
Corollary: have you noticed any identifying factors for people more likely to "buy" an agile approach? Bigger budget? Software experience/ Bad experience in the past? More intelligent? Less intelligent?
Any input appreciated!
Helms and Peters Out Loud has sold me on the "Build the interface First" concept.
Basically, at a 'small' fee or an hourly rate you build the interface (either as a paper prototype or an HTML prototype, or photoshop mockups or whatever).
After the back and forth on the prototype, client approves prototype and you provide a fixed fee bid for implementation.
I'm still getting my head around this approach, but so far I've had success with it as long as I walk the user through the prototype.
I think for simple projects in well known spaces fixed bid makes sense, but for many other cases it really doesn't provide the client the best value for money. Thoughts?
DotComIt is the "Subject Matter Expert" firm with ColdFusion and Flex; not specializing in any individual vertical market. If the client isn't willing to put up front time to get us to understand their domain and how to work within in, then the project is really doomed from the start.
I have not figured out the trick to doing projects succesfully, although we are much more successful these days. Lately I've had a bunch of clients that came to me with prototypes already built; which makes things much smoother.