Financial Understanding

In 2013 I wrote a series of posts about what to do as new CIO. My thinking continues to evolve on this topic, but I’ve come to rethink the need to understand the financial model for IT in your organization and to put greater urgency on that understanding.

In an enterprise, an IT organization and associated investments are made to facilitate the operations of the enterprise and to protect the enterprise. We don’t make investments just because they are fun or just because we want to do them. There is a driving force behind these investments.  Those forces are things like: operational improvements (reduce waste, speed, reduced friction, etc.), financial control, collaboration improvement, security, etc.  The benefits of these investments are mostly outside of IT. Yes, some investments benefit IT, but most of what we do benefits other organizations. Saying it differently, the costs might reside in IT but the benefits reside elsewhere.

That is the central problem/opportunity to understand. How does your organization account for this fact of life? This simply must be understood by all parties and it must be clearly highlighted to all parties and that takes a lot of help from Finance. This is probably one of my biggest failures. I should have done more in this area.

Projects in IT can save tens of millions of dollars in operations or across the supply chain yet cost millions in IT to make that happen.

M&A activity are particularly dangerous to IT in that unless the costs of integration are budgeted and called out and planned for as part of the go/nogo decision on the acquisition, IT can appear to spending a lot of money to integrate that that is not really an IT cost, it is an acquisition cost. I read a while back that the two biggest risks in M&A efforts is merging cultures and IT complexity/integration risks. A company board might decide to spend $600M on an acquisition but that decision should upfront account for the cost to integrate the companies together.

IT spend is a cost to do business. Probably, the best answer to this problem is to work out a clearly understood, above board way to charge costs back to business units that are driving the investments. That chargeback would include the startup costs for sure, but also might include the sustaining costs to run or support the capabilities. In any case, the costs need to be clearly visible and either chargeback or shown back to the business and across the business. Tools like Apptio might greatly help in these conversations too.



Cloud Platforms and M&A Work

So I’ve been wondering if having a system in a cloud platform makes it easier to do M&A work, i.e. integrate an acquisition into your company’s environment. Is it easier to merge them into a cloud platform than to an on premise platform?

I know of what case where an acquired company and the acquiring company were both using the same cloud service. One might think it would be easy to merge them together, i.e. the provide could flip a switch or run a script or press a button and the domains would be merged. Not so fast, doesn’t work that way, actually very hard to do. In fact, a 3rd party is needed to merge the domains. Weird, strange and dumb.

In another case, three different companies that were merging used the same cloud service. In this case, it was easier, not because they could easily merge domains, but because all three companies had the same skills and knew how to use the systems and thus merge the systems. In this case, the new combined organization had lots of expertise that could be applied to consolidate the systems. However, one might argue that this would be true even if they were not a cloud platform, i.e. a on premise platform.

It seems to me that the advantage of having a cloud platform like is that all the companies are on the exact same version. The cloud integration completely avoids the problem of being on the same software but different versions. That would seem to be the key advantage. Less variables to control.

What other advantages can you see? Is it an advantage at all? What do you think?

1B) Portfolio

The second top priority (ball being juggled) is to find out what your IT team is working on right now.

If you don’t have a complete inventory of your IT projects from small to big, then ask your team to work on it. The creation and ongoing management of this portfolio of work is one of the key, ongoing requirements for an IT leader. You simply must know how your people are spending their time and where your budget dollars are going. Portfolio Management is one of the most important things you must focus on because there is always, forever, no matter what, more to do than can be done. Your organization must have a good understanding of what is going on.

The portfolio should include information about each  project including costs, timelines, risks of not doing and risks of continuing, business purpose, business counterparts and champions. There are countless tools and systems that can be used to track and manage the inventory and there has been countless articles written about this need including earlier ones by me here, here and here.

With this portfolio, you can begin the assessment of how what you are doing (Portfolio) matches with what you are learning while (Connecting). As you continue the conversations with your counterparts, you can continuously test how well your team is helping the other teams succeed. This is an ongoing process and can start with the first conversations or later ones.

A good understanding of your IT portfolio gives you several advantages. First, it can inspire confidence in you and your team in the eyes of others. If you can always given an accurate picture of what you are doing and why, then it helps your peers feel confident in your work. Second, an accurate inventory helps you have smart conversations with your CFO and your boss. You can discuss trade-offs if necessary, you can explain relative priorities, you can discuss spending needs out into the future, etc.

The portfolio is a key. Build a good one and build a good process to keep it up to date.

No IT Projects


Everything we do is a business project. Quit calling them IT projects. What we do in IT is for the business or there really is no reason to do it. If we are working on security, it is protect the business. If we are upgrading a system it is because our business partners need the new functionality or we are reducing risk to the business by getting to a current or supported release. If we are installing new hardware it is for a business reason.

We really don’t do IT projects. Quit calling them IT projects. Especially when the IT part of the business project is only 10% of the project.

OK, I’m off that soapbox. For now.


Time for a Simplification

You know, this IT stuff is getting harder. There are more threats/risks, more control points and demands, more functionality being required and more services being delivered. There is just more and more and more going on and it is getting harder to keep on top of all of it. I wrote of wicked problems a while back and those hard problems are still here with us. And business is speeding up with supply chains getting shorter and moving faster.

The combat these changes in business we need to:

  1. Simplify where you can. Ask your team where we are doing things that are not adding value and not helping the core part of the business succeed. Tell your staff and your teams that if you are driving complexity or chaos, that you expect them to speak up. Then be sure to listen when they do. If you can’t listen to their response, then you are in the wrong job.
  2. Make non-strategic things someone else’s problem. Can you move your mail environment to one of the several cloud email providers and cut all those servers in your data centers? Can you find other SaaS solutions that will simplify your universe?
  3. Surround yourself with great people and then get out of their way. You’ve got to have great people all over the place and then trust them to run the business. The leader should focus on strategy, operational expectations, relationships and staff development. The leader shouldn’t get into the weeds of database tuning, patch management, detailed feature reviews, etc. except where there is a critical gap of some kind.  I need to keep repeating this to myself.
  4. Put good metrics and scorecards in place. Measure what needs to be carefully done and don’t measure things that simply don’t matter.
  5. Network with peers in the IT industry and listen to what they are doing and telling you. Don’t ever assume you have all the right answers. Seek out wisdom and experience all over the place. Read.
  6. Network with the leadership in your own company. Connect with them often and listen to what they are telling you too.

What other ideas do you suggest? What have you learned?

Jevon’s Paradox and IT

I came across Jevon’s paradox the other day (can’t remember where) and it connected with me on something I’ve been thinking about the last few weeks. Jevon’s paradox, from Wikipedia says:

In economics, the Jevons paradox (sometimes Jevons effect) is the proposition that technological progress that increases the efficiency with which a resource is used tends to increase (rather than decrease) the rate of consumption of that resource.

While not a direct application of this paradox or effect, it seems to me that a similar effect happens with IT work in a group, department or company.  Namely, no matter how much good work is done in that area, there will be still be a list of additional work to do the next time period. If you manage your portfolio of work by organization, no matter how much you do for that organization in a year, there will be a similar list of work to do the next year. No matter how much you do or how much better the organization gets, there will be a list of improvements to undertake next year.

This ‘infinite’ amount of work is one of the key problems in IT and why always working on improving portfolio management is a critical priority for IT leadership and the business. The IT leadership team has to be constantly working with business partners, customers and suppliers to make the smartest decisions possible about what to work on.  The amount of work is infinite so being busy or having a lot to do is meaningless. What counts is working on the right things.

I’m also thinking that this effect is causing me to pause and re-think some of my ideas or beliefs about how that portfolio management should be done. Perhaps, for parts of the business, you tightly constrain the resources available to work and let the most important or highest ROI type work bubble to the top. Then, divert the large fraction of your resources to work on the truly strategic part of your business. I have to think on this more.

I’d welcome your thoughts on the matter.

A Question About Estimates

I’ve got a question about how others do estimating and then use those estimates in their portfolio planning process.  If you estimate the cost and a finish date on an IT project (or really any project for that matter) and over the course of working the project, conditions change where the estimates are no longer valid, how do you handle the change?   Do you revise estimates along the way and then have the resulting situation where the final product ‘meets’ your new revised estimates?  Or do you hold yourself accountable to your original estimates from the very beginning?

If a group is serious about trying to get the estimates right in the first place and then measuring accuracy over the course of months, quarters and years, how you answer this question is very important.    It seems that you must hold yourself accountable to your first estimates because they are the ones that were used to make a go/nogo decision in the first place.   Furthermore, you want to setup a closed loop process where you try to shrink the gaps over time and minimize errors as you get better at estimating.

This breaks down when events beyond the control of the team affect the project.  Perhaps an unexpected M&A effort effects everything or changes in leadership dramatically change priorities on the portfolio.   In situations like these, the original estimates can be meaningless.

Also, you are learning things as you go along.  Conditions change, priorities change, people leave, etc.  Somehow you need to account for these learnings along the way so you can always provide the best estimate possible as your progress through the project.

I saw a recent report that talked about the need for IT shops to get better at estimating.  Seems like I need to get a good answer on this question first.

I’d be curious how other address this?