Software Designers: Need advice on client approvals for a project

I’m more of a web/graphic designer/marketing guy than a programmer, but I’m building some low-level custom Web apps (using ASP) for a client whose Web site we’re also redesigning. When it comes to client approval/feedback on any web/print/writing/etc. project I know exactly when to show them progress, screenshots, drafts, etc. But what about for a software project?

I’ve discussed in detail with the client what we’re going to do. Now I pretty much just need to do it. The client knows zilch about programming and wants to keep it that way. My question: What’s a good policy in this situation? How in the loop should I keep the client? Should I just press on until the beta test? They’re not particularly hands-on/interfering, so I’m sure I could, but I don’t want to make some amateur mistake (i.e., I should have showed them my progress at milestone A, so as to avoid having to go back and re-do everything at the end). Any advice?

I am a consultant/business systems analyst. What you are talking about is a bit of an art and takes some experience to judge.

In general, you don’t let end users design the detailed aspects of software. Lawyers don’t let clients tell them how to word everything in a contract. That is job of the professional to know what to do based on general guidance from the client. You have to assume that you know more about this than they do and act accordingly. Software that was designed with too much user input usually has that “design by commitee” feel and tends reinforce bad habits that are present in the business such as archaic ways of handling data. Users usually don’t have the capability to rethink such things when they are simply used to doing things a certain way.

Here is what you do need:
Specifications from them. These will include a list of all features at a high level, Use cases for every user (just a couple of paragraphs about how different people plan to use the software), a list of inputs, and a list of outputs. Also included should be reports that they need, expectations for reliability, documentation they expect you to provide such as a user manual.

You really have to get them to do that and it will save you both time and misery.

I actually have most of that nailed down already. I guess the only thing I’m concerned about is how much input to allow them between the planning/specs stage (which is complete at this point) and the beta test. We’re developing flowcharts/sitemaps for our own (internal) purposes, but I think showing them that level of detail will confuse them and pull them in more than is necessary. And after that, it’s pretty much just code, code, code.

They aren’t really asking for input in the middle here … I just don’t want to get caught out at the end.

No, you don’t want to do that and it is very advisable that you do not. They told you what they want and now you get to produce it for them. Opening it up to input only invites swerves and exceptions and can jeopardize productivity. The downside is high and the upside is low.

The only time you consult with them now is if you have real questions of roadblocks that require their input.

If you place a custom order for a car, you wouldn’t expect the factory to send you pictures as it moves along the assembly line and invite your criticism and suggestions for change.

Good to hear. Thanks! Now I have to get to work…

The big risk is an extremely common tendency called “function creep” or “scope creep”. That is when people try to add on functions and features to software that is already under development and it becomes more expensive, cumbersome and behind-schedule. Users tend not to be good judges of which features are actually cost effective and efficient. At some point, you just have to establish a cutoff and just build it.

That is what good software project managers can do with some finesse. If it is that important, it can come out in v2.

Build exactly what you have scoped. If you are fuzzy on some details of what they want, make sure you know exactly before they sign.

Once they sign, build as scoped and make sure that your scope says “any changes or improvements beyond this scope will incur extra costs.”

Show it to them when you’re done. When they ask for changes (and they will) be able to point out that what they want is not what was scoped and will cost more. Feel free to discount the price of changes a little since you already have the project “open.”

Shagnasty’s right - it does take time to learn how to do this properly. Especially if you are new to the language. Hard to be able to say “in order to make X do Y it will take Z hours at $$/hr” but the more you do it the easier it will be.

Shangnasty kind of nailed it.

Knowing how to deal with yoru client is a critical part of any business in which you have clients, whether you’re a programmer, contractor or plumber.

You need to learn what kind of stuff you can make a quick change on if they say “that’s not quite what I meant” and what kind of stuff you better get straight before you start it.

Clients sometimes can just screw you up. I won’t go into the details, but I had a requent recently in which the client presented it to me like she wanted something to tack onto the end of a program I wrote. . .in brief, something to deal with the data it generated.

This is really simplifying, but once I got into messing around with it, I started realizing, “wait a minute, this has to be fully integrated with the original program unless I want to store every single bit of data generated”.

So, I called her on the phone to clarify and she basically says, “I suggested that way to do it just to make it easier to test it.”

Not only is that NOT EVEN CLOSE to a decision she should be making, but it would have required a large amount of coding that was outdated as soon as it tested correctly. With a pretty simple phone call, I saved an assload of time and effort.

Should that have been ironed out in the original meeting? Maybe. . .but sometimes when you’re just starting on something you don’t really know where it’s going. Getting that stuff straight saves time and money.

I think that when people say “this job requires five years experience”, that’s the kind of “experience” they’re talking about. Someone out of college might think, “I’m the world’s rockingest coder” and he might be right, but there’s a lot of things about work that he still doesn’t know.