Titanic Project Management & Comparison with Software Projects

Few projects have ever taken on the fame and notoriety of that achieved by the Titanic and her sister Olympic ships, the Olympic and the Britannic, which began design one hundred and ten years ago this year.  There are, of course, many lessons that we can learn from the fate of the Olympic ships in regards to project management and, in fact, there are many aspects of project management that are worth covering.

(When referring to the ships as a whole I will simply reference them as The Olympics as the three together were White Star Line’s Olympic Class ships.  Titanic’s individual and latter fame is irrelevant here.  Also, I am taking the position here that the general information pertaining to the Olympic ships, their history and fate are common knowledge to the reader and will not cover them again.)

Given the frequency with which the project management of the Olympics has been covered, I think that it is more prudent to look at a few modern parallels where we can view current project management in today’s world through a valuable historic lens.  It is very much the case that project management is a discipline that has endured for millennia and many of the challenges, skills and techniques have not changed so much and the pitfalls of the past still very much apply to us today.  The old adage applies, if we don’t learn from the past we are doomed to repeat it.

My goal here, then, is to examine the risk analysis, perception and profile of the project and apply that to modern project management.

First, we must identify the stakeholders in the Olympics project. White Star Lines itself (sponsoring company and primary investor) and its director Joseph Bruce Ismay, Harland-Wolff (contracted ship builder) with its principle designers Alexander Carlisle and Thomas Andrews, the ships’ crew which includes Captain Edward John Smith, the British government as we will see later and, most importantly, the passengers.

As with any group of stakeholders there are different roles that are played.  White Star on one side is the sponsor and investor and in a modern software project would be analogous to a sponsoring customer, manager or department.  Harland-Wolff were the designers and builders and were most closely related to software engineering “team members” in a modern software team, the developers themselves.  The crew of the ships were responsible for operations after the project was completed and would be comparable to an IT operations team taking over the running of the final software after completion.  The passengers were much as end users today, hoping to benefit from both the engineering deliverable (ship or software) and the service build on top of that product (ferry service or IT managed services.) (“Olympic”)

Another axis of analysis of the project is that of chicken and pig stakeholders where chickens are invested and carry risk while pigs are fully invested and carry ultimate risk.  In normal software we use these comparatives to talk about degrees of stakeholders – those which are involved versus those that are committed, but in the case of the Olympic ships these terms take on new and horrific meaning as the crew and passengers literally put their lives on the line in the operational phase of the ships, whereas the investors and builders were only financially at risk. (Schwaber)

Second, I believe that it is useful to distinguish between different projects that exist within the context of the Olympics.  There was, of course, the design and construction of the three ships physically.  This is a single project, with two clear components – one of design and one of construction.  And three discrete deliverables, namely the three Olympic vessels.  There is, at the end of the construction phase, an extremely clear delineation point where the project managers and teams involved in the assembly of the ship would stop work and the crew that operated the ship would take over.

Here we can already draw an important analogue to the modern world of technology where software products are designed and developed by software engineers and, when they are complete, are handed over to the IT operational staff who take over the actual intended use of the final product.  These two teams may be internal under a single organizational umbrella or from two, or more, very separate organizations.  But the separation between the engineering and the operational departments has remained just as clear and distinct in most businesses today as it was for ship building and ferry service over a century ago.

We can go a step farther and compare White Star’s transatlantic ferry service to many modern software as a service vendors such as Microsoft Office 365, Salesforce or G Suite.  In these cases the company in question has an engineering or product development team that creates the core product and then a second team that takes that in-house product and operates it as a service.  This is increasingly an important business model in the software development space that the same company creating the software will be the ultimate operator of it, but for external clients.  In many ways the relevance of the Olympics to modern software and IT is increasing rather than decreasing.

This brings up an important interface understanding that was missed on the Olympics and is often missed today: each side of the hand-off believed that the other side was ultimately responsible for safety.  The engineers touted their safety of design, but when pushed were willing to compromise assuming that operational procedures would mitigate the risks and that their own efforts were largely redundant.  Likewise, when pushed to keep things moving and make good time the operations team were willing to compromise on procedures because they believed that the engineering team had gone so far as to make their efforts essentially wasted, the ship being so safe that operational precautions just were not warranted.  This miscommunication took the endeavor from having two types of systems of extreme safety down to basically none.  Had either side understood how the other would or did operate, they could have taken that into account.  In the end, both sides assumed, at least to some degree, that safety was the “other team’s job”.  While the ship was advertised heavily based on safety, the reality was that it continued the general trend of the past half century plus, where each year ships were made and operated less safely than the year before. (Brander 1995)

Today we see this same problem arising between IT and software engineering – less around stability (although that certainly remains true) but now about security, which can be viewed similarly to safety in the Olympics’ context.  Security has become one of the most important topics of the last decade on both sides of the technology fence and the industry faces the challenges created by the need for both sides to action security practices thoroughly – neither is capable of truly implementing secure systems alone. Planning for safety or security is simply not a substitute for enforcing it procedurally during operations.

An excellent comparison today is British Airways and how they approach every flight that they oversee as it crosses the Atlantic.  As the primary carrier of air traffic over the North Atlantic, the same path that the Olympics were intended to traverse, British Airways has to maintain a reputation for excellence in safety.  Even in 2017, flying over the North Atlantic is a precarious and complicated journey.

Before any British Airways flight takes off, the pilots and crew must review a three hundred page mission manual that tells them everything that is going on including details on the plane, crew, weather and so forth.  This process is so intense that British Airways refuses to even acknowledge that it is a flight, but officially refers to every single trip over the Atlantic as a “mission”; specifically to drive home to everyone involved the severity and risk involved in such an endeavor.  They clearly understand the importance of changing how people think about a trip such as this and are aware of what can happen should people begin to assume that everyone else will have done their job well and that they can cut corners on their own job.  They want no one to become careless or begin to feel that the flight, even though completed several times each day, is ever routine. (Winchester)

Had the British Airways approach been used with the Titanic, it is very likely that disaster would not have struck when it did.  The operational side alone could have prevented the disaster.  Likewise, had the ship engineers been held to the same standards as Boeing or AirBus today they likely would not have been so easily pressured by management to modify the safety requirements as they worked on the project.

What really affected the Olympics, in many ways, was a form of unchecked scope creep.  The project began as a traditional waterfall approach with “big design up front” and the initial requirements were good with safety playing a critical role.  Had the original project requirements and even much of the original design been used, the ships would have been far safer than they were.  But new requirements for larger dining rooms or more luxurious appointments took precedence and the scope and parameters of the project were changed to accommodate these new changes.  As with any project, no change happens in a vacuum but will have ramifications for other factors such as cost, safety or delivery date. (Sadur)

The scope creep on the Titanic specifically was dramatic, but hidden and not necessarily obvious for the most part.  It is easy to point out small changes such as a shift of dining room size, but of much greater importance was the change in the time frame in which the ship had to be delivered.  What really altered the scope was actually that initial deadlines and projects had to be maintained, relatively strictly.  This was specifically problematic because in the midst of Titanic’s dry dock work and later moored work, the older sibling, Olympic, was brought in for extensive repairs multiple times which had a very large impact on the amount of time in the original schedule available for Titanic’s own work to be completed.  This type of scope modification is very easy to overlook or ignore, especially in hindsight, as the physical deliverables and the original dates did not change in any dramatic way.  For all intents and purposes, however, Titanic was rushed through production much faster than had been originally planned.

In modern software engineering it is well accepted that no one can estimate the amount of time that a design task will take as well as the engineer(s) that will be doing the task themselves.  It is also generally accepted that there is no means of significantly speeding up engineering and design efforts through management pressure. Once a project is running at maximum speed, it is not going to go faster.  Attempts to go faster will often lead to mistakes, oversights or misses.  We know this to be true in software and can assume that it must have been true for ship design as well as the principles are the same.  Had the Titanic been given the appropriate amount of time for this process, it is possible that safety measures would have been more thoroughly considered or at least properly communicated to the operational team at hand off.  Teams that are rushed are forced to compromise and since time cannot be adjusted as it is the constraint, the corners have to be cut somewhere else and, almost always that comes from quality and thoroughness.  This might manifest itself as a mistake or perhaps as failing to fully review all of the factors involved when changing one portion of a design.

This brings us to holistic design thinking. At the beginning of the project the Olympics were designed with safety in mind: safety that results from the careful inter-workings of many separate systems that together are intended to make for a highly reliable ship.  We cannot look at the components of a ship of this magnitude individually, they make no sense – the design of the hull, the style of the decks, the weight of the cargo, the materials used, the style of the bulkheads are all interrelated and must function together.

When the project was pushed to complete more quickly or to change parameters this holistic thinking and a clear revisiting of earlier decisions was not done or not done adequately.  Rather, individual components were altered irrespective of how that would impact their role without the whole of the ship and the resulting impact to overall safety.  What may have seemed like a minor change had unintended consequences that were unforeseen because holistic project management was abandoned.  (Kozak-Holland)

This change to the engineering was mirrored, of course, in operations.  Each change, such as not using binoculars or not taking ice bucket readings, were individually somewhat minor, but taken together they were incredibly impactful.  Likely, but we cannot be sure, a cohesive project management or, at least, process improvement system was not being used.  Who was overseeing that binoculars were used, that the water tests were accurate and so forth?  Any check at all would have revealed that the tools needed for those tasks did not exist, at all.  There is no way that so much as a simple test run of the procedures could have been performed, let alone regular checking and process improvement.  Process improvement is especially highlighted by the fact that Captain Smith had had practice on the RMS Olympic, caused an at-sea collision on her fifth voyage and then nearly repeated the same mistake with the initial launch of the Titanic.  What should have been an important lesson learned by all captains and pilots of the Olympic ships instead was ignored and repeated, almost immediately. (“Olympic”)

Of course ship building and software are very different things, but many lessons can be shared.  One of the most important lessons is to see the limitations faced by ship building and to recognize when we are not forced to retain these same limitations when working with software.  The Olympic and Titanic were built nearly at the same time with absolutely no time for engineering knowledge gleaned from the Olympic’s construction, let alone her operation, to get to be applied to the Titanic’s construction.  In modern software we would never expect such a constraint and would be able to test software, at least to some small degree, before moving on to additional software that is based upon it either in real code or even conceptually.  Project management today needs to leverage the differences that exist both in more modern times and in our different industry to the best of its advantage.  Some software projects still do require processes like this but these have become more and more rare over time and today are dramatically less common than they were just twenty years ago.

It is well worth evaluating the work that was done by Harland-Wolff with the Olympics as they strove very evidently to incorporate what feedback loops were possible within their purview at the time.  Not only did they attempt to use the construction of earlier ships to learn more for the later ones, although this was very limited as the ships were mostly under construction concurrently and most lessons would not have had time to have been applied, but far more importantly they took the extraordinary step of having a “guarantee group” sail with the ships.  This guarantee group consisted of all manner of apprentice and master ship builders from all manner of support trades.  (“Guarantee Group”)

The use of the guarantee group for direct feedback was, and truly remains, unprecedented and was an enormous investment in hard cost and time for the ship builders to sacrifice so many valuable workers to sale in luxury back and forth across the Atlantic.  The group was able to inspect their work first hand, see it in action, gain an understanding of its use within the context of the working ship, work together on team building, knowledge transfers and more.  This was far more valuable than the feedback from the ship yards where the ships were overlapping in construction, this was a strong investment in the future of their ship building enterprise: a commitment to industrial education that would likely have benefited them for decades.

Modern deployment styles, tools and education have led from the vast majority of software being created under a Waterfall methodology not so distinct from that used in turn of the [last] century shipbuilding, to most leveraging some degree of Agile methodologies allowing for rapid testing, evaluation, changes and deployment.  Scope creep has changed from something that has to be mitigated or heavily managed to something that can be treated as expected and assumed within the development process even to the point of almost being leveraged.  One of the fundamental problems with big design up front is that it always requires the customer or customer-role stakeholder to make “big decisions up front” which are often far harder for them to make than the design is for the engineers.  These early decisions are often a primary contributor to scope creep or to later change requests and can often be reduced or avoided by agile processes that expect continuous change to occur to requirements and build that into the process.

The shipbuilders, Harlan and Wolff, did build a fifteen foot model of the Olympic for testing which is useful to some degree, but of course failed to mimic the hydrological action that the full size ship would later produce and failed to predict some of the more dangerous side effects of the new vessel’s size when close to other ships which led to the first accident of the group and to what was nearly a second.  The builders do appear to have made every effort to test and learn at every stage available to them throughout the design and construction process. (Kozak-Holland)

In comparison to modern project management this would be comparable to producing a rapid mock-up or wireframe for developers or even customers to get hands-on experience with before investing further effort into what might be a dead end path for unforeseen reasons.  This is especially important in user interface design where there is often little ability to properly predict usability or satisfaction ratings without providing a chance for actual users to physically manipulate the system and judge for themselves if it provides the experience for which they are looking. (Esposito)

We must, of course, consider the risk that the Olympics undertook within the context of their historical juxtaposition in regards to financial trends and forces.  At the time, starting from the middle of the previous century, the prevailing financial thinking was that it was best to lean towards the risky, rather than towards the safe – in terms of loss of life, cargo or ships; and to overcome the difference via insurance vehicles.  It was simply too financially advantageous for the ships to operate in a risky manner than to be overly cautious about human life. This trend, by the time of the Olympics, had been well established for nearly sixty years and would not begin to change until the heavy publicity of the Titanic sinking.  The market impact to the public did not exist until the “unsinkable” ship, with so many souls aboard, was lost in such a spectacular way.

This approach to risk and its financial trade offs is one that project managers must understand today the same as they did over one hundred years ago.  It is easy to be caught believing that risk is so important that it is worth any cost to eliminate, but projects cannot think this way.  It is possible to expend unlimited resources in the pursuit of risk reduction.  In the real world it is necessary that we balance risks with the cost of risk mitigation.  A great example of this in modern times, but outside that of software development specifically, is in the handling of credit card fraud in the United States.  Until just the past few years, it has generally been the opinion of the US credit card industry that the cost of greater security measures on credit cards to prevent theft were too high compared to the risks of not having them; essentially it has been more cost effective to spend money in reimbursing fake transactions than it was to prevent those fake transactions. This cost to risk ratio can sometimes be counterintuitive and even frustrating, but is one that has to drive project decisions in a logical, calculated fashion.

In a similar vein, it is common in IT to design systems believing that downtime is an essentially unlimited cost and to spend vastly more attempting to mitigate a downtime risk than the cost of the actual outage event itself would likely be if it were to occur.  This is obviously foolish, but so rarely are cost analysis of this type run or run correctly it becomes far too easy to fall prey to this mentality.  In software engineering projects we must approach risks in a similar fashion.  Accepting that there is risk, of any sort, and determining the actual risk, the magnitude of the impact of that risk and comparing that against the cost of mitigation strategies is critical to making an appropriate project management decision in regards to the risk. (Brander 1995)

Also of particular interest to extremely large projects, of which the Olympics certainly qualified, there is an additional concept of being “too big to fail.”  This, of course, is a modern phrase that came about during the financial crisis of the past decade, but the concept and the reality of this is far older and a valuable consideration to any project that falls onto a scale that would register a “national financial disaster” should the project totally falter.  In the case of the Olympics the British government ultimately insulated the investors from total disaster as the collapse of one of the largest passenger lines would have been devastating to the country at the time.

White Star Lines was simply “too big to fail” and was kept afloat, so to speak, by the government before being forcibly merged into Cunard some years later.  This concept, knowing that the government would not want to accept the risks of the company failing, may have been calculated or considered at the time, we do not know.  We do know, however, that this is taken into consideration today with very large projects.  An example of this happening currently is that of Lockheed Martin’s F-35 fighter which is dramatically over budget, past its delivery date and no longer even considered likely to be useful has been buoyed for years, but different government sponsors who see the project as too important, even in a state of failure to deliver, for the national economy to allow the project to fully collapse.  As this phenomenon becomes better and better known, it is likely that we will see more projects take this into consideration in their risk analysis phases. (Ellis)

Jumping to the operational side of the equation we could examine any number of aspects that went wrong leading to the sinking of the Titanic, but at the core I believe that what was most evident was a lack of standard operating procedures throughout the process.  This is understandable to some degree as the ship was on its maiden voyage and there was little time for process documentation and improvement.  However this was the flagship of a long standing shipping line that had a reputation to uphold and a great deal of experience in these matters.  It would also overlook that by the time that Titanic was attempting its first voyage that the Olympic had already been in service far more than enough to have developed a satisfactory set of standard operating procedures.

Baseline documentation would have been expected even on a maiden voyage, it is unreasonable to expect a ship of such scale to function at all unless there is coordination and communication among the crew.  There was plenty of time, years in fact, for basic crew operational procedures to be created and prepared before the first ship set sale and, of course, this would have to be done for all ships of this nature, but it was evident that such operating procedures were lacking, missing and untested in the case of the Titanic.

The party responsible for operating procedures would likely be identified as being from the operations side of the project equation, but there would need to be some degree of such documentation provided by or coordinated with the engineering and construction teams as well.  Many of the procedures that broke done on the Titanic included chain of command failures under pressure with the director of the company taking over the bridge and the captain allowing it, wireless operators being instructed to relay passenger messages as a priority over iceberg warnings, allowing wireless operators to tell other ships attempting to warn them to stop broadcasting, critical messages not being brought to the bridge, tools needed for critical jobs not being supplied and so forth. (Kuntz)

Much like was needed with the engineering and design of the ships, the operations of the ships needed strong and holistic guidance ensuring that the ship and its crew worked as a whole rather than looking at departments, such as the Marconi wireless operators, as an individual unit.  In that example, they were not officially crew of the ship but employees of Marconi who were on board to handle paid passenger communiques and to only handle ship emergency traffic if time allowed.  Had they been overseen as part of a holistic operational management system, even as outside contractors, it is likely that their procedures would have been far more safety focused or, at the very least, that service level agreements around getting messages to the bridge would have been clearly defined rather than ad hoc and discretionary.

In any project and project component, good documentation whether of project goals, deliverables, procedures and so forth are critical and project management has little hope of success if good communications and documentation are not at the heart of everything that we do, both internally within the project and externally with stakeholders.

What we find today is that the project management lessons of the Olympic, Titanic and Britannic remain valuable to us today and the context of the era whether pushing for iterative project design where possible, investing in tribal knowledge, calculating risk, understanding the roles of system engineering and system operations or the interactions of protective external forces on product costs are still relevant.  The factors that affect projects come and go in cycles, today we see trends leaning towards models more like the Olympics than dislike them. In the future, likely, the pendulum will swing back again.  The underlying lessons are very relevant and will continue to be so.  We can learn much both by evaluating how our own projects are similar to those of White Star and how they are different to them.

Bibliography and Sources Cited:

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry, February 2007.

Esposito, Dino. “Cutting Edge – Don’t Gamble with UX—Use Wireframes.” MSDN Magazine, January 2016.

Sadur, James E. Home page. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 13 February 2017.

Winchester, Simon. “Atlantic.” Harper Perennial, 2011.

Titanic-Titanic. “Olympic.” (Date Unknown): 15 February 2017.

Titanic-Titanic. “Guarantee Group.” (Date Unknown): 15 February 2017.

Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture”. (1998): 16 February 2017.

Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 16 February 2017.

Ellis, Sam. “This jet fighter is a disaster, but Congress keeps buying it.”. Vox, 30 January 2017.

Additional Notes:

Mark Kozak-Holland originally published his book in 2003 as a series of Gantthead articles on the Titanic:

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers and later ProjectManagement.com (2003): 8 February 2017.

More Reading:

Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.

Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.

US Senate and British Official Hearing and Inquiry Transcripts from 1912 at the Titanic Inquiry Project.

January 28, 2017: The Noto Cultural Society

Today is Saturday.  We have been in Noto for about a week now.  What a week it has been.  We are feeling kind of worn out.

My day turned out to be one interruption after another.  We started off needing to take a hike down the hill to go to the big grocery store down there.  That is about 2.2 kilometers which is not very much if the ground is flat.  But it is a bit of a hill here and on the way up the hill I have to carry all of the groceries so it is hot, sweaty and slow going.

We were only home for an hour or two before we had someone that we did not know stop by the house to inform us of the Noto cultural society (or the swarm as they call themselves) meeting this evening in town.  Of course the person who came by only spoke Italian which made the entire thing so much more challenging.

She was probably at the house for most of an hour, but we eventually got things figured out that we were to go to this meeting across town about two hours later, take the kids, pay twenty Euros… meet people or something.  All very complicated and surprising.

So our day ended up being absolutely nothing like we had expected it to be.  Dominica was in the middle of cooking dinner when the woman arrived, too.

So it was a scramble to get everyone showered, bathed, dressed, prepped and whatever and out the door to walk across town and try to find this place.  This is not what we pictured ourselves spending our evening doing.

We actually did pretty well finding the place.  You had to enter an ancient building and poke around a bit and fit a door going to a stairway and go up to what is basically an apartment upstairs.  We were actually decently early so took the kids for a walk down to city hall to kill twenty minutes before going back to be on time.

It turned out to be a very interesting evening.  There were only a few people that spoke English, mostly ex-pats from the UK and Scotland.  There were three kids there and after a bit our girls managed to break the ice and the five of them had a great time playing for hours.  They ran around the whole place like maniacs and did not want to leave.

There was a small dinner there and we visited with people and learned about town, although mostly what people want to talk about is American politics, unfortunately.  No escaping it here.

We stayed out until late then walked back home.  Definitely a very interesting and educational evening.  Well outside of our comfort zone.

January 27, 2017: Full House and Minecraft

Friday in Sicily.  Nice day today with the windows open again.  Sun is out.

I did some back end website work tonight.  Dominica is going to give it a try and see how she will do at doing some web design work.  She has talked about doing this for a long time but it has never come to fruition.  It takes time to get past the initial barrier of figuring out the platform, figuring out the theme(s), getting the hang of the latest styles and trends and you really need a bit of time to just concentrate on that.

I put in a normal day then spent the evening with the girls in the living room working on our long standing Full House marathon and playing Minecraft on the Apple iPads with each other while the show is on.

January 26, 2017: Full House Marathon Begins

Thursday.  The weather is nice enough today that I opted to open the windows around the house and get fresh air in.  It’s chilly, but not bad.  About fifteen degrees and the sun is out.

Very busy day of emailing, writing, posting and all of the usual.  Plus some new scrambles caused by yesterday’s news.

This evening we finally got (I guess “finally” is a strong word, we have only been here three days) got the Amazon Fire Stick set up in the living room and got everything working so that we can use Netflix.  Like back in Romania, Full House is available for us here.  The girls have been asking to be able to watch this for more than six months now.  They love this show.

So we picked up where we left off with Full House back in Romania in June and are over halfway through the series now.  Making our way towards the end so that we can start watching Fuller House all over again.

We stayed up quite late watching Full House and snuggling on the couch.  Dominica has a recliner sort of thing in the living room that she uses and the girls pile onto the one couch with me.  The television that comes with the rental house is tiny and only 720p but it works okay.  We will be getting our projector hooked up at some point, although we have no idea when or where we are going to put it.  We’ve been contemplating it and walking around the house trying to figure out where it could work and there are several places that are almost great and none that are really good.

We had a bidet mishap this evening that literally had the water pressure turn on so high that it blew Ciana’s pants right off and shot water all over the room.  That’s one bidet that is going to need some careful management.

The girls are anxious to be video gaming again.

January 25, 2017: Day Two in Sicily

Wednesday and our second full day on Sicily.  This morning we were up a bit earlier and we went to the local produce market and picked up a small number of supplies to get us through another few days.  Liesl has discovered yellow delicious apples and cannot get enough of them.  She goes on and on about how much she loves these apples.  They taste exactly like the yellow delicious apples from New York, but she has never wanted to try a yellow apple before until they were the only ones available and now she realizes that they are the best apples that there have ever been and she is eating them with reckless abandon.  Not only does she eat one after another, she eats them right to the core with the seeds falling out.  There is nothing left but a stem!  Yellow delicious have always been my favourites, so I guess that she gets that taste from me.

I did a lot of writing and posting today, was at it all day.  Loving that this house has an office for me to work from.  Most places that we rent do not and that makes it very hard to get anything done.  Either there is nowhere comfortable to sit or I’m stuck in the middle of where the girls need to do school or whatever.

This afternoon I got some work related news that might turn out to be good but for the moment has us rapidly trying to figure out our work, living, finances, travel and overall situation.  Lots of things are suddenly up in the air that were not before so our time in Sicily suddenly became rather hectic.

Dominica made pasta for dinner.  I have very little free time today as I am trying to catch up from all of the travel time and busyness and our week off in Rome.

Had some wine and worked until late in the night.


January 24, 2017: First Day on Sicily

Tuesday, our first full day on Sicily in the little hill top city of Noto. I was up at eight. Of course, there was no Internet so there was not very much to do. I set some things up and did a little posting from my phone, but that was about all that I could do. It was rather stressful because no one was responding to us and we have never had working Internet here so we did not know how bad this was likely to be. You expect that when you arrive at a new place that the Internet will be on, tested and working for you at least upon arrival. Hiccups happen, a lot, but they should be working when you get there! They have had unlimited time to make sure that that part was working.

We were very pleased when the Internet came on between ten and eleven this morning. We got everyone online and started doing some catching up. Now we can really start to get settled. And we know that we do not have to find a new house right away! That would be a major problem, of course.

Around noon I finally had a chance to set out on a hike around the city. We need supplies and I have to figure out where to get them. I had been out for a walk last night and came across nothing at all, so that was not promising.

I walked all over town, doing a lot of kilometres. I got down to Corse Vittorio, the main street in the city, and made it the entire length of the city! At least of the old town. On the way I found the big cathedral that is the main attraction in the city. And the amazing baroque city hall. And next to that was a large tourist information centre, although they were pretty much just into talking to one another and did not seem very interested in the fact that a family had just moved in for three months. They handed me a paper map and seemed to feel that their entire, large, three person office was only there to hand out a paper map. Odd. I did ask, though, and they showed me some stuff in town and where some mini-markets were.

I set off on a very long walk which got me to the edge of town just fifteen minutes after the only market on that side of town had closed and would not open again for two more hours. I took a picture of their open times, told Dominica and set off to walk back home. That really sucked.

I got quite the walk in, though, and got home and spent a few hours doing work in the new upstairs office. This is my first chance to start to actually catch up in weeks. I need the quiet, alone time of the office.

In the late afternoon, we went to the market after it had opened and did our first real grocery shopping. We got as much as we could carry, maybe a little more, and hoofed it back to the house. Now we have ingredients and can cook. And now we have bottled water so we can drink since we can’t waste the water in the house because we need that for toilets and showers and stuff. Having so little water is a major issue.

That was an exhausting walk, and I had done it twice (plus more.) I was super tired. The stairs up to my office are a flight and a half of very narrow, very stone stairs that wear you out quite quickly, too. I am getting a workout.

Dominica made pasta for dinner, what else would we have for our first homemade meal on Sicily?

We did discover that there is a market right around the corner from us, but that it is only open in the mornings, so we will check that out tomorrow if we can. There is a bakery near there as well. Hopefully that means simple, fresh, daily bread is available.

The evening was spent posting, writing and getting the house in order. Tonight we hooked up the Amazon FireTV in the living room and got Full House up and running so we started watching that as we only get to watch it when we are not in the United States and the girls love the show and have been waiting to watch it again since, we think, Romania. A long time, no matter what.

January 23, 2017: Train Day to Sicily

I got effectively no sleep last night.  I did not get into bed until almost two and was up by four.  At four thirty I gave up on resting at all and just took a shower to get a jump on the day and get out of everyone’s way so that we could get ready as quickly as possible once Dominica and the girls were up.  This is going to be a long, long day without a real chance to rest.

It was a bit of a scramble to get everyone out of the door by a quarter till six in the morning, but we did it – just barely.  We had to lug our luggage down the street and over to Cavour where the Uber was going to pick us up.  We were right on time and he was waiting for us.  We were on the wrong side of the street so he swung around in his Renault van and we fit in nicely.  Plenty of room for everyone and the luggage, we didn’t even need to use the third row seating to do it.

The drive to the train station, Stazione Termini, was only a few minutes and most of that because of construction.  Fourteen Euros and we were good to go.  It was before six thirty and we had more than an hour to camp out and relax before our train was scheduled to depart.  That’s what we like, better to be a little bored than in a panic.

We had time to build a luggage fort for the girls that they played in.  They thought that that was great fun.  We got coffee and snacks for now and snacks for the train.  Plenty of time for a walk around and scoping out the train station.  We got there only a few minutes earlier than ideal and not knowing how Uber was going to work in Rome, we did it perfectly.

We boarded the train right on time and off we went.  No issues this morning.  It was still dark out when we got underway and would be dark when we arrived in Sicily, too.  A long day, but no changes so we just get to sit back and relax all day.

The ride went well.  Long, but well.  Our luggage all fit into the end luggage area so we were able to keep a decent eye on it easily.  That was very good.  Our backpacks went into the overhead above us.  We had a table just for the four of us so we all faced each other as a family.

We got to go through Naples, which was neat.  What a huge city.  Napoli is actually larger than Roma, just by a little.  And both are much smaller than Milano up north.  Those three dominate the country as the big power house cities.  In Napoli we got see to Mt. Vesuvious was is pretty cool.  We have seen a lot of volcanoes in the last year!

The trip south went well and was interesting.  The train route really does hug the coast once you leave Roma so we got to the sea for a large portion of the trip, which was neat.  Southern Italy was far more industrial and depressed than I would have imagined.  Hundreds of miles of beaches and we never saw a single person out enjoying some of the best sea front in the world.  Just old run down houses and condos in one little depressed town after another.  I knew that south of Napoli, Italy got pretty poor but I really did not know the extent to which the coast itself was not even developed.

The highlight of the trip was getting to the port of Messina where our train drove onto the giant ferry to cross the strait between the Italian mainland and the island of Sicily.  How cool.  We have done nearly everything with trains, but this is a new one.

On the ferry Liesl was fast asleep so I stayed on the train with her while Dominica and Luciana went up on deck.  It was a good thing that they did as there was a tiny storm and the water in the strait was really rough.  We were getting thrown all around down on the train in the bottom of the ferry. Dominica was getting a bit sick even up on top in the air.

The strait is tiny, so small that they regularly consider building a bridge to cross it, so the crossing was maybe fifteen minutes of actual time on the water.  Not bad at all.  Once docked the train just pulled us out and we were right into the Messina station where our half of the train was separated from the half that was heading to Palermo and we went down the east coast of the island towards Siracusa.

Eastern Sicily was much, much nicer than western southern Italy.  Beautiful towns and we got to see the mammoth that is Mount Etna, Europe’s most active and imposing volcano.

We were all pretty sleepy by the time that it was dark and we pulled into Siracua, the final stop of the mainland train.  It is nice riding to the end because there is plenty of time to unload the kids and the luggage of which there is so much.

Thankfully Siracusa is a terminus and we were able to walk on ground level around the end of the tracks, no need to go up and down a ridiculous amount of stairs.

We were going to book another train to take us on to Noto, but there was a taxi van waiting right outside of the station, so I went and talked to them and they said that for eighty Euros they would take us to Noto, so we did that.  A bit more expensive, but we could go there straight away.

The taxi took no more than half an hour and we were up into the hill town of Noto.  It was very dark so we really got no view of the area around.

Google Maps, as always, was useless. It could not show us a way to get to our house and kept trying to send us on roads so narrow no car could go down there and some were stairways!  We would days later figure out that Google Maps has the road names all wrong in this town and many are in the wrong places.  Our driver had no idea where to take us and had to use our GPS since he didn’t have any.  This is a good reason to use Uber, they have this stuff ironed out a bit.

The driver and I wanted to get dropped off at a spot that he found where it seemed reasonable for us to walk.  Dominica would have none of it and made him drive us all around trying to follow her GPS.  It would turn out later that the driver and I had found the spot literally closest to the house on the best ground.  We did not know that we had, but from looking at maps it appeared to be the best possible option.

So we drove around a bit and ended up parking on Cavour and blocking the street for quite some time as we unloaded onto the tiny, tiny sidewalk and then worked to drag everything that we own up a very uneven cobblestone street with traffic constantly making me move over to the wall to let them pass.  It was terrible.

Thank goodness the housekeeper for the house got our message that we were nearly there and looked for us out on the streets.  It turned out that we were never going to find the house given that the maps were totally wrong.  There was no way to ever find it.

Even with her finding us, it was an ordeal to get all of our luggage to the house itself. There was just so much and no good way to move it.  I was in some serious pain by the time that we got into our new home for the winter.

The house is really nice.  Solid old stone structure and a lot of room.  A nice big living room, good bedrooms for us and the kids.  The bathroom upstairs is ridiculously small, to the point of actually being a joke.  The girls can use it, but neither Dominica nor I can, at all.  We actually cannot physically get to the toilet in it!  It has a nice shower, though.  The downstairs bathroom is really big, which is good.

No Internet was on when we got in.  None at all.  Apparently they forgot to turn it on before we got here.  So our first night is one without any Internet.  Not such a big deal, we get 3G and sometimes LTE inside of most of the house, so we are able to let people know that we have arrived and are safe and we can let the landlord know that we have no Internet.  We are pretty tired so not looking to be up very late, anyway.  By the time that we were really into the house, it was likely nine or ten at night.  We are exhausted, especially after getting essentially zero sleep last night.

The really big shocker for us is that there is only two hours of water, per day, in the house.  That’s right, I said it, only two hours of the day is there running water and twenty two hours of the day, there is not.  The only water available during those times is what is in the hot water heater (which we’ve not seen, it might be an inline) and what is stored on the terrace in two, big Rubbermaid cisterns.  There is a total of 2,000 litres that gets stored up there, if all goes according to plan.  Enough for the basics, but just barely.  Showering, laundry… these things are going to be difficult.

Well, our new adventure in Sicily has begun.

There is no food in the house, obviously, since we just arrived so we decided to go out to eat on our first night. Dominica set to unpacking some things and I did a walk around the vicinity to see if there was anything open.  I found one thing, a trattoria, that was really close to our home that was open and looked nice.  I walked quickly home, got everyone dressed and ready and we walked the girls down there and went out for dinner.

It turns out that the place was pretty fancy, as it would turn out nearly everything in Noto is because it is mostly a tourist town, and we were the only people in the restaurant, likely all evening.  We popped in and asked, in Italian, if they were open and they assured us that they were and we ordered their antepasti buffet, which was seven amazingly different antepasto piatti mostly made of seafood.  The girls tried octopus (pulpo) but did not care for it.  There was a lot of really neat stuff.  We enjoyed it a lot.

Then we had pasta for dinner, all of us.  It was all amazing and we were very happy with dinner, although it was not cheap and we were not looking to spend any money unnecessarily.  But it was what it was, we needed food and it was the only option.  Tomorrow is going to begin the search for groceries.

After dinner we got home and were off to bed.  Dominica and my bedroom is the not the master, but is the ground floor room with the main bed, it is off of the living room.  The girls have the upstairs master suite that doubles as my office.  They have the en suite pointlessly small bathroom.

Finally, time to sleep.  Fingers crossed that someone will get us Internet access in the morning.