Where IT Vendors lose customers

Having a mentor on hand to show the way can be vital for continued success.

Imagine your standard project deployment lifecycle:  3 months of research, 6 months of deployment, 3 years of operation, then it's time to start again.

The problem is, vendors tend to be involved at the "interesting" front-end of the cycle, but ignore the day-to-day side of things as they focus on the next win. This is hardly surprising: sales teams are continually goaled to make new revenue,  and are also mainly engaged with the big decision makers in an organisation, who typically are interested in the new projects rather than business as usual (BAU).

With three or more years of deployment, though, it's important to make sure that the new changes and techniques introduced in the project aren't lost, that once-winning features sidelined or relegated to the old way of doing things, or that – worst of all – some operational problem doesn't derail the entire system and throw the vendor's ability to execute into question.

As previously discussed, some of the sales-to-deployment transition can be better handled by incorporating solution architecture into the process: having someone shepherd the process from inception to deployment is important to make sure that everything goes to plan.

Even in cases where the deployment is carefully managed, however, many organisations still don't have a smooth handover from implementation to day-to-day operations.  This is the sort of case that devops is supposed to address – avoiding the "throw over the wall" mentality that is so common when IT projects move from the "interesting" new phase to the often-perceived boredom of normal operation.   In the worst cases, operations staff haven't been involved in the project, and are merely faced with a raft of new systems and procedures for which they don't see value.

This is where operations mentoring is important: getting a customer's BAU staff up to speed and onside with the new projects capabilities can be crucial to successful adoption of the technologies as intended, which in turn can have a significant impact on later sales.

The operational level is also a crucial relationship to make in order to understand what's going on at the customer, and avoiding "CNN moments" or unfortunate incidents just at the time that renewal (or another project) comes along.

An operations mentor is a skilled member of the vendor's technical staff – not necessarily part of the sales team – who can sit with the customer's operations group for an extended period (say three months), and help build up their own local knowledge in the new products and technologies. Where no local guru exists, this person fulfils that role, with the goal of bringing the customer's own team up to a higher level of operational capability.


It's important to realise that this isn't a traditional staff augmentation role: the goal here is to build up competency so that when the mentor leaves, the customer's team can continue on its own.  With that in mind, the tasks for the mentor should not be day-to-day management of the new systems, but should rather be to help the customer with supplementary education, tips and tricks, and the development of guides and run-books.  The idea is to follow the proverb: "give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime".

The "lifetime" in this context includes future interactions with the sales team – when a customer is comfortable with the previous technology, then they can be much more open to new products, and to deployment in new projects. Operations Mentoring is the way to develop that comfort, as well as to show that the customer's continuing success is important.

What's Really Needed for Solution Selling - DevOps for Vendors?

Solution selling has been held at the pinnacle of achievement by IT vendors for a long time. The goal is to become the trusted advisor to the customer and, ideally, so integrated into their strategy & decision making process that sales simply happen as a side effect.

This isn't as easy as to achieve as the corporate bods who run sale training programs would like to think:  a couple of years ago the Harvard Business Review published an article describing how conventional solution selling has reached the end of its usefulness, especially when the "solutions" being applied to customer problems are really just pre-packaged configurations of what products are available "on the truck".

The hardest thing about B2B selling today is that customers don’t need you the way they used to.

 – Brent Adamson, Matthew Dixon and Nicholas Toman in Harvard Business Review (July 2012)  

The thing is, given the Internet and other ready sources of information, many customers no longer need to approach vendors simply to acquire data about products and capabilities. Customers are also naturally suspicious of the "sales" approach, not wanting to be either baffled by (or simply subjected to)  techno-babble or waste valuable time when they perceive that a vendor simply has a quota to meet.

What they do need, whether they know it or not, is someone to help take them on the journey past simple product selection and into design and deployment stages with deeper insight than they can manage themselves. This is clearly evident by the large number of "vendor neutral" consultants that are often found floating around major projects. Of course, the the challenge that these consultants often have is they lack the detailed design & implementation knowledge required to take full advantage of the technologies purchased by the customer, and also don't have access to the back-line support to engineering & product teams for detailed assistance.

This is where vendors can really help the customer by integrating the sales, design and delivery portions of their organisation. With simple feature & product comparisons already done by the customer's online research, the sales team can become more valuable by being really involved with the design process, and helping see this through to implementation (& even beyond).

Sadly, all to often corporate structures aren't set up to cope with this idea: too often there's a strong demarkation between sales and delivery, with only a few very large customers having access to a team of solution designer^[1] and professional services delivery people as part of a vendor relationship. The difficulty is further compounded, even in these cases, by the separation of profit & loss for sales, professional services and education. Of course it's important to measure performance, but in complex sales situations the complete solution is almost always going to be a combination of product, services and training.

What IT vendors need is to have someone (let's call them a solution architect^[2]) to take the customer on the journey from idea to deployment. What I mean by that is to have someone who will listen to (and help document) the customer's requirements, be involved in pitching a solution concept, work on a developed design, and then guide the customer (and perhaps a larger team) through the implementation phase to successful operation.

The Architect - by BoonieT

This may be easier said than done, as it requires a skill set and temperament to see things through from inception to deployment, and may include the need for project management skills if the architect is to lead a team of others, especially if they are from other organisations. The biggest hurdle, though, may be entrenched corporate structures or simply industry culture in the vendor organisation. This is clearly a significant role, yet the prevailing wisdom is that "sales" jobs are more senior/appealing/lucrative than "implementation" roles. Even if senior, technically-competent people exist in an organisation, it is often the case that such folk are seen as being "too valuable" to tie up on on account or one project for a long time: either they need to get on to the next sale, or fight some fire at another customer.

This is where the traditional concept of separating sales and implementation needs to be changed, to be thought of as simply different phases along the same continuum. Perhaps this idea is really a vendor version of devops.

Of course, operations is where the real rubber hits the road, more on that in a later post.

1 - I studied "real" architecture - buildings and suchlike - so the application of the word "architect" to stuff we do in IT often seems wrong to me

2 - This is more like what a "real" architect does, so I'll consent to use the term here