Get-There-Itis: A Major Stress Factor for IT Projects

Gayan Perera, 27 August 2020

“Get-there-itis" or “plan continuation bias” is a term I learnt when learning to fly. Essentially it’s the eagerness of a pilot to reach a destination even when conditions for flying are unfavourable. I see this creeping into IT projects, disregarding obvious risk just to get it done.

Let’s start with a story:

Last Christmas season, we packed the airplane with tents, car seats and kids and had a great time camping with friends in Whitianga. As we needed to be back for work the following Monday, I checked the weather on Saturday and informed Jaime, my wife, that we may struggle to get back on Sunday due to bad weather coming our way. On top of this, the Australian bush fires were causing our skies to turn orange!

Early Sunday morning, I checked the weather again and told the family we needed to depart before 10am if we were to beat the weather. While driving to the airfield Jaime wanted a coffee, in my head I was telling myself “Oh man that’s another 10-15min delay” but I allowed it. I was feeling the stress rising as we got to the airfield, said our goodbyes, fuelled up, did the pre-flight checks, got in, double checked the weather, checked the route and took off.

I had planned a route that would take us across the Coromandel ranges, the lowest possible terrain, on a direct track back to Ardmore. Based on the weather and terrain, I planned to fly between 2500 to 3000 feet, well clear of terrain and 500 feet below cloud. I knew that the winds were very gusty, about 22 knots gusting 28 knots and bound to get worse as the day went on.

Red line is the planned route. Green line is the actual route.

Once airborne I realised that there was less clearance between the terrain below and the clouds above, so I chose to go south, then track back west. It wasn’t a good move; the wind across Table Mountain was creating a lot of turbulence so I tracked further south and decided to head for Pauanui to give myself more time to come up with a revised plan.

In my head, the worst-case was we could land in Pauanui and drive back if things didn’t work out. The other plan was that I knew I had enough fuel to go to Port Jackson via the coast and come back around to avoid all terrain and turbulence. Instead I chose to embrace the turbulence across higher terrain, prioritising sticking to original ETA’s and avoiding putting other people out.

Things were bumpy but not enough to worry me, then suddenly we hit turbulent air which tipped the left wing up violently banking the airplane to the right at a very sharp angle. It was enough to frighten me. Jaime who doesn’t swear said something along the lines of “Ohhhh S***!” I knew she was scared, the kids were blissfully unaware…

I slowed down, pretended like it was nothing and carried on. If I’d panicked the outcome wouldn’t have been good for anyone. However, inside I was very worried. I knew there was more of this, but I couldn’t see it (turbulence). How do you defeat something you can’t see?

I assessed we were about 2 nautical miles from clearing the ranges and that we had another 3-4 minutes of turbulence ahead so decided to carry on. Luckily the rest of the trip home went well, apart from the sky turning orange and bumpy. There might have been a different ending that day.

-----

Bringing this back to IT projects, pressured to get it done by a certain date we often make decisions disregarding obvious risks. We have project plans and those plans change based on things that pop up, while alternate plans are rejected due to budget and time constraints etc. The desire to reach a milestone pushes us on even when we know maybe we shouldn’t and end up stressed, scared, worried and facing undesirable consequences.

How do we overcome this tendency? Here are 3 tips that I’ve learnt that may help:

1. Be courageous!

• Have tough conversations, make the hard calls and be prepared to say no. In IT projects, when a deadline is unreasonable or unachievable, say no, find another way.
• Talk to your client/team about what trade-offs they are willing to make, for instance, is the deadline more important than quality?
• Classic example, when users don’t perform user acceptance tests to your liking, go back to them and say this is not good enough please do it again, maybe with additional training.

• One bad decision on its own will not necessarily cause much harm, however one bad decision leading to another leading to another will!
• E.g. If the internal quality controls fail (tester’s tests fail), don’t carry on training users because that’ll have a negative effect on users. As they say “Don’t let the train leave the station!”

3. Give yourself space to think!

• Give yourself space & time to assess.
• Create alternative plans for different scenarios.
• Be aware of what’s happening around you, ask the question “what’s important now?” 
• Situational awareness and foresight are paramount.

I do regret choosing to fly across the higher terrain that day, in hindsight I should have just gone the long way around, it would’ve been more comfortable for everyone. It highlighted a gap in my knowledge and experience, and since that trip I have completed the first part of my mountain flying and commercial licence courses to ensure I am better equipped to make better more informed decisions next time.