Archive for June, 2015

June 2, 2015

Why Your Software Project Isn’t Like Buying a Car, It’s Like Seeing Your Doctor

For the past 15 years or so, I’ve worked in software, managing projects. I’m still surprised when the word “estimate” and “time and materials” means one thing to me, and something entirely else to customers. I’m not blaming the customer, per se – it’s not their milieu, so how should they know better?

For example:

Patrick Customer
Estimate An approximation of time and cost, based on what we know right now. Subject to change over time as we learn more. This is exactly how long it will take and exactly how much it will cost. Probably less.
Time and materials We’ll work on a time and materials basis – if it takes longer for any reason, we’ll let you know. This is a fixed fee project. If you make mistakes, that’s your fault and I’m not paying another dime.

I get it, though: I recently did a small bedroom update, and my contractor worked on a time and materials basis. But since I don’t build things for a living, it was easy for me to be shocked at the price and the timeline.

For example, after the demolition was done, I thought “how could this take 4 more weeks?”

It looked like it was much closer to completion than it was – looks can be deceiving. It was my lack of experience that made me feel that way, not that my contractor wasn’t doing a terrific job.

Not Like Buying a Car

When you buy a car, you are purchasing a product that is complete already. Sure, you can pay more or less when you pick tires, a stereo, a sun-roof. But you know before you sign how  much it will cost, and you also know when you’ll get to drive off of the lot. That’s terrific.

Software isn’t like that. Sure, we know a lot more than we did: there are scores of books about software development and best practice, and software tools are better than ever.

What those things don’t do though, is solve for all of the stuff that you (and we) don’t know.

Here are a few examples of areas where small unknown’s or seemingly simple choices can skew project costs:

1. You don’t know your data, and we don’t get to see it in advance. So we make a good faith effort to tell you how long it will take to migrate it to the new system. When we see the data we find out that you’ve blended all of the first names and last names into a single field, so we have to review and parse all of your data first.

2. You have an existing system and a previous developer purchased a calendar widget to make it work. That software is no longer available and doesn’t work with modern operating systems or browsers. So we have to replace your entire calendaring system.

3. You are certain that your case managers work always start with a screening so we build a screening widget. We find out at launch that you just wished they started with screening, but really they always do a full intake. So we have to tear out the screening features, and fix all of the processes to match what is really happening at your agency.

More Like Seeing Your Doctor

Say you have a cold, or think you do. You go and see your doctor, and she says “There’s a thing going around. Rest, drink a lot of liquid, and come back in 5 days if you aren’t feeling better”.

You come back in five days.

Your doctor says “This looks like it could be allergy related. Take one of these every day for the next 5 days, and come back if you aren’t feeling better”.

You come back in five days.

Your doctor does some additional testing and determines that you have an infection. She prescribes medicine and you get better.

Great. You just saw your doctor on a time and materials basis, and what you paid for was the fix and all of the steps along the way.

With software, you do the same thing: you pay for the process. But a lot of customers want to pay for just the solution. Imagine going back to your doctor and telling them that you aren’t paying for the first two visits. Wouldn’t that be nice for you?

But you know better: medicine is an enormous field, and experts work through a process to help you. The apparent thing isn’t always so; the path forward is sometimes murky; and its better to start with simplicity and move towards complexity than it is to go the other way around.

Software is like that, too.

What Can You Do, Then?

  1. Shop around. You can tell when the person at the car lot is blowing smoke, so you can learn to figure out which software vendors are reputable.
  2. Have a contingency fund.
  3. Be ruthless about features, and implement the crucial ones first. Don’t get bewitched by the cool, bright and shiny thing that increases your cost without providing commensurate value
  4. Make sure you actually participate in the project.
  5. Grow your technical expertise. You don’t have to become a software developer, but you should learn as much as you can about their proposed solution as possible.
Advertisements