Table stakes: Operational keys to success for the strategic advisor

I recently had a conversation with a friend about my post on using big projects to become a strategic advisor in the C-suite. While he agreed with my main points he talked about a recent large enterprise software project he ran and how the CIO damaged his opportunity to become a strategic advisor. It wasn’t because of inadequate attention to the strategic aspects of the project, but rather because of poor operating practices.

Many of us spend our time articulating how the CIO and other executives need to strategically plan and invest in technology-based solutions. What we talk less about are the core operating responsibilities of the CIO and how they need to use operational successes to bolster their position as a strategic advisor.

Big enterprise software projects are really hard. Panorama estimates ERP projects fail around 72% of the time. McKinsey has found that IT projects that cost over $15M run over budget 45% of the time and deliver 56% less functionality than originally anticipated.

While these are scary numbers for the sponsoring executive, they don’t mean it’s impossible to do big visionary things and make a strategic difference for the company. What they do mean is the CIO needs to be able to balance being an operator and being a strategist to build and hold onto credibility in both areas. The trains need to run on time before you have the influence to build an airport.

With that, I will offer four keys to success for any sponsoring executive of a big enterprise transformation projects.

1. Achieve radical transparency

Do not hide problems. Openly report on risks, major issues, and how you plan to overcome them to the steering committee and the team from the start of the project. If there is an issue or risk that threatens to sink the whole project, you need to ask for help from the other executives – it’s their business too. If it looks like you may go over budget (fortunately you planned enough contingency), report it quickly with alternatives for how you will accommodate it. If you don’t have a solution yet, tell them and provide a date when you will.

 This sounds like motherhood-and-apple-pie kind of stuff, but it is incredibly important and frequently disregarded. If you are suspected of being a political player – hiding things that make you look bad and promoting things that look great – people are unlikely to trust your strategic recommendations. And if you don’t get the support the project needs from the other executives the project will almost certainly fail.

2. Make sure the technology works

Ultimately, ownership of the technology itself is squarely on the shoulders of IT. This includes the custom development, mechanics of the software itself, and infrastructure. Whether it’s an on-premise solution, managed services model, or in the cloud, IT needs to make sure the technology and its vendors are successful on Day 1. To ensure this, they need to be successful by Day “30.”

Do not underestimate what it will take to make it work well, get your people the training they need, bring in great people in key areas, and test it early and often. At the very latest, you should test your production infrastructure during user acceptance testing (UAT), which means you will need to complete performance testing even earlier than that.

Here’s the main thing: the technology is capable of working. It always is. If you hit your design and build deadlines, the technology will work. The technology may not work if you miss those deadlines. So push the business and your vendors to hit their deadlines and retain credibility by making sure the technology works when they do.

3. Keep track of the finances

Nothing damages credibility more than appearing fiscally irresponsible or, worse, indifferent. Project actuals and forecasts should be updated on a bi-weekly basis and shared with your project leadership (including your vendors’ project managers) and summarized and shared with the steering committee. I like explicitly showing the “change order” or “over budget” number and maintaining backup detail on the causes of this number in every leadership deck.

If vendors forecast budget overruns, proactively work with them to realign the budget. Be sensitive to the fact that if you only approach this by pushing for free time and deeper discounts, this will filter back to the team and likely hurt the project. Make sure all parties are working together to alleviate budget issues and nobody is taking the brunt of the impact.

 4. Empower your team; monitor results

The only way you will have time to focus on the steering-committee, board-level, strategic aspects of your job will be to appoint strong project managers to lead each piece of the project and allow them to make decisions (and some mistakes). Good project management discipline includes robust status reporting, enforcing hard deadlines, and open and honest reporting of risks. Make sure these PMs don’t feel they will be penalized or shamed for every mistake they make, but rather when things go wrong they will have your support and the support of the project leaders to get back on track.

Finally, recognize that great solution people are often not the same as great project managers. Do not confuse the two skillsets when assigning your leadership team. Good project management discipline is what keeps big, complex enterprise software projects on track and is capable of fixing mistakes in solution architecture. Good solution architecture cannot and will not keep a project on its timeline. Keep your architects in positions of influence on the team, but make sure you still have good management around them.

CIOs are often in the best position of any executive to turn an abstract business strategy into real implementation. Make sure that once your strategic recommendations are adopted by the C-suite you have the ability to execute and retain their trust.