views:

1128

answers:

16

Several projects I have worked on have satisfied all the requirements, yet for some reason lingered on. Typically what happens is that the client is spending time with their new product and is asking the vendor (consultant) to modify such-n-such "just a little". Or perhaps they realize that although requirement such-n-such is satisfied, it isn't what they intended. To create a happy customer, the vendor/consultant usually complies, and the project doesn't end.

Working in sprints (2-4 weeks) has certainly mitigated the problem, as the customer sees the product sooner and able to give course-corrections (feedback).

Here are some other ideas I've had:

  1. Just say no. Maybe the client will respect me more for this, maybe they will feel abandoned.

  2. Make sure each requirement is testable and has tests. When each test passes, the requirements are satisfied. This still doesn't account for requirements that the client insists the vendor/consultant misinterpreted. Also things like usability are subjected to the client's interpretation.

  3. Have a big ceremony, the more elaborate the ceremony the more obvious it is that the project is over. This is more of a psychological activity to change the client's mindset into a "project is over" mentality.

  4. Capture client changes and imply that you'd be delighted with the opportunity to work on the next phase, with proper funding of course.

  5. Near the end, create a burdensome change request process meant to discourage changes. This seems counter to agile as well as good customer service.

What are some best practices you know of that ensure a distinct end to a software project?

This question is probably more relevant in the client-consultant context than an in-house developer situation. I feel it's absolutely vital in fixed bid projects.

Thank You

+38  A: 

Charge for changes.

Steven Sudit
Usually in the contract I like to say the first 2 minor changes are free of charge, then any change after that will cost them (I also make sure to define what constitutes minor in terms of hours). This makes them feel like I'm not purposely trying to milk them and usually ends with a happy customer.
Jage
@Jage: To some extent, changes are a manifestation of the consultant's inability to precisely grasp the requirements, particularly the unspoken ones. To another extent, they're the result of the client not knowing what they want until they have it (and not always then). Based on this, it's not unreasonable to factor in some "free" changes, but this can't be allowed to turn into a clown car.
Steven Sudit
@Steven, charging for changes is correct. But there's the problem of human interpretation. One man's change request is another man's incomplete requirement.
Matthew Sposato
@Steven Which is exactly why I limit it to only 2 changes, with each change having to be under 5 hours of coding. I agree that it is usually the client not knowing requirements, but how often do you come across clients or managers at work that know ALL the requirements for the entire piece of software. Requirements will for the most part change some throughout a project's life cycle...in a fixed bid contract this sometimes can put the customer in a bind. I'm not saying my way is right, just that it gives them some flexibility they might not otherwise have.
Jage
@Matt: You certainly do have a point, but even here, we need to distinguish between not providing what was promised and not promising what the client turned out to want. The former is reason enough not to consider a job completed, but the latter isn't. Regardless, you are right to say that it's unrealistic to expect to be completely accurate regarding requirements from the very first day, which is where iterative development with progressive sign-out fits in. The idea is to recognize the requirement errors early and make the corrective changes while they're still cheap enough to lump in.
Steven Sudit
@Jage, @Steven. In future projects I'm considering incorporating your ideas into a "usability review" period, which would include a limited number of hours for fixing usability issues. It would happen after the requirements are satisfied. The user could tweak things according to their preferences, but I'm protected from endless changes. In my experience, usability is a subjective quantity that the user interprets to get more changes. I need to allow those changes, but in a rigid time/money bounded way.
Matthew Sposato
@Matt: That's quite sensible. I hope it works out for you.
Steven Sudit
+18  A: 

Offer the customer a maintenance agreement. They will pay a recurring fee that entitles them to minor changes. Also, get a sign off at the end of the main development phase stating that they agree the product is "complete" and can move into the maintenance phase.

Jon B
I think the key point here is getting paid in full for work already done.
Steven Sudit
Another key point is discussing the maintenance agreement at the beginning of the project, with clear expectations when the maintenance phase begins.
Matthew Sposato
@Matt: Yes, it shouldn't be a surprise to spring on them after they hand over the check. Depending on the type of client, they might not be very sophisticated about how software development works, so they might not really understand about the lifecycle of an app.
Steven Sudit
+24  A: 
  1. Define success at the beginning of the project, and make it clear that any changes once the objectives are met will have to be done on a new project. (However, specify that minor changes, or functionality that can't be lived without can be squeezed in - be reasonable.)
  2. Learn to say "That's outside the scope of this project." without feeling guilty.
David Stratton
3. Charge for changes. :-)
Steven Sudit
I agree - and voted that one up, as well as Jon B. Both are good answers.
David Stratton
@David, I think most of the answers, including yours and Jon's, amount to specific suggestions for *how* to charge for changes. And I upvoted them all.
Steven Sudit
+1 Learn to say "That's outside the scope of this project." without feeling guilty
WDuffy
+1  A: 

First step is a contract to define the 'functional range' next to pass an 'acceptance test' anything out of this scope should be charged. Regarding minor changes: 'do good and talk about it'.

stacker
+2  A: 

From a legal standpoint it's black and white. From a business standpoint it's a grey area.

Fixed bid projects are vital to get the major requirements, scope of work, etc. in writing. If the client is under contract to pay for a particular set of deliverables, and you deliver them, they are required to "end the project" as far as you continuing to work without further compensation. Legally, once you have completed your end of the contract, and they pay you, you are not required to continue work.

However, projects continue to go on because the project may be a very small piece of a larger picture. As a consultant/contractor, you often work for free upfront in exchange for future goodwill. Often times it's better to work a little more for a $100,000 contract in order to get that next $500,000 contract.

Unfortunately it's often not that you can't stop the project, it's that you want to keep presence to transition to more and larger projects with the client.

"Out of sight, out of mind."

Ryan Hayes
I've been a consultant, and I found that, if you expect to be paid for future work, you must insist on being paid for past work, lest you set a precedent. If you let them drag their feet about paying for a completed project by requesting free changes, they will. And they'll keep doing it forever, if you keep letting them.
Steven Sudit
Yes, I mean there are times when it makes sense, but I don't mean that there shouldn't be boundaries. A free maintenance period is absolutely not what I am suggesting by a long shot.
Ryan Hayes
@Ryan: Good. My concern here is that I've seen too many consultants bend over backwards to satisfy an unreasonable client based on the theory that it will give them an "in". It turns out that the sort of client who'll happily take your work without paying is not likely to start paying you.
Steven Sudit
+1  A: 

It appears that you are through the first two stages of a standard project and are ready for steps 3 through 6:

  1. Enthusiasm
  2. Disillusionment
  3. Panic
  4. Search for the guilty
  5. Blame the innocent
  6. Reward the uninvolved

(If anyone knows the author, I'd like to give credit.)

Patrick
This is an attempt to be amusing, but it is not a helpful answer to a serious question.
Steven Sudit
The author is Karla Jennings.
Pascal Thivent
+1  A: 

The first step is to decide at least the major points that constitute a finished product the second is to be firm but fair with the client when it comes to changes. Be strict with yourself and your client, when a request for more work comes in decide whether it's a bug fix or a new feature. Once you are happy that you have met all the requirements go through a at least a semi-formal user acceptance stage. Once that is complete you have good grounds for telling the client that everything else is chargable work.

wobblycogs
Bug fixes would be done under warranty, but they're not a reason to delay completion of the project once there's been a final acceptance. If you present the completed project but the client finds show-stopping bugs, that can block acceptance. An alternative is for them to accept, contingent upon the correction of the specified defect.
Steven Sudit
+2  A: 

What do you mean by "end"? - terminate all support for the software? I've never worked on a project that ended in that sense, and I can't see how such projects can work. Once you start, you (or your successors) are in it until the users stop using the software, or you no longer care about the howls they will make if you cut off support.

anon
I interpret "end" as "get paid", in this context. :-)
Steven Sudit
@Steven Well, I like to get paid every month.
anon
Neil, I see your point. For clarification, what's ending is the project for initially creating the software, not the software itself. I.e. I built you a house, pay me for it and move in. Just because you want to change the faucets does not mean the house is incomplete.
Matthew Sposato
I'm with you on that one. In fact, I sometimes like getting paid as often as twice a month. But, as a freelance consultant, getting paid is half the job. This means managing expectations, getting client acceptance and not doing work for free.
Steven Sudit
@Matt: Nicely put.
Steven Sudit
anon
@Neil: I've done fixed-price projects successfully. It helps if the requirements are set in stone, you get at least half of the money up front, and the client is not insane. Even then, I kept track of hours worked and had the client approve changes as they became visible. As a result, the final sign-off was a formality.
Steven Sudit
+5  A: 

Projects dragging on can be a common problem. To mitigate this, my company uses a project sign off document, as well as appropriately worded Statements of Work (SOWs).

The purpose of the project sign off document is to approve the completion of deliverables and services provided by our team under a given Statement of Work (SOW). We ask our customers to acknowledge that the deliverables and services as described in the SOW have been completed and accepted per the acceptance criteria set in the SOW.

Our SOW's also have acceptance criteria set in that show time limits for customer acceptance. This gives our customers a time limit to determine if any deliverable does not not perform as to the functional requirements specified, the limitations of this warranty (for example, we require them to keep our automated tests passing) and also sets time limits for us to fix any of those problems.

In addition, as someone else noted, we also have maintenance agreements to cover support beyond the warranty period noted in the statement of work.

Paddyslacker
Somewhere, a lawyer earned their bill.
Steven Sudit
+1 for making me laugh! Actually no lawyers were involved in this language. Just years of experience of projects for different companies and wanting to do it differently this time. This way, the customer gets a warranty and we get to put limits on it.
Paddyslacker
Well, it's a sensible way to communicate clearly and protect everyone's interests. Worthy of a *competent* lawyer.
Steven Sudit
+3  A: 

Being (partially) transparent with the schedule, and therefore the cost, with your client is important. I think 2, 4 and 5 jive with this:

"2. Make sure each requirement is testable and has tests. When each test passes, the requirements are satisfied ..."

If you make your test plan part of your initial specs, and have the client review them, you can show what your exit criteria are, and get them on board to agree with that. This doesn't mean it can't be an iterative/agile process, but it does mean that they will know that testing is important. They will understand that it impacts your schedule, and they will understand the expectations they can reasonably hold you to for the money they are paying you.

"3. Capture client changes and imply that you'd be delighted with the opportunity to work on the next phase, with proper funding of course."

Take iterative feedback, but cost the changes, and tell the client that there will be an impact to the schedule, and therefore the cost. Of course, build some buffer into this, and make the buffer clear, so they know that they can get some changes in without breaking out their wallet. That, of course, is on top of the buffer you add for yourself, and the unknowns you will encounter :)

Once release milestones are reached, costs are more expensive, and you should let the client know this.

"5. Near the end, create a burdensome change request process meant to discourage changes. This seems counter to agile as well as good customer service."

I agree with this, depending on your definition of burdensome. An e-mail, a hack with no testing, and a quick re-deploy may cost very little, but it still has a cost. Make this obvious to them. Build in some free changes (as I suggested earlier), but make sure they know that bigger changes, and too many changes are going to end up costing them. Cost everything!

The burden should be like a feature request/bug filing process, which would be useful to them anyhow. Then, you can have bug triages with them, and see what will fit for free, what they'd have to pay for, and what they're willing to pay for.

If they have numbers and dollar costs staring them in the face, they may be a little less inclined to keep requesting tiny changes, then expecting them for free.

Basically, just be honest, and while being honest, bookkeep everything. You'll be more comfortable with the final result, and so will your customers.

One more thing, a major portion of this depends on whether you're giving a flat rate, or are costing your project. If you give a totally flat, unqualified rate (because you really want the client, or you're just starting out), then you may have to just suck it up :)

Merlyn Morgan-Graham
+2  A: 

Definitely charge for the changes, as Sudit says. Also, how about scheduling key people to start an important, new project about a week or two after the end? This makes sure that they're clearly not around for idle questions, but without the abrupt cutoff.

Don Branson
This hints at another really, really important point for freelancers: as your current project is coming to a close, you *must* put time aside to make sure that your pipeline remains full so that you have billable hours coming in afterwards. Sales sucks, but it has to be done.
Steven Sudit
+1  A: 

Have a big ceremony!! lol I like that.

Duncan Krebs
+3  A: 

Always bill by the hour. Embrace change!

tcrosley
Not all clients are willing to sign a blank check for your hourly fee.
Steven Sudit
@Steve: I simply don't do fixed-price contracts anymore. I've been consulting full-time since 1978, got burned a couple of times 25 years ago and now only take on projects where I bill by the hour. Almost all clients ask for a estimate up front of what it is going to cost, and some insist on some sort of cap -- which I set significantly higher than my most conservative estimate, with the wording "subject to revision if there are changes in specifications or features."Billing by the hour also simplifies the billing process -- I don't have to wait for some sort of milestone.
tcrosley
@Steve: In a comment to another post (which I can't comment on since I'm a newbie here), you said "as your current project is coming to a close, you must put time aside to make sure that your pipeline remains full.." One of the advantages of not ending projects abruptly, and instead making oneself available for maintenance on a per-hour basis is that you can also fill in the gaps by catching up on some to-do lists for previous clients. I am a "one-man" shop, but currently have five active clients. The oldest I have had for 6 years, and typically work 10 to 15 hours a month for them.
tcrosley
@tcrosley: You're not wrong. I haven't been a consultant recently, but I did try to avoid tying my hands. The way I used to explain it is that, if I commit to a fixed price, I need to be able to control everything else. So if they want to be able to customize this custom job by offering feedback and tweaking requirements, they need to go hourly. The compromise is to make a reasonable estimate and do your best to stick to it, while being very transparent about the impact of change requests. Ultimately, the goal isn't to screw the client or screw yourself.
Steven Sudit
@tcrosley: I think it's possible to end a project firmly and decisively, getting paid in full for work done, while being wide open to per-hour additions. This way, you can still fill in gaps but at least you're getting paid to do it. :-)
Steven Sudit
+1  A: 

At the end of a project there has to be a sign-off.
The customer signs off on the acceptance test.
After that point you might optionally have a warranty period where you fix any bugs for free.
Anything after that is a new project: requirements definition, analysis, design and then test plan, etc... etc...

This is where a good set of requirements and some formal milestones are critical, whether you are dealing with internal or external customers. It makes no difference.

Romain Hippeau
I'd very carefully differentiate between bugs and changes. You should warranty actual bugs for a period of time. If you want to bundle in some amount of maintenance and changes, that's based on total work.
Steven Sudit
+1  A: 

Many people here said - charge the client.

The strong logic behind it:

if the customer can get more for free... Well your customer is usually an employee that is committed to his company best interest - getting more without paying - is the company interest. So he must keep asking for more - or he is not serving his company properly.

If the company has to pay (even small amount)... it becomes a budget issue which at some point stop serving the company interest - and eventually the customer will stop asking for changes - even if the cost is low - the cost extends the budget.

I saw many projects where 20-100 hours of support where offered for free, yet the customer was told so many times that he get there hours for free that after the customer used them... He knew he had to pay for the extra.

Asaf
+1  A: 

If you are billing on a basis of a time and material contract (which is the ideal contract for agile), there is no problem and the customer should stop paying for one more iteration if this iteration doesn't generate more value that it costs.

If you're using a fixed bid contract (which is somehow anti-agile as it implies frozen requirements, frozen scope, while the whole agile stuff is about scope management) then you must include a change request process in the contract and obviously charge for changes.

Without such a clause, customers have zero interest in stopping the developments. And because frozen requirements often means that the customer won't get what he really wanted, there will be changes. And because changing will be risky for you (because the application was not necessarily kept flexible), they'll be very expensive to either discourage the customer and/or CYA.

And this is why I think that fixed bid contracts aren't ideal for Agile projects.

See also

Pascal Thivent