Best Practices to End a Software Project.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:
Just say no. Maybe the client will respect me more for this, maybe they will feel abandoned.
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.
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.
Capture client changes and imply that you'd be delighted with the opportunity to work on the next phase, with proper funding of course.
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
ACCEPTED]
Charge for changes.
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.
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.
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 :)
Always bill by the hour. Embrace change!
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."
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.
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.
Have a big ceremony!! lol I like that.
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'.
It appears that you are through the first two stages of a standard project and are ready for steps 3 through 6:
(If anyone knows the author, I'd like to give credit.)
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.
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.
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.
If you are billing on a basis of a time and material [1] 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 [2] 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.
