Best approach for bidding a project

Question

We basicly have project that always turn around the same pattern. But, it sometime happens that we have project that go absolutly at the opposite of what we usualy do. It become now more difficult to bid and give this bidding to a potential client. In harder case, there's sometime things which look very difficult to do and we just don't have an idea of how much time it could take... We also (for sure) want to take as less possible time to bid this knowing that we should maybe never get the project.

So, my questions are;

• On what you base your time?
• What are the factors to consider (I know it's a bit hard as you don't see the base informations).
• Is there any tools that can help?

To wrap it all, is there a better way to do it and if yes, what is this way?

Answer 1

Bidding a project (which I assume is what you are talking about) is always difficult. If you try to hit the steps below you will be in a good spot:

• Make sure you have a complete set of requirements. Obviously you will need input from the client here and you will also need them to sign off on these requirements.
• Once you have the requirements, try break them down into the smallest pieces possible. This will make it easier to estimate how long it will take to implement each piece. Take the sum of these pieces as the base for how long it will take to develop (give yourself some padding)
• When the client comes to you with new requirements (which they will) try to address them in the next development cycle. I like using a phased approach to development, this allows you to get the clients sign off on the original functionality you agreed on before looking at additional stuff.

If you worry about minimizing the time to bid the project, then you risk the project failing or taking way longer than you expect. It's entirely possible that you might loose the bid, but that is probably a good thing. I would rather not get a project than get a project from a client that won't tell you what they want.

Answer 2

Estimating the effort required during the bid process is always difficult, especially when you don't know exactly how to solve the problem because the requirements are complicated or ambiguous.

Where the requirements are ambiguous, I would definitely try to identify the areas which are not clear and send a list of questions to the client to ask for clarification.

If your problem is that the project is complicated and you are not 100% sure what the best way to solve the problem is, I would be inclined to bid for the project on the basis that you will spend the first x weeks evaluating the project's requirements and prototyping possible solutions. It's not unreasonable to ask the client to pay for this time, particularly if the work is complicated. I would estimate how long you need to identify all of the unknowns and work out any gaps, and give the client a solid estimate for that part of the process.

On top of that, I'd estimate how long the total project would take on pessimistic assumptions, and then add 30% - 100% depending on what you think the client's budget is. I'd provide them with this rough estimate of the expected total effort, but make it clear that the effort is contingent on coming to a clear, agreed scope, architecture and implementation plan.

I think most clients will appreciate this sort of approach, particularly if the project is complex and you have relevant expertise.

Answer 3

It sounds like your going after a fixed-bid project and you and your co-workers have never done one before. I would recommend not even bidding on the project in your situation. If your company doesn't have the financial strength to absorb a total miss on the cost estimates (think 100% overrun, at least) and continue operating, then run away. The precision required to write the contract to avoid long periods of lawyers yelling at each other at $300/hr, the detail required in the requirements (to constrain scope) to make sure the client doesn't subtley push the goal posts farther away near the finish, details on what consitutes successful delivery, warranty concerns (shorter the better) is difficult. Large, experienced companies fail at this all the time. The only reason I see to do a fixed-bid project is the carrot of a multi-year support contract to follow on after the project is complete. Without that stream of extra revenue, the risk/reward is not aligned for the suppliers. There are reasons that the stats say 60% of software projects fail (or whatever the number is this week) and fixed bidding it doens't fix it and just passing off the risk to the supplier/developer doesn't solve the problem either. You are still going to change your mind, find out the requirements don't meet the real world needs, and now there will be a fight on who is going to bear the cost of the change and if you are not willing to spend the entire contract fighting to make sure your client bears the cost of change, you are going to lose money on this. Plus, from experience, fixed-bidding harms your client as well b/c the end up with software that satisfies the requirements in the contract not their business needs. Leave fixed bid IT engagements to email system implementations and such, they are far more predictable than building software.

Answer 4

You're pretty focused on figuring out how to get a fixed price number, but I would encourage you to think about other contract types, such as time and materials or cost plus. The way to make these palatable to the customer is to propose specific milestones and deliverables along the way, so that they can see progress and they are making incremental payments.