How do we get business and IT to play on the same team? by Ivar Jacobson

How do we get business and IT to play on the same team?To close the gap between business and IT we need to get them to play on the same team, as said in my two previous blogs. I compared this team with a soccer team in which the participants are not just specialists but also generalists – they can all kick the ball when called upon.

The Business-IT “team” should work in a similar way. Despite having specialized roles, all of the participants should contribute to achieve a common goal in order for everyone to be successful.

But do they? If they were a soccer team they would probably not win many, if any, games. Extending the soccer analogy, the business often acts like the absentee owner who wants the team to win but does not really want to take the time to be directly involved. Instead they try to micro-manage from a distance, demanding a detailed play-by-play plan for who is going to score and when, and they berate the team for not adhering to the plan. They will say that they will provide players (business representatives and product owners) but the players they assign are usually absent because they are too busy doing other things. As the team owner, they also don’t want to spend too much to hire the best players and coaches, but they still want to win against teams that are willing to spend more.

But on the IT side it is often not any better. Instead of providing convincing proof that the team is making progress, they hide behind detailed play-books and technical jargon. They claim they cannot win unless they get the best uniforms, and a nice practice field, and the best shoes, and a new stadium. They spend lots of time coming up with new strategies and play-books and little time on the field actually practicing. They require the owners to review and sign-off on all plays, and if a play does not work they blame the owner for not providing good feedback. Are you beginning to see the connections? Maybe soccer and software are not so different after all! To be more direct, here is what often happens:

• The Business often wants to dictate, or at least lock-in, the price (or cost) and schedule even before they really understand what they really need or what problem they are solving.

• The Business is rarely accountable for the business benefits claimed in the business case. Business cases are often “rigged” to justify a project that the Business “wants to do” - but the project team is held accountable for cost and schedule estimates based on an often poorly conceived “wish list” of features, and on the “overly optimistic” business case.

• The Business often feels that anything less than meeting all their initial expectations, no matter how poorly understood, is failure.

• The Business often is unclear about its real needs, and tends to demand a lot of things that it does not really need and that never get used.

• When they do change their mind about what they want or need, they rarely adjust the original cost and schedule.

• The Business is often not willing to invest time in better understanding their needs because that will “take too much time”, and yet failure to deliver will be considered IT’s failure.

• The Business is often not willing to provide access to the most knowledgeable people because they are considered too valuable to take away from their regular jobs, even though the project cost is great and the need for success even greater.

• The Business often regards software development as a commodity skill that they can outsource to the lowest cost provider. They do not value software development professionals who actually understand their business and they are often not willing to invest in developing the IT organization as a strategic resource. But IT is not a blameless victim in this game:

• IT usually accepts the situation, feeling that they are powerless to do anything about it. Even when they know they cannot provide estimates of cost and schedule with only a vague understanding of the needs, they provide one anyway, and this “vague estimate” becomes the measure against which the project is held accountable, even when it is an poorly-informed guess.

• IT managers often do not really understand software development, and they don’t tend to take an interest in becoming better informed. As a result they think that people are interchangeable, that a good process can compensate for lack of skills and experience, and that success means delivering what the business asks for as opposed to what they really need.

• They often measure the wrong things - like production of artifacts - rather than measures like quality, risk reduction, and actual progress as measured by running, tested software.

• IT's engagement tends to be low-level, not strategic, focusing on “cool technology” that is poorly connected to business benefits. They are not trusted by the business to contribute as strategic problem solvers, mainly because they have not demonstrated that they really understand the business and how to apply technology to creating business value. They wait for the business to tell them what to do, rather than offering solutions.

• The technology itself is immature and not well understood, and decisions are often driven by fads and the desire to “play with the latest technology”.

• And finally, the IT team members often do not respect each others’ contributions. Developers look down their noses at testers and business analysts. Business analysts tend to be unconcerned about whether something they specify can actually be developed (that is a mere detail), and testers often lack the skills to do more than manual testing, since that tends to require real development skills.

Is there really a simple way to break down these barriers to really working as one team? Yes, and no. Some of the changes are simple in concept but hard in execution. Other changes require a fundamental re-thinking of the relationship between the Business and IT. The first step to take is to stop thinking about business as “the customer” and IT as “the vendor” - they need to play on one team, together, in order to win. But more about the next steps in my next blog...

1 Comment
  1. Chris Gerrard | March 16, 2010 at 3:23 pm Reply


    I quite like the analogy, and the extrapolations. Particularly the framing of software development as a commodity activity best undertaken by the lowest-cost factors of production. History clearly shows that saving money by using the lowest-cost developers simply lowers the cost of failure – an organization that has this view of development -will- fail, but it’ll spend less money doing so.

    There’s another facet that comes into play. The rewards and promotions tend to go to those who can promise shiny baubles and declare success in the face of failure. This character trait is fundamentally opposed to the nature of someone who is actually good at software development, which requires a dedicated pursuit of the good, useful, and valuable. Organizations that reward self-promoters over accomplished professionals, particularly those effective collaborators whose contributions magnify those of their colleagues, end up with team captains and coaches who drive the team towards the bottom. But, unlike real sports teams, there is no objective measure of success or failure – wins and losses – to assess the team’s real effectiveness.