Erwyn van der Meer

Well for what it's worth...

I think you can. If there are not too many complicated business rules you can write such an application.

However....

I say this because I use the tool MyGeneration to generate the complete data tier for me... so there is no coding involved. This makes it very easy to implement schema changes.

Besides that I use MyGeneration to create simple CRUD screens wich require no logic at all. So a prototype is quickly produced.

Because a lot is generated it's easy and fast to implement changes. Without such a tool I wouldn't start on it. Then you are too busy recoding everything all the time while you should focus on changing/extending functionality....

I do think it's hard to give an estimate of the cost. But i think this will depend on the complexity of the desired application.

I think it depends. If the RFP estimates are copy-n-pasted into some planning, then you should be clear on the fact that it's just a very rough estimate. Obviously you should not give them an estimate of 100 days and afterwards a 1000 days were actually needed.

But most of the time, you can make a rough estimate and yes, most of the time based on a database driven approach. Because you can always map those requirements onto a relational database, but it's much harder to map into a (large) class model that's based on the domain. Because of the lack of knowledge of the domain, like you said.

I always try to make clear the questions that I have that are left wide open and can highly influence the final estimates. But those sales guys/managers always want that RFP.

What bothers me more is getting a full functional document in which there's already so much technical/project-process stuff specified that you have a hard time explaining your customer that you think you have a better suggestion. Also, when you find out later the functional specs did not cover a very large part of what-you-have-to-build/what-the-customer-expects you can expect that they are going to ask you to explain why it took longer. And most of the time you again have to defend your better solution! :)


But in the end it's always down to us just delivering the RFP, no matter what. And then we just have to work overtime because our oh-so-rough estimates are just copy-n-pasted into a planning which you are bound to :)

It’s not my preferred way but I think it is possible to make an estimate based on a database design. A database model alone isn’t enough, at least a (rough) description of the required functionality has to be available also. I have seen estimates based on this information that in the end seems relatively accurate. Based on the complete functional requirements it is possible to estimate the cost including making a detailed design.

In this case however making an estimate for a fixed priced project based on preliminary analysis phase sounds very risky! In my opinion it is very likely that the estimate will not cover the actual resources needed. Functionality will probably change in the coming time and is not covered by the estimates you’re doing now.

I think a RFP for a fixed-price project based on incomplete requirements is not preferable. If I was responsible for answering this RFP I might have tried to convince the customer of this. This means, not you refusing to make the estimate but the managers responsible for this RFP talking to the customer.

To cover the risk involved in this you will probably see your estimate multiplied by a factor, after that a lot of overhead costs are added to the outcome of that and to be really ,really sure you will not lose money on this RFP an extra amount is added to the semi total. Resulting in a fixed price that might be too high which of course minimizes the change the customer agrees with your proposal.

Maybe it is better to wait for the customer to finish his analysis phase and base a fixed price proposal on that. But hey, most of the time that isn’t the decision of the people responsible for making the estimate :-)