Your First Four Steps in Transforming Enterprise IT Governance

Enterprise leaders often ask us how to get started in digital transformation. The question usually comes after a discussion about the urgency of transformation and what a transformed enterprise looks like—the benefits of transformation and the business models it enables. At first, the journey seems long and involved; the changes dramatic and far-reaching. We often suggest that companies move resolutely but in small increments. “Great idea,” the executives say, “but how does that apply to IT governance and investment management? How can you make small, incremental changes starting today with immediate impacts in an area that is so vital and that requires care and accountability?”

What makes governance and investment management seem particularly challenging is that the digital way of doing things appears to sacrifice control and accountability—exactly the focus of governance—to achieve speed. That is a misconception; in fact, the digital path offers better control and accountability—but its mechanisms are very different. In the digital world we harness speed, agility, and automation rather than extensive pre-planning to improve control. To put it bluntly: digital transformation is actually a betterway to carry out your fiduciary duty to your shareholders and other stakeholders. It is also a better way to secure your information systems and to build a company that will remain healthy in the long term.

Yet IT investment management and governance practices must change to align with digital strategy, and the change is urgent because the old way of governing investments is adding risk and keeping companies from accomplishing exactly what they are trying to do through digital transformation. The traditional IT governance approach—based on organizing IT work into large projects, building and approving business cases, and managing against rigid plans—is slow and limits innovation. In today’s digital environment of uncertainty, complexity, and rapid change, the assumptions made in business cases cannot be trusted—the pace of change itself makes plans outdated even before the project begins. The traditional method doesn’t work anymore, yet executives’ fiduciary duties and their need for control hasn’t gone away.

When it comes to changing governance and oversight models, I think there are four critical overarching objectives, and there are immediate steps that can be taken for each of those objectives. There is little risk in moving forward incrementally—why not try these steps and see how they go?

1. Reduce the Size of Initiatives

Large initiatives are risky and take too long. Given the uncertainty and rapid change in the digital world we have to expect that over the time it takes to complete a large project, the enterprise’s needs will have changed considerably. Instead, enterprises should take advantage of the cloud and DevOps to work quickly and see results from even small sets of requirements. In the digital world, we are looking for fast time to market (or to value, for internally-facing applications) and fast feedback to see if what we are building is actually accomplishing its objectives.

To start moving toward smaller initiatives, leave your current initiatives in place, but for one or two new proposed projects work actively to reduce their scope. If necessary, take a large idea and break it into stages, which can each be funded separately. The important thing is that each stage must deliver completely functioning capabilities into users’ hands (and actually be used!). Based on the business results accomplished in each stage, decide whether to fund the next stage. This is important: each stage must show actual business results. When I say “results” I don’t mean that software was created or deployed—I mean that revenue increased, costs declined, competitive positioning improved, customer service improved, or the like.

As a target, I would suggest that initiatives be limited to what can be done in six months or less.

2. Reduce Lead Times

Consider the lead time from idea to capability (“concept to cash” in some cases). This is the time from when the enterprise decides that it wants or needs to do something to when that thing is done. I don’t mean the time from when requirements are handed to IT to when an IT system is deployed. I mean the entire time from the original idea to when the idea is actually having a business impact. Map the entirevalue stream. Then start aggressively reducing that lead time.

Typically, this will include things like assembling the idea along with other related ideas into a project, preparing a business case, putting it through an investment governance process, writing requirements, creating and approving a project plan, assembling teams to work on it, developing and testing software, training users, and deploying the capability. With contemporary IT techniques, every one of these steps can be sped up. If you have started on Step 1 (reducing project size) then you will have already made a large impact on lead time. Try streamlining the investment management process (smaller projects might mean less overhead, for example). Don’t write a big requirements document; instead, have users work with developers while they are creating features. Don’t hold features until it is time for a big deployment; release each one as it is ready.

It is easy to get started on this step as well: just map the value stream, choose a few “low hanging fruit” areas where you can begin shortening the time required, and have at it.

3. Start Finishing

In the digital world, progress is measured by finished product (“finished” means it is making a business impact). In the old world, we measured progress by hitting intermediate milestones in a Gantt chart, or maybe by estimating completion percentages (“we’re 37% finished developing this feature”). But in the digital world, every capability is in one of two states: finished or not finished. With the cloud and DevOps, it is possible to finish a small IT capability quickly and then move on to the next one and the next.

I like to ask two questions at each moment: (1) What is the vision or the outcome that we are driving toward? And (2) what is the smallest thing that we can do (finish) in order to move toward that outcome? The answer to the second question should be something that can be finished in between one day to two weeks. Remember that finished means finished. Done. Complete. Ended. Over.

To move forward with this step, I suggest putting in place a bit of scaffolding. The team that will start finishing things quickly should have available to them some technical tools: (1) the ability to spin up some cloud infrastructure, (2) a secure “landing zone” in the cloud, and (3) a set of DevOps tools and processes that makes a “pipeline” to production. Go ahead and do this on the smallest scale you can. AWS can help you set these things up quickly, and, of course, you only pay for what you wind up using.

4. Change Focus to Outcomes and Hypotheses

In the traditional model, we organized our governance around sets of requirements. A project was given a fixed scope and its business case was based on the projected costs and benefits for that scope. The problem is that the business outcomes of any particular set of requirements are highly uncertain; in a way, the whole scheme is backwards. What we want to do is start from a desired business outcome and then find the least expensive way to accomplish that outcome.

What we have called a “requirement” in the past is really just a hypothesis that building a particular feature will help accomplish the outcome we desire. Like any hypothesis, it needs to be tested. Often we can build a minimum viable product or some other experiment that will test our hypothesis. If the hypothesis appears to be valid—if there is evidence that building the capability will help accomplish our desired outcome—then we continue to invest in it. If not, then we stop and think of another “requirement.” By proceeding this way we accomplish two things: (1) we reduce the risk that we are building things that won’t have the impact we expect, and (2) we control “feature bloat”—that is, the amount of work we do that is not really necessary for accomplishing our goals. This saves money and reduces risk.

To begin down this path, choose a small project where the desired outcome is simple and easily measurable. For example, increase the number of claims an adjudicator can process in a day from 10 to 15. Choose a reasonable (tentative) spending level to accomplish this goal. That is the entire investment decision. Now begin generating ideas for how to accomplish the goal, test each one, build it if it seems promising, and check to see how many claims an adjudicator can now process. Decide whether it’s worthwhile to continue investing. If so, proceed to the next hypothesis. Keep going until the expected return from continuing is less than the expected cost.

These four steps make up both the long-term vision and the first steps in getting there. Each allows for experimentation and provides low-risk ways to proceed. Try them!

–Mark
@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value
War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age (now available for pre-order!)