I ran out of altitude, airspeed and ideas all at the same time.
— Test pilot explaining why he ejected
For an organization to pilot a marketing business process only by bringing in what may be thought to be a technical resource to work on a marketing project is not at times easy. The sponsor may prefer to hire a marketer that can do technical work.
I’m often brought in under these conditions to help assess the best way to establish a database-driven demand generation operation. Usually I propose a 4-phase development approach toward delivering what becomes essentially a global marketing operations ecosystem.
And under these conditions my first job is typically to build that first database plus all other adjunct assets that it will need to stay alive. Then the fun of using the entire system to operate the marketing business begins. My approach is rather straightforward. It involves:
- Defining a marketing operations process first, then proving the concept that it can be automated and that this automation would enable improvements in operation efficiency, thus, cost reduction as a reason to make the initial investment. This step is known as building the proof-of-concept or POC.
- Next I build a short-term pilot version of this POC and run it for a specific amount of time with a focus group to test and collect intelligence on how to fine-tune the process under evaluation.
- Third comes the launch of a long-term pilot that covers more interest groups or even the entire marketing organization.
- Finally, after refining the process enough to know where most efficiencies are found, I migrate the tested-out process onto a more robust, scalable and permanent platform.
All this work has always involved internal information technology resources, as well as third-party software vendors and service providers. The projects are intense, but can be very exhilarating and dramatically effective at changing the way the company does business. But the politics are usually thick. Here is one experience to learn from.
Taking Off On Four Phases In The Real World
I began a project once by presenting the 4-phase approach to the sponsor, who proceeded to take me before the CFO and information management decision makers to convince them to fund the entire proposal. By then we had built a POC that took 4 weeks to complete, and the sponsor had already approved development of a pilot that would run for at least 6 months but no more than 1 year.
The business process that we would pilot was very comprehensive. It would cover about 60% of what the business wanted. Contingent upon the interim system’s success would be support to migrate it to a more reliable platform later on. This would allow delivery of the remaining 40% of the process requirements upon completion of the interim system migration effort.
However, a variety of influential stakeholders had come quietly to expect the pilot to do more than what the sponsor had agreed with my manager and me to provide to them. The sponsor, in fact, had misled them, by getting excited with the additional requirements that he had heard from them. He therefore decided to accommodated their expectations without telling the pilot team anything about it.
The stakeholders came to expect about 10% more than what we had planned for, agreed to and committed to deliver.
That Sponsors Are Critical Is No Joke
During development I learned of this discrepancy in expectations, and with my manager requested the sponsor to clarify for the client base what would be delivered. But he became obfuscated, frightened and unwilling to revoke what he had initially said to them.
He would not own up to having to level set expectations with the client base. His own boss, the companys Chief Marketing Officer was silent on the matter. Months later we came to learn that the sponsor had intentionally kept him in the dark about everything.
Slowly but surely stakeholders began to insist during discussions that they anticipated more than what was required of the pilot. This raised the risk of project failure to an unacceptable level. To mitigate this risk, my manager and I organized behind a strategy to build more room to meet additional requirements.
We designed the pilot to cover 75% of the defined business process, while never acknowledging that they had ever been part of the original project scope. In professional project management circles this “change as you go” practice is known as “scope creep” and its insidious.
That Creeping Sensation
Scope creep means that instead of freezing requirements for a project and officially holding the line and allowing no more changes until a next phase is agreed upon, Management decides to modify a deliverable ‘on the run’.
This leads to a cycle of disappointment, as issues continue to originate from stakeholders who assume that any time they encounter a complication with what is being presented to them, it is because the requirement that could have resolved it was omitted or forgotten.
They wont recognize that the interim system was meant to deliver only a particular degree of functionality by a certain point in time, and that the next level of functionality is being captured, in fact, as official requirements to formalize as a plan of action for another project phase that will subsequently arrive to fulfill them.
In short, scope creep is a recipe for disastrous discontent.
Despite having prepared to cover 75% of process requirements with this pilot, the client expectations continued to change even during interim system launch. This made its adoption very challenging, forcing the task to take twice as long as necessary and requiring the pilot team to add yet another 5% of additional process coverage before the system was finally embraced. Nevertheless, no sooner had the process been successfully accepted than process efficiencies began to become apparent.
Marketing activities that used to take 8 to 12 weeks to complete now could be done in 2 days. Unexpectedly, however, the volume of activities rose from 30 to 150 per quarter.
Although the company could afford to execute faster on the 30 events, it could not afford to execute much more than 30 events. The sponsor now faced a serious operational challenge. He would need to establish internal controls to keep more efficient marketers from burning through the budget at a faster rate than usual.
The Critical Creep That Was A Joke
For this sponsor the fear in confronting his own organization to level set their expectations on what the pilot was meant to do for them, resurfaced in his unwilling to force it to adhere to internal cost containment controls for over a year.
Cost trend information began to pile up immediately after pilot launch and was collected for over 6 months.
As the time came to forecast the next years run rate, the CMO in stunned disbelief said that the estimated expense rate would be unsustainable and instructed his direct report to ensure drastic cost containment for the following year.
He failed to achieve this, despite significant effort from his own staff to demonstrate that a stronger hand was required to compel the business to perform within budget constraint. The well-oiled machine was running almost flawlessly and getting fine-tuned with every cycle revolution. But the user base was out of control. This was neither a process nor a technology issue. It was entirely a managerial issue.
Amazingly enough, the run away cost situation together with the client base resistance to adoption that scope creep had created a year earlier, blended with the aloofness of the CMO had all provided ample room for the sponsor to point to a grumbling organization as being dissatisfied with a pilot that now covered 80% of the process requirements and supported 100% of the demand creation operation for over 90% of the global organization.
This misplacement of responsibility struck a raw nerve both in the team that had worked to build the pilot as well as in the user base that now depended on it, and removed the focus away from taking on phase 4 in the 4-phase approach and placed it onto an attempt to reinvent the wheel.
In Conclusion
The lesson? Building a marketing operations ecosystem, as challenging as it can be, may actually be the easiest part of the work in establishing a database-driven demand generation operation. The toughest part of the job is managerial and may involve having to manage your manager, coax stakeholders and step on leeches.
By far running a pilot is harder work than both building a POC or migrating an existing process onto a new environment, because running a pilot is equivalent to flying an instructor plane. Its not as safe as flying a simulator. Its not as complicated as flying the MIG. But you can still kill yourself while trying to convince your trainee that flying is the easiest thing in the world to do.
Return to Marketing Automation from Pilot A Marketing Business Process