Triggers. Sometimes the smallest thing you see can trigger what seems like a lifetime of angst. Recently, a LinkedIn update from a former co-worker brought me back to a complex transformation project we worked on together more than 20 years ago. The project was to build a customer relationship management (CRM) database for a large auto manufacturer.  Our firm was to provide strategy and viewer while project management and coding were to be done by other partners. The tone of the entire project was set at our first meeting when one of the contractors responsible for coding said, “We build missile systems, how hard can a CRM database be?” It turns out, a lot harder than they thought.

Now our agency probably came across as snot-nosed kids to the seasoned engineers who may have actually worked on the Apollo space missions (most of us were in our 20s or early 30s). Who were we to tell them how to do their jobs? This underlying “credibility gap” in terms of perceived competence, business strategy and work style created stumbling blocks that slowed the project and reduced the scope of what was produced. The takeaways from this project have shaped every transformative project I worked on from that point forward. Be it marketing, supply chain, or general process transformation. Here are a few of the lessons.

Common Language

In the CRM example, this was the first relational database for our client. As a result, we had to educate them on the key differences between flat files both in terms of design as well as the hierarchy of data. With this came new terms and a need to change how we collectively spoke about data. We also had to be sensitive to the pride of the seasoned team and not talk down to them. Consider how your kids explain Venmo to their grandparents.

A supply chain example of language differences between disparate groups can be shown with the phrase “long tail”. In supply chain terms, long tail pertains to items with intermittent demand such as spare parts. The long tail can drive up costs and become operation challenges. In marketing, the long tail pertains to ads and other properties that continue to produce results long after the campaign ends. Think of printed swag with a URL on it or a saved email. This is positive for campaign results – and is an operational challenge to attribute over time.

When there is not a common language/terms, each member of the team understands conversations and next steps differently. This creates confusion and mistakes. One way to avoid this is to generate a glossary of important terms and phrases at the start of your next transformation project.

Silos

For the CRM project, we all reported to the project owner (a senior executive) and all communication flowed up and down with little communication across our three functional groups. As a result, if there was a challenge for our team, we wrote a report which flowed up to the executive and then (if he wanted to) back down to the other teams. This also created competition between functional teams for the executive’s time and attention. The outcome was a slowing of decision-making on critical issues and contentious meetings where there was more finger-pointing than problem-solving.

These days, project management software has eliminated much of the up/down communication and drives an impressive amount of “forced” collaboration. Still, silos do exist, though more surround budget and outcomes. IT has a budget; Ops has a budget and oftentimes varying goals based on these budgets. It’s important to be sensitive to team needs and be able to relate them to the overall project goals.

Process vs Progress

This project was well before today’s world of agile development. In 1999, it was mostly mag tapes and mainframes. Process was important in this environment to control labor and prioritize projects. The IT vendor had binders upon binders of process documentation. If a tape was to be pulled with data, it required form completions, approval by management and then a time for it to be run. In effect, it took 3 to 5 days to get data. It was like tree sloths shooting clay pigeons. Plus, prioritization was often determined by the level of the executive making the request and not by the benefit to the project or organization. This was one stumbling block we could not work around. The process was entrenched. However, we were able to help filter requests before they came to the project management team.

Traditional vs agile supply chain

Utility vs. Value

Successful transformation projects deftly make tradeoffs between what is nice to have and what is necessary to deliver the expected results. Some of the nice-to-have items are often pushed to phase 2. The critical things to ask when weighing utility vs value are:

  • Is it necessary to achieve goals?
  • What is the scale of the impact of the item?
  • How complicated is it to implement?

It’s basic triage.

There is scope creep, delays and loss of momentum when this is not contained. In the CRM example, every division of our client wanted custom data fields and we had to work hard to manage expectations regarding what data fields would benefit all as opposed to just a few.

What if it Works?

Let’s consider the impact of success on the company and people. In the CRM example, success would result in less revenue for the IT company responsible for project management. The database we were building would eventually be hosted in-house and managed by an internal team. So, the more successful the project was, the worse it was for them. This created headwinds designed to slow the project (and sabotage it).

In the supply chain, there is a common fear that transformation and automation will eliminate jobs. Especially for less technically trained team members. It is important to stress that team members can be retrained or provided new roles. Also, remind the team that with improved service levels and less inventory comes more cash to invest in the company and staff. Try to make your conversation less about the “numbers” and more about the positive impact it will have on the individual and the opportunity for professional advancement. A team that is bought in on the project’s benefits will ensure more successful adoption of the technology and better results.

If you are about to embark on a transformative project, I hope these war stories provide a useful perspective. If you are thinking about making a business case for a new project, check out this white paper on managing supply chain transformation. It will help you prevent the war stories I just relived.

Managing Transformation Beyond IT CTA