Post Go-Live – The RELENTLESS cycle of change and constraint
Introduction
In the last post we looked at how business systems evolved into the complex platforms we use today. Thirty-plus years of development, consolidation through acquisitions, and relentless feature accumulation produced systems of remarkable capability, and equally remarkable structural weight and complexity. Systems that work well in meeting business needs, but that carry consequences most organizations feel every single day.
Let me be clear upfront: these costs are not the result of bad implementations, poor choices, or mismanagement, although those do also play a part in exacerbating the already built-in costs. Even if implemented extremely well; the nature of the systems we use, how they have been developed over time, the constraints of the resources available and processes used for implementation and change, means that costs are built in whether we recognize them or not. They are natural, predictable outcomes of the configure-down model itself. When you build software intended to serve every possible customer and then ask each individual business to carve out the subset it actually needs, certain outcomes follow. Reliably. Repeatedly.
At the end of the last post we had just gone live with our excellently defined and implemented project. We acknowledged that the business starts to change as soon as go-live is complete. What this means in reality is the work we did in that project will need to be repeated across some of the same areas of functionality. Plus, any backlog or additional items defined. This time though the process will naturally be constrained to a shorter period of time and less scope due to the periodic nature of system change most companies will go through. It’s also likely that you do not have the benefit of external consultants to help with their expertise in these change windows.
Going back to our analogy, the dog is starting to feel some perturbations from the wagging of the oversized tail that has been attached to it.
The two types of change
When we come to make changes to the system we implemented there are two fundamental sources of that change. One that is forced and one out of choice. Both must be considered and planned for by the business across its operations and IT teams and ultimately the users.
Type I
The first type is from the vendors of the product(s) that were installed. As part of a defined and known release cycle, Vendors release periodic updates to their products. These releases will contain many things, security updates, bug fixes and new functionality designed to keep the software functional and current. Some of these changes will absolutely be needed or wanted in your implementation, some won’t. Some may bring relief from manual workarounds as new, improved or fixed functionality is delivered. Others will enforce change to the business regardless of need. The work of understanding this change and applying it to your production environment is very similar to the work done in the implementation project. Once again adjusting the business to the software or the software to the business; again, configuring down from the full set.
This time though it is not done from a blank slate but must incorporate regression testing to ensure that the previous configurations, localizations, customizations and integrations are still working as defined, or, as they are forced to be updated as a result of these changes from the vendor. The timeframe in which this is done is also constrained to the release cycle and is repeated multiple times per year. In effect each update is a mini-implementation project complete with all the same steps required; understand, define, build, test, train and go-live and with all of the attendant change management required.
This forces the business to adopt the same schedule of change, not necessarily the schedule they would like, but enforced by the vendor in order to keep their installed software ‘up to date’. Missing one update may cause some issues for the customer but miss more than one and you start to lose continuity, introduce potential security risks and potential loss of vendor support if not on the ‘latest version’. There is not really a choice. Also, if you have modules from different vendors on different release schedules, one every 6 months and one every 4 months, the complexity and change management required is almost unmanageable. All of this is taking up the finite resource that can adapt the system environment, resource that you really would prefer is making the second type of change.
Type II
As we finished our implementation, we acknowledged that there may be a backlog of items that did not get fulfilled, we also know that there inevitably will be business change. A list of items requiring work from the teams responsible for executing these changes is produced, the aim being in essence to improve and enhance efficiency and productivity across the domain covered by the systems. This list can be long, very long. And must go through prioritization by the business entities involved. This prioritization of effort is also constantly changing and must be carefully evaluated to maximize the positive effects. However, this prioritization can come from different areas, some of it from the business environment; keeping up with trends, changed or introduced legal requirements that must be enforced; some from analysis of process to weed out inefficiencies; some from newly introduced or changed products or services; some, as described previously, enforced by the vendor’s updated release (often some of these are ‘non-negotiable’ and must be done forcing the hand of the prioritization team). As this prioritization is finalized it becomes clear that not everything can be delivered.
The Change Management process
Updating the system to perform the requested change may require coding to be done. Sometimes those changes are huge, introducing a new module or functionality that requires massive coding effort over multiple windows; or they could be tiny in terms of number of lines of code updated. Alternatively, the change may be configuration only, adding to or revamping the content of a list of values, no coding required. Each time, regardless of the size or nature of the change, they still require the full change management process to be completed.
The change management process must be adhered to, you cannot allow changes to the systems to be done without it, or risk massive dysfunction if change is not planned, analyzed and communicated. Resource and time are the issues, coupled with the built-in complexity of making those changes. Huge amounts of effort from multiple teams to plan, co-ordinate, communicate, understand, absorb, test and train the changes. As mentioned before these are mini-implementation projects.
Here is an example. The backlog of items coming out of the implementation stood at a count of 20 items. This change cycle has introduced a further 40 change requests, the vendor update has introduced 10. We now have 70 items in the backlog. The prioritization process from the Ops side produces a list of the top 20 items, knowing full well that even this reduced list will not be able to be delivered with the resource available. This is then handed to the IT team who will size each item and define the work required to implement based on the definitions carefully produced by Ops.
The IT team comes back with 8 items they can realistically build, test and deliver in the cycle. Even if the development cycle is for 4 months that does not mean you get 4 months of coding, given all of the ancillary work to define, design and test, the coding portion may be as little as 6 to 8 weeks. Even then some of the work involved in those 8 items may get de-scoped or changed in order to deliver to MVP. For this example we will quantify that as 90% of the requested change. So from 70 items the business is going to get 8 items delivered. That’s 11%. The full calculation; 90% of 11% of what was identified as required to enhance the productivity and efficiency of the business. A portion of which isn’t necessarily on the business’s wish list and is enforced by the vendor’s update. The backlog now sits at 62 items.
The Backlog
Over time this backlog list grows and morphs introducing another process just to manage it. Each change request is not a single line requirement but needs to have documentation for its rationale and objective, the who, what, why, when and how of the need from the business. The attendant process change, metrics, KPIs, ROI, success plans. All this needs to be specified before it can even be logged as a change request. And must be present to effectively evaluate whether it is a priority or not. And if the change is not accepted for development? Then the request is ‘in the queue’ and must be managed over time. Regularly reviewed, checked and updated to reflect the changes in the business baseline.
Let’s go back to what happens to those additional 62 items. Not all of these are immediately required for the business to improve productivity. Some are legitimately ‘nice-to-have’, the replacement of a manual process taking up human resource, that could be automated to free up that resource for other tasks. Others are absolutely required but fall above the cut off line for the prioritized list of changes sent to IT; or, are on the top 20 list but fall outside of the 8 being developed. For example, an additional step in the process to update a sales stage that must be performed by every Rep, every time they move a sales stage. There may be multiple requested items in a single backlog request; a list of 12 changes to Deal Qualification rules that gets rolled out 4 at a time across the whole year.
These types of items all have something in common. They are being ‘worked around’ by humans when the system should complete the task, manual effort in place of code and compute time. These changes may only have a large effect on a few people doing the work, others may have a tiny effect on a large group of people, but that effect is felt every time they perform a task, potentially one they do multiple times a day. In the example of releasing small sets of change to Deal Qualification rules over three change windows rather than one, the change management process is unnecessarily repeated.
And the result? 90% of 11% of what was identified as required to enhance the productivity and efficiency of the business.
The point I’m making
Change is hard, it is constant. In this current paradigm it takes a lot of time and resources within the business. It involves a lot of the same type of tough decisions that needed to be made in the implementation project. Decisions about what should get built and what can wait. It is done in a more constrained window with less available resources. And at the end of all this work the amount of change effected is a fraction of what is required. The rest must be done by humans in the form of manual effort and workarounds. This manual work though is prone to error; bad data entered because governance is not enforced, process steps either not done or done at the wrong time because the system has no guardrails. These manual steps need to go through the change management process. They still need to be communicated to the users alongside the actual system changes. They also generate more work in clean-up of the errors. What we see is layer upon layer of dysfunction that has a detrimental effect on productivity, efficiency and innovation within the business itself.
These patterns are widely documented. Many Salesforce admins report struggling to keep up with the platform’s three annual releases, with technical debt and configuration sprawl making each update increasingly risky and time-consuming. As we have seen organizations often find that only a small fraction of identified improvements actually reach production each cycle, leading to persistent manual workarounds that cost significant productivity, sometimes 20-30% or more in lost efficiency across sales and operations teams. Converting this to a monetary value, that could mean hundreds of thousands or even millions of dollars.
Now fast-forward 2 years, after 6 of these change cycles. Ask yourself this, how much ‘blood and treasure’ has been expended and how far the business has really moved forward? These are the costs that can be readily seen, there are other more intangible and hidden costs. Those are the subject of the next post.
Finally, back to the analogy, just how fast is the dog now being wagged ?
About 90 Degree Circle
Dysfunctional CRM is a money pit. How much is yours costing you?
I advise enterprise and scaling B2B revenue teams on CRM architecture, system drift, and the structural issues that create dysfunction in their revenue engine. With 30 plus years at the intersection of business process and IT systems across ERP and CRM environments, I help organizations diagnose and resolve root cause problems, restoring functionality, operability, data quality, and process flows, so you can finally realize the full ROI your CRM system was built to deliver.
