2

1. When to treat a software as deployed and when to start charging for maintenance ?

In most of the cases the software we make is deployed on the web at early stages to enhance the testing process from the client side. This means that bugs keep arising and we keep fixing them alongside development. Not just that, as the clients use it, they come to know of modifications required which creates a pile of extra work for us. Because of no demarcation line between development, deployment and maintenance stages its hard to understand when to charge for what.

2. How to charge for software maintenance ?

I read that vendors charge 15%-22% generally for softwares annually. That being a fixed fee what happens if the maintenance takes more time then expected ? What happens if the system runs fine or without issues for an year ? Does the client still pay maintenance ?

3. How to charge for non-application specific improvements ?

We use a core engine to build business applications. Improvement in that engine means improvements, new functions, etc can be made available to all clients without modifying their application layer. Should that be included in maintenance as free upgrades ?

4. How to charge for maintenance in case of hourly contracts ?

If we work on an hourly project most of the times the scope of the project keeps expanding but that doesn't require a revaluation of the project because the increase in scope equates to increase in hours and hence increase in budget. But most of the times due to increase in the scope the bug fixing and maintenance work also gets included in the development time. Is that good ? Or should there be a demarcation between deployement and maintenance even for hourly projects ?

|improve this question
  • 4
    If you want to ask multiple questions, create multiple questions. – Matthieu Dec 16 '11 at 13:58
4

1. When to treat a software as deployed and when to start charging for maintenance ?

When the Statement of Work is complete, the job is done. If you don't have an SoW, you're being too informal about building software for others, and you'll inevitably get into disagreements with your customers, and possibly get threatened with lawsuits.

Anything not covered in the SoW is outside the scope of the paid-for project. If you choose to do it anyway, it's usually a good idea to make sure the customer knows you're giving them a freebie - customers like freebies, and it reminds them that the next one might cost them.

2. How to charge for software maintenance ?

18% of the then-current purchase price is a common Annual Maintenance Fee for purchased software. Some vendors succeed in getting as much as 20%, but more than that is unusual. If you structure your maintenance this way, the customer generally gets whatever you do, regardless of how much or how little time it takes.

The other way to go about it is the way lawyers do - you ask for a retainer, which is really just a pre-payment for work at an established hourly rate. If the work doesn't consume that many hours, the customer gets the overpayment back. If the work would exceed it, you talk to the customer about an additional payment - sometimes in advance, sometimes in arrears.

3. How to charge for non-application specific improvements ?

If you charge an Annual Maintenance Fee, that usually includes any other Enhancements and releases you make as well. In fact, such fees are usually called "M&E" in the software business - "Maintenance & Enhancement" - for just that reason. It's not a "free upgrade", it's part of what the customer is paying for.

4. How to charge for maintenance in case of hourly contracts ?

See my answer to #1. If you have a Statement of Work, it's easy to see what's in and out of scope, and negotiate the results.

|improve this answer
2

From your question I infer that you are not doing test driven development.

The best way to switch from development to maintenance mode is with a formal customer acceptance were they agree "Yes, the software does everything that we originally requested." Of course you need an objective way to determine if the software does in fact meet the objectives, that is a formal test plan. If you write the test before writing the software, (test driven development) then this should be a natural part of the process.

You talk about "come to know of modifications required which creates a pile of extra work for us". This should be part of a written "change work order" and priced accordingly. Of course part of the work (to support the change) includes modifying the formal tests. Don't take this too lightly, many firms (government contractors come to mind) make far more on the change work orders than they do on the original contract. (what does it cost to make a grey boat - $100,000....We're half done, could you paint it white instead? Sure that will be an extra $75,000) If you are too loose about not charging for (and adjusting delivery schedules) then "feature creep" will kill you.

As for "maintenance", once again you need to clearly define terms. Strictly speaking maintenance would be limited to items spelled out in the original statement of work but which the test plan failed to test. For example suppose that the original contract called for the About Us to be done in 14 pt New Times Roman font and for some reason it was done in 13 point font and the test plan did not check to see if the correct font was used. Then six months after delivery someone discovers the error and asks you to fix this latent defect; that is maintenance. If however you use the correct font and they call up and say "You know that About Us page with the 14 pt New Times Roman? Could you make it 16 pt Helvetica instead?" - well that is not maintenance, that is a change. This is what I would label "break/fix" and I would think the client should not be charged for it.

|improve this answer
  • +1 for bringing up Work Orders/Change Orders. In many contract-focused businesses (e.g., programming, kitchen remodeling), the price is much higher for these additional requests, both to discourage them and because your costs might be higher. – Ross Patterson Dec 23 '11 at 13:16
  • 1
    Ross - thanks. Most people grossly underestimate the true costs of a "simple" change. Like the painter starts to paint the new kitchen and the housewife asks could you make that yellow a little darker? So the painter leaves to go get the paint re-tinted and comes back in an hour. Meanwhile the electrician shows up to install the outlet covers and can't because the paint isn't dry so he decides to come back tomorrow. Now the guy comes to deliver and install the electric stove and he can't because the electrician hasn't installed the cover plate.... – JonnyBoats Dec 23 '11 at 13:24
0

All these things are very subjective and are based on what your clients expectations are.

The maintenance charge seems to be in a sensible range, and matches my expectations for it - the idea isn't that you charge the client for every bit of maintenance you do, but that this charge is meant to cover your costs for providing ongoing maintenance. Obviously, the more bugs your software has, the more time you're going to spend on maintenance. As far as your clients are concerned, this is your problem.

You do need to draw the line between what counts as a new feature and what is maintenance, and the best way to do that is to have a definitive spec for each feature; if it's not in the spec, and you feel it's a significant change to current functionality, then it's a new feature. If it's existing functionality that doesn't work correctly, then it's maintenance.

That's how I draw the line, but recognise that most clients will try to push back on this wherever possible, as it will save them money!

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.