Vernieuwen IT-systeem  kansloos zonder excellente proceskennis 

Upgrading and renewing existing systems are tasks that are usually assigned to the IT department, for example to the duo of a functional manager and an application manager, in consultation with the IT supplier. This is generally a logical choice, as no one knows an IT system as well as an IT specialist. However, studies by organisations such as the Standish Group and Ernst & Young show that most IT projects fail. In the end, systems do not adequately support the organisation or lack functionalities that are crucial.

What can an organisation do to prevent a major, project-based renewal from failing?

IT specialists cannot be expected to carry out a thorough reassessment of the organisation. Management itself must take the lead. With the help of excellent process knowledge, the foundation is laid for an IT system that fully meets expectations and truly aligns with the needs of the organisation.

Background

Many organisations have, at some point in the past, chosen to implement a system that Many organisations have, at some point in the past, chosen to implement a system that met their needs at that time. If it was implemented properly, it would have taken into account the organisation’s strategic direction at that moment. However, insights change, methods and techniques evolve, market demands shift, society changes, and as a result the organisation itself changes as well.

All these changes are gradually addressed by updating parts of the system on an ad hoc basis. What typically emerges is a patchwork of functionalities:

• Some functionalities serve needs that have long since been forgotten
• Some functionalities were well designed and built but never properly implemented
• Others were thoughtfully designed but overshoot their purpose due to an excess of features
• Finally, there are functionalities that are still handled outside the system, for example in Excel or Access solutions

The ongoing development of an IT system starts to resemble an unstructured puzzle. The puzzle keeps growing, one piece at a time, while the overall design, which would normally be visible on the box lid, has been lost. In fact, it is sometimes no longer clear whether the newly added pieces even belong to the original puzzle.

A common pattern is that the organisation assigns the IT department the task of ‘renewing’ the system. What follows is often a brief assignment of just a couple of pages with general objectives for the IT professional to work with. In many cases, there is a lack of substantive direction, concrete input for the IT supplier, and clear, shared expectations about the outcomes of the project.

The result is almost inevitable: as the system is being built, it becomes apparent that the project is heading towards disappointment. The well-known rule of thumb applies once again: IT projects take twice as long as planned, cost twice as much as budgeted, and deliver only half of what was expected.

_{Figuur 1: integrale procesgerichte aanpak voor IT-projecten} 

This article presents a process-oriented approach in which an IT (renewal) project is guided in the right direction through four integrated steps. Throughout the process, continuous attention is given to eliminating the root causes of IT project failure, which is key to success.

Step 1: Minimise changes in direction through clear scope definition

One of the main reasons why IT projects fail is that, during the build of the new system, the project has to change direction, resulting in additional costs and longer lead times. Deciding halfway through the project that “everything needs to be done differently” is the number one problem and has led to major issues, for example in government IT projects.

The first step towards a successful system renewal is to clearly define the scope of the IT system to be renewed. This starts by determining in which processes the IT system should play a role. To stay within the puzzle analogy: begin by laying the corner pieces. At the same time, this provides an initial indication of how many pieces the puzzle consists of.

Many organisations no longer have a clear view of what their own ‘puzzle’ looks like and have long since lost the corner pieces. Bosman, Schijff and Van de Vliert argue in their white paper “Enhancing Innovation Capability with BPM” for the use of the INK model as a starting point for redefining the scope of the processes to be redesigned. This involves first identifying the needs of stakeholders, such as customers, employees, management or financiers, and society. The organisation’s strategy and policy are then aligned with these interests.

Based on the organisation’s strategy and policy, all processes can then be identified. A proven method for this is the design of a business process model. This provides an overview in which the entire organisation is captured as a complete set of processes. Since an organisation carries out more activities than just producing a product or service, a distinction is made between:

• Primary processes: all activities that directly produce a product or service
• Supporting processes: activities that facilitate or support the primary processes
• Steering processes: all activities that provide direction and control to both primary and supporting processes

_{Figuur 2: Het bedrijfsprocesmodel als rand van de puzzel} 

The IT system to be developed plays a crucial role in the exchange of information between the various identified processes. The business process model defines the full scope of the organisation, in the puzzle analogy, the edges have now been laid. If a process has not been identified, it does not contribute to the organisation’s objectives.

Step 2: Create an explicit alignment between the process and IT

A second key cause of IT project failure is that insufficient clarity is created about what the IT system must be able to do, at what moment, for whom, for what purpose, and with which data. The second success factor is therefore the (re)design of each process within the business process model and, as a result, determining the ideal system support. This concerns defining the overall structure of the puzzle: is it a landscape, or rather a cityscape?

To move from a high-level overview of processes to the detailed design of a specific process, the Quality Function Deployment (QFD) method can be used. In this method, customer needs and requirements are translated into design requirements for specific processes. The result is a matrix, known as the House of Quality, which clearly shows the relationship between customer requirements and the processes within the organisation. This insight enables individual processes to be analysed in depth, improved and innovated. 

Figuur 2: Het kwaliteitshuis 

Kroon en Van de Vliert bieden een integrale aanpak om  elk ideale (deel)proces te Kroon and Van de Vliert offer an integrated approach to designing each ideal (sub)process and then carefully linking it to the supporting IT systems. The starting point is the redesign of each work process in the form of a functional flowchart. This clearly specifies which activities should ideally be carried out, who performs them, which messages (the input and output of each activity) are exchanged, and what timeframes apply.

This functional flowchart is then extended with an additional layer: the ideal IT support. This results in an integrated design of the two worlds of ‘business’ and IT, and establishes a shared language for further collaboration.

A brief aside: four tips for achieving a strong process–IT alignment

• Ask critical questions when defining interactions with the supporting IT system. Is there a sound business rationale for this interaction? Does the organisation truly need it? Will it become overly complex or difficult to use?
• Redesign processes based on the organisation’s strategy and policy (see also step 1). This ensures that processes are well aligned, customer-focused, value-adding and future-proof.
• Allow employees to redesign their own processes. After all, they will be the users of the system derived from their ideal workflow. If they help shape the solution, they are more likely to embrace it.

Take inspiration from developments in IT. Did the previous system fully leverage the benefits of tools such as online forms, smartphones, tablets, Bluetooth printers, pocket projectors, social media and improved programming techniques?

Step 3: Provide a clear brief to the IT supplier

In steps 1 and 2, the organisation itself is still the one solving the puzzle within the project. It is only in the third step that the second puzzle-solver, the IT supplier, comes into view. A third important cause of IT project failure is the lack of alignment between the organisation and the IT supplier regarding the feasibility of the specified requirements. It is the organisation’s own responsibility to define as precisely as possible what the IT supplier is expected to build and deliver. In the previous step, the interaction between process and system has already been defined; now, using this process–IT interaction, it must be specified as clearly as possible what is expected from the IT system to be delivered. In terms of the puzzle, all the loose pieces are defined as concretely as possible in the form of a comprehensive list of requirements and wishes, directly linked to specific activities within the processes. An example of a requirement is:

“At activity 3.2: the ability to retrieve a complete overview of applications, differentiated by application type, status and date of receipt.”

To properly discuss how all requirements will be addressed with the IT supplier, the MoSCoW method provides additional structure. MoSCoW is an acronym that stands for:

• Must have – this requirement must be included in the final result;
• Should have – this requirement is highly desirable;
• Could have – this requirement will only be included if there is sufficient time, and
• Would like to have or Won’t have – this requirement will not be addressed now but may be of interest in the future.

By reviewing all documented wishes and requirements together with the IT supplier, a number of aspects can be established in a structured way:

• the priority of each requirement
• how the defined wishes and requirements will be met
• which requirements call for further exploration by either the organisation or the supplier
• whether the process still needs to be refined based on proposed alternatives

At the level of individual requirements, alignment is achieved regarding the possibilities and constraints, expectations and the importance of each requirement for the organisation. This leads to a clear, realistic and, above all, shared understanding of the system to be built. It also allows the IT supplier to indicate which requirements are challenging and therefore costly to implement, or which requirements will not be addressed or will be deferred.

The outcome of this alignment is the blueprint for the new system, consisting of the requirements to be built along with annotations, clarifications and boundaries. In puzzle terms, this is the lid of the box. The lid provides guidance for every puzzle-solver, as it shows what the final result of the construction process should be.

Step 4: With proper monitoring, no deviations occur during the build phase.

Now that the lid of the puzzle has been defined in alignment with the IT supplier, the build phase can begin. The puzzle is clear, the edges have already been laid, and all pieces have been discussed jointly. The responsibility now shifts to the IT supplier to build what has been agreed.

During progress meetings throughout the build of the new system, the IT supplier can report back in workshops on the progress made. The blueprint, being the lid, together with the underlying requirements, the pieces, provides a concrete framework for these discussions. The IT supplier demonstrates progress, while the organisation can tick off which requirements from the blueprint have been delivered.

Good progress monitoring prevents ambiguity about the expected outcome during the build phase. If adjustments are required, the organisation can use the integrated process design to find a workable solution that preserves the internal flow of activities.

System renewal? Use excellent process knowledge.

IT (renewal) projects often fail to deliver what an organisation actually needs. Common causes include the absence of a clearly defined scope, vague requirements, poor alignment on what is and is not feasible, and insufficient monitoring during the system build phase. By applying proven techniques, these problems can be avoided and an organisation can create the conditions for a successful IT project.

To achieve this, the organisation must rethink its scope and be aware of its own responsibility in clearly defining the requirements for the IT system as an integral part of every process design. After all, if the organisation itself does not know what it needs, how can the IT supplier be expected to know? That is why it is crucial to ensure that the puzzle is complete; there is nothing more frustrating than a missing piece.