Skip to main content.

Software integration for ship chartering

Summary

This case describes a business risk analysis and planning exercise for a ship chartering company (CharterCo) and its in-house IT team to consider the Cargo Plus Project. It describes a relatively simple process that clarified everyone’s understanding of the project and its objectives, identified key risks, and helped the project team set priorities for the next phases of the work.

Background

The project

A purpose built software system called Cargo Plus was to be used to integrate CharterCo’s business systems. It was intended to provide a platform for longer-term strategic development of the chartering business.

The introduction of Cargo Plus was to coincide with other revisions to CharterCo’s business processes in a separate company-wide interface project. As with any significant project involving software development and process revisions, there was a degree of uncertainty about the execution of the project and this brought with it risks for both CharterCo and the IT team.

Workshop objectives

The purpose of the workshop was to arrive at an agreed view of the objectives of the Cargo Plus Project and the major risks that could stand in the way of achieving them, with an assessment of the risks’ significance. It followed a process based on the international standard ISO 31000. This consists of five main steps: establishing the context, risk identification, risk analysis, risk evaluation and risk treatment. The workshop addressed the first four steps and set the scene for the fifth, planning how best to deal with the risks. It was intended to support risk treatment planning and continuing risk management activity on the Cargo Plus Project.

The workshop provided an opportunity for all parties to clarify their understanding of the project and one another’s views on the issues that it presented. The participants were drawn from CharterCo and its IT team.

Context

Objectives, criteria and priorities

To be able to agree what risks might affect a project, it is necessary to agree what is at risk, or what constitutes success. This is so basic that it is often overlooked when risk is considered informally.

The meaning of success for a project is described in terms of the project objectives, the stakeholders who have to be taken into account and their objectives, and a small set of success measures, which can be used to derive scales for measuring the impact of risks.

The objectives of this project were to:

  • Reduce operating costs
  • Achieve the designed performance, incorporating redesigned business processes
  • Meet business needs
  • Be acceptable to users
  • Complete within the budget
  • Complete on schedule
  • Minimise disruption of day-to-day business
  • Integrate with CharterCo’s logistics systems infrastructure.

The stakeholders and some of their main concerns are listed in Table 1.

Table 1: Stakeholders

Stakeholder

Main concerns

CharterCo system users

The system works

Minimum business disruption

Data integrity

CharterCo management

Project objectives achieved

Efficiency gains in the business

Cost savings

IT team

Project objectives achieved

Continuing relationship with operations

Reputation of the team

Develop personal experience

CharterCo customers

Accurate information, on time

Transport service

CharterCo finance team

Timely information

Business process improvement

Other CharterCo projects

Minimum disruption

Co-ordinated interaction

Good ongoing communication

CharterCo suppliers

Accurate information on time

Transport service

Legacy systems owners

Replacement functionality on time

Provider of initial software development environment

Good reference site

Successful project

The project objectives and the stakeholder analysis were used to derive a set of key measures of success for use in the risk assessment. The potential impact of a risk was determined by the measures of success the risk might jeopardise.

Success measures were addressed in two stages, first identifying the measures and then defining a simple scale to summarise a range of impacts. The criteria against which the impacts of risks were to be measured were:

  • Business capability
  • Initial costs
  • Operating costs
  • Completion date, as currently planned.

A five-point scale was developed for each criterion, structured to take into account the contribution of each to CharterCo’s overall business objectives and its risk appetite.

Another five-point scale was used to represent risk likelihoods. The top end of this scale was set at 50% since anything more than likely to happen is best taken as a planning assumption rather than a risk. It makes no sense to base a plan on assumptions that you do not expect to be fulfilled.

Risks were allocated a priority for attention according to the combined effect of their consequence and likelihood ratings indicated in Table 2.

Table 2: Priority for attention

Key elements

Key elements set the scene for the risk identification step by defining areas in which risks will be considered. Rather than trying to identify risks by thinking about a project as a whole, it is more effective to break the task into topics and take these one by one as prompts for thinking about risks.

Seven key elements were used.

  1. Business performance (functionality, financial outcomes, efficiency, strategic potential, integration)
  2. Interfaces
  3. Technical performance (throughput, response time, infrastructure)
  4. Software development environment
  5. Resources and staffing
  6. Data management and migration
  7. Change management.

Risk assessment

Assessment workshop

Risks were identified in a brainstorming workshop, working through the key elements in turn, and any associated controls were noted. The aim of this step was to get potential risks on the table so they could be discussed, even if some were discarded after later consideration.

The risks identified for each key element were assigned a consequence and a likelihood of that level of consequence arising, using the scales developed in the context stage, and taking into account the existing controls. Where a risk had an impact on more than one criterion, the impact recorded was the worst it produced against any of the criteria.

Outcomes

The workshop identified 16 Major risks, 43 Moderate and 6 Minor, plus two risks associated with the interface project. The major headline risks and their primary contributors are set out in Table 3. They all demanded the close attention of the project manager and the Project Steering Committee (PSC).

Table 3: Headline risks

Headline risk

Primary contributors

Poor business process definition

Business units' rules conflict with one another

Processes change during the project

Decisions not made in a timely manner

Inadequate CharterCo management support

Transport business units fail to support the project

Transport business unit managers fail to demonstrate commitment

Loss of key staff

Inadequate change management processes

Major schedule slippage

Fail to meet the desired completion date

Fail to replace existing systems to match related system upgrade projects

Schedule slippage or functionality shortfall means staff cannot be redeployed when planned

Design based on inaccurate information due to misinterpretation between projects

Technical shortfall in the development platform

The platform is unable to deliver Cargo Plus across a WAN

The platform is unable to deliver all functionality

Two risks had already begun to compound one another at the time this assessment was being completed. A key member of staff, the change management leader, left the project shortly after the workshop, raising concerns about maintaining the momentum of this important aspect of the work.

The discussion around the risks made it clear that almost all staff on the project would be difficult to replace, and the loss of any one of them would cause significant delays. This had to be considered in the context of the project start having been delayed, meaning that the schedule was already tight and any further delay was unlikely to be absorbed within the existing schedule.

The tight schedule made the project particularly dependent on the actual and perceived support of CharterCo managers. Their attitudes and the messages they conveyed to their staff would shape the responses of those staff to the project. Similarly, the role of the PSC in resolving disputes and making decisions without delay would be crucial to achieving the current schedule.

The project was dependent on other work under way within CharterCo, such as a key interfacing project. Cargo Plus had to establish and sustain close and frequent communication with these other projects to assure its own success.

While the Cargo Plus Project was susceptible to developments in other CharterCo projects, it had the potential to disrupt the CharterCo business if it was unable to meet its own targets. Any delay in the completion of Cargo Plus could have serious consequences for compliance and planned staff reductions.

The most important risks identified in the workshop would require the joint attention of the project manager and business managers, represented by the PSC. The moderate risks were likely to be handled by the project manager and leading personnel within the team, although it would be prudent for the PSC to review them from time to time.

There were a few technical issues which had the potential to place the project at risk, particularly concerns about the development platform and the technical interaction between the various IT projects currently in hand within CharterCo. However, apart from the project’s potential to affect the rest of the business if it slipped badly, an important issue in its own right, the bulk of the risks related to processes, staffing, management and decision-making.

The development of a substantial software application, rather than customising an off-the-shelf product, was bound to generate concern about the software development activity, and its technical, schedule and cost performance. The outcome of the workshop made it clear, though, that the timely execution of the management functions required to support the project deserved at least as much attention, especially decision making, business processes definition, staff management and change management.

Being seen as part of the routine practices of the business, these management issues frequently receive less priority than is required to protect a project’s schedule and budget. The Cargo Plus Project was as much at risk from issues arising in the management of its external interactions with the business and other projects as it was from matters internal to the project.

Lessons

In addition to identifying and analysing the risks to the project, the workshop provided an opportunity to clarify the participants’ understanding of some of the less well defined areas of the work, particularly the role of the development environment of the project and the strong dependence on specific key staff.

The majority of the risks identified in the workshop fell into the moderate category, neither so severe that they would necessarily lead to total failure nor so minor that they could be left to the routine processes of project management to control them. However, there were several high priority risks that demanded direct attention from the project manager and the PSC.

Several major risks were effectively eliminated in the course of the workshop, when it was agreed that the software development environment that had been selected initially should not be used. In spite of its initial attraction, the risks associated with using a tool with which the development team were unfamiliar were considered too significant for this project.

The workshop participants included a good selection of senior business decision makers, which allowed such critical decisions to be made at the time. This immediately enhanced the chances that the change process and software development would be successful, without the delays that often arise when the results of an analysis have to be communicated to senior managers and time has to be allowed for them to confer with one another.