You've sold the C-suite on a new project. Only now things aren't going according to plan and the data is telling you it may be time to either pivot the project or abort it all together. How do you decide whether to pull the plug or try a different approach? And perhaps the biggest challenge of all how do you have that conversation with the C-suite? In an interview with The Enterprisers Project, Patrick Butler, chief product officer of resume writing services at Talent Inc. offers some insights.
The Enterprisers Project (TEP): Is it a greater danger to quit too soon or too late? Are there specific signs that tell you a project will simply never work out and its time for a change?
Butler: Transparency is optimal. I've never regretted taking accountability for introducing a project that went off track or even failed, only that I didn't do it sooner. An honest mea culpa demonstrates the ability, willingness, and maturity to learn from mistakes.
The type of transparency is important too: eliminate emotion and stick with metrics. Throwing engineers under the bus or blaming other departments can obviously create long-term problems. A red flag for something going awry isn't missing a deadline, it's seeing morale and productivity impacted by the missed deadline. Did we simply underestimate the time needed? Or, are we trying to build a solution for a problem that doesn't exist and the team subconsciously knows it? I try to surface any issues to management as soon as this happens, especially since they usually can help see the obstacle from a new perspective – or help expedite killing a project, if necessary.
TEP: If you do decide it's time to make a change, what is the best way to broach that to the C-suite? Are there times you shouldn't? Times when the circumstances are optimal?
Butler: I am a huge proponent of setting time limits in advance for hitting goals, so the tricky situation you describe doesn't arise. That way, you're dealing with fewer decisions when the deadline passes, and the C-suite is already on board with making a call. I've fallen prey to waiting until I could temper bad news with good. It only sometimes helped at a personal level, but it might not always have been best for the business. Rip off the Band-Aid and make the decision as soon as you know it needs to be done.
TEP: What if the project is one that's been requested or sponsored by the C-suite and it just isn't going to work out?
Butler: It's a great question because the answer is nuanced. Typically, a project sponsored by the C-suite has fewer hypotheses backed by data. This isn't always a bad thing; these executives are tenured experts, and moving quickly can make or break a business. When that's the case, it usually means one of three things: it's a just a hunch, or it's a pet project without tangible KPI or both.
With the fiscal hunch, data is a powerful ally, but framing the presentation is even more powerful. With pet projects, you're dealing with human emotion. Avoid making it personal and support your assessment with facts. If the goals were agreed upon in advance, stick to them. If they weren't — and next time, make sure they are — reveal key metrics in everything that is core to the business. Maybe it's revenue, ROI, page views, banner clicks, cost per FTE, or a number of widgets rolled out. Each business and business unit is different, which is why the scorecard should take the complexity out of the decision. If you can't come up with cold, hard data to validate your proposed solution (even if it's killing the project altogether), it's unlikely to be the best solution.
TEP: What are the most common mistakes you see CIOs or CTOs make around letting the C-suite know when a project needs to pivot or abort?
Butler: The obvious mistakes are waiting too long and placing blame on the wrong person, department, or project sponsor. Contrary to some executives' beliefs, technology departments are more than just cost centers. In fact, many of the world's most famous business models came from tech and data delivered by CIOs and CTOs.
That said, CIOs and CTOs often can get an inflated view of their department's self-worth. Tech leaders who make this mistake risk alienating employees and building products that aren't needed. The most common mistake is the CIO/CTO who fails to compromise in this respect, then fails without even realizing what went wrong. You'll recognize these people as the ones who complain that management didn't see the vision. Unfortunately, they're likely to repeat the process again, which is completely preventable.
TEP: What general advice would you give CIOs and CTOs about handling this very delicate situation?
Butler: There's a reason agile methodology has become so popular, and that's because it works. Data and new requirements empower you to course-correct, which benefits everyone. While I certainly don't advocate a one-size-fits-all product rollout for every business, iterating on the process is perhaps more important than iterating on the product itself. Getting ahead of the process, and delegating accountability in advance of any product push is ideal.
