Business meetings

I'm about to go into my first freelance business meeting about building a customer software solution for a reasonably major company.



How have people here gone about business meetings with regards to software?

I plan in this first actual meeting to go over the ideas in more detail then previously done over the phone, give a break down in expected time frame for specific components, and feel around for how much they are looking to spend.



is this a good approach? what should I bring with me? what should I expect to hear from them? all advice would be great

The only experience I have in this is a single lower-division class covering the process, so don't take my advice as gospel.

If you have anything at all to demonstrate - a presentation, some example code - bring your own laptop to present it. They won't like having to set up a platform for you to demonstrate on, except in the case of Powerpoint if they've already worked something out with you for that.

Are you working by yourself? If not, how many people will be working with you on this? I would recommend following the part of the Extreme Programming methodology that advocates keeping your client involved in the process. That means a lot of short meetings to show off what you've completed, and keeping your solution working for the demonstrations. At each meeting you should have something new and concrete to show them, whether it's a new part of the interface or a refined feature. Coming into a (weekly) meeting and saying, "we couldn't finish this aspect yet like we said, but this is what else we got working," is fine, and it allows you to represent your working schedule to the company and keep them on top of things. Companies and clients tend to like being kept very involved and very on top of things.

The worst thing you can do is go in and say, "This is what we can do, this is how long it will take, and we'll talk again at a later stage," because you'll inevitably get held up on something, or find out you just can't integrate a certain feature.

Just what I've learned, but I have no other experience.

Couple of things I can think of right off that might be of some use:

1. Depending on what the software is used for, you might try to gather some existing documents, forms, or software to gather a better idea of what the software you'll be writing needs to do.

2. Are the people you'll be meeting with the end users or just company managers? If you're meeting with management then you should take some time to interview the end users.

3. I wouldn't even suggest a scheduled delivery date unless they insist upon it. You could give a vague time-line, but be sure to emphasize that it's just an estimate and until you've completed the requirements phase and started the detailed design you won't be able to give a more concrete date.

4. If available you should try to attain a customer checklist so you know exactly what they expect the software to do.

5. You should try and gather their expectations in regards to reliability, ease of use, etc. Also you should emphasize that the more reliable you make the software the more testing that will be needed (you may even need to hire a third party for mathematical validation) which will increase software costs.

6. You'll need to see what their expectations are with regards to source code. Some companies maintain their software internally, so you might be required to use a specific language. You should be sure to point out that if a specific language is required that can add to costs (good compilers aren't usually cheap). Also you should make arrangements as far as intellectual property. In other words, you'll probably want to be able to reuse code for future projects and you need to make sure they're clear that you reserve the right to do so. If they don't want you to be able to reuse code, then, once again, it increases costs.

7. Also, you should try an separate "must have" features from "wouldn't it be nice" features and give estimates for each feature set.

I can't really think of anything else right off. Depending on the time allowed for this meeting you might break it all down and include some things in follow up meetings (which you'll need anyway to clarify the requirements).

As far as using the XP approach, I'm not really that fond of it. I can see a lot of the benefits, but every project I've seen that used it either degenerated into a "patch fix" project or was very close to it. I would suggest you look into a hybrid type approach. Go ahead and gather requirements, complete the spec document, and create a detailed design. After your design is complete then break down the implementation into 1-2 week segments and integrate each segment as it's completed and present it to the client.

Anyway that's all I can think of to add, hope it helps. Good luck.