Know-How Exchange : Other

tylerdewitt

I think you should start asking yourself a question if can afford not offering out of the box solutions? It's the same as saying that you cut yourself off from bigger accounts.
If no then you have to really give it a deeper thought.
One of the solution in such cases is hourly rate, but be sure to figure it out beforehand within the range of +/- 10-20% of your project time. Otherwise customers will get frustrated.

Another option would be extreme programing, but never heard it worked out really ok for any party involved.

Adam

Adam

If you don't have a clear specification on what the client wants, then you're doomed if you try to do a fixed contract (since the target is so nebulous).

This gives you a few choices: 1) have them pay you by the hour for the integration, 2) have them pay you by the hour to create a target specification - then you bid on the fixed cost to the spec, 3) have a group of consultants you refer this business to (and possibly take a percentage for the referral),. 4) take on the new integration needs -- creating new packages in the process to sell later.

Ouch...that was quite a sentence!

Ok, if I hire you for a customized solution and you give me an hourly rate...I'm going to ask you for an estimate of time. If you can't give me an estimate...I'm not going to hire you.

That leaves you with the option of NOT offering customized solutions or spending time looking at other websites (ones you know are customized) and figuring out how much you'd charge for that type of work.....so you're ready when the time comes.

The bottom line is to make money, right? Many developers offer off the shelf stuff and make plenty of money. Their marketing programs are also different.

Michael

Break the project down into phases

Price by phase at a pre-determined number of hours
X dollars per hour after exceeding predetermined
allow between 10-20% excess time (add in to original hours you project)

Payment due at different phases/interval of project

Be clear of what the client must provide to you for each phase of the project to enable you to move forward

Add in rush fees and other miscellaneous fees

Clarify hours of the day you will work (8-5 is one rate) after hours is another rate

That's all I can think of off-hand from my days of programming and projecting.

Account for data and file errors and charge accordingly...if you're proposing to transfer data, make exceptions (extra fees) when required to fix data errors or they must supply with < 10% errors, etc.

Travel fees included in proposal

Holiday fees

Licensing fees

We would run back over projects and look at reports for programming similar projects and estimate times in that way.

Can you offered "pre-programmed" for some aspect of the project to bring them to level one and then begin adding on custom programming as needed once the basic foudation is in place?

Could also break the proposal out into separate categories, for example: Equipment and licensing fees, basic programming fees, custom programming fees, data transfer fees, etc.

The problem you face is one that is faced by nearly everyone who makes a living selling there time rather than a hard product. I know this will sound a bit like words.. easier to say than to do.. but you need to develop a process (and expertise) for large jobs.

Here are a few pointers from a kindred industry:
1) Learn to develop detailed specifications of what the customer is going to get. Whenever possible work to convince the customer that nobody can truly work in his best interest without those specification.
1a) when possible- charge the customer for the time developing the detailed specification. He can use it as a quotation document and take it to your competitors to make certain that everybody gives a fair price.

2) Build your price around the detailed specification.
2a) if the specification changes.. mid stream.. after you have already started the work, it requires a change order. Change orders cost extra.

3) After the work is completed, review the specification and check off the work one feature at a time. Be prepared for the customer to ask for some tweaks - see 2a)

4) your reputation will build based on how big a deal you make over providing some of the easy change orders for free...

5) live happily ever after...

tyler,

how are you doing? I hope well!

based on my long executive and management experience in

SW industry I beliveI'm qualified to help you the best way.

just have to go some where for some time please wait for my answer very soon

regards,

Mohammad Aboali
Marketing and Strategic Advisor

It’s a common problem caused by an inability to negotiate an appropriate contract – possibly because negotiating contracts isn’t what you do well or because you lack the experience. It’s common in the software world and the amazing thing is that a cost over-run of a contract appears to almost acceptable, the bigger the contract is and the bigger the client. Have you ever heard of a government software contract coming in on time and on cost?

In the small to medium marketplace, you are looking at people with needs, but people who think that they have fixed costs which come from a budget. If your project overruns the quoted cost, they only see the impact on the rest of their bottom line, and sympathy to your position is limited, even if it is down to poor specifying from the customer in the first place. If you can’t specify a contract (I.e. negotiate the exact product you are going to deliver to a detailed specification) then you can’t price it. It might still be the case that unknowns in the deal mean that you still can’t price it accurately and that you will need to leave room for negotiation at the end. That’s a fraught process, because you’ve either delivered a product and want some extra money or you’ve not delivered and you want paying to finish it. Either situation is ugly. For reasons of competition and poor negotiation, you rarely see the situation reversed, whereby you end up delivering ahead of schedule and on spec so that the customer wants some money back.

The dynamics of the situation, were they random, would indicate that as many jobs overshoot as undershoot, but the foibles of the negotiators mean that it’s always a one way process where you risk losing money. That’s why jobs, when sophisticatedly priced include an element for the risk. The impetus is for the contractor or supplier to work their guts out to hit targets and schedules in return for sharing the revenues. The penalties are that if you get it wrong, you’ll lose money and equally, if the client starts to change the goalposts, it will cost them. Sadly, few contracts are secured on such a transparent, bi-directional share of the risks and the supplier or contractor usually takes on the majority of the liability.

Your solution to this is not so much a marketing solution but one of sales competence – learn to negotiate properly or don’t go for this kind of work.

I’d be inclined to stop there were the world a simpler place, but its not. Your problem isn’t just that you have a problem with negotiating; you appear to have a problem choosing what you want to do. Optimisation for a CEO is a real headache and you’d expect that someone involved in the hard and fast digital world of software would be able to come up with a neat equation, but there isn’t one.

You state that your biggest profits are made from packaged solutions. If that’s really the case, why don’t you instruct your team to concentrate only on those? I used to manage a company which made electronic instruments and we had a saying, any idiot can sell a “special” and any idiot can manufacture one, but to do it profitably, takes more than an idiot – so sales people were tasked with selling what they had and engineering was tasked with making what they’d agreed could be sold at a profit.

Marketing was expected to help to direct the sales force towards people who would buy standard, but at the end of the day, convincing a client that they want out-of-the- box standard is down to a salesman closing the deal. Customers always want something you don’t make. Engineers always want to make exactly what they want. But to make a profit, salesmen sell what they’ve been told to sell and engineers concentrate on product development for the next product, not some variant of this one. There: We’re back to sales instead of marketing again.

But that does leave you with a marketing dilemma. You can’t deter would-be customers who want a bit of customisation or a lot of customisation from making enquiries, so that’s back to the dilemma you started off with. How do you price the job? I’d go further and say, do you even want to price the job? Rather than spend a week on trying to negotiate a 50K deal, what would happen if you spent that time doing bog-standard sales activities for bog-standard product? And then what are the risks and rewards for the 50K job versus the effect of spending the time selling standard?

Here’s what usually happens and it’s because you, the CEO or the owners or the bankers are looking next week’s order book. Devoting that time to selling won’t put a penny on your figures in the next week. If fact after a month, it might show up on a forecast (You tell me the timescale – you havn’t stated what it is or can be) but it’s not going to show up on a bottom line for some time. So you look at the special job at 50K and say, “If I get this right, that’s 50K on the books by the month end” Reward looms large and risk takes a back seat. So you pitch on whatever basis you use – per hour, with our without a cap, for the job, mixed pricing – whatever. And the customer tells you that you’re up against stiff competition so your prices are looking high. Now you’re in a bit of a hole. You and your team have probably already spent a couple of weeks on the job, when you could have been laying the foundations for a more profitable income and you are going to lose all your work because of price. Oh dear, we’re back to poor negotiation. You feel forced to meet the price objections, despite the fact that you’ll never know exactly what the opposition was offering. A salesman shouldn’t get to this state, because they should have closed on the aspects of the deal through negotiation as he went along – negotiating all the time.

Eventually, it sounds as though you take the work at the price the customer appears to want to set, probably to a specification which is less than crystal clear. That means that you are left with most of the financial risk and the customer will hold the upper hand. If anything goes wrong or over schedule, you lose on profit. You also lose on the opportunity cost of not doing something which would have been more profitable. You’ve just entered into a deal which at a low margin which decreases daily with every problem you encounter when in reality you could have been doing something far more profitable, but you aren’t because you got suckered into the idea that a figure on the books is better than a forecast in the pipeline.

Optimisation of the profitable use of your time is never going to be easy, but you will need to do it if you are to bid for large complex contracts. A further complication is the marginal utilisation of resources. What if your people were, for whatever reason (Usually poor planning), not going to be gainfully occupied. In other terms, you’ve got slack time. Well, as it happens, you might as well use it as profitably as you can. If you decide only to take on marginally profitably projects utilising the time which would otherwise be spent dusting the filing cabinets, your cost model can plummet for that job allowing you to price it more keenly. But you can’t have this both ways. If you use marginal costing for some jobs, it means that full costing must be applied to all other jobs, so your overall profit margins will suffer.

We’ve had some interesting discussions on optimisation in the past and I agree, it is one of the hardest disciplines, but unless you learn to negotiate, you’ll never be allowed to optimise.

Best wishes

Steve Alker
Unimax Solutions

Hi tyler

Your main problem is simple. You cant properly quantify what your customer wants.
You prospect assumes that you immediately understand the implications of everything they are saying and cant understand why you cant give them a fixed price.

Assuming you want to undertake larger projects, lets say 25k plus then you simply have to build steps to drive out uncertainty.

step 1

If you can get a business spec from your client. This gives you a baseline. A point at which you can both start to discuss what actually needs to be done. If you cant say you need one. Call it an investigation. Charge T&M (time and materials a simple daily rate) and you can do this in less than a week.


Step 2
From this business spec do a functional or technical spec which turns the business specification into a technical document that your programmers understand. Do this T&M also. This does two things it gives you a more detailed baseline document. Its driven out as much uncertainty as possible and hey prestoe you've been paid to produce a detailed quote.

Step 3
From your detailed specification you can give a fixed price with confidence because you know what your quoting for and your prospect now has something in detail telling them what they're going to get. YOU MUST GET THEM TO SIGN OFF on the spec, that way if you build it there no arguements. Add 10-15% contingency on your fixed price.

Step 4
Change Control. Do what it says "control change". Dont make ANY changes without having analysed what it takes to build it and what implications it has for the system your building. Get them to sign it off BEFORE you do it. Most projects go wrong because you try to be helpful and make changes on the fly or against a verbal request and get stuffed because it takes longer than you thought and your client ends up refusing to pay

For this to work you need decent project managers. That means someone who actively manages the situation not someone who just reports progress, but who can fix things when problems arise.

This is a bit old fashioned I know but then I'm over 50 but I made over 14% profit at the net level on my projects and they were delivered on time.

Laurence Ainsworth
England