Thanks guys really appreciate your advice and knowledge that you have shared.
If you have any other advice with regards to running a business I am ALL ears.
Printable View
Thanks guys really appreciate your advice and knowledge that you have shared.
If you have any other advice with regards to running a business I am ALL ears.
The sushi menu thing is good advice. Otherwise clients end up insisting on something that takes way more time than it's worth and you end up skimping on important features to fit everything into the budget.Quote:
Also, if it's a custom job, you can try break the billing into milestones or deliverables, that way you have something to work towards, and you can keep the cash flow going, and the client actually gets a feel that things are happening.
Yeah they keep adding things they would like the software to do.
So you day I should list them and add a price to each one and estimate the cost of each concerning creating it and implementation.
That's called scope creep. It's fine if you're still on the specification phase because that's when you're deciding what it should and shouldn't do, although it's good to cull off some unnecessary stuff for a first release, but once you're in agreement on what the system is and isn't going to do, especially if you have started dev, nail it down in writing with estimates for each thing. Then if they ask to throw in some other bit of functionality, say it's not in the scope of the project, so you can either revise the estimates (and their budget) to include it, or say that you can put it on the list for phase 2 stuff, which will be a separate project with a new budget.
- - - Updated - - -
Sounds like you're still in the specification and design stage of things, the best advice I can give you is spend a lot of time with this to make sure you and the client know exactly what the system will and won't be. We often use a program called Axure to make wireframes of the screens that users can click through and interact with. They don't look like much and everything is spoofed, but when they see how things work, it can help a lot to get expectations in line and find out what will work and what won't and see what's missing. Then we also get a graphic designer to mock up a few screens so that they will see how they will actually look.
Thank you so much Matt,I'm taking notes on this and relaying it to my partners.
I told them about writing down all the specs that the client wants and adding prices to it.
We have a meeting tomorrow with the Finance department,hope it goes smoothly.
Sure thing dude, I'm not a business owner, but I am in software development so I know how these things tend to go. Generally clients don't actually know what they want, or really understand what it is they are asking you to do, they just have a vague idea about more or less what a thing should do but can't really visualize how it would work, so getting specs and designs and wireframes done long before you write a line of code really helps everyone to understand what's actually going to happen, and it helps to get proper requirements out of the client.
Otherwise what you find is that they explain stuff to you, and you think you understand, and you write this whole system, and when you release it for testing, they say this isn't at all what we expected, and it really has to do this random thing that I never told you about, and ooh I didn't think of this issue, that won't work at all.
Plus, it's really really important that what you expect to deliver and what the client expects to receive are the same thing.
Also, bolting on features, and jippo-ing code to work a different way than you initially planned tends to make the code very messy and buggy, and often inefficient and hard to maintain, so a good initial specification and understanding of the whole system is very important before you start coding.
Yeah the client keeps saying" I want this,can you put that in" but I told them they NEED to give us exact specs on what they want and write them down.
Ya dude you have to get a full specification done before you start coding. You're in for all sorts of trouble otherwise. You can write the spec and get them to sign it off, but it means lots of meetings to figure out what they need and how best to do it and get the software and the client's business processes to work together.
One thing that works very well for spec docs, and also for meetings where you are figuring out specs, is draw pictures. Make nice ones for the spec docs, but while you're in meetings figuring things out, sketch the screens, draw flow diagrams, draw everything. Everyone thinks that having everything written out is all proper and stuff, but drawing things helps people visualise things and understand each other. They don't have to be pretty drawings, even blocks and arrows does fine.
Yeah that is what we discussed in our meeting today.So far there are no specific requirements,what we'll do is come up with possible ones and just have them on the side,while we wait on what they want.
We just have the basics and so far they are happy with it and we will demo it again sometime next week.