Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
The context is as follows: Enterprise software developed without enough direct customer involvement. We did not develop this software for a particular customer but to fill in a market gap. We worked the core requirements with major customers only, more customers jump on now. Mandated deadlines, requirements changing, little time to design. Fun time! :)
We got the first release out of the door. Then we got second release out of the door (luckily in a more organized fashion)
Most problems that the sustaining engineering is facing for both releases are what they call 'design bugs' rather than good old code defects.
In general these 'design bugs' are such that a feature or part of a feature behaves as designed but that behavior is not what some customers want the product to do. It is not that all customers have these problems - each customer is different and what is enough for one is not for the other.
This makes me wonder about several things and I could really use an insight from y'all with more experience.
Here are some esoteric questions:
How much do you think is this a common phenomenon in product lifetime?
How much do you think did the context contribute to this?
What is/was your experience and context?
This is absolutely common that needs differ from client to client and that they want to drive the product in different directions.
There are three options for any given change:
1) You don't do it - they've bought product software, they have to live with the product. I wish Word did somethings different but I paid a couple of hundred pounds for it rather than having a bespoke word processor built from scratch so I have to live with it.
2) You branch the product and have two different versions - as often as not this is the worst thing to do. As a software house your model is dependent on many clients contributing to a common code base. Having multiple versions significantly increases costs (every bug fixed twice, two manuals, etc. etc.) and breaks your business model. Again, if they want bespoke software built exactly to their requirements then they need to pay for that - you don't get bespoke software at package prices.
3) Customisation (potentially as an option / module / configurable setting) - this can work but you really need to think about whether it's the right thing to do for your product. Each extra options massively increases the number of ways in which the code can interact and the number of tests which have to be carried out so there is a significant cost attached. In the enterprise space you will have to accept that clients will make demands in this area but you need to accurately assess the consequences and costs (one off during development and on-going for support) and make sales and management aware of them.
But essentially they all come down to the same thing - product software, even on the enterprise level, is far far cheaper than having an in-house team (or consultancy) build something bespoke. That price advantage comes with a downside - it's that you don't get exactly what you want and that the business needs to flex to the software sometimes.
It's not usually a popular message with clients or with sales but you need to work out which market you're in (product or bespoke) and remember that when making decisions.
In terms of the other two bits of the question - I don't believe the context created it at all. The root of it is that organisations are different. Unless you have all your clients the same, it was always going to be a problem at some point. Maybe it's a bit worse than it might have been but probably less than you think.
My experience in this area: I've been on both sides of the fence. I've been a development and / or project manager commissioning enterprise (and non-enterprise) third party software products (portals, finance systems and travel booking systems) and I've worked for two software houses developing them as a development manager (which is currently what I do).
Enterprise software developed without
enough direct customer involvement
in such cases, this will be a common phenomenon in product lifetime. If the customer is not involved and you don't know what and how he wants things, you'll be up for quite a bit of disappointment when you deliver the product and you find out his reaction.
How much do you think did the context
contribute to this?
I think it's the main cause.
What is/was your experience and
context?
Similar context, up until about half-way across a project's development period, when delivering an intermediary product, I found out that many of the customer's expectations were quite different than what I had in mind. I guess it was a good idea to send something intermediary for approval, this way I had much less to modify than if I were to send a final product that would not meet customer expectations, so I suggest you keep a connection with the customer from time to time, and get him to approve features before you move on to new ones. This way, when the final product is ready, it'll be what the customer has seen and approved step by step all along.
It depends how long-lived the product is: the longer the life-time, the more evolution is possible and/or required.
For example I helped to sustain one software product from 1991 to 2003; and at the end, it was hardly anything like at the beginning:
It started as an assembly TSR for DOS, implementing modem-sharing for small (e.g. lawyers') PC-LANs.
It ended as a distributed service for NT, implementing least-cost fax routing for several telcos.
It was sold throughout this time, several releases per year; it was what customer wanted, but the customers (and their needs) changed over time, as did the underlying O/S, the competition, etc.
This is why you create API's. I've also seen enterprise level applications that allow users to create their own vb/java scripts behind forms and inside reporting tools. Yes, embed a reporting tool writer and don't try to make all of them yourself.
Enterprises are notorious for their desire to have massive amounts of features in every app. Even within the same company, you can get multiple ways of doing the same thing. I their defense, time is money, so when you save a 1000 users a click, it can add up. On the other hand, they also have people with too much time on their hands to think of every possible piece of data they may ever have to track in the entire lifetime of their company and will want them all in your app. They have the money and are set in their ways a lot longer than say a startup.
When you deliver something the customer did not want, you have failed with requirements engineering. Since this is the first stage of software development, and design, coding and testing are based upon it, bugs in the requirements are the most difficult and costly to fix.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm building a shareware software that allows users to import various types of files (XML, CSV, etc.) into a database. I'd like to provide a trial version, but limit it in some way to prevent users that really need it, from not having to buy it ever.
I considered time based limit, but it seems that there are so many ways to work around that, especially today with virtual machines and stuff.
So, I'm thinking to limit the functionality, but I don't want this trial version to become crippleware.
Have you ever bought some shareware software? What was limitation of its trial version?
edit: Also, how do you feel about nag-screens as a user?
Look at this blog post, it's a survey made by Andy Brice on small software vendors. Here you can find the trial types and its % of use.
http://successfulsoftware.net/2009/04/23/the-truth-about-conversion-ratios-for-software/
I recommend you the Business Of Software Forum:
http://discuss.joelonsoftware.com/default.asp?biz
Regular posters there seem to agree that you don't have to think too much about piracy. People who won't buy won't buy anyway and complicated copy protection schemes run the risk of bothering the honest customers.
This is an excellent post by Patrick McKenzie about this issue:
http://www.kalzumeus.com/2006/09/05/everything-you-need-to-know-about-registration-systems/
Limit to number of uses is the fairest way.
As for stopping circumvention... Anyone who wants to crack your software will, and most people are too lazy to circumvent anything but the most trivial usage.
I'd argue that you want to get those people who regularly use your software to happily pay for it. They're most likely to happily pay for it if they've used it a non-trivial number of times.
b.t.w. Beyond compare has a system where you can use the software for 30 non-consecutive days. i.e. If you use it one day, and then use it 2 weeks later, then this will only count as two days. I've never been so happy to pay for software than when I paid for Beyond Compare.
Many people will only need this tool once in a lifetime for an import of some data.
So you will definitely have to go to a limited version instead of a time version.
It is common for software during the trial period to lack (or limit) some significant feature, such as printing or saving. I've tried (and bought) a panorama assembly tool that put a large watermark across the finished image. It allowed the quality of the tool to be evaluated, but put a real limit on further use of the images created during the evaluation period.
I've shipped a trial version of a commercial product that allowed all features to be used with limits generous enough to run through all of the tutorials in the user manual, but did not permit saving your work. We know that many users were able to quickly determine whether the tool would work for them by constructing tests with their own data, and it generated more than enough sales to justify the added development work to create the demo version.
The trick in your case will be to find a way to limit the functionality without eliminating the key utility of a trial period: actually trying out the software.
Perhaps limiting the number of records that can be converted in one run would do the trick?
I would definitely go with a time-based limit. As you mentioned, this usually is fairly easy to circumvent, but I promise you that if your software has a large enough user-base, cracks will be around in no time anyway. Thus there IMHO is no point in making it hard/impossible to pass by your software's time limit.
Any other limitations (such as annoying pop-ups or limited functionality) would definitely be a show-stopper for me. If I cannot evaluate the software properly, it has to be very good to make me consider buying it.
Please do not fall into the trap of limiting anything about the trial version other than time or number of uses. Reducing functionality and/or having annoying popups saying "This is a Pro feature" will simply alienate your users. Besides, the trial period is a chance for you to impress potential buyers, so you should showcase all of the features rather than hide them.
This is a marketing decision and the answer to any marketing decision is always "it depends...". For example it doesn't make much sense (commercially) to have a 30 day time limit on software that most users will probably only use once (e.g. harddisk recovery).
There are some issues association with time-limited trials:
A user might use it once and then not get chance to complete the trial
before the 30 days is up.
Time limitations are easy to work around, e.g. using VMs, registry
hacks, additionalmachines or
resetting the system clock.
Longer sales cycle - most customers will only buy on day 31.
Some of these are avoided if you go for a limited number of uses.
The main issue with feature limited trials is that the customer might not feel they can fully evaluate the system. But this isn't too much of a problem if you have a good money-back guarantee (and you should).
As a vendor I prefer feature limited trials in most cases. You can be quite creative in how you cripple the trial (watermarking, limited number of records input or output etc).
I just wanted to add that this is a strangely biased group. As programmers we want to be able to see all of the features, and play with them, etc. We get annoyed by certain limitations, and ads, etc.
However, normal people seem to react to these things differently. I'm just saying that we aren't really the target market here, probably.
ALSO, we should note that most people aren't nearly as good as we are at circumventing these things, so as has been mentioned, something pretty dumb is probably ok...
We have one product with a free - limited version, and a pro version, and another product with a 2 week free trial. Actually the free version also had a 2 week free trial of the pro, so it was sort of both...
All in all, I think it depends on the product and the people using it...
Limited number of uses
Ads
Splash screens that make you wait X seconds before it goes away
Not all functionality is available
Demo limited to a single database
Closing the gap was a very enlightening read when Eric first posted it, I believe it is equally relevant today.
You could limit the size of the import file supported. Or the number of uses. Or if insertion speed is a critical factor you could start out at full speed and then after 30 days add some delay (but be sure to tell your users this is intentional).
BTW, one of the worst schemes was in the Ingres database for Sun workstations 20-odd years ago. If you entered the wrong license key, Ingres silently enabled a dozen serious query processing errors. After playing with it for an afternoon, I told the salesman that his product was ridiculously buggy and that we'd be going with a competitor. He quickly told me what the issue was, but by then the sale was all but lost.
You can limit the number of times the users can use the functionality within a given time period; say they can use it 8 times in a month, before it throws up a "nag screen" when they use it. And if they need to use it more than, say, 20 times in a month, insist that they buy the software. If you do this, you may want to provide a certain number of keys for charitable purposes or educational purposes as well; it helps users to buy the software when they know that there are some charitable purposes their money is going to pay for.
I've purchased plenty of shareware but always tend to be annoyed when it disables certain features. I prefer to check all features before I make a purchase.
I do like the limitations that Altova add to their software. You always need a registration key to use their software and to get one, you have to provide your email address to which they will send you your temporary key. You can then use their software for up to a month and then you'll need a new key. Some people will just continue to request a new temporary license but most users will sooner or later purchase a permanent key.
The Altova software does make a "call home" to validate the key it uses. It does this to restrict the number of users that can use the software. I can install their product on as many computers as I like, but at any moment, I can only use it on a single computer. If I try to use the software on two or more systems at the same time, the software will discover this multiple usage and thus block my access to the application.
Still, I do know that many people are willing to pay for your software if it's good enough. Especially if you can provide some additional services next to the software itself. (E.g. regular updates or subscriptions to additional data feeds.)
No, I have never bought limited trial versions. However, I have donated to a couple of open source projects. If this were a software for people, instead of companies I would recommend a donation system.
This software sounds like a work-related app, so:
constant reminder, like Foxit
just 2 file formats
app married to a single database
Since this is a software to import data in a database, you could also add rows to the database indicating that the importation was made with a shareware version.
Just annoying enough (rows are still deletable), but you get most of the functionnalities.
How about keeping all the functionality in but randomly re-arranging the menu/buttons in the non-paid version ;)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
How do you cope with that?
Is it normal to allow the costumer to change the software as often as he wants? I´m working in a environment where there are no specs and constant requests for changes.
For every new costumer we have to create a new branch and makes so many changes that by the time I finish I have a complete different product. I´m pretty much losing my interest in programing because of that.
So, am I wrong to say that the costumer should not be allowed to change the software at his will?
English is my second language, so please excuse any mistake.
Related:
How to deal with poorly informed customer choices
EDIT: I originally missed the part that you have many customers and are customizing a single piece of software for each. I'll leave my original answer for reference, but it's not really applicable to this particular situation.
In your case, I would suggest that you need a different tack to addressing customer concerns. One technique I have seen used is that any changes need to be consistent with making the product more useful for all customers. This would mean that you can say yes to many changes. For example, making the UI customizable via templates. That would benefit all customers, but may be driven by a particular customer's desire to fit the look-and-feel into their standard. But it would also mean that you need to say no to some requests, or modify them in a way that they are generalized to be useful to all.
You may also want to have your customers use something like UserVoice to make feature (and bug) requests and vote on them. This allows your customers to have some direct input into the direction of the product, but forces the requests to be filtered through all of them. Again, you need not always accept the highest rated requests and you can accept some lower rated requests. The guiding principle ought to be making your product useful to the widest range of customers.
I don't think that it's practical to have a separate, custom branch for each customer unless you plan to have only a limited number of very high-paying customers. Eventually, your version control system will become your bottleneck and not allow your company to grow or even serve your current customers well.
Once you get into a more sustainable feature selection mode, my original answer may still apply. Hope this helps.
Original
I'll say up front that some customers are just not worth having. Only you can tell when this is the case.
Typically, though, it's our job to discover what the customer actually needs and deliver that. I'd recommend following an agile development methodology to do this. Rarely does a customer actually know up front exactly what he needs. Even more rarely does a developer understand what a customer needs before they start writing code. Agile methods embrace this reality and follow practices that make change less damaging to the process.
First, agile methods employ lightweight processes and delays making decisions until the latest possible moment. There is "just enough" up front planning to lay out a basic architectural framework, but for the most part it is design-as-you-go. This is not as freewheeling as it sounds as the techniques used in agile methods, such as TDD, pair programming, refactoring, etc. are sound techniques that encourage good design and design improvement.
Second, agile methods are light on documentation. While not documentation-free, these methods keep document maintenance to a minimum. One of the worst aspects of change is that documentation becomes dated and must be constantly updated to be correct. Agile methods identifies those documents that are truly useful and maintains those, but other documents that become out of date can be discarded. They are used in the moment as needed, but you are not tied to them. Agile methods put a premium on the code, and tests, being self-documenting.
Third, agile methods encourage a cooperative form of development based on mutual trust. This goes both ways. The customer must trust that you have their best interests in mind, while you must trust that the customer knows or, at least, can recognize what he needs when he sees it.
Lastly, the hallmark of agility is release early, release often. Getting the product in the customer's hands early is the best way to get feedback (again, early) on what he really needs. Once you have a concrete product you'll start getting information on the changes that really matter. By planning to release early and often, and coupling it with other agile practices, you'll also build a framework into which change can fit more easily.
Even when following these methods, though, as I said earlier: some customers are not worth having. If your customer doesn't trust you enough to follow your advice when a change is bad or if the customer doesn't know and can't recognize what he truly wants, then there may come a time to sever your ties with them. I'd suggest that talking with them and letting them know that you want to get them what they need, but they need to know what that is. Spend some time talking about it so that you both have a better understanding of the goal and put into place agile methods to deal with the reality of change. If they are still unreasonable, then perhaps it's not going to be a good fit for you.
am I wrong to say that the costumer
should not be allowed to change the
software at his will?
Who owns the software? You or them?
If I own a house, I can hire someone to paint it in a different color every week if I want to. If the painter complains, I can get a new painter. If I run out of money, maybe it is because I am an idiot. But the painter did nothing wrong in painting my house, getting my money and using it to feed his family.
If I own a certain software, I am allowed to do whatever I want with it. And if you don't do it, then I'll ask someone else.
specing out the app is as important (more even) then implementation. Giving the customer at least a base line document, UI mock up or something like that i think is critical.
you have to accept change requests as the system evolves and matures, otherwise the system will suffer from entropy and any hard work you have put in will be lost forever. if it is a more commercial product try and restrict to changes that all your customers want. then everyone is getting added value.
If you have baseline documentation you can then charge for customization. the less you want to do the customization the more you charge :P make sure you document and estimate all the change requests. (i use fogbugz for this but there are many other tools out there) If the customer is paying for the changes then at tleat you will be getting renumerated for the pain of changing the system.
Your company is running itself hopelessly into the ground.
You should go job-hunting immediately.
before i put forward my suggestion, i should say i personally believe that a business is there to make money. so if a client is willing to pay for something they want, figure out how to accommodate them (rather then turn them away).
now, a solution:
i was at a company where they had a software package which they sold to many government organisations - each with their own particular tweaks and features.
i asked the managing director how they avoid version hell - considering they have to maintain a specific version for each client. he said "we dont, everyone gets the same version". they simply maintain one version for all clients, but switch off features which arent specific to a client.
LM
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Suppose you're the product manager for an internal enterprise web application that has 2000 users and 7 developers. You have a list of 350 future features, each ranging from 5 to 150 developer days of work.
How do you choose what features to work on, and how do you run the release process?
Here's what I'm thinking: (skip if boring)
Release Process. Work on several features at once, release each individually when it's ready. The other option (what we've been doing up to this point) is to pick out a certain set of features, designate them as "a release", and release them all at once (announcing via mass email).
The advantage of a shorter release process is that we can release features as soon as we finish development. The advantage of a bigger process is that it's easier to organize.
Feature Prioritization. Put all the future features in a spreadsheet with columns for feature, description, comments, estimate, benefit, (your) estimate, (your) benefit. Give copies to 2 senior engineers, the other senior project manager and yourself.
The engineers estimate all the features (how precisely? consulting each other?). To determine benefit, everyone allocates points (total = 10 * [number of future features]) among the future features (without consulting each other?), compare scores and average (?).
Another potential strategy here is to just rank each feature on an absolute (say) 1-100 scale. Having an absolute ranking is nice because it makes prioritizing as our feature list changes easier (we don't want to have to redistribute points every time someone proposes a new feature).
What's your strategy? Do any books / websites attack the problem at this level of detail?
There's a great book that helps cover this topic called Agile Estimating and Planning by Mike Cohn. It has some great ways to estimate and plan releases. Including a planning game called planning poker where the engineering team gets together with cards to estaimate user stories. Each engineer plays a card 1,2,3,5,8,13 face down. The high and low card explains and you do it again. After 1 or 2 repeats there is generally convergence on the same estimate.
There's also Beyond Software Architecture: Creating and Sustaining Winning Solutions by Luke Hohmann which might help with some of the product management related pieces and the reasoning to use to prioritization. I have not yet read the book but I went to a talk by Luke Hohmann where he covered the subjects of his book and I can't wait to read it.
Also I would recommend reading books on various Agile Development processes such as Scrum, Crystal Clear, and XP. There's Agile Project Management with Scrum by Ken Schwaber and Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. Also Extreme Programming Explained: Embrace Change (2nd Edition) by Kent Beck and Cynthia Andres.
As for feature prioritization, that is generally done by the stakeholders. You need to work on the features that address the needs of your stakeholders, which, as Luke Hohmann points out, includes the system architecture.
However, one of the most important things is to make sure that you have agreement on the software development process from the team. If you force a process and the team doesn't believe in, then it will not work.
Surely you don't have 350 independent features, some must depend on others.
Put them all into some task management software which allows you to define which tasks depend on which other ones, and you might soon find that you've got a much easier decision process...
As for the release process, you could introduce the features when they are ready and inform the users via a company blog that is updated whenever a new feature is done. Such a blog entry should then give a short overview about the feature, where to find it, how to use it, etc.
Not only does this keep your users curious and coming back, it also offers a great way of potential customers to check out the progress of your offering.
As for prioritizing future implementation: how about involving the customers there as well? Look at uservoice (it is used to track requests/bugs for this site). It offers a nice way of letting the users vote on most desired things as well as showing what is being worked on and what is planned.
"rank each feature on an absolute (say) 1-100 scale"
Build them in order.
Release them when you've got (a) significant value or (b) critical mass of small things.
Always work in priority order. Build the most important stuff first. Deliver as much value as quickly as possible.
a few people here have already said it - involve the end users in the decision process of what goes in and what waits. after all, its not about whats useful to you, but whats useful to your end user.
that said, i wouldnt leave it open to 'all users to decide'; there should be a representative from the user group who you work with (i.e. senior user role).
even then, you arent saying "what features do you want?" to the user, you ask them what functionality they would like to see arrive next. the reason why you put it to them that way rather then letting them pick off a massive spreadsheet of individual features is two-fold: 1) they dont know about dependancies, 2) you want to gather together a pack of features for a logical release.
so the user representative may say "we need to have the photo gallery working next". they might not be aware that the photo galery is practically the same as the file upload module (it just accepts different file types).
so, in the next release version, you pack together the photo gallery and the file upload - why wouldnt you, considering that the file upload is like 75% done because of the work that went into the photo gallery module?
i dont believe you necessarily have to work on the hardest features first, its what the users need sooner + what other features you gather together to make a 'logical pack'.
to a certain extent, you want to clear the feature log too. so for example, you could have the following features and estimaed times:
Registration Form - 3 hrs
Photo Gallery - 8 hrs (<- client has said they want this next)
File Upload - 2 hrs
Voting/Poll module - 7 hrs
Stock Ticker - 5 hrs
out of these contrived features, i would take no. 2 (because the client is asking for it), then i would take no. 1 and 3. no. 3 because its practically done when the gallery code has been done, and no. 1 purely because its the smallest estimate out of the remaining features. nothing will give you or your coding crew the feeling of progress on your project like seriously beating down the feature list (it will probably refill though).
as far as letting people know about a new release and whats in it, i would do it via email (rather then by blog or within the program itself). and i would make it as brief as possible, bullet points, something like this:
===
Version 1.1 of Blue Widgets has just been launched and is available for your use now.
The following has been added:
Photo Gallery
File Upload
Registration Form
The user manual within the system contains more information on how these features work.
===
bang - done, make it as easy for people as possible.
LM
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I currently work for a bespoke software agency. Does anyone have any experience of how to win well priced work?
It seems there is so much competition from offshore/bedroom programming teams, that cost is extremely competetive these days. I feel that it is very different compared to a software product company or an internal IT department in terms of budget.
As someone else said before, we only ever really get to version 1.0 of a lot of our software, unless the client is big enough. In this case it doesn't make business sense to spend ages making the software the best we can. It's like we are doing the same quality of work as internal IT staff. Also a lot of our clients are not technically minded and so therefore will not pay for things they don't understand.
As our company does not have the money to turn down work it often goes that we take on complicated work for far too little money. I have gotten a lot better at managing change and keeping tight specs, etc. It is still hard.
Edit-----------------------
Almost 3 years on from this post and I can list some important lessons that I have learnt since then.
Please see below for my answer
If you are concerned with doing too much work for too little money then work on an hourly basis. Yes, that is harder to sell in most situations.
Maybe you can try a two-phased approach instead. Have a very short initial engagement where the deliverables are very specific requirements documents that become the property of the client. You risk having to compete for the actual development but you take away the risk of pricing the project too low because you will already understand what the client is like to work with, as well as, the application requirements.
Once you win the work at a fair price then use the best practices suggested by mathieu to help ensure quality and productivity which both lower the cost you incur.
What you described in your post, (not your question), I think is a sales, management and marketing question first and foremost.
You say that your clients are not technically minded, this will require to have a cohesive sales, consulting and communications strategy, this isn't about programming skills.
Also, if your company constantly accepts projects that are too complex or expensive for your team, and you deliver low quality products you'll sooner or later be stuck in a hole. You will attract customers that you do not want, and existing clients will be turned off by your 'incompetence' and sooner or later find another company on which they'll try to play the same price game. Those clients are worth nothing in my opinion.
You ask 'how do you win well priced work'? People are social animals, they talk with each other. If there's a market perception that you are an unreliable company, people and future clients will sooner or later know. Customers don't care whether you offered them a product at a really low price, on a too tight schedule - It's not really their error, it's you who accepted it. So once again, I think whole ordeal is a bad business practice.
I found that you really have to define tight specs on jobs with low budgets, define what you will and can deliver, tell them the price, stop your boss from offering too many long term customer discount price tags because they are too afraid to lose the client. Communicate early and often when things start to get out of hand. Write precise offers for additional features. Write these precisely down, don't rely on phone conversations (you: "that's an additional 4 hours of work", client: "ok"... 4 months later, client "what was that again??? why am i supposed to pay for this").
Now of course, one way you keep prices down is by not hiring complete morons that might be initially cheaper than better qualified programmers. This is a shortsighted approach and will fail miserably.
It is the relationship with your customer that will win you additional business. One developer actually stepped forward and halted a project because his sales consultant basically lied to us concerning a solution set. The developer then offered a straight forward, bare bones solution within the same budget and he delivered on time.
This guy and his team has been consulting at my company now for over 6 years. His integrity and earnest, hard working nature has been an immense advantage, and he has found quality people to work for him as his reputation has grown. His honesty is worth more than any savings I could get by shipping my company's intellectual assets overseas.
"so much competition from offshore/bedroom program teams" - sounds like you guys need to put some time into networking. At the end of the day, people like to do business with people, not with businesses. If you're well known and liked in your client communities, you'll be the front-runners and you'll get a better price from the confidence you have built. And referrals will give you a powerful edge - ask for them.
"our company does not have the money to turn down work" - lot's of companies have this as a start point, but ultimately you have to get past this approach The time you spend on these types of jobs stands in the way of being successful. You need to make decisions about what type of work you want to do (and who the customers will be) and just as importantly what you don't do.
As a consultant, I have personally moved to an hourly-rate-only model for just this reason. I have been burned by too many contracts-gone-wild, and I feel your pain.
In the end, people who only ever go with the lowest priced proposal will be trouble for your company. While you can't be so choosy, such that you don't ever get projects, you definitely want to steer clear of contracts whose supporting management are so agnostic about the actual software development process that they only look at the initial price tag for something. Usually, it's the stuff not in the contract or specification that changes the profit margins and timelines.
It's often in you best interest to be picky up front rather than lowering prices in order to receive a wave of what end up to be trouble-clients anyway. In your case, while there's always the contention between an RFP that is not as concise as a technical requirements specification, initial quotes should be understood as a general estimate based on the level of clarity in the RFP.
And I definitely agree kitsune, that if your company is consistently accepting contracts that don't fit your company's development expertise or bandwidth, all that will result is overhead and bad reputation.
This could be seen as quick guide to the above problem.
Proposal Document
Start with a proposal document that explains your understanding of the clients needs as best as possible. This can be done in 1-2 pages of writing as a minimum. It can start heading towards requirements, but it should be more casual than that.
Budget Document
Now go to Excel and list all the tasks in the project you think you will have to do. Put down the times in days, none bigger than 2 (0.25, 0.5, etc.).
Add a column for testing, and make it a percentage of the development time (20-30% is normal)
Now add a column for management (project + account) and add a % of time for that (over the previous two columns). 20-40% is normal. (70-30 split pm/am)
Set a day rate for your company. You can get more complex and have different rates for different user functions, but as a minimum set a rate that will mean that you will have a good margin whatever the work is being performed.
Work out what the value is for the total days that has been recorded so far. Then add a contingency amount on top of this (for fixed price work) 10-20% is normal here, but can change based on experience with the client and the amount of change you are used to with them.
At this point you can discount the total amount, which is better than lowering any other part of this document, as it will show the client that you are not magically making jobs go faster, rather you are removing some of your margin. They should therefore not expect you to reduce the timeframe of the project.
**Important - Analyze your client's budget and business when developing a costing. There is no point in you delivering a costing designed for a huge enterprise to your mate who wants an application done cost effectively. Likewise, make sure that you charge correctly to an organisation that will be used to high end freelancer rates.
Think like a business analyst. Not only will it help you make the client happy when they see your costs, but it will probably give you a greater insight into their business. If they are going to make money by using you, then you are probably onto a winner. If you can't ask directly how much money they have to spend with you, work it out by asking how many customers they have, what they charge, how many employees they have, etc. You should then be able to work out if what you are proposing is going to be profitable for them.**
Go back to your proposal document, and add a table with sections for design, development, management, etc... You could show the client your costing sheet in certain circumstances, but it is better to avoid complexity in most cases. It's there as a backup though, and you didn't just cough up a number.
Timeline Document
Take the list of design and development tasks from the budget, and put it into a new sheet (or Project if you're posh like me). Put in the start and end dates of each section adding roughly 30-50% extra on top.
Add some graphical representation of the days as blocks in Excel or use a Gantt template like this one.
Go back to your proposal document and add key milestones from the timing document.
Proposal stage completed
Send or present your proposal to your prospective client. Hopefully they are excited with what you have proposed and happy to proceed to the next stage, full requirements gathering. In subsequent projects with the same client you may be able to go straight to requirements.
Requirements stage
List each requirement against a separate id, either 1,2,4,5 or 1.1,1.2,1.3. It doesn't really matter, but the second one can help with large lists.
There are some tests for requirements and you can try to follow these, but sometimes they don't apply (some requirements might be design led for example). Some of these are: Is the requirement testable, is it singular, is it clear? I'll try to find a link to this somewhere.
This is my developer standpoint:
Version control best practices: Keep the trunk clean, don't commit code that doesn't compile, and commit frequently
Continuous integration
Unit testing (with code coverage)
Automatic deployment on test servers
Automatic packaging of the application
Automate as much as you can :)
Also, hire good developers, and treat them well :)
Sell fixed price, fixed scope work, not hourly work. That mitigates your customer's risk of an over-run (you absorb all the risk, but you're doing that anyway), and frames the project in terms of the value of the software, not the quality of the effort going into it.
We are trying to build a product and reuse existing experience. Comparing to UK in Ukraine (where I work) salaries are lower, but still 4-5 times higher than in India.
So far, the best result is to get two new clients, which need a similar solution, so we can offer better pricing and we are more confident in our estimate.
BTW, I checked out whywaitdigital.com, and it seems that we have a product which your clients might need. We do portals - editorial, B2C, geo-enabled product catalogs and we use ASP.NET MVC also. You can find contact information on our website, www.socialtalents.com.