Get certified - Transform your world of work today


Are You My Customer or My Partner?

13 March 2013

Alston Hodge
SolutionsIQ | Accenture

"IT as a Business" (ITAAB) has been a common marketing slogan and business model promoted by thought leaders from firms such as Gartner, Forrester, and Forbes in the past ten years.1 At its core is a philosophy of managing IT as a self-sustaining service that treats internal users as external customers. The model had its origins in the IT outsourcing industry. At first glance, it seems a logical and responsible IT strategy, especially for companies with large internal IT departments. But recently, a few leading consultants and CIOs have started to challenge this "best practice" based on their experience in the real world of business.

Several writers in the past few years have discussed the fallacy of the ITAAB model. IT organizational specialist Bob Lewis referred to it as "a train wreck waiting to happen."2 IT strategists such as Bassam Fawaz have stated that this "conventional wisdom that is generously dispensed by many IT think tanks and opinion makers is largely theoretical and offers little or no practical value."3 A novel called FruITion, by Chris Potts, presents a compelling story of one company that discovered the fallacy of this IT strategy.

As some companies try to adopt Agile as their primary approach to software development, the fallacy of this IT strategy becomes even more apparent. IT leaders are put into the difficult position of adopting ITAAB versus Agile, or attempting to blend the two, or simply ignoring the consequences of trying to follow these conflicting philosophies.

Recall that transparency and collaboration are promoted as key tenets in Agile product development. Ideally, the IT and business sides of a company work closely together, focused on maximizing business value for the company. One of the key principles from the Agile Manifesto states, "Business people and developers must work together daily throughout the project." The implication is that the business side and the IT side of a company view their relationship as a partnership. For any company that successfully adopts Agile, it understands that IT and business sides actually work as true partners, working in a collaborative and transparent manner, with a common goal of maximizing the business value of their company's products and services. The success of the company depends on this important partner relationship.

Within the ITAAB model, however, a company's IT department tends to view itself as a service provider (a business) and to treat its internal business users as customers. One potential problem with this relationship is that the business users may return the favor and treat the IT department as a business. In other words, the company's IT department could now be viewed as just another IT service provider — which means it could be a candidate for outsourcing. When treated as customers, the internal users are in the best position: They can set high (and sometimes unrealistic) expectations and demands, with the threat that "if you can't do it, there are other service providers willing to try."

This relational conflict between the IT and business sides of a company has become more common in the last four years, as companies struggle through the economic downturn and look for ways to reduce costs and increase speed to market. Unrealistic expectations and demands are naturally fueled by the increasing threat of competition during the latest recession. For some companies, it's presented as a matter of company survival. "Failure is not an option" is a common mantra lately.

Also during the past four to five years, more companies have explored the use of Agile to improve their competitive edge. And for those steeped in ITAAB, Agile adoption can be an eye-opener to the inherent dysfunctions of this IT model. It puts the company into a position of having to choose between the two different philosophies — or ignoring the conflict and suffering the consequences.

Consider the following story of one company whose IT department viewed its business side as the customer and later attempted to adopt Agile.

Business partner or customer?

This particular company was in its fourth year of Agile adoption when I was hired to serve as an enterprise Agile coach to help advance that adoption. My previous coaching experience included working with more than 20 different companies at various levels of Agile adoption, including an insurance company three times larger than this business, plus two other health care companies.

The company's earlier adoption strategy included a pilot with several teams in the first year, followed by several waves of adoption in different areas of the company during years two and three. At the end of four years, however, only about 50 percent of the teams were still practicing Agile. The original adopters, though quite successful in their first 12 to 18 months, were now showing signs of declining performance and product quality.

Within the first week of my coaching engagement, I began hearing the familiar call from IT senior leadership that "we need to focus on pleasing the customer, delighting the customer, proving our value to the customer." I assumed they were referring to the actual customers outside the company, those who purchased health care services and products. But I later learned they were actually referring to the business side of the company — the product owners, product managers, process managers, and so on, who represented the actual customers.

In their corporate communications, the CIO and vice presidents would often refer to the business side of the company as "customers" rather than partners. And, of course, that mind-set was promoted throughout the company on both the IT and business sides. They implemented "voice of the customer" surveys with the business side to better understand its satisfaction with the IT department. This was not a 360˚ survey, however, but a 180˚ (one-way) feedback.

When the company began its campaign of Agile adoption and promoting its values and principles, there were struggles to create a culture of true collaboration and transparency. Though the Agile training promoted these concepts, the view of the "business side as a customer" was difficult to overcome for both the IT and business sides. Four years after the initial training and rollout, most business managers didn't understand and appreciate exactly what Agile had to offer.

As I began surveying the teams and trying to understand their challenges, I found that many Agile teams were polarized. A team would consist of the typical ScrumMaster, product owner, and development team, but an IT project manager and business project manager were added to the mix. Essentially, the team was now two teams in one: an IT team and a business team.

The business team, under market pressures to deliver more and faster, would make unrealistic demands on the IT team to deliver products. The IT team, with the mind-set that the business side was its customer, would not necessarily challenge these unrealistic expectations but would instead accept them and commit to doing their best to deliver, often knowing the expectations would not be met. The business side would then become frustrated when deadlines and budgets weren't met. The IT team would be frustrated with the unrealistic expectations from the business and its own failure in meeting them. Distrust on both sides soon followed. According to their customer surveys, innovation was perceived to have dwindled in the previous four years.

IT projects or business projects?

This company often described projects in terms of systems and applications, more than in terms of business products and services. Project charters were written by business managers with the assistance of IT managers and analysts, but in the language of IT, not business. It was not always clear what specific business value would be realized from completing the project.

How did this mind-set come about? Within this health care company, Agile adoption had been introduced four years previously as an IT initiative, not a company initiative. Significant resources were used to train mostly the IT side in Scrum, while the business side was only introduced to the basic concepts and given a sales pitch: "Agile is an IT methodology and business need only help in prioritizing the requirements." When I asked some senior IT leaders why it was presented this way, one explained, "We don't want to burden the business side with the methodology of Agile. Our job is to take care of their IT needs." When I pointed out that Agile approaches actually require the business side to be fully engaged and, frankly, in the driver's seat, one IT manager stated, "But we don't want the business in the driver's seat. After all, these are IT projects."

This revealed another problem. The view from the IT department in this particular health care company was that they were in the business of delivering IT solutions. Interesting. I thought they were in the health care business!

When we stop and think about it, the objective of every project should be to provide business solutions, not IT solutions. IT is simply the vehicle for delivering business value. If you view projects only from a systems perspective, you miss out on understanding the business value and making development decisions based on the business need.

So I looked next at the charters (vision and scope statements) of some projects and quickly discovered that nearly all were written from the perspective of systems and application and did not clearly explain the real business objectives. Major features were sometimes defined, but usually in terms of systems and applications, and they were rarely prioritized. And since the features were defined in terms of systems and applications, there were naturally strong interdependencies between them, meaning no real business value was achieved until all features (systems) were developed. This meant that there was no need to prioritize them. And this meant that my incremental project was now an all-or-nothing proposition.

When product owners and development teams were handed these systems and application-oriented major features to be decomposed into stories, the resulting stories were, naturally, technical stories. Since the technical stories were based on systems and applications, often there were strong interdependencies between them. Again, no real business value could be achieved until most or all of the stories were completed. This led to several other anti-Scrum patterns:

  • If all of the stories have to be completed before any real business value is delivered, then there is no need to prioritize.
  • With no prioritization, there's no need to have sprint goals. Teams become more of a story factory, cranking out stories within a given sprint that may or may not be related, rather than a feature factory.

The need to market your IT services to the business side: If you see yourself as a business, then you naturally will need to sell your services. That means marketing your services. The money and energy expended on marketing your services takes money and energy away from actual development work. I was intrigued by the notion that IT functions felt they had to market their services to the business side. If we really need to do that, it suggests that the business side has an option of either buying your service or outsourcing it. Perhaps, rather than promoting IT as a business that provides IT services, you should promote yourself as a business partner.

Think about this. As the internal IT department, you have something that no other IT company has: a combination of IT expertise and intimate business knowledge of your company. Anyone can come in and provide IT services to the business, but you're the only one that can provide IT and internal business knowledge. If you insist on selling anything, sell this fact: that you are the only team with the business knowledge and IT knowledge/experience.

Reluctance to be totally transparent with the internal customer: If you, as an IT manager, view the business side as your customer, you are unlikely to reveal your internal challenges or your issues, especially those that have to do with the business side. When issues are not addressed, they fester and grow into bigger problems for both organizations, and for the company. Examples of resulting problems include:

  • Distrust between IT and the business side. If you're not transparent, then perhaps you have something to hide. Why should I trust you? Lack of transparency can easily lead to distrust.
  • Diminished innovation. When distrust occurs and we are reluctant to be totally transparent, we no longer work together toward a common company goal. Communications become diminished. As a result, innovation is hampered.
  • Multitasking. Treating the business as your customer means trying to meet all their demands, no matter how unrealistic they may be. For example, taking on more work than you have capacity for results in multitasking, which further reduces the productivity of the team and IT organization. One team at this health care company had six concurrent projects within a single sprint! Countless studies have explained and demonstrated the fallacy of multitasking, and yet these IT managers were reluctant to point out the problem to their "customers."
  • Massaging the metrics. Organizations typically collect and report performance metrics to their business side, but if the business is your customer, you may be inclined to massage or manipulate the data to present it in a more positive light, rather than engaging the business for joint ownership and to discover the real root cause of problems. Sometimes the root cause may be the behaviors of the business side! But with this mind-set of the business side as your customer, you may be reluctant to point out the real problems and work with them. Again, this is wasted time that could be spent understanding the problems and engaging the business side as partners to help solve them.

From an Agile standpoint, some interesting anti-patterns (behaviors that diminished the inherent value of an iterative and incremental approach to development) resulted from the "IT as a Business" model:

  • When a product backlog is scoped in terms of systems/applications instead of business value, it leads you to having to complete all of the systems/applications before any real business value is realized. So a product owner may now be inclined to think, "If I have to do all of the stories in the backlog to realize any business value, why do I need to prioritize them? Just do them all!"
  • If a product owner thinks that all stories need to be completed and there is no need to prioritize, then there is no need for a Sprint goal. Without a sprint goal, teams become "factories" attempting to crank out completed stories, without understanding the goal for the sprint.


The adoption of Agile has helped some companies to realize that perhaps IT should not be viewed as a business but more as a partner in the business. Viewing "IT as a Business" can be counterproductive.

If your company has adopted the ITAAB model and then attempts to adopt the Agile approach for product development, you may be forced to reconcile these conflicting values and principles. Or you could choose to ignore the problems and suffer the consequences.



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (3 ratings)


Rex Lester, CSM, 3/13/2013 3:04:09 AM
With or without ITAAB
"But we don't want the business in the driver's seat. After all, these are IT projects."
seems like a familiar theme; the arrogance can be breathtaking. Thanks for an insightful article.
Brian Clements, CSM, 3/28/2013 7:52:44 AM
Great article Alston. I can identify with a lot that you have said, especially where Agile is seen as an IT initiative and not seen as a company-wide enabler. Without business buy-in, it will never fly...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up