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.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work with a small team (4 developers) writing firmware and software for our custom hardware. I'm looking into better ways to organise the team and better define processes.
Our Current Setup
Developers are generally working on 2-3 projects at a time.
We have projects that work in an iterative sort of way, where a developer is in regular contact with the customer and features are slowly added and bugs fixed.
We also have projects with fixed delivery dates, and with long lead times, final hardware might appear only a few weeks before delivery. The fixed projects are usually small changes to an existing product or implementation and the work is somehow intermingled.
We are also moving from consulting to products, so we are occasionally adding features that we think will add value, at our own cost.
The Issues
We have a weekly meeting where proportions of time are allotted to each project. "Customer A wants to test feature X next week", so the required time is allotted. "Customer B is having issues with Y, could developer P drive down and take a look?", etc.
When we're busy, these plans are very loosely followed. Issues arise and lower priority stuff gets pushed back. Sometimes, priorities are not clear to developers so there is friction when priorities appear to change. The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.
I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.
Developers are generally working on 2-3 projects at a time.
Multitasking is incredibly inefficient. Switching the brain from one task to another requires time for the gears to change over.
When we're busy, these plans are very loosely followed.
Then why create plans at all?
Is it all possible to dedicate just one developer to one task / product / customer? So developer P is the only one who talks to customer B? (Certainly the developer would need to document exactly what he's doing in case he gets hit by a bus, but he should be recording issues and roadmaps anyway.)
The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.
If there had been only one developer on project Z anyway, he wouldn't have been distracted by customer A's problems.
Don't think in terms of a pool of developers serving a pool of customers, think of one developer for a given customer. (This can make vacation planning a little tougher, but if you're constantly pulling all-nighters, you aren't spending enough time away from the office anyhow.)
I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.
Aren't we all.
"Customer A wants to test feature X next week", so the required time is allotted.
Allotted by whom?
Do you create your own schedules? If not, the only response to management creating a schedule for you is all-nighters.
Realistic non-all-nighter schedules will bother management. Until you can prove that your customers want a better schedule with fewer all-nighters, there isn't much you can do.
The only way to reduce the all-nighters is to get stuff done sooner. But if the hardware doesn't arrive sooner, there isn't much you can do, is there?
Two thoughts: drive quality and improve estimates.
I work in a small software shop that produces a product. The most significant difference between us and other shops of a similar size I've worked in a is full time QA (now more than one). The value this person should bring on day one is not testing until the tests are written out. We use TestLink. There are several reasons for this approach:
Repeating tests to find regression bugs. You change something, what did it break?
Thinking through how to test functionality ahead of time - this is a cheek-by-jowl activity between developer and QA, and if it doesn't hurt, you're probably doing it wrong.
Having someone else test and validate your code is a Good Idea.
Put some structure around you estimation activity. Reuse a format, be it Excel, MS Project or something else (at least do it digitally). Do so, and you'll start to see patterns repeating around what you do building software. Generally speaking include time in your estimates for thinking about it (a.k.a. design), building, testing (QA), fixing and deployment. Also, read McConnell's book Software Estimation, use anything you think is worthwhile from it, it's a great book.
Poor quality means longer development cycles. Most effective step is QA, short of that unit tests. If it were a web app I'd also suggest something like Selenium, but you're dealing with hardware so not sure what can be done. Improving estimates means the ability to attempt forecasting when things will suck, which may not sound like much, but knowing ahead of time can be cathartic.
I suggest you follow the Scrum Framework. Create a Scrum Environment with an enterprise product. Have product Teams working on the features for their own individual products, which is a part of the combined enterprise product. If you have the resources have a production/issues support and infrastructure Scrum Team. If the issues are coming your way too quickly, have the infrastructure Team try following Kanban or Scrumban.
The Scrum Framework in itself will solve most of your problems if adopted properly.
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 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
Considering the vast amount of digitized information sitting in each department of a large organization, is it a worthy goal to refocus information systems development away from linking individual systems and start considering a single infrastructure that aspires to be flexible and extensible enough to meet all the current and future requirements of each department?
For example, sales has a CRM package but would like to integrate with a custom-built system that the legal department uses. Both refer to the product database that is managed by the engineering and business development departments. Business rules across departments abound.
This web of dependencies is messy- so I am wondering if there is any best practice in dealing with this. Is a single "system to rule them all" a practical approach?
Does this type of goal amount to a net positive for the business, or have you experienced net negative effects?
It would obviously be an iterative development process but should some pieces get rolled out without a full spec + implementation, or would it be better to run a parallel system and cut over at a certain time?
I still haven't mentioned the business requirements of the finance department... :)
I've worked on a number of these... at early stages of just trying to get all the players in the same room to actually building out something that was "agreed" upon. No matter what happens, who does it, how it comes about, etc, etc, it's painful.
The problem within an existing organization is that each group - sometimes department, sometimes product team - has developed their own tools and methods for getting the job done. No matter how inefficient or out of date it might be, it's theirs. If you can get these people willing to check out the system, that's a starting point.
The next problem you'll run into is that each team does things a bit differently, has different jargon for the same things, and wants to store/interact with the information a bit differently. While this doesn't seem like a huge thing, it is.
The complexity compounds with each and every group you add to the mix. And if you think "well, I'll start with this group and add more and more groups as I go!", it doesn't quite work that way. Once you launch it with one group (sales?), the other groups will see it as the "sales system" and be adverse to doing it.
Trust me... there are reasons why ERP-type system runs into the 10's of M's... it's not all technical, lots has to deal with the willingness to put up with this crap.
As soon as you can construct a development organization that everyone who has profit-and-loss responsibility can agree will fairly balance everyone's priorities and understand their needs at least as well as the people under their direct control do, and will allocate resources as efficiently and responsively as they can acquire them from elsewhere, then it would make sense. But I'm not holding my breath.
When you have one monolithic big-#$$ mainframe/etc, that becomes more do-able. However, in my experience, I fond that each department has its own priorities, wants and needs. Quite often, they are not compatible with each other. If you try and make these things fit together, you can never get total agreement on the end product, and probably never server your departments to the level they require.
This also leads to a secondary problem where the departments build their own ad hoc systems in secret (probably in MS Access or Excel); that you discover years down the line when the maintainer quits/retires/is_fired, and the department discovers it needs some kind of maintenance.
There's also a timing issue. You now end up with multiple departments waiting on the upgrades for another department before their can get their own. Sorry, F&A - you can't have your tax update until engineering gets their fizz-bang enhancement in, an they are 2 months behind schedule already.
I think it is saner to have multiple systems dedicated to the task at hand. If data needs to flow from one department to another; that's where glue code and interfaces come into play. Or in the worst case situation, you just add it to a humans task list. "Clerk Jane, on Monday, you are going to print report X and send it over to Dept. Y through inter office mail."
In short:
an organisation in a growing market has better things to spend it's money on than this kind of global optimisation of costs
in a stable or contracting market, it's unlikely to be financially viable unless it leads to real savings: i.e. job losses
the people who would lose their job if it succeeds almost certainly have an effective veto over it's success.
Take a look at the concept of Enterprise Architecture, for which multiple frameworks exist in order to solve exactly the issues you mention.
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.