Today’s pace of business demands that IT move quickly to address business needs – which has a prerequisite of IT getting very tight alignment to what the business needs and doing that work in the right order. It seems basic. But IT has a bit of a history of focusing solely on IT performance – cost, quality and speed – and being a little light on clear business outcome metrics. With these measures, IT ends up driving toward standard solutions in the name of efficiency but forgets to measure business effectiveness. Here is why this happens.
The Shift To Efficiency Created Problems
If we look back at the history of technical solutions deployed in business IT, we see wave after wave of attempts to bridge the business/technology chasm. In the 1980s, we saw the emergence of case tools (if you are too young to remember, look it up). Case tools were supposed to be the ultimate in connecting business process and data to application development. Once you had the business defined right, then COBOL code was automatically generated. You would never write a line of code again.
Then we had object-oriented development, then services-oriented architecture, then micro services and many others too numerous to mention. While there was nothing intrinsically wrong with these approaches if you started with the business process first, companies never became good at starting with the business process first.
In those few companies that were successful in deploying these approaches, one often found a business-oriented IT group and an IT savvy business group working together. Humans, not methodology, were the bridge between business need and technical solution. Sadly, that entente seldom lasted past the coming of the next new fad in IT.
In the turmoil of transition to a new methodology, the focus on business effectiveness often got lost. When a company loses the connection to business impact, the only opportunity for IT is cost. And if cost is the only concern, then standardization and centralization are very attractive.
MORE FOR YOU
The Effect Of Centralizing And Standardizing And ITIL
Centralizing and standardizing the development process made the situation worse. How? Just ask Stuart McGuigan, the former CIO of the U.S. Department of State and, earlier, the CIO of Johnson & Johnson.
“At one level, we know that optimizing steps within a process instead of the end-to-end processes as a whole is wrong. In fact, local optimization can lead to rapid sub-optimization of the end-to-end process since you end up making the bottleneck worse,” says McGuigan. “And the bigger the company, the more tempting it is to centralize and standardize by vertical silos and, as a result, sub-optimize the horizontal processes.”
He explains how the mistake of not instrumenting manufacturing processes end to end occurs. “If the company measures manufacturing efficiency by itself, then setting up the manufacturing line once and running it forever is the best strategy. If distribution is measured on inventory costs, then the warehouses do not want all that product, and often neither do the customers. Only by modeling the horizontal end-to-end process from a customer perspective can you optimize operations while meeting customer need.”
As companies diverted their focus to becoming efficient, they lost track of what a business-effective IT organization looks like. There are great frameworks like ITIL to help structure the approach to delivering IT services’ but here, too, it is easy to lose focus on what matters.
“You can check the ITIL boxes that you have ‘implemented ITIL.’ I have worked in organizations that had all the basics: incident management, problem management, change management, etc. So, from an ITIL-implementation perspective, they got a perfect score. But as we collected no business metrics, we couldn’t know if we were providing increased reliability, better performance and lower costs to service from a user perspective. We had the form of ITIL but not the substance.”
McGuigan says that rolling out new systems that do not make people happy sometimes is viewed as inevitable and the price of doing business. But he counters with this mindset: “That’s the opposite of what we should be doing. We should build systems where people say, ‘Oh, thank God! This system does 10 things that I need to do (or that a customer wants us to do), and I can’t get them fast enough to grow the business and serve customer needs.’”
He adds, “If your internal users are not after you to speed up rollout and cheering IT on, then stop and start over.”
Is It The Perfect-Fit Product?
When companies focus on efficiency instead of effectiveness, they do not stop to first consider whether a product is perfectly fitted for what it is supposed to do to solve the business need. It seems basic that this would happen. So, why is it typically not the case?
Agile development methods are designed to solve for this. The Product Manager role is supposed to be filled by a business decision-maker who is an integral part of the Agile team. McGuigan says the problem arises because the right people from IT and the business are not actually in the room together and, even if they are, they are unable to articulate to each other what needs to be developed to solve the business need.
“There are only a few cardinal rules for Agile to be successful. One of the most critical is that teams are self-directed. Without the business decision-maker in the room, teams can’t really decide things like what is in a release and what tradeoffs can be made to achieve business results quickly. Agile teams without a business owner in the room are just doing short waterfall iterations. I have never seen Agile really succeed without being self-directed, and I have never seen it fail when the business is part of the team.”
On the IT side, in theory, it should be possible to find someone who is gifted technically and knows how to solve system problems and adopt new technologies. But McGuigan points out that the company needs to provide a technology career ladder, which rewards individuals who want to stay technical and be part of these teams.
“R&D organizations provide a career ladder for scientists,” McGuigan explains. “Some technology organizations include a career ladder, but it’s not prevalent enough.”
For companies that see themselves winning or losing depending on their success with technology, an increased focus on IT talent just makes sense.
“Find the people on the business side and in IT who are passionate about an issue and the company’s business and get them involved at the front end in the interface discussions,” says McGuigan.
Otherwise, the company can end up with developing a product that is not perfectly fitted for solving the business needs.
The good news is there a proven remedy for solving ineffective communications between the interfacing IT and business leaders. I will share insights on this remedy in my next blog.