Software Consulting Customer’s Bill of Rights

I enjoy working with a diverse set of customers in the software consulting business.  Large, small, government, private, start-up, publicly-traded, etc.  Working with this diverse set of customers has given me the opportunity to see different worldviews at work.  Different sets of assumptions cause me to work differently with different customers.  One thing is the same, however.  Customers want me to help them alleviate pain.  If there was no pain, they wouldn’t be a customer.  Regarding custom software, customers buy for two reasons:  Pleasure, and Pain Reduction.

Buying for pleasure:  In this case, a company is doing well, but management has a strong drive for excellence.  They reach out for that extra bit of help to get them operating at the next level.   This reason for buying is not as common as the next.

Buying for pain reduction:  Pain is a powerful force.  Just like in the physical form, it can  surpass other causes for action.  Here, a customer might be losing market share because they can’t react to the marketplace.  With our coaching business, the internal development organization might not be moving as quickly as management requires in order to keep up with the market or launch new products.  Most of the time, management knows that they are frustrated but can’t identify the specific causes.

When customers come to Headspring, all they know to expect is what they have experienced in the past.  For instance, if other software venders have delivered low quality deliverables, they will be conditioned to negotiate regarding defects up front.  If they have had to wait for months for releases of the software product, they will want to focus on schedule of delivery because they are keen on avoiding similar pain in the upcoming project.  Different customers come to the table with different experiences.  All in all, customers don’t know what is reasonable to expect because there are no widely accepted standards around this. 

Here, I present a rough draft of a Customer’s Bill of Rights when working with software consulting companies.  I will focus on rights when a customer is buying a custom software implementation.  Please feel free to comment on the individual rights, but I am a very strong advocate for the customer.  In my opinion, the customer is going to drive improvement in the software industry.  The more the customer demands, the more we will be forced to deliver for them. . . the more software professionals will be forced to improve.

A Software Consulting Customer’s Bill of Rights

  • A customer has the right to know and interact with the people building the software in question.  The vendor should not hide the software team behind a local front man.
  • A customer has the right to the source code he is paying for.  The vendor should not leverage control over the source code as a negotiation point.
  • A customer has the right to working software on a consistent basis throughout the project.  The vendor should not deliver a written status report in lieu of working software
  • A customer has the right to high quality software at all times.  During feature development, existing feature should continue working.  Calling a screen with ten defects a “feature” is not acceptable.  The vender should do whatever it takes to maintain defect-free software every step of the way.
  • A customer has the right to know relative costs of possible alternatives and make the decision among them.  The vendor should present alternatives when less expensive courses of action exist.  Doing nothing is always an option.
  • A customer has the right to a software demo at any time.  The last good build should always be available for evaluation.
  • A customer has the right to frequent builds.  During active development, this would typically be several times per day.
  • A customer has the right to be challenged.  If a customer gets exactly what was asked, but it does not solve the problem, the customer still has nothing.  The customer should expect the vendor to challenge assumptions when the requested solution will not solve the target problem.
  • A customer has the right to an estimate for how long the software in question will live.  The customer typically has life expectancy assumptions.  This should be discussed opening.  A customer should not have to accept a software rewrite without planning for it.
  • A customer has the right to be materially involved with the project every step of the way.  He should not be forced to go away and way for a long period of time before seeing some results of the project.

I welcome discussion around these and proposals for more.  This might seem like I have jumped to the other side of the fence since I’m in the business  of delivering software.  I feel it is in my best interest for software customers everywhere to begin expecting more from software providers.   This is how the software industry as a whole will improve.