Top 7 symptoms to look for if your software firm is losing money on implementations
I heard a sage comment from a CEO recently, which was, "there is no tougher job than implementation, especially for a company in its growth stage." I cannot agree with this sentiment more. There are some telltale signs and rocks to kick over to make sure you are setting the organization up for success. While the implementation team should not be 100% focused on revenue generation, you should not be a cost center causing a tremendous negative financial impact. Below is a list of some symptoms that I commonly see and some advice on fixing them.
1. No Involvement in the pre-sales process:
I know I preach about this often (most recently here), but I cannot stress how much of an adverse impact this can have on implementations. Too often, the first time the implementation team hears about a deal is an email saying, "new deal- can you kick them off tomorrow? I promised them they would be live in half the time it usually takes", and "oh, they also have custom features" and no discovery was done. If your implementation team is having problems with cost overruns, late launches, and angry customers, be sure to address this situation first. You will need to align with sales, have resources that can be salesy, and have a painless discovery process. This is not always easy, but it is necessary.
2. You Are Not Charging for Implementation:
I reviewed this topic pretty heavily here, but here is the short version. Anything free is not valued and won't be a priority. What gets done faster - free with no deadlines, or $10k, and you have 30 days before your implementation consultant hands off to support and CSM?
Also covered in the link is a simple fact that great resources cost money. If you are delivering into the Enterprise, you will need engaging staff that can get the job done. If you are adding dollars to sales and the bottom line, you will have a bigger budget to fund these resources.
3. Your Process is not defined:
Too often, implementation teams do not have a detailed process to follow, and all of the implementation consultants onboard their customers differently. George does it his way, which is different from Alice's, which is drastically different from everyone else's. By not having a consistent way to roll out, you will see teams using patchwork methods. Consultants are hacking fields to meet requirements, I have seen a disturbing trend where new features are not implemented because an implementation member never learned how to do it or thinks it's too much of a hassle. If you are leading a team that is currently guilty of this, then you need to get to the core of this and work with the team to create a documented process. You want your team to be implementing your customers in the same way, or at least 90-95% the same way, as each project will have its intricacies. I typically like to use templates in rollout software that you can spot check to make sure that your team is rolling out new customers in a consistent manner. I have a screenshot of a recent project I did using my new favorite tool for emerging companies, Baton.
Be on the lookout for a rather detailed write up on process shortly.
4. Your Software is missing features or too hard to implement:
This is another prevalent issue for emerging companies, and there are books written about just this subject. You are a new company and competing in the feature war, cranking out as many features as possible to start getting core adoption. Along the way, the features perhaps were not tested as well, or they are missing an administrative component. The result is that it is hard to implement the software for the customer. The more complex your product is, the harder and longer it takes to roll out to customers.
Another area where this problem is exposed is when you win a deal, but the product team needs to build the features to go live. There is often disagreement about who owns this process- product or implementation. The answer is simple- if the core development team is building this, and if other customers could potentially use this feature, the product team owns this. That means they control the requirements gathering, validating the components before and after development, and updating the customer on the feature release timeline. If the feature is an adjunct one being created for just one customer, this becomes a professional service and needs to be managed by the implementation team.
If your software is too hard to implement and transition to customers, your product team needs to focus on new features and focus on getting the small things right before becoming big things.
5. Your staff - Not enough or the wrong fit
As a growth stage company, one of the hardest things is having enough employees to do critical work. While most of the money goes into product development and sales, you will find out soon enough that you also need to make sure that these hard-fought new customers are launched as quickly as possible and with little issues. I covered the staffing here, with the most important points being that you need to make sure that you have a team that focuses on implementing customers and having enough capacity to launch them in a timely manner. You often have understaffed and frustrated resources that start making careless mistakes due to having too high a workload.
The other issue for your team is that as you move from generalists to specialists, and start adding process to the mix, some of your team members may not like the new way of doing things. Unfortunately, sometimes the team you have from 10-30 employees is different from those you need for 40-100.
6. The Deal was sold for the wrong reasons :
We have seen it all hundreds of times. It's the end of the quarter. Sales needs to meet their quota. Suddenly deals show up where they are just using a "little piece" of the software. They are not paying much and never seem to get off the ground, as it doesn't matter that much to them, and didn't cost much, so there is no pressure to use. Selling deals just to hit either sales quotas or "logo quarters" are very harmful to the numbers that matter, like net retention and customer satisfaction. A smart board of directors will realize that adding in the wrong customer is not fixing the customer acquisition problem.
7. Not using collaboration software designed explicitly for implementations
As professionals, we deserve 21st-century tools designed specifically for our trade. Imagine a team of construction workers using pickaxes when jackhammers are required, an obvious waste of human resources, and project time. Our world is no different. There's an emerging category of project management software that is built precisely for managing complex software implementations across multiple organizations. I use a tool called Baton (hellobaton.com) because it provides a centralized work platform where authorized vendors, clients, and third-parties have real-time visibility into due dates, task interdependencies, milestones, and phases. This technology eliminates chasing spreadsheets and digging through endless email chains to get an up-to-date snapshot of each project's status. I like that owners of overdue items are flagged automatically, so you avoid those awkward calls to team members who are about to miss an important deadline. I use Baton's dashboards to see multiple projects simultaneously and historically, and I use their templates to be more efficient in future projects...to be, you know, professional.
Key Takeaways
So, in summary: The best organizations HAVE figured it out:
Kick-off respect on both sides from the outset of the business relationship by charging for implementation
Define a process - even if it is just a ppt and a ten-line checklist for consistency of experience
Model the best behavior within your teams and are critical of what is not working - in order to continuously improve
Work with best-in-class project tools designed for software implementation
As always, comment below, and if any of this sounds like a topic that you want to discuss more, send me an email at jeff@jeffkushmerek.com, or schedule a call.