Surviving Catastrophic Project Failure- Part 2

By: Michael Gaccioli, CEO, Managing Partner

Welcome back for part 2 of our series Surviving Catastrophic Project Failure. We are going to take a dive into the project. This section will set up the eight (8) key survival tactics that I have taken away and use to this day if something starts to become problematic. If you haven’t read the first part, please go back, and have a read. You won’t be successful if you read the last chapter to understand the book, shortcuts don’t work.  All your comments and insights are welcome. We continually strive to refine our practices and we hope that this presentation proves as insightful and valuable for you as it has been for all of us at BTI.

---

Part 2: The Project

We all hate to admit failure or be responsible for a failure. To understand why we really don’t like to talk about or admit failure; we need to look at our own psyche. This stigma comes from a place that is deep with us and is depicted most effectively by Maslow’s Hierarchy of Needs. Most of you have probably heard of Maslow and his theory, but for those of you who haven’t or have forgotten, Maslow theorized that there were five basic levels of Human needs.

The base of this hierarchy of needs are the survival requirements, these being the most of our needs and the foundation of our requirements for life, things like food, shelter, water… The highest level of need is self-actualization. Essentially this highest level fulfills the need to achieve a “Zen” like status. This is where you would be comfortable with who you are, what you do and what you stand for. Although Maslow’s theory has been rebuffed for being too individualistic and not considering the collective in his theory, I am going to disregard those for the purposes of this discussion, because really, it’s all about number one now, isn’t it? Out of all of these needs it is the second level that we will revert to the most. Safety. The security of body, resources, and employment. Interesting that employment should be so low on this hierarchy, right? Well not really. Employment and by extension money means we have some sort of security in life. Security to buy food, provide for our families and when this is threatened, we start to become fearful.

It is not a stretch to think that as we fear our job or the ability to support our family, we start to regress in the hierarchy of needs back to the safety level. Some people even try to protect themselves by not acknowledging an impending failure. They try to avoid the inevitable or don’t disclose the problem(s) to others such as sponsors or stakeholders. Not being a psychologist, I am going to blame this on our parents and educators, because they aren’t here to defend themselves. Seriously, if you think about it, when were young we undoubtedly did something wrong, got yelled at, were grounded or worse spanked. The learned or acquired reaction would be to hide or avoid the thing we did wrong or what we perceived as wrong, to avoid this consequence. This is obviously the wrong reaction. Thanks mom and dad. So how does this relate to the topic at hand? Well fear of failure or worse the act of failing causes us to sink back from the self-actualization or self- esteem plateau that we may have been at and depending on how severe the problem is we begin to worry about ourselves and our family and yes drop right back to protect the safety of all we hold dear.

I read an article recently about research into the fear of failure at Carleton University in Ottawa. The article provided me with some insight into aspects I wouldn’t have thought about otherwise when dealing with fear and Maslow’s theory.

The article entitled “Fear of Failure” discusses the relationship between fear and procrastination and how the fear of failure is one of the main reasons for procrastination. As a procrastinator, this seems like a reasonable assumption. The underlying theory of this article is very interesting and relates perfectly to what will be discussed in this presentation. One of the researchers at Carleton, Adam McCaffrey presented some preliminary data from his thesis. Under the supervision of Dr. Timothy Pychyl, an associate professor of psychology at Carleton. McCaffrey (Adam) measured the fear of failure and the relationship it has with procrastination. He measured its effect when considering the notion of vitality. Not surprisingly the higher the measure in the fear of failure the higher the prediction of procrastination, conversely the higher procrastination. From these findings McCaffery and his team considered the relation between the fear of failure and procrastination when considering a measure of competence or our feeling of being capable. It turns out that even though we have a fear of failure, if we feel competent, we are less likely to procrastinate, thus getting on with the job at hand. Simply put, if we feel like something is going wrong or we have done something wrong, we are less likely to deal with it. We want to turn a blind eye and hope that it will go away, but if we feel like we are competent to deal with the situation at hand, we will try to solve the problem, even if we might still fail.

It may sound like I am rambling about our inner workings and psychology, but it is necessary to understand what makes us and our teams tick for us to understand or appreciate why a project can fail or what challenges we will be faced with.

Now, let’s look at the project details that I was managing that took a turn into a very unpleasant detour.

Here is the set up.

• Project: A natural gas processing facility control system migration with an operations simulation training system
• Duration: 1.5 years
• Project manager: yours truly
• Team size: 32 engineers/technologists at the high point
• Project value: $9.7 million (total install costs)

I took over the control system migration project at the beginning of detailed design phase from another PM and I felt this was going to be a great project to manage. The control systems were a known entity to our team as they have done this work many times before. The team was amazing! We had some real superstars in the engineering business at the time. Lead control system engineer, one of the most intelligent and respected control system programmers I know with years of experience behind him. This guy is a no-nonsense kind of guy, but he would be the very last person to tear your head off if things are a bit rough. Lead electrical engineer was intense, analytical, and meticulous. The lead process control engineer was respected and crazy smart. These engineers were known for their expertise and knowledge and they are also strong willed and independent when it comes to how they execute their work. All three had very different personalities and required a different approach to communication and although I could see some challenges with these guys and getting information out to them, I was on cloud nine. I had a team that could knock the project out of the park, and this was going to be an amazing job.

We were starting up the detailed design. The skies were blue, the birds were singing with rainbows and sunshine with the team was skipping through the halls to get to meetings and discussions (figuratively of course). Project reports were coming in from the team and I trusted my engineers implicitly. They were on top of the project and their respective work effort. They knew what work had to be done and getting it done. We all are loving life. Nothing could possibly go wrong. Right?

Well not exactly, in retrospect, there were warning signs. Who can really say that there were warning signs that early in the project? A little slip in getting a status here and issues of normal or expected magnitude there. Nothing too major or so it seemed. The requests that I made to show progress appeared to be of satisfactory quality, but as I would find out, they were not. As engineering progressed the little items that made me think, “dig a bit deeper on this” didn’t get that attention. At the time it didn’t seem necessary and there was always something more important to be done. All the engineers on the team were expressing that there were scope issues that needed to be handled and I was dealing with them in the appropriate fashion, discussions with the client, status reporting of the progress and meetings with the team and as required, change notices. I knew very well what the electrical and controls engineer were talking about because that was my background. I didn’t know exactly what the process engineer was talking about to the comprehension level that was needed.

At the beginning of the new year the client project manager that started the project left the project and the company and a new one took his place. Let me say that a change in the project manager is never easy and when issues start to rear their head, that’s the last thing you need. The education of the new project manager took up a considerable amount of time and status reports and checks took a back seat to ensuring the new PM was up to speed on the project and how we were managing his budget. At this point things felt slippery. I was not getting the warm fuzzy feelings from one part of my team, but we discussed the slippage that was occurring and decided that we could handle them internal to the project. Then it happened, the new PM wanted to see for himself how things were going. Confident, I set up a meeting and the team was to present their work. Control lead and team, no problem. Electrical lead and team, no problem. Process leads and team, uh-oh, not so good. The client PM and I had a chat and he felt that something was amiss. After his departure I checked it out and sure enough with the added pressure of the client PM’s request the problems started to fall on the floor and pile up and started to get deep. A new meeting was booked with the process team and client PM to demonstrate the work completed and still the process team couldn’t display what they had accomplished in the past 8 months. How could these problems have gone this far without me noticing? 

Time to bring in the big boys. I discussed the issue with our office manager, my boss and told him how bad I thought it was and it was bad. I tried my best to dig into the problems, but the stress was mounting. I was trying to manage the other two portions of the project, but the team was feeling the heat from the client PM because of the failing portion of the project. The only saving grace about the failing portion of the project was that it was not mission critical. This was a nice to have on the project rather than a need to have. The team could feel the pressure. We had to separate the stressors from the controls and electrical teams that were being produced by the process team, not an easy task. Senior management from our company and the client were involved at this point and let me tell you, those sleepless nights I spoke about in the introduction, wondering if I was going to lose my job didn’t last a few days or a week, but two long months and even after that I was still looking over my shoulder for months. There was no indication from my boss, or senior management that I was going to walk the plank, they were very understanding, and I am thankful still to this day. One of the senior managers gave me some sage advice and insights as to why, I will share that tidbit with you later. Eventually we managed to agree on the scope of completion and cost splitting for this process portion of the project. Reduction in scope, expert help, lots of cash and many late nights for all involved finally brought the end of this portion of the project, successfully, but I guess that depends on your definition of success.

So, let’s dive in and I’ll show you some of the major components that I feel are a part of surviving a project that is in trouble or worse, failing.

• Identifying that something is wrong.
• Determine your current state.
• Informing project sponsor
• Inform the client.
• Maintaining other project activities
• Project team cohesion
• Team self esteem
• Becoming the informer not the solution provider
• Working to salvage relationships

Based on my project or any typical project that may be in trouble, what went wrong, why did the problems elude me, the client PM, and the rest of the team for so long? Let’s look at this and pull some of those ‘how to survive lessons’ out of this project so that we can become better project managers today! First things first, we need to determine if something was going wrong.

Thank you again for joining me on this trip down memory lane and learning about failure. Next time, we will dive into the first four (4) key components of surviving a project failure.

Until then, I wish you success.