It is no surprise that IT is not always aligned with business goals.  The conflicts arise because IT is often unaware of how the business uses the systems that IT is responsible for installing and supporting, and the business is often unaware of exactly what is involved in an IT project.  There are several other reasons for the disconnect between IT and the business.

The Fundamental Disconnects

The first of these conflicts occurs because of the way IT projects are often initiated and funded.  The business determines that they need a system to perform a certain function and decides how much they are willing to spend on the system.  IT, with a desire to bring a project in under budget, often selects an enterprise system that meets most of the needs (and is a new technology that they want to learn) without thoroughly identifying the business requirements and performing a gap analysis between the selected system and the identified requirements.  As a result, the selected system needs extensive modification to meet the business needs, or else the business user develops work arounds in the form of spreadsheets or many smaller stand-alone systems that need to be integrated with the enterprise system.  The calculated costs of maintenance and support are often restricted to that required by the enterprise system without consideration for the additional costs of spreadsheets or the stand-alone systems.  Also, the budget may include the initial costs of the license and implementing the system but may not consider the total cost of ownership over a period of time.

A second area of conflict is often the result of the business designing new processes in the abstract without regard to the standard functionality of the system.  I have been on many projects where the business spends a lot of money designing the best-in-class order to cash or procure to pay business process and then expects IT to just make it work in an existing system.  Without knowledge of the existing system, the business designs a process that requires many customizations or enhancements that cost IT money to develop and maintain.  Then the business says that IT took too long or was over budget, and maybe they still didn’t get what they expected.

In a similar scenario, the business doesn’t understand the features of the new system.  The design of the accounting chart of accounts is a good example.  The business tries to replicate a legacy system in their new ERP system without being familiar with the functionality of the subledgers.  As a result, everything goes into the chart of accounts (projects, customers, employees, etc.), and then they demand that IT write custom reports to track and reconcile the detailed transactions.  The cost of the custom reports was not included in the cost of the ERP system.  Alternatively, because the business can’t get the reports they want out of the ERP system because it was not properly designed or the data is not complete or consistent,  IT begins a large data warehouse or business intelligence project to try to accommodate the requirements.  The business only sees the additional costs and huge projects and still doesn’t have the information that it needs.  Who’s to blame?  Why, IT of course.

A third disconnect results when the business does not delineate the benefits of an approach to IT and only specifies the end result.  For example, the business might say that they want to consolidate all of the instances of their ERP system.  IT thinks that means consolidating the various databases onto a single server.  They do that, but the business is still not able to report across instances or have consistent information and standards for the enterprise.  What the business really wanted was a single consolidated instance with data differences reconciled and suppliers, employees, and customers rationalized.  The company might save infrastructure costs by consolidating to a single server, but the business did not get the benefits of standard processes and consistent data.

Desire for Chaos

This next area is very controversial and one that few in IT will admit.  The Maslow principle states that people must provide for basic needs and feel secure before they can be productive.  Many of the IT initiatives that help cut costs in fact do so by eliminating positions.  Let’s take the example above with consolidating databases.  If there are multiple instances of a database, then multiple IT people are needed to support and maintain those databases.  If 10 instances of a production database are running (one for each regional area or line of business), then development, test, training, recovery, and production databases must be supported and maintained for each instance, or a minimum of 50 database environments.  If a DBA (database administrator) is responsible for 10 databases and the company needs 24 x 7 coverage (168 hours/week), then it would require a team of approximately 21 people to maintain 50 instances (168 divided by 40 work hours per week = 4.2 people for around-the-clock coverage, times 5 teams to cover 50 databases).  If the company consolidates into a single production database, then only 4.2 people are needed for coverage, and the other 17 people are likely out of a job.  Each person needs to feel secure in their position, and thus, doesn’t fully support the concept of a single consolidated database.

In another example of job security, many systems are customized without full documentation.  There is only one person in the organization who understands how the code works and can enhance and support it.  That is job security.  The notion of job security also applies to the business side of the house.  Again, few spreadsheets or business processes are fully documented, and only one person understands how to reconcile the company’s receivables to their general ledger.

Finally, because the data is not transparent across the enterprise or there are no clear data governance and stewardship responsibilities defined, only a few people understand how to generate the reports or analyze the data that the company needs to operate.  The resulting chaos is job security.

Fastest Time to Value

When new IT projects and initiatives are brought to the table, care should be taken when assigning project sponsors and leadership positions.  Just because IT has received buy-in from the business for a project doesn’t guarantee that a successful project in the eyes of the IT organization will be a success for the business.  If the project leader is focused on achieving the fastest time to value, the value piece must relate to value for the business – not value for the IT organization, as is sometimes the case.

Conclusion

Removing the disconnects and diluting the disparities between the business and IT is possible, but it can’t happen by itself.  One option is to create job descriptions or modify existing descriptions for IT positions that introduce an aspect of accountability to the business.  These key employees can act as mediators between the business and IT, making sure the requirements of both parties are met when carrying out new initiatives.  A person is likely to put time and effort into fulfilling his or her role if they are held accountable for it.  IT must not cut corners just to bring a project in under budget.  The business cannot design a best-in-class system without giving IT the budget to bring it to life.  The mediators make sure both parties are on the same page and communicate perceptions and expectations for budget, project approach, and end results to both IT and the business.  Everyone is in the loop, and everyone’s expectations are more likely to be met.  Furthermore, the resulting systems are better able to fulfill the business’ needs, so the reliance on spreadsheets, smaller systems, and other nuisances that create the original disconnects fades away.  It becomes a win-win situation for both the business and IT.