What's the best way to wrap up web projects that won't end?
I have worked on a few projects with clients who, even though I did my best to define the scope of the project, keep wanting to make improvements or change their mind on the way certain features work. This is understandable (and I don't want to deliver a bad product) but it causes a lot of problems as the project timeline gets doubled or even tripled. How do you deal with that without losing a good review from the client?
Expert Answers
Sort by Date
Sort by Votes
Dec 18, 2014
If clients desire additional enhanced functionality on their web projects which was not part of the initial scope, or the scope keeps increasing perhaps you could insert a future clause in your contract for "Change Requests" and you could then charge them further revenue every time a "Change Request" is Submitted. Usually third parties often allow a few change requests cost free of charge with a set limitation, and after that they start imposing costs. If you need to constantly add additional code for feature enhancements, then clearly your providing additional services. If you have existing clients, you could update them of your new terms and conditions giving them a timeline of when you will start charging for "Change Requests" in the future.
Dec 18, 2014
Well, I went with a same situation many times. Most important thing is to get the required things done as per scope of work within timeline and get good reviews. ( Get the work done is important than to make a perfect product ). After than pitch that client again with new improvements on his website, He may/may not agree to proceed with it, but he will always like you. It will work definitely.
Dec 13, 2014
I've worked with outside vendors on projects where they set, in the RFP response or scope of work, a specific number of revisions. Anything beyond the number they set incurs a cost. I've found this really allows them to focus on doing a good job while in review.
Dec 12, 2014
Under the assumption that you have all clients you work with sign a contract, do you have a revision limit? Or just charge the time it takes? Personally - I don't do flat rates on projects for this very reason. A lot of people don't understand the design process and it takes more time for both parties and as a result can drag on.
Your two options are:
1. Keep the project going and get paid (assuming you are getting paid...if not)
2. Terminate the project
If it consuming too much of your time and interfering with your other work then you need to terminate. The best way to avoid these situations from happening is to clearly outline the budget/timeline and if the client tries to exceed it stand your ground.
Dec 11, 2014
Hey Geoff. This just happened to me on a web project for a non-profit that would have dragged on forever if I didn't finally put a finger in the dike.
When in doubt, always refer to your original estimate/proposal, and when requests for changes begin piling up to the point where they begin to fall out of scope, you need to let them know right away and be clear as possible that you'd be happy to accommodate them, but it will cost extra. Equally important, you can be the adult in the room and say that in order to respect the desired launch date, certain compromises need to be made, and that further revisions cane done after the site goes live by means of a monthly 'service and maintenance' contract.
In my case, it was always understood that the client would take care of their own updates once I delivered the finished site, so I included some WordPress training before the project was delivered and handed off to them.
The key to a satisfied customer is to keep the lines of communication open throughout the process. I found at times that they weren't always aware of the sheer volume of work required to achieve the results they wanted. That's where we as service providers need to communicate clearly, manage client expectations, and understand that many times our clients have their own challenges in dealing with those whom they need to answer to within their organization.
Good luck!
Steve
Dec 10, 2014
Hi Geoff,
I want to understand you should disscuss things beforehand. Like a deadline before you take the sunk costs, and how a change in specifications could be charged extra. Anyways if this annoys your clients, inflate the amount of work with revisions beforehand, offering a product with constant communications than one just without, and if you want to read the entire story, read here.
http://www.cognizant.com/InsightsWhitepapers/An-Agile-Twist-Fixed-Bid-Pricing.pdf
Do get in touch before simulating the price for the next contract.
Dec 10, 2014
It is all about establishing the appropriate agreements, managing customer expectations and relationships, and project management skills.
If they don't have an organziaed approach, it is up to you to put some structure. There are ways to say NO and convince your customer, and still build strong relationships, specially when good and factual arguments are used.
I recommend the following:
1. Clearly define and document scope and business requirements.
2. Establish project milestones (gates), which are intermediate stages with clearly defined deliverables that need to be revised and approved by your customer. Once a gate is closed it is assumed as completed, and "can't" be modified.
3. Establish a Change Control process, for any change that may impact those deliverables that has been revised and approved, the impact has to be assessed and quoted separately (your initial agreement has to establish that).
4. Build a strong relationship and be firm. Work with the customer on changes that are material and not those that are cosmetic.
5. Identify new requirements that can be incorporated as part of a later release or phase of a project, and set them apart. Work with customer to actually complete a project stage and not let new requirements significantly impact.
Dec 10, 2014
Google "scope creep", study hard, and decide on how you want to manage your business relationships and commitments.
Dec 10, 2014
Define an exit strategy. Give the client an opportunity to shift to another phase by saying, "I'll be stepping away Monday so that your next developer can do the changes you wanted. I've enjoyed working alongside you folks very much and be sure to mention me to any one looking for what I've done here so far. I can pass along some of my notes if your next dev is confused about anything, which can happen when projects switch hands like this. I'll be available at my normal consulting rate for any serious complications."
Dec 10, 2014
You should try to start with a clear agreed upon scope, and once you feel that there is an overrun than I would require a client to sign a final document, that you will have to negotiate hard to keep it as short as possible, and that document should be agreed by the client that these are the final requests for the sign off,
Dec 9, 2014
Mate, you have to firm the scope in stone with the client before the project. Let the engagement state that there is a penalty for features that remain un-negotiated in stone. Its better for everyone for the client to hire you to build the specification on an hourly basis before the job, and if they can't agree to that, they clearly will just be a hassle anyway. Sure, this method reduces the number of sales suspects you will successfully convert, but your suspects will remain a higher quality.
The specification has to be granular in detail, and as flush with a description of everything as humanly possible.
It's best to have candor with your clients. Be honest, and direct. Do not succumb to their irrational demands. Software is complicated. When you rework one feature, it may cascade into several changes being required to the underlying framework you built to what you thought the client was requiring in the first place.
When you slip on that deadline on one of those websites, the client likely can prevail in arbitration. Either way you step, you're either losing money or losing the client or losing the review.
The only way to make the review back is to work for free beyond your negotiated scope.
Dec 9, 2014
Confidence leads to the next tactic for making design reviews go your way. You need to remind the client why they hired you. By that, I don’t mean to suggest you carry around your credentials and testimonials, ready to pull them out when your expertise is questioned. Rather, this has to do with constantly projecting the image of a passionate professional who is undivided in their focus on the client’s project… even if that is not a perfectly realistic assessment of your situation.remind them that you are the expert. Your skills and ability are what made this project come to life. Never give the client a reason to doubt that. Don’t let them get the sense that you are distracted from the end game. When they ask you to make a questionable alteration, your know-how and experience should trump their wishful thinking. A trickier tactic is to make it seem like their idea...
Dec 9, 2014
There is no easy way to deal with such clients.
I would say the main thing to look at is to see what you have spelt out in the contract .
Is it a time and effort contract or a turnkey(fixed price bid).
In case of a time and effort contract , one need not worry, just ensure that you invoice the client regularly.
However my experience is that such endless changes would happen if the contract is a turnkey project and the client is not ready to give a written sign-off on requirements. In such a case, its best to let go of a losing deal,, coz no matter how much work you do if you are losing in first deal, the client will expect lower rates in next deal.
Dec 9, 2014
Geoff, Great question. We have run into the same issue. We've had some luck recently by suggesting to clients that out-of-scope requests be included in "phase" 2 or even "phase 3" of their website. This allows clients to get their website up quicker, get initial feedback and assures you get paid for the additional work. It's a win-win.
Dec 9, 2014
You've got to get to the "NO" with the client...Every time they ask for more, ask them if they understand what the additional scope will entail, benefits vs. cost and be assertive if you think the changes cannot really help your client in a substantial way and that would be wasting your and their time and money...It is difficult when you have a client who can't get to finish line...Help them see it or walk away
Dec 9, 2014
Classify, priortize, monetize and set stringent deadlines.
I follow these 4 points when handling projects.
Classify: A simple way to put things into a bin- Must-have, Nice-to-have, Just-for-the-heck-of-it. If I am more than 20% beyond the time and cost of the project, I trash the items in the Nice-to-have and Just-for-the-heck-of-it bins.
Prioritize: The remaining items (beyond the 20% excess) are prioritized with client's approval and charged (monetized) per item. This makes the client re-think whether it's worth paying for or not.
Stringent Deadlines: there needs to always be a cut-off with the requirement giving and that needs to be followed religiously, both for the sanity of the project manager and the client.
Hope this helps!
Dec 9, 2014
Let your clients know immediately, when they ask for more than the original project entails - that they will incur additional cost. Remind them what they agreed to. For instance, if the original agreement said "two round of edits" and they ask for a third round, tell them they will be charged extra, and what that amount will be.
Dec 9, 2014
Whilst project creep isn't such a bad thing (and I agree with most of the comments below), I also feel (from my recent experience), that Eric Waddell is right on the button.
In my case, it was a matter of tug it or walk away and I walked away from the project to avoid any embarrassment or further legal wranglings down the line.
You see, sometimes, you come across clients who haven't got a clue about what it is they want. "They" contact you via a recommendation (crucial to new business development, but can also kill your service), "They" expect you to solve a problem (walk them through every step and eventually say yes to whatever you recommend) or help them.
Now as a service provider, investing time and resources into building client relationships is essential but when it starts to hurt your pocket and workflow, then you need to pull the brakes. At some point, you have to submit a scheduled invoice to bring to their attention of the mounting costs.
Anyway, cut the long story short, the client started avoiding my phone calls soon after I submitted the interim invoice and suggested that a down payment for the already completed phase must be settled before we continue (bearing in mind I did everything you mentioned here Patrick) and after endless revisions and shifting posts, in the end, I had to succumb to the fact that they didn't deserve another minute of my time (you have to make the call at some point)
Sadly. but true, there are people out there who expect you to work for nothing whilst taking advantage of your expertise, knowledge and generosity - "Dangerous". At this point, the phrase"money is not an object" begun to take on a whole new meaning.
In the end, I walked away from the project with the knowledge that I did everything I could and offered the client suggestions, advice and valuable time.
"The worst case scenario is that you become tarred-and-feathered as "that consultant who could never deliver what they wanted." Ewwwwww!" - Sad but true...every now and then, we come across a bad apple.
Dec 10, 2014
Absolutely agree with Roland and Eric. I like the idea of the "interim" invoice that has to be paid before you move on to the next phase.
Dec 9, 2014
In theory, it's the easiest thing in the world. Just say "later" (don't say no).
Practically, it can be a struggle for clients who are comfortable with loose timelines. Different tactics will affect clients differently, so use some judgement. But in general, here are a few things you can try:
1- open a second contract and push all change requets to the new project.
2- try to explain that websites are never perfect and a work in progress. get them to agree to a final spec and a monthly retainer where you guarantee X hours per month for ongoing changes (and remind them that what you have in staging is probably already better than what is in prod, and they're loosing days/weeks/months of potentially leveraging the improvements already made)
3- go hardball and tell them no more changes until the project goes to prod
4- get the hell out of a waterfall system and go agile (STRONGLY recommended)
5- if they are hellish clients, ask yourself how much business you'll really get from them - and what the true cost of changing change requests are vs. putting that time into fresh business development efforts (if you do the hard math, you'll surprise yourself with the result)
Dec 9, 2014
NOTE: I see a lot of people suggesting you define the project better at the beginning, but anyone who's done dev work with non-technical people know it's a rediculous expectation (due to several reasons, not the least of which is a complete lack of understanding on what they are agreeing to - even if you explain it to them).
Personally, I like the tough love approach, but you dug this hole youself the moment you entered into a waterfall contract with an inexperienced client. Pivot them to agile and commit to a release schedule (it doesn't have to be CI or real time)
Dec 9, 2014
yes yes and yes. -- I think trying to be clear on the technical aspects of the project with a non-tech client can be a huge challenge. But ALSO I think that asking a client to pivot the "way they do things" (aka - waterfall --> agile) (akaX2 - trying to convince them that they are doing "waterfall") is hard. Another thing I've noticed is that you get many more problems with clients who are trying to "build their dream" for the first time. I notice that people don't often have their personal goals clearly defined. I love working with people who have entrepreneurial drive, but it often comes out similar to: "I know what's in my head, but I can't get my hand to draw it, and you are doing a bad job drawing it too".
Dec 13, 2014
@GDaigle - my presumption is that the OP has control over the process, and that it's not actually a change in how the client does things - just in how you choose to interface with them.
Dec 26, 2014
After 25+ years of I.T. consulting I have come to the conclusion that most clients do not fully understand how they actually conduct business. They think they do, but rarely ever know it "cold". As a consultant, I expect to help my clients discover how they actually conduct business.
Why is that?
Malcom Gladwell writes that it takes 10,000 to develop expertise. That's slightly under 5 years. Who in today's business environment has done the same thing 5 years in a row? Hmmmmmmm.
Great story, Roland. I've been there too!