The head of services in any enterprise software company will recognize certain patterns.
Some are great patterns, like the instantly recognizable traits of a new customer who will be great to work with and who will drive the project to success. Or the perfect project with the perfect scope that fits exactly within the lines of what the product does well and which has been delivered many times before.
And some are not-so-great patterns.
One not-so-great pattern that any head of services will recognize is when a project is handed off – or thrown over the wall – that includes too many new, never-before-delivered services elements (tasks, deliverables or technologies). That pattern signals that the project will, with almost perfect certainty, be challenging, and that completing it without incurring collateral damage will be difficult. Lets give this pattern a name…can we call it the “Promises Made” pattern?
Now there are several types of Promises Made Projects, each essentially a pattern of its own. There is the Promised Date pattern, an irritation, yes, but a catastrophe, no. And there is the Promised Feature pattern, a huge problem but one for another day, as it includes the product and dev teams. Today…here…I am talking about the Services Promised pattern. That’s the one where someone said during the sales process that “we can definitely do that.” Even though we have never done that before.
When new services are made up during the sales cycle, it is practically a guarantee that the implementation is going to be a problem. You can count on customer frustration, schedule problems and financial challenges. In my case, I basically put Services Promised projects into escalation with extra oversight and controls right from the get-go to try to control the issues.
Why are these projects so hard? Because, by definition, a Services Promised project includes new service elements that have not been delivered before. And that means there are no tools and methods available, no best practices to follow and no experienced person to deliver it. The learning curve has not had time to do its magic through repeated deliveries of the same thing.
So when this Services Promised pattern occurs it means expectations about scope and schedule have to be adjusted basically from day one. That will reduce trust with the customer from the outset. Delivery team members will be wary, trying not to be the one thrown under the bus when things get dicey. And the sales and services teams will bicker over who committed what. Ultimately, even with effective mitigation tactics there is still a high likelihood that the result will be a financial calamity and, at best, a less than delighted customer.
This Services Promised pattern – when new services are invented during the sales process– is a very serious problem. It has always been a problem, even in the perpetual license days when we got all our money up front and then fought through the implementation.
But today, in a SaaS company, a new customer whose implementation is based on new service elements is a crisis, not a problem. That’s because, let’s face it, without three or four years of renewals no new customer is actually profitable. Year one of a SaaS contract is break-even at best when cost of sales are considered. So we need delighted customers, raging fans, who fall in love with us as a company and who renew eagerly. And it is hard to get raging fans when you have to start the implementation by pulling back expectations,
Why does this problematic pattern endure? One reason is obvious. We all want new customers. We want them a lot. A really, really lot. And saying yes is a lot easier than saying no, or saying “we’ll see” when trying to get a deal closed. So sales makes promises. Those damn sales people, we should put strict rules in place so they cannot do that. In fact we in services should see every proposal, review and approve it so this doesn’t happen. Wrong. Well, ok, fine if you want to slow down sales and frustrate the sales team.
So whoa there before you blame sales so quickly. Maybe the problem has a root in the way your services are defined and offered. Maybe Sales is being forced to make, er, “stuff” up is because you, the services guy (a gender neutral term in my grammar) have not been clear enough about the services you do actually offer. The services you do know how to deliver. The services you have the tools for, and methods defined for, and a team trained for,
So start by asking yourself, how are your services communicated? Are they very clearly defined in understandable chunks that can be mixed and matched at the point of sale. Is it easy to configure a complete project from your services components. If your services are vague or defined at too high of an abstraction level, then of course sales will fill in the blanks. Because you left those blanks.
The key element required to interrupt this pattern is to define, document and publish a complete set of well-defined services components that can be selected, combined, integrated and presented to the customer as a logical whole. That’s where an application like WorkRails come in. WorkRails takes services abstractions and epics into well structured chunks, the same way User Stories work in defining products.
And WorkRails enables the services components to be constructed as interchangeable and mix and match-able (sic) components that can be easily selected and combined and then presented to a prospect by sales, without taking a detour to services or having to make up stuff.
Once sales has a complete set of services elements that they can select from a list and combine into an SOW or proposal, they will be much more likely to stay on the “Rails”. That means you get to deliver the things you know how to deliver, that you have delivered before and that lead to great project successes.
Maybe this was way too long of an essay to make this simple point: If you want sales to “sell what’s on the truck” then it is your job to define what’s on the truck clearly and make it easy to sell.
And tools like WorkRails make that easy to do. Otherwise, expect to see the Services Promised pattern recur, with all the accompanying challenges. Because sellers are gonna sell, sell, sell, sell (Sorry Taylor). And that is exactly what we want them to do.
The answer is not more control of the sales process with interruptions for services to review SOWs. The answer is to make it easy for them. Give them a catalog of well structured, well defined services. And make the Services Promised pattern one pattern you don’t even recognize anymore.
For more information on WorkRails or to schedule a demo visit www.workrails.kinsta.cloud
