Advice for making maritime software projects work

Digital Ship held a webinar on June 25, sharing advice about better ways to make maritime software projects work, with speakers from Anthony Veder, Ionic Shipping and Euronav. Karl Jeffery, founding editor of Digital Ship reports.

Advice included to spend 75 per cent of your time on planning; to keep focused on the core purpose and value of your pro ject; to communicate with people how they will need to change how they work; recog­nise that people in the company do not necessarily have the same level of IT competence as the IT staff; and find the right people with the right mindset that you can work with.

Speakers suggested you should only use Agile when you have already worked out what problem you are trying to solve, and have moved to the stage of your pro­ject of developing a solution.

Sifra Westendorp, Anthony Veder

Sifra Westendorp, digital development manager of Anthony Veder, emphasised that 75 per cent of your effort should be on planning, before you get to implementa­tion. “If you do this right, it will save you a lot of headaches once you start executing,” she said.

As part of planning, you might consider factors such as whether there is a strategic fit between the project and the company strategy, whether the project really solves a problem or is just a ‘cool tool’, whether the rest of the company will support it, and if the company will provide resources and knowledge to help.

While planning the project, you can also make a plan for how you will encourage adoption.

Anthony Veder is based in Rotterdam, and runs 32 vessels, of which 21 are ethy­lene carriers.

Ms Westendorp has worked as a digital development manager for 2 years, and before that was in the operations depart­ment of the company. This “gave great insights into how a shipping company works, and how Anthony Veder works,” she said.

Her department is responsible for for­mulation and execution of digital strategy. Its current projects include providing remote assistance to vessels, reducing administrative workload onboard, devel­oping new ways to provide information to customers, and predictive maintenance.

For a project to be successful, it is important to keep focussed on the “why” – having a good understanding of the prob­lem you are trying to solve. If you lose focus on the why, instead putting your attention on the tool itself, you can end up with a tool which does not actually solve anything, she said.

The “why” is the core of your business case for the project. Having a strong business case will give you an answer if people question the purpose of the project in 6 months’ time.

Another element for successful projects is “very strong change management skills”. Many people say they want change and better ways to work, but when they are actually asked to change, they don’ t actively co-operate or even sabotage the project, she said.

You can counter this by being very open and transparent to people about what will and won’ t change, and what benefit they will get from changing. It also helps if you develop an understanding of how people work and what problems they face, and aim to get their support from early on.

You should also have a robust project management method, to ensure your budgets and schedule stay on track. That is “something that I learned the hard way,” she said.
As an example of what planning work can look like, Ms Westendorp explained how she embarked on a project to reduce administrative workload onboard vessels, by doing many interviews and workshops with people in the office and onboard, to try to understand where the administration workload was coming from.

“It turned out that what we thought was the problem was not the root cause,” she said.

Once you understand the problem, you can try to find a tool which will solve it.

“You need the discipline to dig into the problem and understand the root causes, show the business value.”

“There is an abundance of tools on the market, they all claim they will reduce the workload, but does it actually solve the problem, or is it just fighting symptoms?”

With software, Anthony Veder has a guiding principle of buy before build. “We are a shipping company, we are not a tech company. Developing your own tool will require a lot of functional control and maintenance. If you buy a tool, that is being taken care of,” she said.

You may need to develop your own tool if there isn’ t any available on the market.

When developing software, Agile should not be a goal in itself, but a means to an end, Ms Westendorp said. “Agile should never be a reason to start experimenting and see where it goes. An Agile methodology starts when we have understood the problem and start thinking about a solution,” she said.

Agile may be more useful for “iterating on what you have discovered, test, learn, adapt, reshape it and develop an actual tool.”

When it comes to change management, Ms Westendorp stressed that you should not assume people will change just because a project has approval from senior management.

But a strong message from management can certainly help, if they say, “this is how wé re going to do it, whether you like it or not, we see the benefits and believe it fits into our strategy.”

Andreas Polidis, Ionic

Andreas Polidis, IT advisor of Ionic Shipping, emphasised the importance of being very clear about the scope and value of the project, to ensure you are not just running it “for the sake of IT”.

His talk focussed specifically on shipboard software implementation, which “in most cases is the most difficult part”.

Ionic Shipping is based in Glyfada, Athens, with 7 tankers and 16 bulk carriers.

As with any software project, you have to be very clear about the project scope – who will benefit from the project, he said.

You need to identify how the crew are going to be involved in the project, and how you expect them to change how they work, and what effort they will need to make, bearing in mind crew will be operat­ing vessels at the same time.

You will need to provide training or support, familiarising people with the software or solution you are implementing. It can be helpful to give people a “test environment” they can learn with, he said.

It can be helpful if you can limit the amount of new software functionality provided to people, so you limit the workload and potential confusion understanding the new tools.

It helps if they get advance warning about what is coming.

You may find some nationalities of crew have different characteristics to others, in terms of whether they easily follow new guidelines provided to them about using new software systems, or they prefer to take their own initiatives. Many crew members may not be from the “internet generation” and slower to adopt new software methods, he said.

Crew members who are less committed to their employer may be less motivated to do the work of learning new software, he said.

It is helpful if you can find a “power user” onboard, who can be a liaison between the office IT team and the rest of the crew.

If the crew changes partway through the project, there needs to be a way for knowledge to be passed from departing crew to the new crew, and include information about the software in training material which is given to manning agents.

You also need to consider the communications infrastructure from the vessel, in terms of bandwidth and reliability. If it can’ t support your proposed software, the whole project may be a waste of time, he said.

When it comes to change management, the key is communication, he said.

“You need to involve all the people. If you communicate every change you are planning to do, that is the key factor to implement these changes without any resistance.”

Software approaches

When Euronav is considering software products and vendors, it is keen to find options where it can maintain flexibility, including to change vendor. The priorities of shipping companies continually change. “That’s why we cannot be locked with deci­sions that we take,” said Stefanos Christakis, innovation manager of Euronav.

Where it buys software off the shelf, the company is keen on vendors which give it an opportunity to get involved in their product development road map.

Developing software in-house is “probably the least desirable option, wé re trying to move away from that.”

It helps if software is intuitive, or explains itself, so it can be used without a manual, he said.

Agile can be a useful tool in engaging people early and avoiding going in the wrong direction. But whether you use it will not be a key issue in whether or not your project is successful. A more impor­tant issue is the level of focus on how the software is designed, he said.

An iterative approach to software development can be better than sending someone to work on developing some­thing for three months and having a risk they go off track. You may also find that priorities change over time, so projects need to be re-focussed.

You do not want to be encouraging peo­ple to use a “minimum viable product” which is not in its final form, otherwise people will just say, they will wait until it is finished before adopting it. It makes it harder when you have to say to people, “we have this new thing now, you are requested to adopt it.”

People and personalities

Mr Christakis sees four “types” of people you may encounter as a software develop­ment person.

The “visionary” is someone who had the idea for software, is excited about it, but doesn’ t necessarily have the patience to explain it to others, go into detail, and make it work. “It’s nice they have this vision, it is something you can work [with], but it is probably not the guy who will be able to help you implement the project.”

You meet “short term” people, often quite senior in the company, who might be just focussed on the immediate business problems. That’s “not someone we can really work with.”

You meet “impatient” people who want digital technology right now. “If you ques­tion the urgency, sometimes you see it is not really urgent, just that they haven’ t really prioritised in a proper manner,” he said.

“The [people] you really want to work with are the ones that have the focus, they are open to listen. They have the patience to look at it, see how it works. They are open to other options, and to shift the way they work a bit, if this means that by using this software they will be more efficient.”

“The implementation of software always comes together with a change in working process – it is important to under­stand that.”

It is important not to let people stretch the scope too much. “A lot of people have different ideas and opinions about how it should work, what it should do. It is a role of the business analyst and project team to be critical and challenge that.”

You need people in authority who are able and willing to make decisions. “You find you go into endless discussions about a particular specification, how it should work, what is the interface. Sometimes it makes sense to go back to the beginning and start over,” he said.

You need to involve people as early as possible. “Don’t think that just because you have software which seems to match what they want, you can start working on the project. Make people part of your project from the beginning. It is important to prepare people for what is coming.”
For big projects, you can involve the company’s in-house communications department – including making banners, newsletters and videos for the vessel.

If you nominate people as “ambassadors” for the project, they can feel more involved. The more people get involved, and have invested their time in the project, the more they feel they have a stake in its success.

The ambassadors can explain to their own colleagues why new software technology is helpful. This is very different to someone from the IT department trying to explain it.

You always need to have a ready answer in case someone asks you “why did we do this”.

Some of the people who show the most resistance to using new software are people who are comfortable using Excel for their own analysis. They don’t accept that a software system might make life easier for the whole company. These people can be jokingly labelled “Chief Excel Officers”, one audience member said.

“I fully understand what you mean, we know these people,” Mr Christakis replied. “The approach we take is to find ambassadors, people who are willing. Don’ t ignore the ‘Chief Excel Officers’ .”

“But you cannot get everyone onboard from the beginning. You have to pick the right people, get them onboard slowly, you’ll see everybody else will also come onboard, one point or another.”





  LMB-BML 2007 Webmaster & designer: Cmdt. André Jehaes - email