Five things your CEO should know about your IT transformation programme

Five things your CEO should know about your IT transformation programme

What is the right level of attention from the CEO and what should be the focus? How can the CEO avoid getting confused by tech-talk and getting paralysed by making every decision himself?

Information Technology has become a major source of competitive advantage in today's business world. Companies that are able to leverage IT effectively can realise cost savings and revenue upsides, while gaining market share over competitors. In order to stay ahead in this game, many corporations embark large IT transformation programmes to upgrade or renew their IT architecture. The IT Transformation programmes mentioned here are not only very complex and large in size and scope but also highly cross-functional in execution, affecting several organisations within the company. There is at least IT as well as one or more business user division involved, requiring people from these different organisations, different backgrounds and potentially diverging objectives to work together.

CEOs have to decide how deep they want to get involved into such programmes. On the one hand, CEO attention is necessary because IT transformation programmes can have a major impact on the company success, are highly cross-functional and consume significant funds. On the other hand IT transformations tend to be very technical in nature, which is why many CEOs without technical background shy away because they feel they lack the right skill to effectively support the programme. What is the right level of attention from the CEO and what should be the focus? How can the CEO avoid getting confused by tech-talk and getting paralysed by making every decision himself?

This article points out some best practices on how the CEO can help his IT transformation program to succeed and deliver enduring results. It gives some practical advice based on interviews with senior leaders that have accompanied IT transformation programs in different roles as well as the author's own experience. The experience of the contributors spans various industries including automotive manufacturing, aviation, telecommunication, high-tech and financial services.

The following practices have been identified as the most relevant and impactful for the CEO to get involved:

• Empower a Skilled Team at the Top

• Establish a Technology Enables Business Transformation

• Move Inch-by-Inch Towards the Larger Goal

• Build a Trusted Relationship with Key Suppliers

• Get Prepared to Cope with Issues

For each of the practices, the following sections provide background and recommend focus areas for the CEO to make the IT transformation programme more smooth and successful.

Empower a Skilled Team at the Top

Many managers of large IT transformation programmes complain about a lack of attention by their CEOs and the senior executive team. In fact, frequent changes in such programmes are inevitable. Plans are usually not a prescription but a moving target. Consequently, rapid and well-analysed decisions for cross-functional issues are a necessity and many decisions get escalated to the CEO making him a bottleneck.

Here's one illustration: A major national Airline Carrier was implementing a strategic partnering initiative. One prerequisite for the partnership was the implementation of a set of IT requirements. The IT division was not represented on the board of directors and the executive team was not paying much attention to the IT division. As a result, the IT and business divisions could not make decisions effectively. Finger-pointing instead of assuming accountability was common practice. Most IT projects got delayed significantly or failed completely and eventually the strategic partnership was put at risk.

On the other side CEOs often find themselves drawn into IT transformation programmes, dealing with detailed issues that the next level of leaders cannot resolve effectively. The CEO starts to push the programme forward despite not having detailed knowledge nor the IT experience. This often results in poor decision-making while valuable executive time is siphoned off from other more strategic issues.

To resolve this, the CEO should delegate authority effectively while ensuring that key issues remain transparent and can be decided by the CEO. This can be achieved through the appointment and empowerment of a strong programme leader who is supported by an extended programme management office (PMO) that I'd like to call strategy implementation office (SIO).

To be effective, the programme leader and the SIO should report to the highest reasonable level, which is at least an executive steering committee headed by the CEO, or the CEO directly. In some programmes the programme leader has the status of an extended board member, to underpin the significance of the role and give him a peer status with other board members. The programme leader must be empowered to make major decisions through a clear governance structure. This will enable him to offload large parts of the decision-making effort from the CEO and the steering committee.

The role of the SIO is goes beyond the administration of project progress and milestones. The SIO team has to be capable to grasp the project content to maintain clarity and over key programme matters and to prepare important decisions. Also the SIO must be able to counsel between IT and business to resolve issues and clear scope disputes. Hence an understanding of the technology and the business domain is required. It is also recommended to involve the SIO already in the strategic planning and design phases of a programme. This would enable the SIO to plan and account for the major project risks that stem from these project phases. Given this job description, the SIO and the programme leader are central to the success of the IT transformation programme.

The selection of the programme leader and the members of the SIO are critical. A project management certification alone (i.e. PMI) is not enough. Strong IT background, paired with a good business understanding is essential. Beyond that structuring and analytical skills as well as strong communication are vital. For the programme leader, experience with similar projects should be mandatory to provide him with the gut-feel to focus on the right issues at the right time.

Many organisations either don't have such talent available, or they cannot spare this talent from the day-to-day responsibilities. As a result, they consider taping external partners to fill such critical positions.

CEO Focus

The CEO has to ensure that a suitable programme leader is assigned, that is not only respected with IT teams but also through the rest of the corporation. He has to embed the programme leader into a supporting programme governance structure and provide the resources to establish an SIO. The CEO should consider the early assignment of the project leader and SIO at strategy definition stage.

Establish a Technology Enabled Business Transformation Programme

A large part of today's business processes in a corporation are orchestrated in IT tools and systems. As a result, IT often gets blamed if business processes are not functioning effectively. This leads to the belief that a new IT tool will fix most process and organisation problems. IT gets under pressure to renew or upgrade the supporting systems and lead to a supposedly better future. However the delivery of an IT project on time, budget and quality this does not mean that the business improvements are achieved. Expected revenue increase, cost savings or other critical performance measures like time-to-market are not accomplished automatically with new IT tools.

Here's another example: A large enterprise in Indonesia wanted to improve the efficiency of its internal software development teams and provide process visibility. The IT management decided to acquire and implement a software tool that to improve the software development workflows. However, the complex legacy software development processes, including the excessive documentation requirements, were mapped into the tool without streamlining or optimisation. Consequently the tool was very complex to use and software developers bypassed the tool in most cases by reverting to the old manual process. Hence, efficiency did not improve and process visibility was not established.

Real improvements can only be accomplished if technology supports effective business processes in a fit for purpose organisation. It is important that the IT Transformation programme is designed with the business as a driving force. The programme should be seen as an IT enabled business transformation programme rather than a technology renovation.

Business process streamlining as well as organisational review should be a mandatory component of the transformation programme. A top-down business process and organisation review supported by the appropriate management levels is the basis for achieving business outcomes. The business leadership has to assume an active and leading role during the whole

transformation process. Leaving the programme to IT alone is not an option and will decrease the chances of success.

The most important step to enable a business driven transformation is by modifying the programme success criteria. Instead of only measuring on time, budget and quality delivery, the success criteria should also include business objectives.

For the definition of business objectives a cross-functional team consisting of representatives from business and IT can work-out a business case for the programme. The business case has to show a sound return on investment and is based on the team's benefit assumptions and commitments.

Case in point: A mobile network operator was planning to renew its CRM as well as its data warehouse and analytics systems. Before even starting the design phase of the programme, the IT steering committee comprising the CEO, CMO and CIO put together a team consisting of IT, product management, sales and call centre management representatives. This team agreed on the outcomes and KPIs that were driven by the IT programme such as improved campaign efficiency, reduced call centre handling time and reduced time-to-market. These KPIs were translated into a financial model and paired with the projected programme cost to justify the investment. All team-members committed and signed-off on the expected outcomes and the steering committee even used the resulting business case to justify the investment with their shareholders.

The joint commitment to business outcomes creates buy-in and supports cooperation between the different teams during later stages of the programme. Decision-making becomes easier if teams are focused on a common goal.

A common pitfall with business objectives is that companies define them, but they are not disciplined to adapt them to scope changes or they don't sustain until after project completion to measure the business result – a result that becomes available only weeks or month after final acceptance.

CEO Focus

The CEO should ensure that a business process and organisation review is established as a driver for the technology transformation. Business users should be assigned with key roles in the transformation programme – possibly even the commercial programme leadership.

The CEO can facilitate in the board of directors to set-up a cross functional team to define the business objectives of the programme. Once completed, he can challenge the business objectives and ensure they are aligned with strategic goals. The CEO should release funds only after business objectives are agreed and committed and the business case is sound.

Teams have to be held accountable by the CEO for the achievement of the business objectives besides the delivery of the programme on time, budget and quality.

Move Inch-by-Inch Towards the Larger Goal

Many IT transformation programmes span over a long period of time of up to five years to complete. This is due to the large size and complexity and high ambition level of stakeholders. The problem with this long duration and large scope is on the one side that business requirements tend to vary and even invalidate after such a long time frame. Hence the delivered IT solution might support a business model that is already out-dated by the time it comes life and miss the respective expectations. On the other hand, the sheer scope size and complexity makes it very hard to manage such programmes, even for very experienced teams. Timelines tend to slip and cost budgets overrun significantly as a result.

An Asian car manufacturer was implementing an SAP ERP system. The ambition level of the senior management was high with respective expectations towards the new tool. In turn the scope was set very large and to be delivered in a big-bang approach, all at one drop. During implementation time it turned out that the complexity in the low-level business processes was overwhelming for the business and IT teams. The project timeline slipped and as costs sky-rocketed, the executive team decided to abandon the project completely, losing not only the business benefits expected from the programme but also the capital and labour invested into the programme.

In order to avoid such severe impact, successful IT executives try to slice the programme into smaller pieces and implement 'inch-by-inch'. Ideally the lead-time to deliver initial results should not exceed 12 month. This approach delivers results fast while retaining flexibility for changing business requirements in following phases. This does not mean that the overall ambition level of the transformation programme should be lowered. The transformation larger strategic goal should remain complete, but broken down into smaller milestones that each deliver business benefits.

The challenge for the planning teams is to find a viable way to break-up the scope. Typically legacy systems are complex and with heavily interwoven integrations. Replacing part-by-part can be costly as legacy systems have to be integrated before they get replaced. Technically it is sometimes more favourable to start on a 'green field' and build the new and advanced IT architecture in parallel to the legacy. In that case only selected processes, customer groups or products are migrated bit-by-bit to the new stack. Identifying the way to slice the business requirements and the technology architecture requires a careful and informed coordination between IT architects and business users.

CEO Focus

The CEO should aim for an ambitious goal but challenge the size and duration of the programme phases on the way to that goal. No phase should significantly exceed 12 months. This can be underpinned by a release of funding in line with the planned phases. At the same time the CEO has to manage the expectations of stakeholders that demand over-ambitions programme phases.

Build a Trusted Relationship with Key Suppliers

Procurement best practices standardise products and deliverables from suppliers and make prices comparable competition over price. As this practice works well for commodity goods it is also often replicated for complex IT programmes. Given the order of magnitude of the spending involved competition on price and commercial terms appears justified. Hence teams define the scope of work very sharp and use competitive leverage to squeeze prices.

The pitfall with this approach is that the scope of work can never be perfectly pre-defined and change is inevitable. Also many details can only be defined in a later phase of the project.

In order to win the deal under competitive conditions, suppliers are often tempted to accept very low or even negative margins for the initial deal while betting on up-scopes in later phases that are less competitive. Once contracted, suppliers try to find ways to push the deal over the breakeven point by charging for the additional effort introduced through project changes or ambiguous scope definitions. As a result, IT organisations respond by managing the supplier by the contract and focus on contract clauses rather than business results.

Example: A large Australia bank assigned a contract manager to lead a major system upgrade worth more than US$100 million. After four month, disputes with the supplier over the scope and milestones got the project to a standstill. Eventually the bank CEO got involved and cooperated closely with the CEO of the supplier. This intervention got the programme moving again after a five-month delay.

Managing a project by contract is very likely to fail. An IT programme of a common size is impossible to be pre-scripted into a contract schedule in every detail and changes can make large parts of the contract obsolete after a while. To avoid this it is recommended to view a contract as the basis for continuous negotiations throughout the programme. While some scope might be added to the programme, some other might not be required any longer and the managers from both sides have to handle this as a trade. It usually helps if the programme teams and the supplier teams have a trusted relationship as it makes negotiations easier. Unfavourable commercial contract terms and financials for the supplier make this on-going negotiation more difficult as suppliers will frequently attempt to up-sell rather then trading scope. Hence a fair and balanced commercial deal benefits the later cooperation -- which does not mean that there should not be any legal pre-caution after all. A reasonable budget for inevitable changes is also recommended -- as there might be changes to business requirements that cannot be covered through bargaining. Splitting the purchase order to the supplier according to milestones keeps up some leverage that can be used in negotiations as well.

CEO Focus

The CEO can help your teams best if he builds a trusted relationship with his counterpart of the key suppliers involved in the transformation programme. This will help the teams to work in a trusted environment as well. It makes it easier to trade scope and resolve issues quickly if escalated. Strength of the relationship and trust can also be part of the supplier selection criteria. If the team suggests a supplier proposal that appears too cheap against objective criteria, the CEO should challenge the choice. He can ask suppliers to open their books and make their calculation transparent to check the soundness of the proposal. If there is a good level of trust between the parties the supplier will agree to this. A budget for un-planned changes to business requirements should be part of every transformation plan.

Get Prepared to Cope with Issues

Experience shows that it is very difficult to plan every detail of IT transformation programmes ahead of time. A plan is usually more of a moving target that is evolved continuously. Besides normal variations there are a number of risks. Classic risk management practices should be able to deal with most of them; however IT projects have some special risks that have to be taken into account. Simply due to sheer complexity it is impossible to make software without any defects. The usual quality assurance measures and test-cycles can reduce the impact and quantity, but will never completely eliminate all bugs. Software is never perfect the first time.

Example: A large Asian mobile network operator introduced a new billing system and migrated all subscribers in one go to the new platform. Despite thorough testing and bug-fixing, it turned out that after migration almost 10 percent of the bills had issues. The programme management team was prepared for this situation by installing a manual quality check before bills were sent out to customers. This way, the affected bills could be withheld from the customers and the intelligence generated could be used to find and fix the remaining defects in the new billing system. At the same time, calls to the call-centre were only slightly above average and customer satisfaction was not impacted.

The transformation team has to anticipate this type of issues and establish respective mitigation measures. All stakeholders should be aware of this and not expect a sunny-day scenario. Besides avoiding disappointment of stakeholders, this can limit the potential business impact caused by such defects.

CEO Focus

The CEO should request and challenge the risk mitigation plans of the transformation leadership. He can also help to engage other executive stakeholders in the risk mitigation plans and manage their expectations with regards to the expected outcome.

In conclusion, the CEO does not have to become an IT system engineer or architect to establish and ensure the success of an IT enabled business transformation programme. All described focus areas are non-technical but give can give the CEO without IT background guidance on how to get involved into the programme and make a positive impact whilst not getting dragged in too deep. If all practices are applied, the chances of success of the programme increase significantly, and many unfavorable impacts on the organisation and the business can be avoided. CIO Asia

Sebastian Jammer is deputy vice president for IT transformation at Indonesia's telecommunications company Telkomsel. Axel Winter, Deny Rahardio and Erik Koenen contributed to this article.

Follow CIO on

Twitter @cio_nz



Download CIO for your tablet here.

Click here to subscribe to CIO.

Sign up to receive free CIO newsletters.

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments