Saturday 18 October 2014

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.