Governance: why support and project teams should be different
Zinovo loves governance and this is a part in a series of posts around Salesforce governance and best practices.
One of the first questions we get from anyone looking to work with us is, “You really don’t do projects?” and the answer is, “Correct, we don’t do large transformational projects like bigger partners do. All we do is support your backlog and enhancements that come before or after a large project and much more”. The little secret in consulting is that Support/Managed Service is basically paid business development for projects. It’s why client partners at larger firms get paid so much when they sell a Support contract. It’s also a way to cover off any errors made in the project work. Together, as a company who is looking to establish or adhere to a strong cloud governance model, it’s considered best practice to separate your project teams/contracts and support.
Often times, it seems cost-advantageous when your partner for the large project offers to stay on and support either with another team or off-shore. They throw out a nice blended rate and keep the client partner on for quarterly business reviews to make sure everything is going swell. From a procurement perspective it's great, one less vendor or contract to manage. But what happens is when there is a conflict in your backlog or an enhancement request with what was built or something was customized by code when you had an option to go native? Who owns the bag when the inevitable “stuff hits the fan”? How do you actually know, from an objective perspective, whether what was done was really what you asked for or adhered to best practices. One of the first things Zinovo does when a client engages with us is deploy our proprietary Health Check that digs in deep around security, code, configuration, architecture, documentation, environment management and more to see where there might be risks or gaps. Most of the time we find a few items to be concerned but many times we have found glaring errors, especially in the use of Salesforce Vertical Packages such as Health Cloud or Financial Cloud. We then work with the business and often times the previous vendor to understand any oddities. And sometimes there is a very valid reason and that the Health Check provides a score and not the narrative to the decision — a key understanding to any consultative support company.
According to a May 2018 Forrester article on cloud support (“Optimize Your Cloud Performance With Proactive Support”)owners of cloud applications chose vendors based three main areas of interest:
- Access to expert skills
- Access to advisory for ongoing best-practices
- Support to enable certain business priorities
Oddly enough, most Salesforce partners that practice both project and support services will only allow you access to experts and advisory on FTE levels and many of them see enablement of business priorities as projects. Also most of the experts are on projects and what you normally get is junior resources with access to SMEs but they don’t know your ORG and how you work.
When Zinovo surveys our clients as to when we provide the most value they tell us the following:
- access to the skilled resources only when they need them while collaborating with internal teams and other partners
- ongoing advisory on how to improve business outcomes and managing business change management on key enhancement efforts
- dedicated team that knows the org and is invested in the long term success in their investment in Salesforce
At Zinovo, nearly all of our consultants come from a core-consulting background and opted in to the value our model provides to our clients and the Salesforce ecosystem. As you look forward on managing internal and external teams, Zinovo provides great value to your capital dollars for your investment in Salesforce and in your internal team.
Up next: How to turn attrition into a value-add in your business
Find Zinovo on LinkedIn
