Change Intelligence – Build the right thing

In the first blog in this Change Intelligence series, we gave an overview and 5 ideas for “doing more with less”.  Each of these 5 ideas can give both short-term and long-term gains.  They were:

1. Build the right thing; Spend more time on upfront business analysis, so you are building what users need. It will reduce the time spent building the wrong things and the resulting rework, and add to the frustration of the business users.
2. Understand the risk of changes; Use automated org analysis and documentation to increase the speed you can make changes with confidence. But you can also prioritize changes based on the level of risk so you can fast-track low-risk changes and allocate the correct level of development resources to every change.
3. Target specific technical debt; Remove unused (and costly) managed packages and technical debt in the areas that is killing agility. Not all technical debt is bad. Not being able to assess the level of tech debt is bad.
4. Improve user experience; Clean up page layouts and provide in-app help. This reduces time spent by users, increase adoption and improve data quality.
5. Make better decisions; Ensure the decisions are based on valid data by analyzing the fields used to drive dashboards, populate integrations and feed Einstein.

Over the coming weeks we are going to dig into each of the 5 ideas in more detail. So in this blog we are going to look “building the right thing”.

$1,000,000,000,000 problem

Whenever I present at conferences I ask the audience to put their hands up if they have built something that the end users then don’t use. Normally the entire room puts their hand up. I was talking to one client who said that the collective term in their org is “a confetti of apps”.  Each is perfectly formed, beautiful, and take time to create. But they not connected to anything else. And in a short time, it will be forgotten and brushed away.

And it is not just a Salesforce problem. It is happening in every ecosystem in every client around the world. So it adds up to over a TRILLION dollars of waste. And it has gotten worse because low-code apps enable anyone to rapidly build an app.

And all these unused apps are technical debt that is killing the performance of your platform and slowing down future development. We will be covering technical debt in a later article in this series.

Just say “No”.

The core issue is that there is not enough rigorous business analysis (BA) performed before you launch into development. Sadly, the Agile movement when combined with Low-code seems to have been derailed and reconstituted as “if it is wrong, let’s just rebuild it as it is so fast.” That is a perfectly acceptable approach for prototyping but not for the development of strategic applications.

For those who remember OrgConfessions.com (anonymous implementation horror stories), the major root cause of all the 1200+ problems was insufficient business analysis. Fortunately, Salesforce is investing heavily in business analysis training with Trailhead badges, Architect courses, and the Business Analysis certification. But there is still more work to do to educate the ecosystem.

At Dreamforce22 there was a fantastic session by Vanessa Grant and Andrew Russo called “Just say No”. This idea was echoed by Jodi Hrbeck in her recent book. Here is an interview with Jodi  where she raises the point that some people don’t even realize that they can say “No” to users’ change requests.  It is all about how you ask business analysis questions.

What is business analysis?

Business analysis is all the activities to get from a wishlist item or change request through to a complete risk-assessed user story that can be passed over to the development team. This may feel like a lot of work, but it is significantly cheaper to make changes in design than when the code is in production. This is concept is called “Shift Left”.  The earlier (further left) in the development cycle we find problems, the quicker and easier they are to fix.

The core business analysis activities are below divided into 4 phases. What is critical is that if ANY of the 4 phases are missed out or not done rigorously, the analysis is incomplete and there is a huge risk that your development effort is going to be wasted.

Here is an interview with Adrian King talking through the 4 phases.

1. What does the business really need? This is by capturing the business requirement
2. Validate requirements by analyzing the data model (ERD) and map business processes and then tying them back to the business requirements.
3. Create risk assess user stories by taking the requirements and breaking them down into work items or user stories. The risk needs to be assessed from a technical (org impact), business and regulatory perspective.
4. Group stories into releases based on the risk profile of each user story.

Here is the interview in full.

Where does Change Intelligence fit in?

The business analysis process that Adrian talked about creates a number of different documents that need to be accessed and updated by different stakeholders through the implementation lifecycle…and beyond.  They also accelerate future development as they are the critical history that is used for future impact analysis.

A Change Intelligence platform is where all the documents are created, stored and analyzed.  We like to talk about Change Intelligence in terms of the 3 C’s

• Content: You need all, not just some, of the documentation to be able to make informed decisions. This means everything related to the core Salesforce platform, customizations and Managed Packages, but also where they are integrated into enterprise on-premise and SaaS apps.
• Connection: Connecting knowledge, where ever it is stored, takes a fraction of the time compared with the creation of the content. It can be automatically analyzed and connected. Providing access to the most up to date content saves hours of frustration and wasted time.
• Context: By analyzing the connected content in context means we can uncover insights that save costly rework and release roll-backs. This early analysis is core to the Shift Left concept – “the earlier you find issues, the cheaper they are to resolve”. The pace of change, the scale and complexity of Salesforce implementations and the number of integrations to other apps means that this analysis can now only be done automatically.

Need to know more?

Run a free proof of concept with us that is tailored to your org and where you want to focus.  During the proof of concept we can then help you build a business case that works for your budget. Like many of our clients, you will probably already get benefits that can pay for Elements.cloud BEFORE the end of the proof of concept. We call that RBI: Return Before Investment.

Talk to us about the challenges you have.   https://elements.cloud/bookcall