Designing and building anything that requires more than one person can be a challenge. The work becomes even more difficult once you add in real-world constraints, such as budgets, timelines, and ROI targets. The only way to responsibly build anything of consequence is to manage the process with a general philosophy and a set of procedures. This is the basis of project management.
When building any innovative product for a cruise ship, there are additional inherent complexities. Project management philosophies and procedures that are best suited for software development may clash with the realities of shipboard operations. And procedures designed for onboard life can hinder and frustrate innovation. In this post, I cover two main project management philosophies, discuss why they can clash when exposed to the cruise industry, and offer some suggestions on how to better integrate these worlds.
Waterfall and Agile
Since the dawn of the software development world, Waterfall project management strategies have been the standard. Waterfall is the tried and true method of planning out the tasks that make up a project, working out which resources are required for those tasks, and then scheduling them in such a way that you can follow each step of the process. If the project looks like it will take too long, you can add more resources or remove tasks. Each step leads to the next, creating a nice Waterfall look to your planning diagram.
A typical Waterfall project Gantt Chart
Waterfall design was the norm for most of the 20th century when it came to software development. However, with the increasing speed of technology, and the business demands made of programming teams to get new features out as quickly as possible, a new project management methodology was required.
The Agile methodology takes its name from the Agile Manifesto, a collection of values and ideas put together by a group of software developers who joined forces in 2001 to discuss ways of improving the profession and pushing lighter-weight project management systems.
Agile is not a noun, but rather an adjective. It is used to describe a number of methodologies that all basically attempt to do the same things — allow the development process to be iterative and adapt to changes, build working software in small chunks, involve the stakeholders at every stage of the process, and focus on the people and communication processes involved.
A number of instructive and formalized processes have grown from these core principles. Scrum and Kanban are two of the most likely candidates you’ll encounter. But I’ll leave the individual details of those systems to you if you want to research them further.
What you really need to know is that using Agile development systems generally means chunking work into “sprints,” or dedicated blocks of time (typically one or two weeks), and planning only a few sprints out at a time. This keeps things flexible for new features and changing priorities, while forcing the team to actually deliver some amount of working code at the end of every sprint for feedback.
A typical sprint board for an Agile project
Why This Can Be Difficult for Cruise Lines
Almost all modern software development teams, and many innovative technology design organizations, have completely abandoned Waterfall methodologies. Agile thinking has, for better or worse, totally taken over throughout the software industry. The internet is largely responsible for this seismic shift in the way we work. With software mainly being delivered through a web browser or an app store, developers have the ability to automatically upgrade their products in almost real time.
Additionally, the ever-increasing speed of technology has created a redundancy cycle that is much shorter than it was 20 or 30 years ago. You would be very lucky to get any new app these days to run on a five-year-old phone. This means that engineers are forced into frequent modifications just to keep their applications working. Agile is the obvious choice to manage the constant demand for pushing out new features and deploying updates.
Where Agile methodologies can be reasonably accepted is for shoreside operations. However, shipboard software development is a different story.
The launch of a cruise ship is mostly a construction project. They are enormous structures that are managed as all construction projects are — with lots of Gantt charts, golden path analyses, and resource management systems. In other words, they use a Waterfall project management methodology.
This is not a criticism. Waterfall management is perfect for the construction industry, and likely unavoidable. Waterfall allows you to trade the flexibility of iterative design with having set dates. This trade off is paid for with design time spent upfront before the actual build begins. The reason for this being the obvious choice for ship construction is that you have to know the date the ship will be completed so that you can start selling bookings. If you are a month late on an improvement to your digital signage system software, it is unlikely that anyone will notice. Being a month late delivering a billion-dollar cruise ship will have far-reaching implications on guest refunds, rebookings, construction insurance, lawsuits, and returns on the investment.
Agile thinking does not work this way. Building a ship is not an iterative process.
The Clash
If all shipbuilding, management, and retrofitting professionals are Waterfall experts, and all the software engineering teams are Agile zealots, the clash is inevitable.
As most cruise lines become more and more technologically sophisticated, software development has become an increasingly large focus, especially in the realm of guest empowerment.
As a result, there are four large areas where the worlds collide:
Continuous Delivery
Deploying software onboard a ship is always tricky, regardless of how it is built. Typically, when a new piece of software or an update is delayed, users are aware of the update and are vigilant. Safety concerns, as well as the limited onboard IT resources, generally mean that rollouts are taken very seriously, are scheduled well in advance, and are managed with change orders. Software affecting the guest experience is sometimes only changed out during stints in dry dock. For Agile-focused software developers, this can be difficult to comprehend as applications delivered over the internet are updated as often as once a week.
Expectations
Users of custom business systems are familiar with the process of finding a bug, reporting it to the development team, and waiting on a new version, or a hotfix if it is urgent. But cruise guests and onboard crew are not typical users. Guests expect near perfection in their interactions, and bugs of even the smallest kind can spark outrage. I’ve been dispatched to a guest’s stateroom on a support call and had the hairdryer thrown at me because a TV channel wasn’t working. (We were out of satellite coverage.)
Feedback
Crew, on the other hand, will work around issues until the problem becomes so bad that they finally report the issue. If your front-line end users are not giving your development team feedback, how are you supposed to create improved iterations of your software?
Training
Training also creates issues. If you deploy a new version of your software, it’s somewhere between impractical and impossible to train onboard users in a timely manner about the new and improved capabilities. Onboard learning management systems can be updated with new procedure videos, but the more effective in-person training is almost never done outside of a ship’s launch or retrofit.
How to Merge the Ideologies
Considering Agile-based approaches to software development are here to stay, the focus should be on reconciling modern software practices with onboard operational realities.
Face the fact that Agile is unavoidable. Software developers are not going to let it go. Agile systems are culturally ingrained, and they are effective. Trying to change the way this side of the process is handled will be close to impossible.
Be clear in the difference between product and project. A project backlog is the list of all the to-do items for a particular project. When you are finished with all those to-do items, the project is complete. A product backlog is different because it represents all the future features that are desired in the application. The features in this backlog are not necessarily part of the project.
Educate your team. If you are working with a development company or systems integrator that is developing custom software for a ship or a business process, and your project managers are not well-educated in Agile, there will be misunderstandings, frustrations, and probably project failures. It is relatively inexpensive to get an employee certified in something like Scrum — a two-day certification class is all you need to get started.
With stakeholders higher up the ladder, you will need to educate them more gently. Changing the anticipations of executives can be a challenge. Here the main goal is to shift expectations to incremental wins, rather than splashy new releases.
Plan to have releases in your Waterfall models. By this I mean have a year-long Waterfall project plan that includes multiple release dates, even if you don’t know exactly what is going to be in those releases. Think of these as upgrades, even if they are each self-contained projects. Train your Waterfall staff to have their expectations set by the change release documents, and not by “final product vision” ideas. These change release documents can be governed by individual projects (adding features), or they can follow a simpler care and maintenance pattern. The change release document should be planned by the development team and sent to the operations team as far in advance as possible. My suggestion for lead time would be at least four weeks.
Your development team should plan to “cut” a release — have a version of tested and working software — ready to go at any given time. My suggestion is to have at least one potential release candidate ready to go every six weeks. This way your development team is always a few steps ahead (in case a critical bug is found), and your operations team can have time for implementation planning.
Don’t get too far behind on releases. Frequent updates are a core principle of all Agile methodologies, but there is a potential danger with this. If change management and regular software rollouts are not part of the cadence of onboard life, the time between updates can quickly add up. This means that changes to systems can become jarring for their users (with an overload of new features). The other more serious risk is that huge swaths of work are made in error because onboard hardware or systems don’t support some software change that could have been detected earlier.
Create a feedback loop from passengers and crew. Guest satisfaction surveys are commonplace in the industry, but they often don’t point out areas for improvement on the technology side. This is partly due to the newness of many of these systems. A guest or crew member might not have the vocabulary to describe how the digital kiosk in the atrium might be improved. However, a small amount of training for specific crew members can go a long way to reporting valuable data. In one experiment, we trained an assistant cruise director to ask one or two random guests about a public interactive TV system, and then to report back to us once a month. This simple request generated a huge collection of improvements and bugs that had never before been considered. The resulting updates also made the onboard staff much more likely to report issues and to feel like their voices and opinions were being heard.
Train your development staff to take change management seriously. Seeing as though the entire software development industry has gone Agile, there is a fair amount of hubris in the field around their chosen project management strategy. Many folks in my field think that Agile strategies can solve any problem, and they look down their noses at Waterfall projects. You may need to remind them that even if you have a hammer, not every problem is a nail. Your dev team needs to understand that they can’t just update systems onboard a ship the way they would a website. Change management documents and frequent communication with the shipboard staff are essential to lowering the odds of outages and botched rollouts.
Shoreside
Shoreside, things are significantly easier. If you are building a system to manage your database of shore excursion contractors, then development, testing, and deployment can be handled in the same types of real-time environments that Agile-style methodologies were built for. Typically, most of the custom-built software inside of a cruise line is operational in nature. There are far more systems managing hotel bookings, flight management, payroll, and communication than there are for passenger-facing systems.
The problem is that the software world has all but abandoned Waterfall project management, and for good reason. Software is a process, not a product. Once you start down the path of custom software development, you are on that road until the end of the system’s life. Waterfall methodologies may have solutions for continuing the development cycle, but they don’t change the concepts in the minds of those involved the same way Agile methodologies do.
Conclusion
- Shipbuilding is mostly managed with Waterfall methodologies.
- Software development is mostly managed with Agile methodologies.
- The two methodologies clash when it comes to building software for ships.
- You can minimize these clashes by:
- Releasing early and often, and planning out the releases as part of the ship’s typical project flow.
- Talking to your passengers and crew regularly to build a feedback loop.
- Training your development staff about life onboard a ship, taking change management seriously.
- Educating your operations team on Agile methodologies and considering certification for them.
Like any situation where two worlds collide, empathy for the people on the other side is vital for success. No amount of training or process will be able to replace basic respect and understanding of your coworkers. The only way that I know how to build empathy is to have people spend time together. Send your developers to ships, send shipboard personnel to your developers’ studios, and train your operations staff on how both sides work. This may be too burdensome a task in the realities of day-to-day business, but it is something to keep in mind.