Comparing Dissimilar Pricing Structures

You've presented a question as old as time itself: What is the best way to compare apples to oranges?

Unfortunately, there isn't a simple answer to your question. You need a lot more information than just the billing method selected by each company.

In the future, you may want to consider selecting a single billing methodology as a requirement for all incoming proposals. If you're not willing to redo the bidding process, and you're not looking to find additional vendors, you're going to have to work with the information you have.

Here's a quick overview of what I would do. Please remember, however, that what I write should be considered a starting point, not a complete plan of action:

First, I'd check for order qualifiers. In essence, I would want to know if either firm is even worthy of consideration.

Here are some questions that might help you:

• Do the companies have reasonably good reputations and histories of success?
• Do the companies have experience and domain knowledge in your field of business?
• Have the companies performed work at the proper scale? Teams that focus on projects that are much smaller may not be able to scale up to handle big, complex systems. At the same time, companies that specialize in the construction of gargantuan systems may find themselves unable to produce small systems on reasonable timelines.
• Are both companies offering the same service? Yes, they're both willing to write software, but is either firm willing to provide product management, help desk support, training, or other useful add-ons?

Assuming both companies appear reasonably qualified, I'd start thinking about how the different incentives will lead to different outcomes.

The following questions come to mind:

• Who owns the definition of "done" for the project? A fixed-fee provider will have a strong incentive to consider a project complete as soon as possible. This may mean lower quality, fewer functions, or minimized quality control.
• How likely are change requests? A fixed-fee provider will likely reject calls for new or altered functionality, or (at the very least), charge for each one. An hourly provider will be happy to accept as many change requests as you can throw at it.
• How much visibility will you have into development? Hourly providers have been known to chew through as much of their budget as they can early on. A stage gate approach with budget caps for each unit of work should be an essential part of any hourly contract. Not only will it prevent the project from running out of money, but it will alert you to trouble early on, and provide points at which the development team could be replaced with lessened difficulties.
• How is support priced? Even well-written software systems will contain bugs, defects, and user interface glitches. A favorite technique of software houses is to undercharge for development (in order to obtain a contract), and then charge an arm and a leg to customers for support. Negotiating support contracts before a deal is inked will provide you with a much stronger bargaining position.

Ultimately, however, I think it all boils down to a famous saying: If you sit down at a poker table and can't spot the sucker, you're the sucker.

Let me say this, as a certified project manager (PMP) who has spent years developing software and overseeing others doing the same: managing software development efforts is incredibly challenging. Studies routinely show that at least half of all software projects end up as failures. You might be betting your future at your firm on what amounts to a coin flip.

I'd strongly push you to think about how you can "cheat" and avoid purchasing custom development entirely.

Have you investigated the possibility of using a commercial off-the-shelf solution (COTS) instead? A COTS package will almost certainly reduce your risks, costs, and time-to-solution, when compared to building a new system from scratch. Not only that, but COTS solutions will have undergone significantly more testing, due to their larger user base.

If COTS is not a practical solution, I'd strongly recommend finding a consultant who specializes in technical project management to assist with vendor selection and oversight. He'd be able to help you define your project, choose the ideal development team, and oversee the progress of the software engineering. Remember: a stitch in time saves nine.

Questions come from readers like you. If you'd like your questions answered, send them my way.