A recent McKinsey global survey1 of trends showed that despite increased spending, IT in many organisations is not perceived as performing well:
- Information Technology is seen as less effective at enabling user goals
- Business people are less likely than 12 months ago to say that IT is performing effectively
- IT executives expect the reduction in performance to continue
Why is this? Information Technology has always suffered from a gap between expectations and delivery, but why is this trend becoming more pronounced? And what can be done to address the problem According to McKinsey, the top two reasons for poor performance identified by IT managers were:
- Lack of business ownership
- Managers lacking an understanding of when to use an iterative approach
This paper will provide strategies to deal with these two issues. We must begin by recognizing the principle reason that these two issues exist: the heterogeneity of IT systems. The current diversity of IT systems means that it is difficult, if not impossible, to provide a single strategy to cover all IT projects. The reasons for lack of business ownership will differ from project to project. The decision of whether (or not) to use an iterative approach will similarly vary.
Therefore we will present different approaches for particular categories of system. The categories we will use will come from Gartner’s pace-layer model2. This model classifies systems according to the pace of change required for the on-going development of the system.
The three categories in Gartner’s pace-layer model are:
Systems of Innovation
Systems of Innovation allow a business to work in new and creative ways. They usually involve the creation of business processes unique to a company. One example might be Virgin Atlantic’s use of Google Glass by airline concierges.
Systems of Differentiation
Systems of Differentiation aim to provide competitive advantage by solving a common business problem in a unique way. For example, an airline’s online booking system would support a commonly used business process (booking) but might do so in a way that is intended to increase market share by making the process more attractive to customers, perhaps by simplifying it.
Systems of Record
A System of Record stores important business data, but does so using processes that are common to almost all businesses. A payroll system would be a good example of a System of Record.
System of Innovation
A System of Innovation supports, or even defines entirely new business processes. Let us consider how to answer these two questions for a System of Innovation:
- How will business ownership/buy-in be maintained?
- Should an iterative approach be used?
"Innovation," Bill Joy once said "is what happens elsewhere". Innovation typically takes place at the edges of an organisation away from the strictures of central corporate control. In many cases, innovation won’t be driven by IT, but IT will act as an enabler, used to scale-up or leverage the value of innovation by making it more efficient and widely available.
Let’s look at some examples. Target stores in the USA ran an Xbox console trade-in programme, which allowed customers to buy an Xbox 360 at a reduced price if they traded in their old console. The trade-in programme was invented at a single Target store, where the manager placed a trade-in tent in the car park and gave customers a $50 voucher towards an Xbox 360 for every console they brought in. This initiative required no IT support and was created by a single store manager who had been given the freedom to innovate. Once it became clear that the programme was popular, appropriate IT support was introduced to leverage the programme across all stores via the Internet.
The McDonald’s Big Mac is one of the world’s best selling products, but it wasn’t created at McDonalds’ headquarters, but by a single franchise owner, Jim Delligatti, in a single store in Pittsburgh. There are similar stories behind the creation of the Filet-O-Fish and the Quarter Pounder. Information Technology won’t produce a better hamburger: that can only be done by innovation within the business itself. But IT can be used to scale the innovation across the business as a whole by improving the efficiency of the supply chain and enabling sales of more products.
How do you ensure that Systems of Innovation have proper business ownership? Creating a culture of innovation, in which the people who understand the business can try out new products and services, will encouraged those people to own and pursue of their innovations. Innovative teams must be led by business people.
Innovation, by its very nature, carries a high risk of failure, so it is important to reduce the cost and impact of failure. Innovative products or services should be tried and tested cheaply and quickly, before making any significant investment. This means developing iteratively, using short cycles, typically no more than a few weeks long. Each iteration should focus on gathering enough data about the product and its market to determine whether to stop or continue.
Consider using methodologies such as Pretotyping (pretotyping.org) to convert ideas into products as quickly as possible. It is very difficult to test the value of an idea, but a product can be directly tested against the market. The Xbox trade-in programme is an example of a pretotyped service: the idea was converted to a product very quickly and cheaply, and staff were able to test real customer demand by setting up a tent and performing actual trade-ins.
Give each team its own limited budget, and allow them to go outside the normal parameters of corporate IT procurement to get IT support in whatever way is cheapest and easiest to manage. This includes having the freedom to choose whatever is the simplest technology to solve the problem and changing technology at will. This may involve buying or renting cloud services or procuring IT equipment directly. Virgin Atlantic’s use of Google Glass required very little corporate IT support. They merely needed the basic equipment and access to the Internet. Limiting the size of innovation budgets helps avoid non-centralised IT spend getting out of control.
If new products and services cannot demonstrate innate value, they should be stopped quickly and marked as successful failures. The learning should not be wasted, but used to inform future developments.
In summary, projects to develop systems of innovation are likely to suffer from lack of business ownership if they are driven centrally. An innovation culture using short, iterative experiments in the grass roots of the company should be used to uncover new and disruptive business practices. IT will be an enabler, rather than a driver of such experiments. Such a culture will be inherently owned by the business and iterative in nature.
System of Differentiation
A System of Differentiation is a system that is unique to a particular business but solves problems common to the business sector. It will typically have a lifecycle of one to five years and will normally support business processes that are similar to processes in competitor companies, but is intended to do so in a way that will gain competitive advantage. An airline online booking system is an example of a System of Differentiation: all airlines have online booking systems, but the aim of each airline is to make their online system better than their competitors’.
Systems of Differentiation will often have to be created quickly, and they will typically have to respond rapidly to changing market conditions. Because Systems of Differentiation are intended to be unique to a company, they are unlikely to be off-the-shelf products. Unlike many Systems of Innovation, they may be driven by a central IT department from the outset.
How do you ensure that there is business ownership of a System of Differentiation?
The key factor is responsiveness. If the project team can respond to changing requirements of the business, the business will reciprocate by taking ownership of the system.
The most responsive practices currently in use in IT are those from the various agile methodologies3, such as Scrum4 and XP5. In an agile project, value is explicitly defined as a backlog of user stories which describe how a process within the system will best support the business. The system has a strong Product Owner who works in the business6. The product owner is a key stakeholder, often a lead user of the system or at least a person with a good understanding of the market, the competition and the system domain. The Product Owner’s responsibilities will include prioritisation of the backlog to ensure that the order of story implementation reflects the business value to be gained.
Agile projects are inherently iterative and focus on delivering value early in the form of working software. This means that at the earliest possible opportunity, some form of the system is available – maybe even as early as after one or two iterations. At first, the system will be very simplistic, but it will be developed in small incremental steps. This will allow the users to clarify what exactly they need the system to do, and it will also allow the development team to respond to changing market demands. The focus of every iteration is to deliver the simplest thing that could possibly work. This will avoid wasting effort building functionality that will never be used.
The combination of close business involvement and an iterative approach will reduce the likelihood of failure (because it is the Product Owner on behalf of business users who decides what is implemented first). It also reduces the impact of failure, because short iterations will deliver smaller changes and the Product Owner can stop development once he/she believes enough value has been delivered.
As we mentioned above, Systems of Differentiation are unlikely to be packaged solutions and are much more likely to be custom developments. Development work could be done by an internal IT department or by an external development organisation. If third party developers are used, close collaboration with the business is essential, possibly involving co-location, but certainly requiring high bandwidth communication. This means that use of offshore development teams may be impractical because of time, culture, or language differences.
In summary, we recommend that Systems of Differentiation are driven by the business within an agile framework, with a string product owner to ensure the business maintains ownership. Development should be iterative to reduce the likelihood and impact of failure.
System of Record
Now we come to the third, and final category of system in the pace-layer model: the System of Record. A System of Record stores core business data and typically has processes that are common across all businesses. For example:
- Enterprise Resource Planning (ERP) systems, such as HR, payroll, order management, stock control and financial planning.
- Business support systems such as Customer Relationship Management (CRM)
Systems of Record are likely to be bought-in packages. They rarely create competitive advantage. For example, a payroll system is unlikely to have an impact on market share. At the same time, they are critical to the smooth running of the business. The focus is therefore not on innovation, but upon stability, security, scalability and cost. IT involvement in these systems typically revolves around data migration, integration and scheduling upgrades and patches. Systems of Record have lifecycles that are significantly longer than those of Systems of Differentiation: they are certainly longer than three years, and often last for more than ten. The business processes they support are likely to change slowly.
How do you ensure on-going business ownership of a System of Record? We would recommend the stronger IT governance provided by more traditional project management techniques.
The development/upgrade cycles of a System of Record are likely to be long - probably several months. The rate at which requirements change is also likely to be slower (many Systems of Record will be working in a regulated environment, such as within a tax or legislative framework). Because these are the foundations of many businesses, any failure of such systems would be likely to have a very large impact. Agility is much less important, and a waterfall approach is probably more appropriate. Therefore, emphasis must be placed on reducing risk by decreasing the likelihood of failure. This means detailed specification and verification of requirements and technical design before any development takes place, and rigorous testing before roll-out. We recommend that you:
- Have a clear IT governance structure, such as a project board comprised of business users
- Spend time on clear definition of business requirements and perform cost/benefit analyses
- Ensure that any change request is accompanied by a well-defined business case
Because a waterfall process defines and documents requirements before development commences, and because the pace of change is slower, Systems of Record tend to be better candidates for outsourced development and/or support, either to the vendors or third-party consultants. You might also consider use Software-As-A-Service (SaaS) solutions instead. For example, you might choose to replace an in-house hosted CRM system with an online service like SalesForce7.
It is worth bearing in mind that while Systems of Record are unlikely to be innovative in themselves, they will need to support systems which are. Therefore, you should ensure that every System of Record has a well-defined set of services or Application Programming Interfaces (APIs) to ease integration with other systems.
In summary, Systems of Record are the oldest and most traditional of IT systems. Business ownership should be ensured by similarly traditional IT governance structures, such as project boards. The slow development cycles of Systems of Record mean that non-iterative approaches, such as waterfall development, are cheaper and more practical.
IT spend is increasing, and will continue to do so by between 2.8% and 3.7% according to Gartner’s Forecast Alert: IT Spending, Worldwide, 2Q14 Update8 but the IT functions within businesses are often seen as slow to respond. IT Managers identify the two major causes as a lack of business ownership of IT projects, and the complexities of choosing when to use an iterative approach. The framework we’ve presented here will allow you to adapt your IT strategy based upon the type of system you’re dealing with:
System of Innovation
System of Differentiation
System of Record
Created by business
Traditional IT governance
Reduce impact and likelihood
Role of IT
Enablement, possibly at a later stage
Integration and upgrades. Work may be outsourced
By using this framework, you can involve the business stakeholders to a greater extent, increasing their ownership of IT, and make smart decisions about when to use an iterative development approach. This will make your IT Department more responsive, allow you to support innovation and business growth and provide the stability needed to underpin business operations.
About Black Pepper Software
Black Pepper Software has an excellent reputation for developing high quality software solutions. We have produced first class results across a wide variety of industries. Examples include education, finance, travel, retail, automotive, commodity trading and logistics. We work with both SMEs and Blue Chip organisations and pride ourselves on being able to deliver tailored solutions and consultancy on time and within budget.
We are leaders in agile development practices. Our use of agile methodologies provides clients with excellent communication, close collaboration, rapid response, on-going flexibility, delivery of early business value and high quality results.