How to stop the never-ending SaaS implementation project

(Note from Jeff- this is actually a very common situation that I have seen and tried to clean up far too many times. Writing this brought me back to some painful lessons learned along the way.)

If you are working in Customer Success/Professional Services/Implementation for a B2B SaaS company, there is a high chance that you have had some painful projects along the way. That chance becomes higher once your organization has started to sell to Enterprise customers.

What do you do when you have that project that has gone on for months and has no end in sight? The customer will be asked to renew before they have gotten any value out of your product. You have weekly meetings that are unpleasant, with lots of finger-pointing and threats. Your internal project tracker is constantly red. So how do you get out of this situation?

Remember Empathy

One important thing to remember is that if someone on the customer side is giving you a hard time, it is usually because they are scared that the project will fail. Perhaps the decision-maker decided to give your startup a chance and canceled the contract with their previous vendor. Now they quite possibly may be paying for 2 systems because you can't "go live." They are now afraid of looking like a fool, or worse, being fired (which depends on how critical the software is to the business). If you approach the situation with this realization, and make sure to be empathetic, you will start to see an improvement versus approaching from an adversarial position.

One quick note on the above... Sometimes the problem is that nobody ever agreed what "live" was. If you sell 5 modules, and the customer is using 4 of them with tons of value, then you have a different problem. I will address this below in the section about how to prevent this from happening, however, if your CSM is doing QBR's and pointing out the value along the way, the customer will realize the incremental benefits along the way.

Back to Project Never-end. The project that causes all of the internal Exec staff problems. The one that gives you hives when you see it on your schedule. You need to schedule THE BIG MEETING. This is often with the project lead, the head of the department, and perhaps your CEO. If you need Product or Development in that meeting, then you make sure that they are there. You also make sure that the Executive Buyer from the Customer is there. I would, however, try to limit the developers and other task oriented resources from this meeting. This will enable you to talk high level, and not get mired in bugs and smaller items.

Here are some notes for The BIG MEETING/ airing of grievances:

• You might need your CEO there so that the customer knows it's very important to the customer.

• Get it all out on the table. Everyone should start the meeting that you are all looking for resolutions, and don't hold back if it will get you closer to a resolution.

• No egos

• Agree to move forward and stop talking of negative history

• When you start getting close to a resolution, make sure to say phrases like "Do you agree that if we get "x" live we are in good shape?" This will prevent whatever next blow-up that could happen from being a show stopper.

• Don't be afraid to say no

• Don't be afraid to suggest resource movement on both sides. Remove the negative energy if you can.

• Don't be afraid to let them know they are the only customer that is in this situation. Sometimes when this is brought to the customers' execs' attention, they realize that their internal process is not optimal.

• Document the meeting and circulate afterward

• Make sure that whatever needed to be built/fixed is tested, retested, and then tested again.

• Make sure that the customer then tests several times with different people.

• Make sure you send out status reports every week, and the day BEFORE the status meeting (not .3 seconds before the meeting starts). This should be the standard, regardless of status.

You may have to project manage this more than normal, but if you can get to this point, you have hopefully turned this around. So, how do you prevent this situation from occurring in the future?

Preventing the big problems

There is usually not one clear-cut diagnosis as to why these projects go upside down. That being said, below is a list of common problems that I have seen.

Common Problems:

• The Post-sale team was not brought in to scope.

• There is a vague SOW or none at all

• Implementation is thrown in for free

• No Joint success plan

• Many free things are given away to keep them happy

• Roadmap features promised without confirming with the product and/or development teams. Or they were confirmed but not documented and communicated correctly with the customer

• If it has gotten really bad you might have switched out a PM/CSM or 2, thinking that a change in personnel will fix everything

• No transparency in the project details

For the future, the following steps will be a huge step for preventing these death projects:

• The project is scoped upfront. You involve technical resources that can properly scope the work that is needed.

• You write a tight SoW with a clear scope, dependencies, assumptions, and deliverables. You also clearly write what is OUT of scope.

• You and the customer have mutually agreed on a Joint Success Plan that ties together what the customer values. For example, if the customer never listed a module/feature that is causing the issue in the Joint Success Plan, you have more leverage than having no scope or definition of success.

• For the love of everything that is sacred,  get a data sample from your customer before the deal closes. I feel that over 85% of these problems are because of bad customer data (and that is being conservative). The other large reason is a little something called ROADMAP DEPENDENCIES. This is a subject for another blog

Before I forget:

Sometimes the never-ending project happens because the customer is not showing up. They don't do tasks and blow off project meetings. This will happen less frequently when :

• You charge for implementation

• Have set durations for implementation

• When you have a split team and can transition to CSM or support from Implementation. The message at kickoff is "Johnny turns into a pumpkin in 30 days" so you should make sure you go live before that happens.

In summary, there really is no clear cut way to prevent these situations from happening. But, there are clear best practices that you can do as an organization that can prevent the frequency.