CIO

Table Stakes: Operational Keys to Success for the Strategic Advisor

This post originally appeared on my blog at CIO.com here

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 the post 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. Panoramaestimates 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.

Subscribe to Ronan Consulting Group - Steve's Blog by Email

New Blog Announcement / How CIOs Can Use Big Projects to Drive Their Strategic Brand

As of this week, I officially have two blogs: The one you see here and one at CIO.com.

On this blog, I will continue to focus on a broad range of issues relating to growth, profitability, and technology-driven improvement across the business and continue to make it relevant for smaller and mid-sized organizations as well.

At CIO.com I will focus on enterprise software specific topics. My agreement with CIO.com means I cannot post the same content here for a few weeks, but I'll put up short summaries with links on this blog whenever I add something new. Today's inaugural post is for CIOs looking to enhance their strategic brand within the C-suite. 

An excerpt:

Enterprise software implementations are among the most expensive, visible and risky projects you will undertake as a CIO. They are also among the most strategically important and, as such, can help propel the CIO to the role of true strategic adviser to the C-Suite.

Click here to read this post and subscribe to the new blog.

Subscribe to Ronan Consulting Group - Steve's Blog by Email

System Selection and the Future of Enterprise Software

Today's entry will be (uncharacteristically) brief because Gartner produced an excellent report on this topic that says much of what I want to convey about the future of enterprise tech.

Gartner's point of view on what they are calling "post modern ERP" can be found here. It is worth your time. (h/t to @John_Hoebler for bringing it to my attention) 

I fully agree with Gartner's view on this topic and it meshes with my experience in many of my full-lifecycle enterprise software implementations. For a few clients, the monolithic model has worked reasonably well, but for many - particularly in software, high-tech, services, and media - monolithic ERP has been a clumsy fit for substantial pieces of their business.

Now organizations have more options available to them. The enterprise software landscape is much more distributed than it used to be. The cloud has enabled many new, innovate enterprise tech companies to deliver products that are highly tailored to a single purpose or function (keeping in the spirit of the weather here in the Northeast, "snowflake systems", if you will). There are great solutions that now cover your most strategic functions. Some examples:

  • If you offer bundled services and the billing module of your ERP solution can't do the revenue recognition required, you can now use Zuora
  • If you have a customer service division that now needs to handle both products and services, there are options like Zendesk that can be used for all your call center operations regardless of the product or service that's stored behind the scenes in your inventory or order management systems.

Your ability to reduce the operational overhead of running these solutions - largely by hosting them in the cloud (usually public) - and turn your investment and people to more value-added activities like managing more integrated ecosystem of solutions and systems will be a greater determinant of your future success as an IT organization.

My point is this:

Software selection and project visioning is more important than ever for new ERP solutions as well as new software that supports any major business function.

New federated ERP models will force companies to carefully select the solutions to bring into their ecosytem based both on their fit to the business and their ability to seamlessly integrate with the core of the enterprise. My advice: don't short-change yourself on the selection process.

  • The decision on your systems will no longer be about the level of fit of every module of an ERP solution to your business processes and how much customization will be required. If it's a clumsy fit to order management but supports the rest of your business, try to find a better order management option.
  • Your should not automatically take a "no customization" route to your enterprise software implementation just because it creates IT complexity. If processes will be substantially sub-optimized by a clumsy process to fit an ERP platform, you should look to see if there is another solution available
  • More native integrations will be available and figuring out which systems and which cloud providers work best together will not be an important part of the selection process
  • Long-term TCO is no longer an adequate measure of a system's costs. If you are sub-optimizing business processes and making people's jobs more difficult to do, you are understating your TCO by ignoring the opportunity cost in these areas. (e.g. forcing data management responsibilities on a sales force because they are the entry point for customer master data)

Systems selection will be about the business goals you are trying to accomplish through ERP and how the systems will integrate with and support the best solutions for every other part of the business. It cannot, fundamentally, be just about the needs of the core area owning the implementation: it needs to also consider the relationship with the rest of the business and their systems.

Elegance used to be defined as the single solution or smallest set of solutions that can enable your business. Elegance now means the ecosystem of solutions that fit your business so well, they can truly help drive your strategy forward.

Subscribe to Ronan Consulting Group - Steve's Blog by Email

Three ways to think differently in 2015, Part 3 of 3: Technology and Talent

Technology and Talent: The under-rated link between simple tools and employee happiness

In the running of a company of whatever size, the hardest thing to manage is usually this: the delicate balance between the necessity for centralized control and the equally strong need for employees to have enough autonomy to make maximum contributions to the company and derive satisfaction from their work. To put it another way, the problem is exactly where within the company to lodge the power to make different kinds of decisions.”
— Thomas McCraw, American Business, 1920–2000: How It Worked

The tools organizations use have a direct impact on the quality of life of their employees. Good tools make people’s work lives better; bad tools make them much worse. Yet, hard-to-use tools continue to take center-stage for a significant portion of companies’ users. Why are we still accepting poor usability as a matter of course in the enterprise? Today we will discuss some of the reasons for this and look at several techniques to help you and your peers in leadership prioritize their people when making technology decisions.

The McCraw quote above is a broader expression of why companies often choose to implement technology: the need to establish control over business processes. This is most transparent in ERP implementations where the very concept is rooted in establishing more controlled business processes. Something we used to say about ERP systems is that even though they make some individual jobs more difficult, there is benefit to the overall organization that outweighs it. This type of thinking is still used to justify avoiding customizations or third-party bolt-ons that would make an individual’s job easier. These turn into “process fixes” which, translated to normal human language, means shifting unpleasant burdens away from the tool and onto the people doing the work. [I redacted an Uber joke that was here – we’ll open that can of worms another day]

Big technology implementations are really hard and take an enormous amount of people’s personal attention and effort. The reason people are generally ok with this is because they think they will benefit from the changes. But too often, when you look at less successful implementations, you see that things actually became more difficult for a substantial number of people.

The Problem with Complexity

Making people's jobs harder, of course, creates problems with “efficiency” and “effectiveness” and “productivity” – the pinnacle of talent management insight. All of these certainly suffer as a result of lackluster tools. The nice thing is that all three can be measured and discretely improved and they’ve been discussed extensively in research related to technology projects. In my mind, they also are only important to a point. Many companies who are focused on these metrics have reached a point of diminishing returns by now anyway.

There is an outcome that you cannot really measure: the connection between the tools and people’s happiness in their jobs. In most situations, people will not draw a direct connection between the clumsiness of their jobs and why they aren’t terribly happy performing them.

There are many reasons for this. Job happiness doesn’t represent a single factor – there is a complex matrix of factors that are weighted differently for different individuals. There are personal and professional reasons, tangible and abstract; physical and metaphysical; social and individual. Talent surveys do their best to pinpoint the source and quality of employee satisfaction, but even the people who create those surveys will tell you that establishing causality through them is an inherently flawed science. Fundamentally, most research agrees that a primary source of people’s job happiness (“satisfaction” is a loaded and misleading buzzword that I try to stay away from) is their feeling of personal connection to the overall mission of the company, and their belief in that mission.

Rosabeth Moss Kanter (@RosabethKanter), a professor at Harvard Business School, has done some wonderful research in this area. Among my favorite of her quotes is the following from a 2011 article called “How Great Companies Think Differently” (which won the McKinsey award for best business article that year). Kanter posits:

…people can be trusted to care about the fate of the whole enterprise—not just about their own jobs or promotions—and to catalyze improvements and innovations without waiting for instructions or sticking to the letter of a job description.
— Kanter, “How Great Companies Think Differently”

She prefaces this with a lengthy examination of why self-organization is desirable and why you don’t want to pigeonhole your people into overly rigid work structures. When the tools and processes people are using consume most of their time, they do not have capacity to accept change, let alone drive it. When those activities become visibly disconnected from the overall institutional mission, we need to expect they will lose a feeling of connection with the enterprise, experience less happiness about their jobs, and this will likely snowball into a number of symptoms of disconnected employees.

Arguments in Defense of the Status Quo

There are common responses to this critique I have had client leaders use as an argument against disruptive change. None of them are focused on the user. 

  • “Our retention rates are above industry averages, therefore our employees’ job satisfaction is acceptable.”

This is an incorrect attribution of causality. The assumptions in this statement include a) industry average retention rates are acceptable. Industry benchmarks can be directionally helpful, but some industries are way behind when adopting change; b) there is adequate mobility in the local market for people to change jobs at will. This is not true for many areas. Retention rates are important for a lot of reasons, but unless your tools are so bad that they are driving people away (which at this point in history would mean using UNIVAC-cards), they don’t really indicate satisfaction with tools one way or the other.

  • “Our HR surveys say our satisfaction rates are high!”

Great! This is important. It also probably means you’re compensating for your weaknesses in other areas. Like you’re giving lots of compensation and a whole bunch of PTO to people may be masking the fact that they really don’t like their jobs. The dimensions these surveys measure tend to move as a group. This doesn’t discredit the importance of the surveys and your ratings, but we need to recognize there are limits to measuring human attitudes. 

  • “Our leaders have many years of experience at our company – we promote from within so they understand the complexity truly required in our business.”

This is also great for many reasons, but it doesn’t really speak to the potential problem. This can also mean that people have accepted your processes and tools as “normal” even more and may be less likely to think changing them is feasible.

What do we do about it?

In general, enterprise technology is too complicated. There are young companies trying to change that (@Netsuite, @Zuora, @Zendesk, @SlackHQ, @Asana just to name a few), but solutions that are currently used at most organizations are overly complex. The complexity of those solutions is made up of three factors:

  1. Business processes
  2. System capabilities (including their relationships with each other)
  3. The cycle of inertia

Business process and system capabilities are complexities that most business leaders understand well. The cycle of inertia is harder to grasp and what, in my experience, leads to the least user-centered enterprise systems. Paradoxically, it’s often the users themselves who advocate for this cycle and their leadership that promotes it. 

The cycle of inertia is as follows:

  • Evolution: Organizations do things in a certain way and change it gradually over time to accommodate immediate business needs
  • Stabilization: Because they are no longer immediate needs, they stop simplifying and innovating how they do these things which eventually leads to an unnecessary amount of complexity in the business. This complexity is absorbed by the people who do the work as it is integrated into their jobs
  • Improvement: When the time comes to evaluate “improving” these things, there is resistance to change because people know how to do the more complex processes really well and they perceive the change as risky to their personal value. The improvement is stripped down to accomplish incremental benefits in the areas of most immediate importance to the users.
  • Inertia: Once the “improvement” is implemented, it ends up creating even more complexity because the incremental improvements add variation to the number of processes, data or systems. Since the organization has convinced themselves it is required for their business, they interpret this complexity as maturation. The cycle starts again.

The bigger the project and more people are involved, the harder it is to avoid this cycle. The only really effective way to overcome fully counteract inertia is by strong leadership support, but there are a few questions you should ask that can make it more likely you will be successful.

Key Questions to Ask

When talking about a prospective project, planning the project, and undergoing design, always ask these questions:

  1. Is this process absolutely necessary for our business? Can any steps be removed or variations be eliminated? The goal is to simplify. Even if the business says they need a certain process, make sure you understand what the intended outcome of that process is. Users are usually correct in insisting they need to do things in a certain way to meet their requirements; the real question is are the requirements important in the first place.
  2. What part of our business mission does this feature, software or process support? If it can’t be easily mapped – if it’s clumsily shoehorned into a part of the mission statement or if its relationship to strategy is heavily assumption driven (e.g. the strategy says we’re growing our services division and we’re assuming those services may be custom products, but that has never actually been established) then it’s not important enough to put effort into.
  3. Is the new system, bolt-on or customization required to make the system easier to use or to support a critical business process? Do not purchase additional software if it doesn’t make things significantly better from a usability or functionality standpoint. If it’s going to be supporting a specific business process, refer to question #1. It it’s critical for the business process but doesn’t make things easier, look for another option. Every additional piece of your ecosystem makes things become geometrically more complex to support. Make sure it’s justified by making the business processes simpler.

And one special question. You know if this applies to your organization. For systems that are replacing Excel or Access: Is the new system going to be easier to use than Excel and/or Access? Excel-intensive operations yield really smart Excel users. People who are great at Excel are not going to want to switch to a system with basically the same functionality they have today but without the flexibility Excel provides. Make sure the system adds value to the user experience – not just to the enterprise.

Technology Characteristics to Prioritize

These three technology characteristics have the most substantial impact on usability and the perception of usability. Weigh these strongly when evaluating a new solution anywhere in the business.

  1. User interface: Does the interface look like something employees use at home? This is too often minimized in the interest of functionality or cost. Make no mistake: for systems, form is function. If the interface isn’t as friendly as Amazon or Zappos or Zillow, it will not be considered user-friendly. Be specific and don’t be afraid to be critical. As a side-note, when working with smaller vendors don’t be afraid to communicate your ideas on how the products can be improved. Many startups will work with you on improving their products and actually rely on that type of feedback.
  2. Mobile: Will the system by available to my employees on more than one platform and does it at a minimum allow, at a maximum encourage mobility? This assumes you have a hardware policy that allows laptops, tablets and smartphones for these employees. If you have any group that is still tethered to their desks, think very long and hard about whether it is truly necessary. Mobility doesn’t just mean working from home; mobility means the ability to work in flexible teams around the office, hold group working sessions and, when necessary, work from home, hotels, airports, etc.
  3. Integration: Do the activities supported by this software interact with other groups or systems? If so, is that integration native or at least buildable? It needs to be. If you are integrating a system that will require users to complete dual entry or run reports to make the data portable you’re purchasing the wrong system.

In Summary

Improve people’s tools and give them a path, a method and a reason to continue to improve them and they will be happier with their jobs. Happy people yield positive results for them and for you and good tools multiply improvement. Strive for simplicity, humanity and continuous real improvement in your tools. Who knows – maybe your job satisfaction ratings will even improve.

Subscribe to Ronan Consulting Group - Steve's Blog by Email

Three ways to think differently in 2015, Part 1 of 3: Strategic Reactions

Happy new year and welcome to our first blog entry!

This week I will look at three new ways of thinking about something you will undoubtedly spend time and money on this year: technology.

  1. Strategic reactions: Exception handling as a means of driving strategy – 1/6/15
  2. “Enabling” vs. “Driving”: The issue with treating technology as an “enabler” – 1/8/15
  3. Technology and talent: Improving the experience of work through every technology project – 1/9/15

Strategic reactions: Exception handling as a means of driving strategy

The way the discourse around technology operations unfolds is always similar: you can either spend money reacting to problems (IT Operator) or growing the business (Strategic Driver). The problem with this reductive conversation is it understates three realities:

  • Even if you're driving strategy, you will still need to react to issues;
  • Technology will probably drive the implementation of your strategy whether it's incidental or intentional; and
  • Most businesses do not bifurcate responsibility for technology operations and technology strategy.

It is unlikely you have the luxury of technology that runs itself without any exceptions and therefore be allowed to fanatically pursue all your strategic goals. On the other side, you will necessarily need to engage in a technology project over the next 12 months to either keep up or to "enable"/“drive” strategic business improvements (more on this on Thursday). The question is how do you do execute the latter while managing the former?

Framework: Visualizing Reactions and Strategy

A more constructive conversation, in my mind, is one of tradeoffs that recognizes the strategic potential of any solution. Consultants sometimes use "process maturity" analysis to help executives understand where on the scale of reactive to strategic their technology decisions fall. This approach is that it implies a binary relationship between solving problems and driving strategy. This does not reflect the reality of how technology, which is now pervasive in every direction of your business, needs to work. You will have more issues to deal with in the next 12 months than you will have projects to drive: this is a guarantee. Great executives will make this work for their strategy. 

I am a proponent of speaking in terms of gradients rather than discrete scales. There are necessary tradeoffs you will need to make, sometimes prioritizing strategy and sometimes prioritizing operations. That’s ok. Is it possible to make some of those operating decisions also drive strategy, either in the short or the long term? Frequently you will find they can.

So rather than a straight-line or x/y axis maturity matrix, I prefer this visual: 

  • Dark blue represents basic operations, or “running the trains on time.” This makes your business work pretty well without substantially improving underlying functions 
  • Light blue represents incremental improvements that will either add up to something significant when combined with future improvements or will make it easier to do something big in the future. This can include adding functionality or reducing complexity.
  • Orange changes the game. This represents fixing a problem in a manner that transforms another function and allows you to achieve a strategic imperative.
Blog 1.6.15 Reaction Strategy Gradient.png

Example

As an example, let’s take a seemingly minor problem that may arise for many companies this year: 

Your accounts receivable (AR) department receives a payment from a customer but it’s missing an invoice number. They go to apply the payment against an invoice and find there are two records for similarly named customers, each with open invoices. What should they do?

For simplicity’s sake, let’s say there are five issues this raises (in reality there are more):

a)    Immediate functional problem: cannot apply the cash
b)    Future functional problem: this will happen again in AR if the customer record issue is not resolved
c)    Operational problem: the operational efficiency of all processes associated with duplicate customer data will suffer inefficiency and potentially ineffectiveness
d)    Cross-functional problem: if these records exist in other systems (e.g. CRM, order management, etc.) then upstream processes will be affected
e)    Strategic problem: Meaningful customer analytics are severely compromised or not possible

First, you will need to figure out which invoice to apply the payment to, solving problem (a). This will probably require the AR department to contact the customer and do a little research. This is simple operations for them now. They’re going to do this anyway, regardless of our conversation. But now the question is how to address (b), (c), (d) and (e).

Pure dark blue: Combine the customer records into one, consolidate the invoices to that single customer, and resolve any data conflicts that arise (e.g. duplicate invoices, multiple shipping sites, missing DUNS numbers, etc.). This addresses (b).

Dark blue moving to light blue: Consolidate the master records for this customer and then, thinking this may be an issue for other customers as well, run reports and figure out if there were other records this applied to. This address (b) more thoroughly, begins to address (c), and makes solving (d) easier and, therefore, more realistic.

Purer light blue: Look at other systems that use that data like your CRM systems to see if the same issue needs to be resolved there. This will address (c) and make it possible to address the rest of (d).

Light Blue moving to orange: Create a customer data management responsibility where someone in the business is responsible for proactively monitoring customer data, resolving issues, and over time working with a technology partner to automate duplicate identification, merges, etc. This address (b) and (c) completely and may substantially address (d) although this will also introduce some new process complexity that will need to be analyzed.

Orange: Implement a data management solution that can manage the customer data across all functions. This will improve the sales team’s ability to accurately identify and track leads, allow integration between social media and customer transactions, provide efficient lead-to-order-to-invoice-to-cash conversion, and serve as the foundation for great customer-based analytics. Odds are, customer-based marketing and spending analytics are on your strategic radar. This will address (e) and, in doing so, drive new ways of thinking, analysis and decision into all customer-related business operations. 

As you can tell, there are unlimited variations of each of these approaches and they all have different complexity, levels of effort, costs, and time horizons. But as an executive you need to make sure the business operates at all, operates at least reasonably efficiently and reasonably well, all while furthering your strategic goals. Maybe you do all of the dark blue things now because they are low effort and low cost, but begin the process of planning and prioritizing a project to address the orange potential.

The main point is, you’re reacting to an issue in a manner that furthers your strategy and demonstrating to the business, through step-wise improvements, that bigger investments in previously ignored, seemingly commoditized areas can result in game-changing improvement.

You never let a serious crisis go to waste. And what I mean by that it's an opportunity to do things you think you could not do before.

Up Thursday: Moving from an “enabler” mindset to a “driver” mindset for technology decisions. A.k.a. Making Technology Investments Matter.

 

Subscribe to Ronan Consulting Group - Steve's Blog by Email