Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share

migration rejected from stackoverflow.com Mar 2 at 19:27

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, MichaelT, GlenH7, Dynamic, Bart van Ingen Schenau Mar 2 at 19:27

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
The question is relevant to in-house development, too, but there it's harder to actually charge for changes. The closest we can come to that is getting an agreement that the deadline must be pushed back to make time for these changes. –  Steven Sudit Aug 4 '10 at 20:18
2  
Andrew, agreed. But the problem is transitioning from the end of initial development to a maintenance phase. What the vendor calls a change request (maintenance) the customer might see as a incomplete feature (initial contract). –  Matthew Sposato Aug 5 '10 at 3:17
1  
The contributed suggestions should go into a compiled answer, not into the question. –  George Stocker Aug 5 '10 at 13:17
1  
@Steven Actually, yes it is. That's why we have answers. Then it becomes, "Is his question really a question or a question and an answer". The "Compile answers into one answer" is a common practice. Not to mention if he's looking for a List of X then he needs to make this a community wiki question. –  George Stocker Aug 5 '10 at 18:39
1  
You click on 'edit' for the question, and check the 'community wiki' checkbox. CW is valid when you're asking a question where there isn't one discrete correct answer, or when you want opinions (which the site does discourage), or when you want a List of X. –  George Stocker Aug 6 '10 at 1:11
show 5 more comments