Posts Tagged ‘center for change mangement’

Hunting submarines is similar to hunting situations likely to fail. In this second blog on organizational fatigue let’s do a deep dive and see what we can find.

There is an irony in that while the submarines are lurking below the surface the organizational factors increasing the probability of failure are right in front of the team. There are several reasons for this, which we will get to in a later blog. For now let’s stay with defining a system that searches for potential failures.

The first question that comes to mind is, “What do we look for?” Elizabeth Lay provides a good list in “Practices for Noticing and Dealing with the Critical. A Case Study from Maintenance of Power Plants.”

 “Error-likely” Climates

Lay provides 8 behaviors that are good indicators a failure is on the horizon:

  1. Leaders who use a top-down or intimidating style;
  2. Leaders who are closed off to listening to those close to the work and discouraged questions;
  3. Leaders who are not engaged in the work;
  4. Unclear roles and responsibilities for day-to-day work;
  5. Unhealthy win-lose competition between groups of workers;
  6. Over-involved customer who lacks an understanding of the work;
  7. Leaders unfamiliar with best practices and/or the cultural requirements for getting the job done;
  8. Leaders who don’t ask for help.

There is something familiar about this. Remember from the previous blog the child making a mess in the department store? What is the first question that comes to mind? “Where are the parents?”

From my work in change management one thing that stands out in this list is the absence of technical excellence. Does this mean we can just march in without technical know-how and still get things done? No. Quite the contrary. We do need technical excellent but it is only a starting point. We need a resilient organization. So how do we know resilience is missing?

Going back to the submarines, the above list is about what is invisible. The invisible component is the human factor – that “soft” stuff. It is about hubris, a subject covered in a previous blog.

Hubris is a big part of what keeps me in business. It shows up as intellectual prowess and the belief that he who knows the most will provide the best product. Frankly, that is just the starting point and provides only half the solution.

Complex projects require a communication network that runs in two directions. The one we are most familiar with is top-down. This sets the stage for contracts, statements of work, etc., and gives the team a sense of direction. This rarely is perfect and complete, which gets to the second direction – bottom-up. In complex projects this is known as emergence. The project actually evolves (which can create real problems in a fixed-fee situation – but that’s another blog) and requires good information from team members closest to the project climate and work at hand.

In order to avoid organizational fatigue a back-and-forth between senior managers, the customer, and team players is needed. In a way, we become our brother’s keeper not so much in terms of taking on his responsibilities but in terms of being sensitive to the ripple effects of what we are doing as well as what is going on in the environment.

Pinging the organization for the 8 behaviors mentioned and taking corrective action will go a long way towards helping steer resources and expectations in the right direction.

In the next blog we’ll continue our journey into the causes and ways to avoid organizational fatigue.

Resilience Engineering has emerged from an approach towards accident modeling and prevention that is based on answering the question, “What makes for sustained safety and success?” The idea being focusing only on what went wrong is important but may give only half the picture.

This all sounds well and good and makes so much sense one would wonder what is so special about this approach. How else would one look at accidents? Turns out in the history of accident modeling one of the first models used took a very different approach, a very personal one. It is an approach that leans towards shame and blame should failure occur and is alive and well in certain areas of the management world.

Don’t Hit That First Domino!

Herbert Heinrich developed the Domino Theory of accidents in 1929 while working at Travelers Insurance. The model has 4 components or dominos and the idea was the damage that resulted from an accident could be analyzed in terms of a series of events that cascaded like a set of dominos. The dominos are:

  • Genetics
  • Individual personality and/or character flaws
  • The Hazard
  • The Accident

“Bad seed” might be the best way to describe the genetic or ancestral contribution to accidents.  The individual is doomed, in a way, before they get started so it would be best to just not hire them.

“Bad habits” would sum the second point where the individual is innately predisposed in day-to-day behaviors to engage in risk-taking activities. Think, “strong urges.” An example would be having the urge to surf the web indiscriminately.

“Risky behavior” is synonymous with the hazardous activity, e.g., surfing the web without antivirus protection and downloading a Trojan horse that takes over one’s computer.

The crashing of a site by having one’s computer unwittingly participating in a denial of service attack would be an example of the damage caused by all 4 dominos falling.

The idea behind using this model would be to remove the dominos or space them far enough apart so that they could not have a chain reaction. For example, pre-screen and avoid hiring anyone who has those bad genetics or predisposition. This avoids the problem completely. If you do hire a person with the undesirable character traits then don’t let them work in areas where their flaws would play out in the work place and cause an accident, e.g., deny them the ability to surf the web at work.

You can see this takes a rather dim view of human nature. It also has another major shortcoming, i.e., failure to take into account the dynamics of the situation and the broader view required to actually determine what causes failure.  Is it that simple? Is my computer participating in a denial-of-service attack simply my responsibility alone? Should I be punished since I must be defective?

Unfortunately, this approach can be very tempting for a manager to use when the heat is on to find out what went wrong in a situation, especially a complex one. On April 14, 2011, Frank Krakowski resigned as the head of the FAA’s Air Traffic Controller Organization because of a series of events where controllers were asleep in their towers.

“Heads must roll!” would be the simple way to sum up the so-called solution to the situation. I have to believe most people know that Krakowski’s resignation had little effect but human nature intensely wants to play into the domino model. Find the bad guy and punish him or root him out! And if you can’t get to the bad guy soon enough then punish the guy who hired him!

The thing to keep in mind in all this is resilience engineering is about determining what it takes to work safely in a complex environment. The air traffic control situation is a very complex socio-technical problem. Simplistic solutions just don’t cut it. Aaaaah! But they feel so good, and for a brief moment give a shot of narcotic allowing one to drift away and pretend to be in control.

In the next blog we’ll look at the next evolutionary step in accident modeling and see what it has to offer.

Project Reality Check #2: Being a Rainmaker

by Gary Monti on December 28, 2010

“Rainmaker” is a title that fits with a lot of project managers. It sets the bar high requiring a great deal of skill and political savvy to bring about the deliverable as if almost by magic. The reality is quite different. In fact, there are several realities that must be juggled to be a successful rainmaker ranging from the very concrete to the intangible. This can be seen when looked at through the nine areas of project management: scope, time, budget, human resources, procurement, quality management, risk management, communications, and integration.

Nested Easter Eggs, Projects, and the Truth

Imagine a project as a nested Russian Easter egg. At the core is the candy, the measurable deliverable – the client’s main focus. Surrounding it is the smallest Easter egg – the triple constraint. The painting on this egg is an orthogonal latticework of scope, time, and budget with one axis just a little wavy. Time and money can be measured, as can portions of the scope. The scope, however, starts bringing in the intangible because it is driven by client needs, each one of which can be multilayered itself. This is why the one axis is a little wavy.

The language of the triple constraint reflects the deliverable but is different since it includes the time and money aspect. It also is more complicated because there are three dialects; one each for scope, time, and budget.  The language gets more complicated because there is a change in the truth system being used. That is how different languages develop, i.e., attempts to describe different realities.

In other words, when we talk “deliverable” one language is used which is different from when we talk “scope, time, and budget.” For example, imagine a soccer player who can put an amazing curve on a kick. Talking about the beauty of the kick is one thing. Talking about everything that went into that player to get to the point where the kick could be made is another. (Many a beer or other beverage has been drunk enjoying going back and forth between these two languages. It’s all very human and very much a part of any project.)

The next egg (layer) has a supply chain network drawn upon it. It comprises procurement and human resources. People, equipment, facilities, etc., are needed so the project can be completed. The intangibility increases. There are more, varied conversations occurring all of which need orchestrated and harmonized. The discussion around this orchestration and harmonization creates another language with two dialects.

This brings us to the next larger egg, which has a swirling pattern of two distinct colors representing quality- and risk management. Imagine it being drawn by a pointillist. Each dot represents a specific test of a component or system (quality) or a specific threat or opportunity (risk) that must be addressed. Holding the egg at a distance the swirls can be seen representing the interaction between quality and risk and how together they influence the inner components of project management and the creation of an acceptable deliverable. And, you may have guessed it, yet another language with two dialects is created.

And what about the conversation itself? This is where communications comes into play. This egg has a nervous system painted on it. Actually it is more like an LCD display where the flow of information through the nerves can be seen. This flow represents the even greater level of intangibility. Why? The message is in the flow between the various parts of the project.

Finally, the largest most intangible egg of them all – project integration. It is invisible. This egg can be felt but can’t be seen. Imagine a magnetic bottle. There is a very real force field present containing the other eight areas of the project along with the specific project components, stakeholders, and the energy that flows between them. This egg can be experienced, it can be discussed, it can be influenced but it remains invisible. Its language is one of connection and interdependence.  It reflects the achievement of acceptable balance among all stakeholders, components, and their performance. The integration exists in that balance rather than inside any one thing or person.

The deliverable only comes alive and is acceptable when integration has occurred and is sustainable.

What does this mean? An intuitive example of connection and interdependence is the relationship between an aircraft wing, the engine, and the payload. The engine must generate sufficient thrust to propel the wing forward and generate lift. However, if a large enough engine is too heavy then the design is pointless because there is insufficient lift left for the payload.

What makes a project manager a rainmaker is the ability to achieve that integration. It is reflected in commitments within the stakeholder community. Those commitments are then mapped into the design and creation of the deliverable through the project plan and execution of the schedule. Oh, did I mention there might be some magic involved?