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.

Who Is Responsible for Quality?

This week we’re going to take a break from talking about Agile in IT operations so we can examine quality in IT.

When Edward Deming, the Grandfather of Quality, taught his methods to the Japanese in the 1950's, he was working with a group that had historically been known for poor quality. Invited by the Japanese Union of Scientists and Engineers to assist Japan in their post-war reconstruction efforts, Deming taught Japanese management, scholars and engineers to focus on quality in order to produce world-class results and become competitive in world markets.

Japanese Leadership

During his early lectures, Deming quickly realized that quality cannot be sustained unless an organization’s leadership focuses on its importance. Initially, he lectured plant managers and engineers who had no authority to implement change. When Deming consulted with his Japanese hosts, they understood the problem and arranged for him to speak to about 100 top-level business leaders.

Deming instilled in these leaders a sense of responsibility for quality in their organizations. He maintained that, ultimately, quality is created in the boardroom and is the responsibility of top management. With senior management supporting quality efforts, the Japanese companies and economy would flourish.

Japanese Success

Deming predicted that Japanese companies would export their products all over the world and companies in other countries would be clamoring for trade protection from the Japanese within five years if they followed his recommendations for improving quality. Although the Japanese business leaders did not initially share his vision, they did as he instructed so they would not lose face. Japan surprised the world with their success and even beat Deming’s prediction by a year.

You probably know the rest of the story regarding Japan's success and what American organizations had and still have to do to catch up with Japanese firms. American firms confused quantity with quality. Demand for American goods was so high in the 50's and 60's the American manufacturing companies assumed this translated to quality for the customer.

However, this misconception was created from the great economies of scale available to American companies due to the war engine. At the time, the United States was the only country in the world which could produce at levels necessary to meet demand. As soon as Japan could both meet demand and offer higher quality, American companies fell behind in world markets.

Putting Out Fires

I have found that many IT organizations function similarly to the manufacturing model that existed before Deming’s quality movement. They judge the quality of their product, IT services, by the demand for that product.

For example, when a system goes down and IT team members scramble to get it working again, companies reward this behavior by praising the heroes who got up in the middle of the night to fix the issue. These individuals are suddenly visible and valuable. They are motivated to continue putting out fires rather than to improve system stability. The incentive to become system arsonists is greater than the motivation to create quality systems.

Continuous improvement is a hard sell for some IT professionals because doing a quality job means nobody notices IT. The better the systems run, the fewer chances there are for heroics. A quality IT group is almost invisible.

Deming’s 14 Points

Below are Deming’s 14 points for management transformation. They were originally published in Out of the Crisis by W. Edwards Deming.

Although the 14 points were written for a manufacturing scenario, try to translate the recommendations into ideas for an IT team. Following these points in your IT group can help you focus on making quality everyone's responsibility.

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.

2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.

3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.

5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.

6. Institute training on the job.

7. Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.

8. Drive out fear, so that everyone may work effectively for the company.

9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.

10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.

a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.

b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.

11. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.

12. Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means abolishment of the annual or merit rating and of management by objective.

13. Institute a vigorous program of education and self-improvement.

14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.

Deming’s 14 points transformed manufacturing into a quality-focused delivery system. The same benefits can be realized in IT, creating continuous improvement in IT processes and products. When quality is built into your IT systems you can increase the value of your department to the business, decrease time spent on downtime and reduce the load on team members who have to fix problems caused by a lack of quality.

The Journey Toward Quality

I realize I am not giving much in the way of suggestions for translating the 14 points into action but I would encourage you to study how you can facilitate making quality core to your business.

All the excuses you will hear from your team about why these 14 points won’t work in IT are probably the same excuses manufacturers made before they made the shift to quality. The arguments have already been made and overcome and the benefits of following the 14 points have been clearly demonstrated.

If you haven’t started the journey toward increased quality and would like help, feel free to reach out to me. I can provide you directions to start. Good luck!

Patrick Phillips and Jen Browne

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