by Esther Shein

The art (and science) of the IT project pivot

Feature
Jul 08, 202012 mins
Digital TransformationIT LeadershipProject Management

Shifting business needs and faltering progress are just a few reasons why an IT project needs course-correction. Here’s how to recognize the signs and make difficult changes for the good.

Agility and resiliency are skills that have become big buzzwords these days, but so is the ability to pivot. Arguably, the biggest project pivot for all CIOs in the past few months was stopping what they were doing to move their organizations to full remote work virtually overnight, after the COVID-19 pandemic began.

That’s different from projects in motion that veer off course, which happens often. Recognizing when it’s time to change direction — and how to do it — though, is something of an art. These IT leaders have found themselves in positions where they had to pivot and have some advice to offer.

Be bold

It’s important to acknowledge when something isn’t working — or when it’s out and out failing — and take quick action to turn around.

For example, Mars Global had a project underway in 2017 to replace a legacy warehousing management system in its pet nutrition business unit in Russia. After testing approximately 70 percent of the functionalities of the new system, the team discovered several detrimental issues that made the go-live date of Q1 2018 not feasible, recalls Miao Song, global CIO of Mars Petcare.

“The root cause was that the global template didn’t fit the local need for [the] business operation,” she explains. “After careful review, we made a bold decision to put the project on hold, and quickly evaluated another technology … that had shown promise with other [consumer packaged goods] companies in Russia.”

At that point, Song says, she made the tough decision to kill the existing project and go in a different direction. Eventually, officials opted to deploy SAP Extended Warehouse Management in multiple locations in Russia, which she says turned out to be the right decision for the business.

“We view projects in need of course correction as opportunities, rather than failures, not just from a management perspective, but also from a leadership learning perspective,’’ Song says. “The key to success is creating a safe environment for people to quickly learn from [these experiences] and adapt to the situation, find different solutions and quickly fix the issue.”

As a CIO, Song says, “I always encourage learning and open-mindedness.”

Analyze, adopt and adapt

When Chris Zeller thinks about projects that need to pivot, he likens them to working in a hospital. “Remember the TV show ER in the ’80s?  I look at what I do when it comes to new challenges like a doctor or nurse would in the ER,’’ says Zeller, director of IT at vitamin and supplement company Country Life. “You prioritize and triage the different events happening. Someone who can’t breathe takes priority over someone with a broken bone.’’

This means constant evaluation while a project is under way, says Zeller. Even when a team proceeds with a plan and the objectives they have to meet, things will go wrong, and a good leader will be flexible and agile, he says.

“It also involves very close workings with the executive team and support from them’’ to know when it’s time to change direction, Zeller says. “I’m fond of using the 3 As: analyze, adopt, and adapt.”

And be resilient so you can “recover quickly from difficult conditions,” adds Song. “In this project, the team’s resilience enabled them to turn the situation around.”

Listen to your customers — and watch the competition

Often, projects are tested when they are in the design phase, and there are some sure-fire indications that something isn’t right, says Dave Garrett, chief strategy and growth officer at the Project Management Institute.

Negative feedback is obvious, but sometimes you have to read the more subtle signs. One is there’s “no excitement and there’s no one asking, ‘How much will it cost, and can I get it now?’” Garrett says. “If you’re creating something compelling those are the questions you’re going to get.”


Also be aware of changes in the competitive landscape, he says. If there isn’t a sense of urgency to get a product into the market, there’s a good chance it won’t succeed. “This happens a lot in pharma — if you have two different cancer drugs, usually the first to market wins and the second will have to close down because it will have difficulty gaining market adoption,’’ Garrett says.

Fast testing is critical, agrees Song. Organize the implementation into discrete sprints, she advises. On Mars Global’s warehousing project, she says: “Instead of moving slowly through the entire project as a single entity, the project team was able to work more quickly by ensuring the success of each phase, as well as funding the project by stages. The functionalities were also carefully tested.”

You also can’t have tunnel vision and only focus on the end result — that is a recipe for disaster.

“If instead you focus on outcomes — what should that thing do for your customers, you have more space and you open your mind and your vision up to different possibilities to get there,’’ Garrett says. “A product could change over time and there’s more discussion around different ways to achieve that outcome.”

Pay attention to the data, and your people

Learning to pivot is not only an art, but a science. When you have data, it’s hard to dispute what the facts are telling you.

That’s what Robert Rosales learned during the implementation of a payroll system project. Rosales, director of IT at Oak Harbor Freight Lines, a premium service carrier on the west coast, says one of his programmers was working on building an interface for the system. The project was more than 75 percent completed when the programmer realized that the APIs required to create the interface would have to go through a third-party provider.

“That was not going to be a sustainable process,” Rosales says. “There were multiple potential holdup points because it was not a direct API extract from the vendor’s database.” The project team felt the process would be too cumbersome and would create time lags.

The vendor didn’t have another product available, so Oak Harbor dropped the vendor and went with a different one that offered a better solution for the interface, he says.

This resulted in a lot of bruised egos with the project champion, Rosales says. “I had to emphasize that the project was for the company and not for one person.”

Typically, when this happens there is a tendency to want to stay the course, he adds.

“But you have to pay attention to the data and the advice of the technical staff, in this case, the programmer,’’ Rosales says. “You want high commitment, low stress. … If it had happened a quarter of the way through it would definitely have been a lot easier.”

Still, Rosales believes that “if you cut your losses, you’re still ahead of the game rather than continuing to feed a losing project.” But he admits it was not an easy conversation to have with upper management. There were different camps: those who felt they should keep going because of all the time and money already invested, and those who realized that supporting the system down the road would be difficult.

Now, the team is starting over from scratch. “But really, the main thing is we’re not losing the vision — we need a new payroll system — we just need to take a different path to get there.” The team would still have gotten to the finish line if they continued the path they were on, he says, but the system “would have been full of bumps and bruises and not be sustainable going forward.”

Determining when a project needs to pivot won’t necessarily be identified by the person leading the project, says the PMI’s Garrett. “It is likely to be identified by the person who is closest to the customer or closest to the product.”

Rosales says that before he escalated the issue, he made sure “my data was in order and I could articulate the danger going forward.” He did his own investigation once the programmer came to him. Then he had a conversation with one of the senior leaders first. “You test the waters and then get feedback” before alerting the rest of management, he says.

Think platforms, not projects

Historically, aging technology was addressed in a “project-based thinking” approach at AvidXchange, a provider of payment automation software, says Angelic Gibson, CIO. That meant fixing one area of the platform on an as-needed basis and then moving on, “as opposed to zooming out and having a platform focus,” she says.

When you apply platform thinking, “you can truly understand where the friction points are and tear them apart and innovate faster,” she says.

There are several products that make up AvidXchange’s portfolio, and Gibson found herself “dealing with silo-based thinking” when the refresh was well under way. When she joined the company 18 months ago, “we literally put a pause on the work and shifted to platform-based thinking.”

Gibson spent her first six months evaluating the state of health of the technology and says when she looked at what their customers wanted, “our delivery pipeline wasn’t fast enough.”

IT needed to become more agile, she says, and leaders needed to understand all the key metrics along the way. Like Rosales, Gibson says, you need data to make your case. She spent time monitoring the usage of their platform to understand patterns.

“The idea of flying blind without data would be crippling,” she says.

If there are gaps in the data, it’s up to IT leaders to come up with a strategy to close them, she adds. “You have to remove all the friction points from ideation to production whether in your processes or the technologies you’re working with.”

Beware of biases — and constantly evaluate

Sometimes people are married to a particular technology and develop certain biases, Gibson says. “But if we test and learn there’s too much friction to absorb the technology into production, we shouldn’t be spending cycles trying to get it to work.”

IT leaders should be looking at the problem they are trying to solve rather than use a technology that seems cool that may not be right for the business case, she says.

Echoing Country Life’s Zeller, Gibson says the art of the project pivot requires being able to assess and evaluate whether your processes are agile and can meet the needs of your customers in a timely manner.

“I don’t like the idea of failure but testing to learn and use those learnings to inform the next step,” she says.

The leading indicators of when it’s time for a project pivot are when you have long lead times getting something of value into production, if it’s hard to deploy and if you are constantly changing things and causing higher than normal project incident rates, according to Gibson. That’s when it’s time to pull back and evaluate.

The issue becomes clearer when there are several roadblocks in front of you, she says. “You can attempt to move past things but as you find yourself introducing more workarounds you realize … the path isn’t as straight a line as you thought. That’s when you realize you have to pivot.”

In her case, “We threw everything up against the wall.” One of the ways IT solved the agility issue was to move to microservices and they built APIs that retailers and loyalty partners would subscribe to, she says.

Always align to business value

Successful projects demand alignment at every level, says the PMI’s Garrett, so that everyone’s driving toward same goal. “Sometimes in the agile world we call that the definition of done — what does ‘done’ look like in a product?”

If you understand the totality of the value being delivered to the customer it helps you decide when you need to pivot, he says. An effective leader will be able to pinpoint the places where IT needs to focus their energy, he says.

Business objectives are changing faster than ever before, and projects are inherently global and need to scale, Garrett notes. Couple that with intense competition, and digital projects tend to get bloated. CIOs need to think about the value they are delivering.

“If a team isn’t paying attention to what you’re saying and it’s not resonating with them on the value you’re delivering, take a step back,’’ he advises. Home in on what matters to them and what’s frustrating them and solve for that. “If you’re not delivering value, what is it you can deliver that will add value?”

Similar to Gibson’s platform versus project approach, Garrett also suggests CIOs focus on being customer-centric as opposed to product-centric. “You’re solving to their most urgent needs versus the ones that are solved by the product you already have. Figure out where the pain is and address that,” he says.

More on IT leadership