Calling all business owners and managers:I need help

[KofDelight]

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.

[matt]

Taking experience with rolling out huge systems over multiple thousands of users, all I can say is make it a sushi menu...

That means list every aspect of what your software can do as an individual line item, and price those options. This gives your clients a great way of choosing exactly what they want, and you are more assured of a sell. With this your prices will seem lower than competitors, but you give slightly less function. Adding the whole basket of options you can even make it at a lower price. Also think about user access, whether you are going to charge for an individual user or for the bulk. You must remember that at the end of the day you need to make money from this as well to cover all your costs.

The size and level of integration of the system into your client environment will play a major part in the costing of the business. Unfortunately no one of us will be able to give you a rand value of what your software is worth, only what you must take into consideration when compiling your costing model. Like I said, it's very complicated and time consuming to do, but very integral to the survivability of your company.

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.

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.

[KofDelight]

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.

[matt]

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.

[KofDelight]

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.

[matt]

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.

[KofDelight]

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.

[matt]

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.

[czc]

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.

Define the scope. Once they agree anything extra they want is a change of scope and an associated cost. First thing is to get the initial scope nailed down.

[KofDelight]

Define the scope. Once they agree anything extra they want is a change of scope and an associated cost. First thing is to get the initial scope nailed down.

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.