How to stop thinking about business as “the customer” and IT as “the vendor” by Ivar Jacobson

How to stop thinking about business as “the customer” and IT as “the vendor”In my last three blogs, I discussed how we can close the gap between the business and IT. I summed up the way forward with the advice to stop thinking about the business as the customer and IT as the provider. Instead, let them work together in teams (similar to members of a soccer team), responsible directly to management.

It will not be an easy journey, but here are some steps along the way:

Management needs to:

  1. Make IT an integral part of all business units by:
    • Funding IT related projects directly from the business’ budget, and charging business units for their direct utilization of IT. Today, IT is often an “overhead” expense, and business units rarely see the direct cost of what they ask for.
    • “Playing on one team”. The team building starts when the business has identified a project and selected a project lead (coming from the business or from the IT or from wherever) and given her/him a budget. The project lead then selects the team needed to become successful using his/her budget. Some of these will come from the business side and others from IT such as analysts, developers, testers, etc. IT is from this perspective seen as a resource center. (IT has other roles such as leading the way into the future.)
    • IT spending needs to be perfectly aligned with the needs of the business, and the business needs to pay for what it asks for.
  2. Choose a technically competent CIO who understands and is respected by the president and the business unit managers, a CIO who can train his/her colleagues in the value of modern technology, a CIO who can lead with enthusiasm and passion. Give him a significant seat at the executive management table.
  3. Let IT and business units collaborate during the chartering of projects to define the problems to solve, or the goals that are to be reached, and to work together to find creative technical solutions to these problems, stimulating innovation.  Today, too often, the business requests or demands a solution based on a limited understanding of what might be done, and often based on an incomplete or flawed understanding of the problems to be solved and the goals to be met.  Working together, with a focus on really understanding what is needed and what can be done to meet those needs, better solutions can be devised and pursued.
  4. Recruit and promote IT leaders who have business sense, that is, who understand the business and have a proven track record for delivering innovative solutions.  And in the business units, recruit and promote people who can create value by solving problems using innovative applications of technology.
  5. Promote IT discussion that value communication in business terms and not in technology terms by continually focusing on how technical solutions will create business value.
  6. Stimulate cooperation and collaboration between IT and business units by ensuring that representative of both speak with one voice and avoid one-way 'monologues'.

The projects and the teams

  1. Prioritize the projects based on the business value that they will deliver over their planned lifetime, and considering the full lifecycle costs and benefits, not simply the initial costs and benefits.  Most project funding requests fail to consider the long-term costs and benefits of applications, resulting in unfunded long-term support costs.
  2. Both business and IT must participate in the development project as if the business depended on it - which it should if the project is worth doing.
  3. Measure the performance of the project against the goals established in the business case, and hold the team, with representatives from both business and IT, accountable for these results. Even before the project delivers, measure results in business terms such as the number of business scenarios that have been implemented and tested - don’t measure progress in terms of completion of documents. When you publish internal progress measures, always present them in business terms.

Product (software)

Derive software architecture from the business model – for instance starting from the business use cases, the business entity objects, the workers and translate these to a road map representing the system's major components and their collaborations and fill the map with executable code, project after project.

Method (process)

  1. Apply practices that may get the business side and the IT to collaborate and which, if correctly performed, result in measurable success. Then the two sides will win together.
  2. Develop iteratively: deliver frequently and encourage requirement modifications after each delivery.
  3. Formulate requirements and tests as use cases: specify, develop, test and validate–a little at a time, starting from the essentials, over and over again until your customers accept
  4. Plan product releases together: understand the purpose and intention of each release, ensure the product addresses the real business needs, synchronize business and development plans, involve the right people
  5. At the right time, understand everybody's commitments.
  6. Use a dash-board: look at what’s important: better, faster, cheaper, happier, and present it intuitively using the language of the business.
  7. Organize cross-functional teams, one for each business feature: bring all the skills (marketing, product design, software development, financial, business process experts) necessary together to make the change.
  8. Formulate business processes as business use cases: lean business design, just model the bits of the business that are being changed, identify increments of business change so change can be made early and often. An agile approach to business modeling.

These are steps on the path to reducing the gap between business and IT, making the IT and the business true partners and removing the customer-provider relationship that is not working. The goal is of course to generate revenue, reduce cost, and improve the customer experience. It's smart for business, and that will be smart for IT.

  1. Anton | May 10, 2010 at 4:30 am Reply


    According – How to stop thinking about business as “the customer” and IT as “the vendor””

    Ivar you are missing an important part in your discription and it is “Communication” and “Language” in between Business and IT. An other important part is “change Management”.
    From my perspective, Business is more economy and customer related and IT is more system and technical oriented. I presume IT calls the” produced product ” differently compared to Business people offering the product towards Customers.
    I agree that that a close cooperation is absolutely necessary. But I’m pessimistic because “change Management” has not been a strong side by either Business nor IT.

    PS: F Y I – I have long experience in Telecom ( product and system development ,CRM, Vendor Relation and O&M……)

  2. Krishna | March 29, 2010 at 8:31 pm Reply


    Hi Ivar,

    What you have outlined is definitely the logical path to move forward. Implementing this, though means blasting through the additional processes and ceremony that’s developed in enterprise IT working as a “technology silo” within the larger organization. This also means, both IT and vendors becoming more agile and business savvy. All exciting changes in the days ahead…


  3. Frans Verschoor | March 25, 2010 at 5:48 pm Reply


    Hi Ivar,

    Thanks for these practical ideas. I have a question:
    How would you distinguish IT from Software Engineering? There are ongoing efforts to define SE (not least because of the Semat initiative) and I think that to be able to define SE it is good to understand how it differs from IT.