Archive for category Consulting

Don’t let your Salesforce.com Implementation Program lose Momentum

Salesforce Implementations can get seriously bogged down after a year or two of haphazard evolution

Salesforce Implementations can get seriously bogged down after a year or two of haphazard evolution

Is progress with your Salesforce implementation program becoming increasingly challenged? 

Symptoms include:

  • Project delivery late and over-budget
  • User adoption decreasing
  • Data quality decreasing
  • Minor changes taking too long to move from idea capture to delivery
  • Stakeholders preoccupation with stabilising the mess rather than taking strategic next steps
  • Salesforce staff failing to be retained

Whilst these symptoms are all too common with larger Salesforce implementations made complex due to the number of business units and system integrations, the good news is there are steps you can take to stay (or get back) on-track.

Make these practical decisions at the start a Salesforce implementation program to ensure you don’t get “stuck in the mud” or perhaps “Stuck in the cloud” should be the modern phrase!

  1. Establish a “Centre of Excellence” to govern change
    – centralise decision making, release management and design standards;
  2. Establish strong product management involving business and IT to assess and prioritise requests for change
    – ensuring high priority/value requests are delivered first;
  3. Stay ahead of the curve with strategy and architecture
    – communicate a clear (regularly refreshed) vision explaining where you are heading and how you will get there;
  4. Use a consistent delivery team
    – yield better results with an agile team working through a regularly re-prioritised backlog to avoid loss of staff continuity across a series of larger stop/start projects;
  5. Deliver releases regularly (continuous delivery)
    – be responsive to change requests (at least for minor enhancements) to keep users engaged as they receive increasing value as the platform is advanced;
  6. Keep documentation current
    – capture the reasons why decisions were made and what outcomes were achieved to inform the future;
  7. Develop a library of test classes/methods which simulate and test critical business functions
    – ensure nothing breaks as changes are deployed using automatically run test methods;
  8. Continuously focus on data quality at the point of entry
    – be clear for all data about why it is needed, how it will be used, and what defines “good data”;
  9. Make an ongoing investment to resolve legacy implementations which are causing problems
    – avoid an increasing pile of “technical debt” which will eventually inhibit progress;
  10. Learn as you go and invest in training
    – improve delivery over time by conducting post-implementation reviews;

If you need help with Salesforce please get in touch with Artisan Consulting.  Artisan provides a cost-effective Salesforce Program Health Check which documents your current state, where you want to get to, and provides practical recommendations for your next steps.

About the Author
Richard Clarke is a Program Director and Technical Architect within Artisan Consulting's Salesforce Delivery Team.  Richard has led Salesforce delivery teams in the Australia, New Zealand and the USA and applies over 20 years of enterprise software experience when delivering business value with Salesforce.com.

No Comments

Ten ways to avoid common pitfalls when delivering Salesforce.com projects

How to make sure your Salesforce implementation does not end up looking like this!

1. Define a Clear Roadmap

  • Not knowing where you want the journey to end guarantees you won’t end in the right place.
  • When you want to arrive is almost as important and where you want to arrive.
  • The end result is usually bigger than “just” CRM (consider all the relationships which need management).
  • Be clear about which business capabilities need to be supported or enhanced with Salesforce.
  • Don’t transfer fractures in organisational structure into Salesforce – share common customer data.
  • Stay abreast of Salesforce’s own roadmap.

2. Define Clear Program and Project Requirements

  • Define strategy (the “why”) and required business outcomes (the “what”) before considering the “how”.
  • The “what” has to be measurable as this defines success.
  • Having key stakeholders including operational managers express and approve requirements is critical.
  • Don’t leave thinking about reporting/analytics until last.
  • Consider security upfront – both who can see what data and who can perform what functions.

3. Don’t do too Much at Once

  • Multiple projects at once are hard to coordinate especially when multiple delivery partners are utilised.
  • Doing two different things at once is three times harder than doing one thing at a time. 
  • Doing two different things fast at the same time is four times harder.
  • Running multiple overlapped software development projects will increase the need for tight governance (processes and tools) to manage requests for change, development, testing and deployment.

4. Choose the Right Delivery Model

  • Waterfall (all requirements up front), Agile (requirements clarified one short iteration at a time) or Fragile (requirements clarified through repeated experimentation).
  • Agile does not mean being continuously vague and discovering requirements by endlessly building the wrong thing then fixing it.
  • If you are not sure what you want or how to build it explore options using discardable prototypes.
  • Use an internal self-managed agile team if your organisation has adequate software delivery maturity and available resources.  Otherwise use an internal partner-managed agile team in preference to using an external remote partner delivering under a waterfall driven statement of work.
  • Consider what the team needs to look like when you are finished and the delivery partners leave.  Work towards that outcome throughout the project so those responsible for operational management have experience with the implementation details.

5. Manage Data Architecture and Data Quality

  • Data quality will degrade without proactive steps to maintain it.  Implement the platform’s tools to minimise duplicate customer data.  Use validation rules to enforce a base level of data quality.  Calculate a data quality score for key objects and use dashboards to drive behaviour.
  • Don’t add data fields to objects unless there is a strategy to populate them.
  • Make sure the relationships added between objects are done by someone capable select optimally between master-detail, required lookups and filtered lookups.
  • Consider reporting and query/report performance early.  Index text/picklist fields which are important for reporting by flagging them as an external ID.  Ask Salesforce to add custom indexes to custom date fields if they are important data selection filters.

6. Know what Success Looks Like

  • Develop a testing strategy and direct delivery partners as to what testing you require them to complete.
  • Testing has to address the outcomes desired as well as the outcomes to be avoided.
  • Recognise Salesforce’s 75% code coverage rule does not necessarily deliver automated tests which usefully determine if the system is working as it should.
  • Software engineers usually make poor testers so resource the testing function appropriately.

7. Maintain Current Documentation

  • Documentation needs to capture how the system works and how it integrates to other systems.
  • Projects should provide documentation which explains what changed (and why) as well as how to reverse a deployment which causes problems.
  • Keep information about system architecture current (what systems different user roles interact with and how systems integrate with each other).

8. Customise with Configuration Not Code

  • There are many ways to achieve the same thing in Salesforce and use a coded solution last.
  • Don’t custom code a user interface until you have tried the auto-generated user interface.

9. Choose the Right Operational Mode

  • The composition of the optimal operational team varies depending on the size and complexity of the implementation.  Include a developer in the team if they are expected to maintain custom code (vs custom configuration).
  • Budget for ongoing training and incentivise team members to achieve and maintain current certifications. 
  • Use Salesforce Trailhead for self-paced learning which is both fun and easily measurable.
  • Leverage operational assistance sourced from Salesforce Premier Support and Salesforce Partners.

10. Measure and Manage Levels of Adoption

  • Define what KPIs matter and measure them.
  • Ask executives to lead by example by being visibly active in Salesforce.
  • Use Salesforce’s Chatter, Ideas, Q&A, and Portal functionality to keep the conversation alive.

No Comments

Should Technology Solutions deliver Perfection or Pragmatism?

In my view senior IT leaders (CIO/CTO/Enterprise Architect) need to moderate their drive towards a perfect technology landscape with commercial pragmatism.

A target end state should be in clear view, and each project should be a step towards greater flexibility, improved performance, increased automation and reduced total cost of ownership. 

But perfection is best attained gradually rather than with giant strides.

Consider these two chairs – the fine piece may well be better furniture – but a pragmatic commercial outcome which balances budget, timelines, resources and required results may well be the other.

Chairs

I’ve seen too many projects founder by failing to deliver a business case with an acceptable return on investment, or failing to deliver a complete solution by deploying quality parts but a compromised whole.

If a business needs a working chair it is best to deliver the right hand option, rather than just the legs of the left due to delivery constraints.  Temper the striving for perfection and avoid being overly ambitious with the size of step change or being overly aggressive with the timeline.

A priority for a technology architect is to understand the blueprint and ensure projects are aligned to IT strategy.  How large a step a particular project should take on the journey from current state to future state is a commercial decision which needs pragmatism applied.

I vote for function over form in most cases and ensure solutions get the job done whilst also being a step in the right direction strategically.  And in that context a good customer experience is primarily about function.  All projects need to avoid looking pretty and performing poorly.

Achieve perfect function with patient progress and commercially moderated small steps.

This approach will also reduce the risk that your crystal ball view about which components form the ideal end state technology landscape is less than perfect and needs to be adjusted along the way.

No Comments

Salesforce.com integrations can start well but end up being messy

All Salesforce implementations begin without any system integration.  Simple.  Clean.  Scalable.

Puppies - theory and practice - 800w

Increasingly though businesses want to integrate Salesforce with their digital assets (websites and mobile devices), internal legacy systems and external third party systems.

Salesforce provides a number of ways to achieve integration including:

  1. Web-to-lead and web-to-case HTML form submission

  2. Email handlers processing inbound emails

  3. Outbound emails sent from Salesforce or via third party products like Marketing Cloud

  4. Inbound synchronous calls to the Salesforce REST or SOAP APIs

  5. Inbound synchronous calls to custom Salesforce web service endpoints

  6. Outbound synchronous calls to external web service endpoints

  7. Outbound asynchronous calls using future methods to external web service endpoints

  8. Outbound asynchronous calls using outbound messages

When I saw this photograph I thought it was a great illustration of where I’ve seen Salesforce clients end up with their integration strategy.  When the project starts everything is orderly and under control.  Then over time development teams introduce different integration patterns which depart from the original architectural blueprint (if one existed at all).  Then the project gets deployed and integrations start firing in earnest.

Combining a myriad of different approaches to Salesforce integration with high volume transactional activity and a large active user base can create a messy outcome.  Salesforce currently lacks strong support for multi-threading control so synchronising data access and modification across a matrix of integration patterns can quickly become problematic.

My advice for projects which need to highly integrate Salesforce is to adopt early the best practice approaches for inbound and outbound integrations.  These can handle bi-directional data exchange in a standardised scalable manner.

Otherwise there will be a lot to clean up!

Credit to Alexander Ilyushin (@chronum) for the puppies photograph which originally illustrated similar outcomes with multi-threaded programming theory and practice:  https://twitter.com/chronum/status/540437976103550976/photo/1

No Comments

Cloud Computing: Not Always a Silver Lining

The Happy Promise

Cloud computing comes with an attractive promise – much like the sun shining on lovely white fluffy clouds. Life's good in the cloud the vendor will say. No more infrastructure to purchase, host and maintain. And with a cloud application platform like Salesforce.com no more developers either as all it takes is "clicks not code". Sounds wonderful. And it always is at the start.

Clouds sized

The Reality

Building complex integrated business solutions continues to be complex, especially when the landscape includes legacy monolith systems unaccustomed to "talking" to anything outside the firewall boundary.

Managing the evolution of an enterprise database is also a challenge as business needs change over time. With Salesforce it is incredibly easy to add new entities to your organisation's "database" or add new fields to entities already there. Add-on applications can easily be introduced from the Salesforce AppExchange – each of which adds to the overall system complexity.

The law of entropy (the second law of thermodynamics) applies here – an isolated system will spontaneously evolve towards maximum disorder.

The faster a cloud platform allows changes to be made then the faster the pace towards disorder will occur.

The Common Journey

Particularly with Salesforce.com the journey starts with business stakeholders becoming exasperated with the speed of their IT department. They engage Salesforce and within days their CRM system is up and running. So easy. In hindsight perhaps too easy.

Initially Salesforce is a clean well-structured system without back-office integration. Then the changes start and the clouds start changing their colour. New entities and fields are freely added to the database. Integrations are established with back office systems. Add-on applications are installed.

Entropy kicks in and the march towards disorder begins.

Eventually the integrated system becomes challenged with data synchronisation issues and fields which contradict themselves (should that be an opt-in or opt-out to stay compliant with anti-spam legislation?). Ownership of the system moves progressively from a front-office business unit over to IT. Who for the most part of been kept out of the journey to date and don't understand how clouds work – other than they look black and ugly and threatening.

The pace of evolution slows or stops and the main point of why the cloud based system was introduced is lost in distant history.

What can be Done?

The good news is this outcome is not pre-ordained and need not happen.

Here are some things to consider early in the journey to avoid ending up in a stormy situation:

  1. Accept building complex integrating technology solutions remains complex even with cloud computing and success will require skilled IT professionals to be involved (regardless of whether the vendor assures you that IT won't be needed and it's best not to engage them).
  2. Accept that database design is a specialist skill and establish good data governance from the beginning.
  3. Provide adequate training and mentoring to the group tasked with administering the platform especially if they come from a business rather than technology background.
  4. Realise the law of entropy applies and there is a need to proactively push back against the drift towards chaos. All changes need to be thought through carefully.

Storm Disbursement

If you find yourself no longer living the blue-sky dream with Salesforce.com and need help to disperse the storm clouds which have accumulated during the first few years of use then I'd encourage you to get in contact. After a detailed current state assessment of your Salesforce organisation and integrations it will be possible to plot a path back to the land of the fluffy white clouds again. It may take a while to unpick the chaos but it is always possible.

Richard Clarke, Salesforce Architect and Integration Specialist
Contact me via email: richard.clarke@fuseit.com

sf

, ,

No Comments