Hello all. I am a noob on this forum, so sorry if this has been covered to death already - but I have searched and searched and found nothing. A couple of friends and I are starting a small business together in programming, and I am hoping to get some advice. It isn''t game programming (although that is on the list for the future) but having read through some of this forum I see there are a lot of professional people around so I figured it can''t hurt to ask. We have a couple of projects lined up, and know enough about designing and producing software to keep us out of trouble (I hope), but we are a bit stuck with bidding / estimating. Here is one scenario: 1. Someone approached us about designing / creating a program for them 2. We had a couple of meetings and got a load of requirements - probably more than you would normally get at this stage - they even gave us a prototype of the program that they have been working on 3. This is where we are stuck - we are not sure what the common procedure is here. The client wants a price (fixed) for the whole project, and we are not sure of how to come up with an accurate figure as we are only startup and have nothing to base our estimates on. Also, what documents do you normally hand over at this stage? Is it the Software Development Plan? Would someone mind outlining the general procedure for getting projects like this? Or maybe there is a website I could be pointed to.. or maybe I am blind and this info is already on this site somewhere (its my first day..!) We know about designing and developing a system, its just the business side of it like how much $$$ to ask for at what stages of development. Oh did I mention they wanted the source code too? That would surely drive the price up a lot... Anyway, thanks in advance for your replies, and feel free to rip my head off if these questions are not appropriate for this forum (and maybe point me in the right direction) or if I am being too vague Cheers! Adz.

With these situations in general, a client is wise to ask for source code and a fixed price contract, since the client is taking a big risk going with a new startup supplier. The startup supplier could go out of business, in which case the client was wise to get the source code. The startup supplier, due to inexperience, may underestimate the work involved, in which case again the client was wise to go for a fixed price contract.

In your situation it sounds like the client wants a "work for hire" project, whereby the supplier (you) do the work, but the client retains ownership of intellectual property, copyright, software, source code, artwork, etc.

In terms of initial documents, in my experience it usually goes like this:
1. Invitation To Tender (ITT) (produced by Client)
2. Proposal (produced by Supplier)
3. Contract

1. The client has probably given you an informal ITT in terms of meetings, prototypes, etc rather than a document listing requirements, this is OK if you've gained a good idea of the client's requirements.

2. The proposal is your document in which you describe to the client that you've understood their requirements, you describe briefly what you're going to deliver when, how long it will take, and how much it will cost. If you decide that further investigation is required and a full design document should be produced, then this is one of your deliverables you state in the proposal.

If you already "know about designing and developing a system", then you should have an idea of how many man days of effort it will take (be realistic/pessimistic here). All you need to do is decide on a rate (X dollars per day), to work out what you will charge for manpower, and add then add any other costs to the quote.

This all sounds very simple, but IMO it is the most difficult thing to do. Estimating costs at the start of a project, when you have the least amount of knowledge of the project, is much more more difficult than developing the software. I'd recommend considering a project methodolgy like DSDM (www.dsdm.org), it wont help much with estimating, but it will reduce your risk of working longer than you estimated in a fixed price contract, since the methodology allows deliverables to be prioritized, variable, and cope with feature creep, even though the scheduled time allowed on the project remains fixed.

3. If the client wants to proceed, then a contract is signed by both parties, and basically states that the supplier will do the work, and client will pay the money (e.g. a supply of services contract). Its a good idea for you to produce the contract, if the client hasn't got a standard one of these contracts. This contract could be provided with the proposal.

Good luck



[edited by - abstractworlds on January 28, 2004 12:03:52 PM]

Hi, thanks for the quick reply
I guess I was a bit vague with "know about designing and developing a system" - I just meant we know a bit about designing with UML and about the Iterative process, as well as other methodologies - waterfall etc. - and the coding of the thing shouldn''t be a problem. The hard part at the moment is just knowing how long the project will take without getting too far into the design.. we could design the whole thing very detailed in UML and have an accurate figure on how long it will take to produce, but that would take time and I doubt this is the normal thing to do.
I guess the Proposal you mentioned is a fairly high level, broad list of requirements, and the time estimation (realistic/pessimistic) using Pert..
We haven''t had any luck with Google on how to write a proposal (only results that come up are for proposal writing software) but have had some luck in the Software Development Plan (SDP) which seems to contain the details you mentioned - or am I getting a bit ahead of myself...

Cheers

> The client wants a price (fixed) for the whole project,
> and we are not sure of how to come up with an accurate
> figure as we are only startup and have nothing to base
> our estimates on.

If the nature of the project is novel you could ask for a ''cost plus'' type of contract where the client pays your costs plus a 10%-15% profit payable at the end. The client pays the incurred costs at fixed milestones and upon delivering a satisfactory product you get your 10%. You still have to figure out some overall ballpark figure but if costs run out of control, they can opt out of the contract at any time and take away the sources without leaving you out in the cold; it''s less risky for both parties. Otherwise if you are running out of cash to finish the project the client is still out on a limb trying to negotiate with someone else, or if you finish too early the client stays with the feeling of having been had.

-cb

A couple of thoughts here to add to some of the advice already posted.

The proposal document is basically akin to repeating the question back to the client and then answering the question. Repeat back to them what they told you the requirements were then address how your design will meet those requirements. This only has to be at the module level and major subsystem level. Do not drop UML diagrams into this document because that's more than likely too detailed. The proposal is a sales pitch and should be treated accordingly. The last thing you want is for the client to be able to use your proposal to solicit some other company to do the work because they have all your technical documents.

A full design document might be one of the first deliverables of the project. If it is, then you need wording in your contract and in your timelines that points out the dependency of delivery upon design. This will allow you to slip the date while the client takes their sweet time approving the design. If you do not include a full design document, then you will need to be sure that you have a good understanding of the design and that they have faith in you to deliver a good design.

The contract is the legally binding document between you and the client. Make sure your lawyer looks it over and by all means provide that document. Ensure that you have jurisdiction provisions that require them to sue you in your city and state governed by your local laws. Without this, a breakdown in the relationship could cost you tremendously in travel and legal expenses. Make sure the contract clearly states its a "work for hire" situation and the client indemnifies you of all liability express or implied. Lastly, I like to stick the proposal as a formal appendix to the contract and I always restate the deliverables explicitly in the contract. Again , make sure your lawyer at least approves of the document layout and always bring him/her questions that you are not sure about. The document binds you as much as it does them.

As for estimating a fixed project, the key is to have an understanding of the requirements and knowing that your understanding is the same as the client's understanding of the same requirements. Once you have that, you can breakdown the project into smaller pieces and begin to estimate man hours. I like to use my own experience, but often times, I find I can do some things faster and some things slower than other professionals. Over time I have learned to not use my personal experience when estimating unless I will be the one doing the work. If you've always been known to be a hotshot programmer, don't use your ability as a guide stick. You really need to use the average ability of your team as a measuring stick for man hours on any given task. Whatever number you decide on, add 20% to that number because the only way you'll get close to the intial number is through years of practice with the same team. This being your first project, its a foregone conclusion that you will not estimate it correctly.

Kressilac


[edited by - Kressilac on January 28, 2004 2:30:32 PM]

[edited by - Kressilac on January 28, 2004 2:34:20 PM]

quote: we know a bit about designing with UML and about the Iterative process, as well as other methodologies - waterfall

I haven't used UML yet, and I seem to get by without it, but maybe that's due to the nature of software I develop. DSDM is an iterative project methodology that addresses many of the problems of traditional waterfall methodologies. One of the great things about DSDM is that it encourages you to go through 3 iterations of the waterfall process, delivering 2 prototypes and a final system (the final system evolves from the prototypes). The good thing about this is the client gets 2 interim milestone deliverables before the end of the project, that they can see and understand, and more importantly for you, pay for, rather than seeing nothing until the end and paying for everything at the end of the project.

quote: The hard part at the moment is just knowing how long the project will take without getting too far into the design.. we could design the whole thing very detailed in UML and have an accurate figure on how long it will take to produce, but that would take time and I doubt this is the normal thing to do.

UML designs are too detailed and too time consuming for the proposal stage. The proposal document should be in simple English as most clients wont understand too much IT speak. Rather than a detailed UML design, think about a high level break down of the system in terms of either functionality, database/business entities, screens, etc hopefully something the client will understand.

If you need to do detailed UML designs then these should be produced in the design document which might be one of your first deliverables/milestones if you get the project. More importantly, you should be charging for this design work as part of the overall quote.

Proposals should be kept high level, and not be too time consuming. There'll be times when you're competing against other companies and you might not get the job, the proposal is a compromise of how much work you're willing to put in without any guarantee of return.

quote: Software Development Plan (SDP)

I don't know much about this, although my guess is its another fancy name for another methodology. Most project methodologies overlap in their similar recommendations, and many of their recomendations are common sense. Some methodologies are better suited for large projects and large teams, in a client environment where there's a lot of project paperwork required (the nature of large development teams means that a lot of design paperwork is required to communicate information to the various people working on their small part of the system, the businees analysts/systems analysts/programmers/testers). I have assumed that your project is quite small which is why I recommended DSDM, which is good for small RAD projects using prototyping and being worked on by with competent developers with a helicopter view of the system (where a developer has a mix of skills taking on the roles of the businees analysts/systems analysts/programmers/testers).

Be careful about methodologies, trust your common sense first, and just make use of good methodology ideas if they are appropriate for your project. If you choose to religously follow an inappropriate methodology you could spend all your time producing documentation for the methodology, rather than system for the client.

[edited by - abstractworlds on January 28, 2004 4:37:02 PM]

Thanks for all the replies, they have been helpful. We were getting bogged down with this bit, as there isn't a lot of info around (that I could find) on the bidding process. Document names like the Proposal, Software Requirements Specification (SRS) and Software Development Plan (SDP) keep coming up but all seem to serve the same purpose of making sure the requirements are understood by the client and developer.

abstractworlds: Thanks for the link to DSDM - I had not heard of this and will look into it.

As for this:

quote: This being your first project, its a foregone conclusion that you will not estimate it correctly.

Absolutely! We are just hoping to get the correct processes / procedures in place and try not to get screwed too bad


[edited by - Lord Adz on January 29, 2004 4:24:02 AM]

> A full design document might be one of the first deliverables of the project.

If the client doesn''t care how things work internally, you could begin with the User''s Manual since this the base from which the project is ultimately evaluated. If the client doesn''t like the interaction or the visuals, then you''re not stuck with an architecture that needs deep changes to be performed on when you are about to put up a UI for it.

-cb

quote: Original post by Lord Adz
Document names like the Proposal, Software Requirements Specification (SRS) and Software Development Plan (SDP) keep coming up but all seem to serve the same purpose of making sure the requirements are understood by the client and developer.

These are three very different documents with different purposes.

The Proposal is a high level document that should lead to a contract or a Statement of Work (SOW). It says essentially "We would like you to pay us $$$ for doing XXX and here is why this is a good idea for you".

A Software Requirements Specification details what you are going to build to sufficient detail to allow anyone to design the software. In the gaming industry this is often called the Design Document, but in the rest of industry that is a totally different beast.

The Software Development Plan details how you plan on developing the software. It typically includes people, money, and timelines. It also includes things like your model of development (Waterfall, Spiral, Iterative, Extreme, etc.). It may need to include risk management information, although on large projects this is often a separate document.

Thank you Anonymous Poster...
I guess this means that all three documents are important in the bid process for a project, the Proposal, SRS and SDP (and sometimes a separate doc specifying risk management strategies). I''ll push my luck and ask if you have any links to where I might find a table of contents, or even better, some examples of these documents? :D