Cross-functional projects can stall even when delivery appears healthy. Development may follow the sprint plan, while the commercial side expects faster results. A shared roadmap does not solve this conflict unless it also explains how the future operating model will work.
Defining the future operating model alongside the roadmap can be particularly useful for programme leads and project managers. It also applies to business analysts and product operations specialists. I developed it while working as a Programme Lead on projects involving both technical and commercial teams. In this article, I share what I learned through a predictive dialer rollout for an organisation with 50 sales and call-centre employees.
Map interpretations before processes
Before defining a process, I identify how each function interprets the project. I ask what will change in their daily work and how they will recognise a successful result. These questions show whether people are working toward the same outcome. They also reveal conflicts that may otherwise appear later as resistance.
For the dialer rollout, I recorded each function’s expectations in one working document. The CEO expected revenue growth, while the Commercial Director wanted salespeople to spend more time with customers. Engineering prioritised stable integrations, but call-centre leaders saw disruption without a clear benefit to their KPIs.
That finding changed the direction of the rollout. The concern about sales and call-centre KPIs was evidence that the new technical solution conflicted with the existing performance system. It also revealed that business process redesign was missing from the roadmap. Once I understood that conflict, I could address the objectives that still rewarded the old behaviour.
Redesign the process and align performance objectives
Introducing the dialer changed more than the technical workflow. It affected how managers handled leads and how their work could be monitored. My initial approach was to demonstrate the system and answer technical questions, but this did not resolve the main concerns. Most objections were about how the new process would affect day-to-day work.
I therefore involved team leads and call-centre managers in redesigning the workflow, while sales managers helped define the future lead flow. This also helped separate technical issues from concerns about workload or performance monitoring. Once these issues were discussed as process questions rather than product defects, they became easier to resolve.
The redesign also exposed a problem with the existing performance model. Some activities previously measured as individual KPIs were now automated by the dialer, which made those metrics obsolete. However, they were still linked to managers’ compensation. Keeping the old model would therefore mean assessing employees based on work they no longer performed themselves.
I brought this issue into the programme and discussed it with commercial leadership. The performance model was revised to reflect the new workflow. Successful call transfers and conversion into sales became the main measures, while time spent on the line was also tracked. Team leads were assessed based on managers’ participation in calling, and the rollout was incorporated into commercial leadership objectives.
The changes were approved before the full rollout, with no retrospective cancellation of bonuses. Once employees understood how the new process would work and how their performance would be assessed, resistance became easier to manage.
Run syncs that make decisions
A status meeting can share progress, but it does not resolve disagreements between functions. I therefore rebuilt the weekly cross-functional syncs around unresolved decisions. Engineering and CRM specialists explained technical constraints, while commercial leaders joined when a decision affected the operating model.
For each disputed request, I asked which business objective it supported and whether it aligned with the agreed project goal. Requests that could not meet those criteria were removed, regardless of who proposed them. This prevented unresolved requests from accumulating in the roadmap and made it clearer what each pilot test was supposed to prove.
Define what a pilot can prove
A half-day pilot taught me why test boundaries need to be defined before the test begins. One manager worked with 100 leads. The pilot was designed to check whether leads arrived in the correct order and whether calls connected. I also reviewed how the funnel stages were updated. Because each defect interrupted the manager’s work, the conditions were unsuitable for measuring productivity.
Leadership later questioned the dialer’s value because the manager had processed no more leads than usual. However, the pilot had never been designed as an efficiency test, so this comparison could not support that conclusion.
Since then, I have used a one-page brief before each pilot. It defines the question and the criteria for judging the result. It also states what the test cannot prove. This keeps a narrow functional result from being used to assess the whole programme.
Measure business outcomes
Process metrics can show whether a system is being used, but they do not prove its commercial value. I prioritise results that leadership can connect to business performance. When an outcome has several causes, I state that limitation rather than assigning the full result to a single system. When a suitable business metric is unavailable, I define how to measure it.
After the rollout, call-centre productivity doubled. SLA performance improved sevenfold in the first year. Business-unit revenue increased sixfold within 12 months. I used the result to show the scale reached once the technology was supported by the revised operating model.
Treat the project frame as a deliverable
For me, the project frame is part of the implementation. Requirements explain what should be built, while the roadmap shows when the work should happen. Neither document can align a business unless it reflects the future operating model. Programme leads must make that model explicit before rollout.
In the dialer project, the technology became ready before the organisation. The requirements described the system, but they did not explain how each function should work after launch. I closed this gap by treating the rollout as an organisational change and adapting the operating model to support it. As a result, the roadmap became a plan for organisational change instead of a schedule for technical delivery.
Featured image credit
