www.rudeandersen.com   •   lars@rudeandersen.com   •   +45 5070 0070

 

 

 

Lars R. Andersen

 

Freelance CIO/CTO  •  Management consultant  •  Project manager  •  IT architect

 

  • Flexible, hands-on, experienced and cost-effictive support.
  • Specific competences within IT management and mobile networks
  • Selected experience available in free white papers

 

Please note that the information here contains my personal viewpoints and not those of any present or previous employer

 

 

IT Transformation

 

By IT transformation, in this context, is meant a change in the business support systems of a magnitude that has major impact on the business, e.g. changing billing, customer service, web front-end etc. As most IT transformations have high cost and risk, they should more probably be termed “transformation including IT” as the funding, management of risk, initiating the use etc. cannot normally be justified from an IT-only perspective.

 

IT transformation is a potential outcome of an IT strategy, resulting if the pain points identified not realistically can be solved with an evolutionary approach. This can be the result of aging systems, a change in the business environment, new opportunities and the like. Due to the transformational aspect, such projects are normally – and should be – the result of a business strategy with an integrated IT strategy with a clear urgent change agenda.

 

For most businesses, a number of standard systems can be found that provides support for various parts. Therefore, the complexity and cost of maintaining a full set of systems developed internally is not normally sustainable.

 

The following outlines a high-level process that takes a business starting point and attempts to adapt the requirements to a standard system. The background and rationale for the process is outlined in the white paper on IT transformation.

 

 

A basic assumption in the process is that software vendors and system integrators will play an important role in the transformation since very few businesses have the size to maintain competence in doing transformation on this scale.

 

Prepare business simplification is an initial step, running in parallel with other preparations. The step and the subsequent execution of business simplification are included under the assumption that a transformation of 1:1 business tends to be challenged by the inhereted complexity from the existing systems.

 

Set distinguishing requirements is a phase where the business strategy is articulated in what is important in terms of IT support. Important in the sense that it is differentiating from a business perspective. There are several ways of doing this, but it should be done with an outside-in perspective, e.g. using customer journeys to document the desired experience. This is an important input to the RFP phase.

 

In this phase, it can also be considered to set a target cost bracket for the implementation and subsequent operation of the IT in scope. This will help focus on relevant potential vendors and can help in preventing scope creep.

 

Design new business is a phase where the desired business outcome is described. It elaborates on the distinguishing requirements, detailing the desired business model. The RFI results can provide further input through limiting areas that cannot easily be supported and identifying new opportunities.

 

Targets for business performance should also be part of this phase.

 

Document “as-is” for RFP. This must contain documentation of current systems as transformation out of those will be an important part of the RFP. In case interim or permanent outsourcing will be part of the scope, this requires additional “as-is” documentation.

 

RFI and vendor short-list. The distinguishing requirements are used as the core of the RFI send to a long-list of potential vendors. The RFI will ask a number of formal questions, but the key will be:
  • How can the distinguishing requirements can be supported through one or more applications?
  • What parts of the application landscape will need to be supported with custom systems?
  • What is the magnitude of effort in time and money required?
  • What is the proposed process to achieve the goal?

 

The list of vendors, the complexity of the process and the expected effort on behalf of the vendors must be adjusted to the size of the potential business for the vendors; for some time, they will need to work for free or nearly so and that must be in balance with the potential earnings.

 

Develop and execute RFP. Based on the new business design and RFI input, a proper RFP can be developed. In the process suggested here, it is still high level in order to avoid the “specification trap” and to maintain the ambition of using standard systems as far as possible.

 

Develop next level specification with 2-3 vendors. Following selection of 2 or 3 vendors based on RFP responses, the user stories developed earlier are evaluated against the proposed solutions. My suggestion is to utilise conference room pilots as the main vehicle. The presentations and responses should be captured throughout the process to be included in the final contract.

 

This is a relative work intensive process for the vendors, and depending upon the size of the potential order, it may be necessary to provide some compensation for the cost incurred in this phase. The vendors will be doing quite a bit of work that is relevant for the solution design, but of course the cost to vendors that are not selected will be wasted.

 

Due diligence etc. In case the transformation is accompanied by outsourcing, the vendors will need to go through the normal process of ensuring that the information provided is accurate and complete.

 

Selection is the process of choosing which vendor to continue the process with, based on the evaluations of the specifications developed.

 

Transformation planning and transformation is the finalisation of contracts, design etc. and the execution of the implementation. This, of course, is where the bulk of work is, but a lot more manageable when the system chosen can cover the functionality without major modifications.

 

Transfer “as-is” is the process of, in case of outsourcing, transferring current systems, operations or whatever the scope is.

 

More details on the process and a generic rationale for change for Telecommunications is outlined in the white paper. While the business background is specific, the process and steps can be applied more generally.

 

Experience and offerings

Having worked with several large scale IT implementations as project manager, program manager, architect and procurement responsible, including executing transformation according to the process outlined above and in the white paper, I can provide assistance with both content and process.

 

Activity

Contribution

Process supportProvide assistance on methodology, templates for specifications, templates and process for RFI/RFQ, staffing, duration etc.
Project managementEnsure progress of transformation project.
ArchitectApplication and enterprise architecture experience, ensuring “good” application structure.
SourcingSourcing packages and process, contract key terms and drafting, templates etc.
PresentationManagement level presentation of findings, progress, issues, challenges and choices.

 

White papers

For further details on IT transformation with focus on mobile, see the Telecom IT transformation white paper. For further details on the procurement / RFP approach, see the value focused procurement white paper.