IT Must Adapt or Die: This Story Brought to You by the Third Party Providers Trying to Make You Irrelevant.

Five years ago, less than 25% of business leaders rated their organization’s IT function effective at delivering the capabilities they needed. Today the number hasn’t changed. IT functions have strived tirelessly to understand demand, set priorities, deliver effectively, and capture value, yet the results still disappoint. Business and IT leaders alike feel they should be getting more—more efficiency, more innovation, more value—from technology. Unasked QuestionsAmong all the talk of engagement, alignment, and “being part of the business,” one assumption is never challenged—that for information technology to grow in strategic importance, so must the IT function. But what if this is not the case? What if a dedicated, standalone IT function is no longer the best option and the function’s resources and responsibilities were better located elsewhere?

Lets face it traditional IT is under assault.  Frankly if you can't compete with these threats then you deserve to lose the battle.  Look at the change in who can provide value to your organization without any involvement from IT.  Today third party providers can create shadow IT footprints all over your organization.  There's little to stop them when they are providing more value to your customer then you are.  There are a tremendous number of consultants out there who will attempt to prepare you to compete against these firms.  In order for anyone to be successful though I have posted the five greatest shifts your IT organization must make in order to stay competitive and continue to provide value to your customer.  

Evolution 1: Data/Information Over Process – The rise of technology delivered as a service, or the cloud, will significantly reduce sources of competitive advantage from information technology. In theory, a start-up could use the cloud to obtain the same functionality, scale, and quality as an industry leader. Thus reducing barriers to entry which will certainly even the playing field.   Differentiation will lie in how IT manages change, integrates its service portfolio, and critically, exploits the information the services generate.The nature of demand for information technology also is changing. Most employees are now knowledge workers. Social media is becoming vital for customer and internal communication, and data volumes continue to rise. As a result, in the business areas that drive growth—innovation, marketing, sales, customer service—up to According to Marty Pine (Marty Pine is a recognized thought leader and an internationally known Global Business Services Professional who has worked as a senior executive in customer, provider and advisor companies.) 80% of IT enablement opportunities relate to business intelligence, collaboration, or the customer interface. At the heart of each of these opportunities is the need to capture, integrate, and interpret information, both structured and unstructured.

Evolution 2: Eliminate the IT Silo and Embed in the Business – Traditional corporate structure is on its last leg. All corporate functions have the same problems: their capabilities overlap; they do not control the outcomes they enable; and after many cuts, they are struggling to find the next big efficiency. And for organizations growing in emerging markets, no corporate function has the scale or expertise to provide sufficient local support.The IT function shares these problems. It has skills in strategy, program management, business process design, and sourcing. All are valuable, but none are needed solely for delivering technology, and so they can all exist elsewhere.  I have discussed this before when defining organizations as vertically managed.  There is no visibility across the value stream because firms are not set up to execute that way.  Creating an IT organization which can 

Second, no amount of alignment and partnership changes the fact that the IT function enables business outcomes that someone else controls. Much value has disappeared down the hole that this situation creates. Finally, cost pressures mean many CIOs face the unwelcome choice of cutting delivery resources needed to “build things right,” or management resources that ensure IT “builds the right things.”

The need for efficiency and joint accountability for execution and outcome will change the IT function’s delivery model and organizational location. Technology will be consumed as part of business services as the IT function merges into a business shared services group alongside other corporate functions.

Evolution 3: Rogue IT – Externalization of applications development, infrastructure operations, and back-office processes continues, gradually eroding the “factory” side of the IT function. The pace will accelerate as the cloud enables the externalization of up to 80% of application lifetime spend. As this occurs, internal roles will shift from being technology providers to technology brokers.

Evolution 4: Greater Business Partner Responsibility – Technologies for collaboration, business intelligence, and customer interface all require experimentation and iteration, use non-linear, user-driven workflows, and offer value from diversity across the organization. None of this is easy for a central function to fulfill.A generation of business leaders and end users is emerging with greater technology knowledge and confidence. They see advanced, user-friendly technology as an everyday occurrence, and can recite stories of companies gaining industry leadership through technology. At the same time that business leaders’ expectations, and their ability to articulate those expectations, are quickly rising, the cloud gives them access to unprecedented technology scale and expertise. The fact that cloud services cannot be extensively customized levels the playing field; business units cannot customize cloud applications but neither can the IT function.Together, these trends point to a greater role for business partners in areas where the value of differentiation outweighs the need integration. This is not a return to local control of IT resources, rather it is a shift in responsibility for technology decision making.

Evolution 5: Diminished Standalone IT Role – As IT roles migrate to business services, evolve into business roles, or are externalized, the scope of the IT function will diminish and its headcount fall by 75% or more. Strategy, architecture, risk, program management, user support, and relationship management will exist at the business services level, not within the IT function. The CIO position will expand to lead this broader group or shrink to manage technology procurement and integration. Roles remaining in the IT function will organize around build and run, and adoptan agile operating model to allow rapid value delivery and resource mobility.Organizations that do not make these shifts will be left behind as they struggle to effectively exploit technology and manage an inefficient IT function and an underperforming corporate center. For IT leaders too,the shifts present risk and opportunity. Those who do not adapt face a much diminished role in a group with little strategic impact. But the opportunityis also significant. Leading a business shared services organization offersnew levels of resource and accountability for business outcomes. Another option is a leadership role in a newly empowered business unit that thriveson exploiting technology for competitive advantage.

These five shifts should move your group to one which can compete with third party providers. Research consistently shows that in most companies strategic intent is not clearly articulated, and this leads to a disconnect between strategic goals and daily activities. The better an organization communicates strategy in clear, actionable, and measurable terms, the more successfully the Lean transformation can focus on driving change where it matters most. There are many perspectives and approaches to strategy, but it all comes down to a few simple questions. How does an organization define and differentiate itself in such a way that customers prefer it over their competitors? What are the activities the organization must engage in to achieve this status? And how do they sustain competitive advantage over time, as their competitors constantly try to capture market share? More important, in our opinion, than the details of an organization’s strategy at any point in time is how well everyone in the organization understands the strategic intent, and how this understanding guides their daily thoughts, behaviors, and decisions.

Technical Debt is a Form of Waste

Technical debt. The term has been popular for a while and is used to refer to a lot of scenarios. It was originally coined by Ward Cunningham to help us recognize that quick and dirty coding sets us up for increased future development effort. It has expanded to include the operational support of code. In my experience, one of the most overlooked forms of technical debt is created when operational support requirements are excluded from the project life cycle.

In many companies, operational support is not considered part of the project life cycle. Operational and project work are often completely decoupled at the lower and middle levels of the IT department, only dovetailing because both divisions report to the CIO or VP of IT. However, this very component of the life cycle, operational support, can deliver the most value to the customer.

This disconnect is created when communication between IT and the rest of the business is limited. When the business defines objectives and timelines for a project with limited or no interaction with the operations team, the operations requirements that are needed to support various projects are presented in an abbreviated form or left out entirely. The project team might not even know that operations requirements exist until the code is almost ready to go live, if then.

I recently participated in an emotionally-charged meeting that was scheduled to review the root cause of the failure of a client-facing system. The project team was angry with the operations team for not supporting their code in a highly-available (HA) environment. The operations team was defensive, stating that they didn’t have the time or resources to address their backlog, including the HA environment.

The project team specified an HA environment in their runbook as part of their handoff to IT operations. The HA system was acknowledged by the operations team as a requirement to adequately support the live code, prioritized it and assigned the creation of an HA system to an operations resource. However, the HA system’s completion was not considered release-gating by the project team, so the project was declared complete as soon as the code was live.

The project team expected their live code to be considered part of the production system, with accompanying up-time SLAs. The IT operations group was working on the HA environment, but didn’t have dedicated resources on the project, so its completion was a long, drawn-out process. The same people working on HA were also doing regular maintenance tasks, working on systems for other projects, and putting out fires.

The key point of failure in this conflict was in not consciously determining the value of the various requirements in the project. It is important in this type of dispute for the business to determine where the customer value delivery exists. Most IT departments don’t consider customer value when negotiating this type of delivery. Without this determination, it is almost impossible to correctly determine where to focus resources.

Part of the miscommunication was created in the beginning of the project, when people from the operations team were not included in the project team. It was exacerbated when the code was permitted to launch without an HA environment. It really snowballed when the project team went on to the next project without fully delivering the value of the code in terms of the delivery life cycle. The operations team, with its own unique requirements, pushed code live without ensuring that the requirements were completed, and then repeated the pattern all over again.

After just a few project lifecycles, it becomes clear that the decoupling of IT operations requirements from business requirements within consecutive projects creates a backlog for IT operations that can’t be surmounted without drastic remediation efforts. Furthermore, this lack of oversight often reveals a lack of understanding of value delivery life cycles. When domains are permitted to hand their delivery over the fence to the next group they tend to value less quality over quantity.

Fortunately, this problem has a simple solution. It’s not easy, because it requires being realistic about how many projects your company can complete in a given amount of time. If you have are in the habit of ignoring IT operations requirements, you might be surprised at how much paying attention to them will slow your project completion rate.

You might have to adjust your understanding of the number of operations people you truly need to support your project work. You need to understand the value you’re creating for your customer is not realized until what you have developed is fully implemented and the customer is finding the value in it. You have done nothing relative to value delivery if you’re not ensuring the product you’re delivering is delivered in full.

In summary, pay attention to three key aspects to prevent a buildup of technical debt as a side-effect of project work:

1. Make operations requirements release-gating.
2. Don’t launch on temporary environments to get the product out.
3. Deliver your product to deliver value, not presence.Bring operations people into the project early and often in the life cycle. In fact, make them an integral part of the life cycle.

Projects are not complete unless the systems on which they live are complete and delivering value to the customer. Anything not providing value to the customer is considered waste. Be the change agent in your organization in halting the creation of technical debt.

Jen Browne and Patrick Phillips

Lean Brings Value to IT Operations

Lean practices are becoming increasingly integral with traditional business practices. Lean provides a way for companies to increase value, meaning that a company's clients are willing to pay for a greater percentage of that company's activities, increasing their bottom line.

At its heart, Lean provides an avenue for businesses to reduce waste. Waste is simply work which does not add value to an organization’s service or product. The reduction of waste can result in the recognition of tangible results such as lower transportation costs, greater individual productivity or reduced spending on inventory storage.

With documented, real-world results, it's no wonder that Lean has taken hold throughout modern business management. However, the use of Lean as a management tool is noticeably absent in one area: IT operations. I'm not pointing the finger at these teams of intelligent, motivated people. After working to bring the value of Lean to IT operations for the last decade, I understand their unique difficulties.

Even in companies that embrace Lean practices in IT development, the operations side of the house generally finds Lean to be a foreign topic. Understanding the resistance to Lean can be better understood when one understands the basic nature of IT operations as an interrupt-driven entity.

Lean requires established processes as guidance but many IT operations teams struggle to quantify this operational work. We fit occasional improvements in between putting out fires. We don't always have defined processes, established metrics, or a strong understanding of how individuals on the team accomplish their responsibilities as part of the whole. Even shops with firm frameworks, like ITIL or MOF, often display gaps in process mapping.

A good example of an IT operations group not understanding its own processes came to me from Niel Nickolaisen, a highly respected IT turn-around CIO and proponent of Lean IT. He was talking with an IT operations group about their process for moving changes into production.

They had two processes: the normal process and the emergency process. The normal was long, complex, and bureaucratic. The emergency process was simple and straightforward. So, everyone made sure that their changes were an emergency so that they could follow the simple, straightforward process. I asked them how they had determined the few steps in the emergency process. They said that they had analyzed the normal process and identified the essential process steps and included those in the emergency process. I told them to make the emergency process the only process. The only difference between normal and emergency should be timing. The proposed changes that follow the normal process are reviewed once a week. The emergency changes require gathering the reviewers RIGHT NOW to review the proposed change. Otherwise they are identical. And, since they both only include the essential process steps, there is no reason to create an emergency to bypass process complexity.

The value of creating a Lean process for this team seems obvious, in retrospect, but the waste created by the added complexity of the normal process existed for years until the process was identified and refined. Add up a few of these "obvious" process improvements, examine the resulting waste, and it becomes apparent that there is great potential for bringing the value of Lean to IT operations.

Here’s how you can start thinking about Lean in your IT operations. Today, familiarize yourself with Lean and its uses within IT. Use a mind map tool to fully understand your organization’s work, the number of services it delivers, and where you are putting your collective effort.

Next month, identify a target process from the mind map and value stream that process. This will allow you to begin to organize the foundations for Lean. With your identified process you can start a Lean pilot in your operations group.

Next year, begin to expand its application and the breadth of tools being deployed, including Agile, Self-Service, etc. Based on your early experiences with applying Lean, your organization will begin to see additional process where you can direct your Lean focus.

Jen Browne and Patrick Phillips