Good, Fast, or Cheap – Pick any two!

Those in the IT business understand the relationship of “Good, Fast, or Cheap – Pick any two!”  This is not something you hear from sales folks, but you hear it often from developers either when discussing internal projects or contracted developments.  I was reminded of this by one of my readers who thought I had lost my roots in serious software development!

I realize that what I have been describing in this blog is underscoring what you can do for relatively little money and expertise as you implement association software.  My intention has been to emphasize how different the world is now than it was five or ten years ago.

On the other hand, “Good, Fast, or Cheap” is still an important concept to understand particularly when you are purchasing commercial software and even more so when you request customized versions of that software or even when you just consider the implementation phase of that software.

Naturally, associations want to keep the cost down while vendors want to keep the profit up.  Unfortunately, the trade-offs are not well-known up front leading to surprised associations when the actual cost and actual time frame evolves.  What makes it particularly difficult is that you don’t necessarily know this until you are so far into the implementation that you will feel it too difficult, perhaps embarrassing, to turn back the clock and do something else.  Buyer beware!

  • “Fast and Cheap” loses “Good”.  “Fast” means you will lose on the care of design, programming, testing, and implementation.  “Cheap” means that the job is done with as little vendor effort as possible.  Everyone loses with this combination.
  •  “Fast and Good” loses “Cheap”.   “Good” can only be achieved by an army of vendor staff at premium prices.   The problem is that “Fast” has the same issues as before.  Costly doesn’t always lead to the best implementation.  “Fast” also puts the most pressure on your own staff.
  •  “Good and Cheap” loses “Fast”.  This doesn’t sound too bad except it means that you are at the bottom of the list of a vendor’s priorities and will get time when they have it available which then translates to a very late go-live date and potentially uncoordinated work by ever-changing vendor staffing.Vendors never have sufficient staff to do what they need to do by a specific time.  It just isn’t cost effective to staff for the busy times and leave them idle when times are slow.  If the pressure isn’t on to complete a contract, the vendor will favor the contract that needs to go live next.  The time frame of your implementation will slip.

None of these sound good, do they?  Seems like you lose no matter what you do.  What you need to achieve is good informed balance.

So, how do you successfully implement a large association software system?  This is where consultants, particularly those with development backgrounds, can be helpful.  Think about the following recommendations:

  1. Know exactly what you are paying for before you sign a contract.  Unknowns become very expensive.  Time-and-materials is exactly what every vendor wants and in many cases needs just to ensure a profitable implementation.  At the same time, it is cheaper than their quoted “fixed price”.  If you can be comfortable with time-and-materials it will cost you less but to do this you need to know exactly what is being done.  The more detail you have on what you need to do and how, the easier it is for the vendor to price your needs and for you to get the best overall price.If you are purchasing modifications or entirely new functionality, insist on at least high level design documents for these changes so you know what is going to be done.  Don’t sign time-and-materials contracts without this.
  2. Plan, plan, plan in excruciating detail from contract signing to final go live date.  Who is going to do what and when both for the vendor and client?  What will the deliverables be and when?  What are the criteria for acceptance?  What should happen if either party doesn’t perform according to the contract?
  3. To the extent possible, use the base software rather than modify it to match your own processes.  Yes, I know, everyone says they are going to do this but I have seldom found it to play out in reality.  Change-orders after the contract mean higher cost at a time you can’t easily negotiate.Most associations don’t need to do everything they currently do in the way they do it.  Their processes have been established and tweaked for years in ways that may be more influenced by their old software than what they really need to do with new software.  Get you staff’s buy-in to new processes prior to contract signing.
  4. Understand what the base software will actually do before you sign a contract.  Don’t just accept what the sales people say.  You need to try an entire process from start to finish before you accept that something is real.Sales people don’t want to raise issues during demonstrations even if they recognize that they exist.  Issues raise doubts.  Doubts are bad for sales.  A screen may look good but is there any real logic processing behind it?  Do not assume anything.  It is easy to provide a screen that says something that looks familiar to you but doesn’t actually do anything.  Your responsibility needs to include teasing out all the details involved in your own processes.  Then you need to compare them to the actual software.  Don’t just accept “Yes, it will do that.”  You need to actually see the process from start to finish!
  5. Plan adequate staff time for the implementation especially for training, testing, and final implementation.  Few associations have the staff to do both their full-time jobs and what needs to be done to implement a new enterprise system.  It takes a lot of your staff’s time to be successful and support for this needs to come from the top.  Don’t just make assumptions that you can just work this in.
  6. Be realistic during negotiations.  Try to understand the amount of time you are contracting for and use your consultants to do a sanity check on this.  Understand that it always takes more time than you expect but consultants often have a good sense of what is reasonable.Understand that if you force a negotiation to reduce the price, you are apt to get less vendor time and effort.  After all, though you will be told you are the most important client they have, the vendor will still need to make a profit on your business.
  7. Finally, do as much as you can prior to contract signing.  Once the contract is signed, you will have lots less influence and power than before the contract is signed.  Sad but true!

So, what do you think?  Does anyone have good examples to share?

4 thoughts on “Good, Fast, or Cheap – Pick any two!

  1. In my shop, “Fast” is bad no matter what you pair it with. Our release schedules are impossible but we are reviewed and therefore rewarded for pushing the software out on time. We programmers are rewarded for getting code out “fast” rather than for code that has been well tested. Then later, we get rewarded for how fast and how many bugs we fix but again “Fast” rules. Fixing bugs fast is considered good, i.e. how many did you fix today. To fix them fast, we have to put band-aids on things to mask the symptom because we don’t have time to do the necessary surgery to fix the real problem. Our programmers do exactly what they are being measured for but everyone suffers due to poor quality and unhappy customers. Everyone at our company suffers partially due to our own misguided priorities and reward systems.

  2. Just came across another description of “Fast”, “Good”, or “Cheap”. The comment I liked the most was:

    “People forget how fast you did a job, but they remember how well you did it.”

    How true it is!

Leave a Reply