Search This Blog

Friday, August 31, 2012

Would you know an Unacceptable Risk if it jumped up and bit you?

[Also available as a podcast]

When I was younger, I was quite risk-averse. I said "no" to a lot of things that some might consider a "safe-ish" activity - like Bungee Jumping or riding a motorcycle. (Dirt bikes were OK though, because I never got going that fast).

So why did I find myself backing away from a snake charmer who was walking towards me with a fully loaded Cobra held out in front of him?

More to the point, why did I let him put it around my neck in the first place?

Most would say that this definitely falls under the category of unacceptable risk. Some might say it was the adventures of youth. I would simply call it stupid.

February 1993 - my first day in New Delhi, India for a 2-week trade show. On the ride in from the airport in the middle of the night, I had passed a man riding an elephant down the street. An amazing country. I was solo for the first two days before the rest of the team showed up, and I was looking for something to do after I had checked out the booth at the fairgrounds. We had organized for cars with drivers, because it takes a whole different set of skills to drive there.

My driver had pulled over to the side of the road so that I could experience some of the local culture and tourist attractions, which apparently involved getting your photo taken with a poisonous snake draped over your shoulders. 

It must have been the smog affecting my brain, because I agreed to do it.

As you might expect, I was a bit nervous so I asked the charmer if it was safe - if the snake had been de-venomed. He nodded. So we proceeded, and the driver snapped a couple pictures of me with the charmer holding the snake across my shoulders.

It was only after he had removed the snake and I paid him that I realized my mistake. The charmer decided he wanted more money as I was walking back towards the car.  So he started to follow me. I turned to see the charmer pointing the "apparently de-venomed" Cobra directly at me like a weapon. Oops.

The driver stood between me and the charmer and signalled me to hand him some money. I did, and he passed it to the charmer, who seemed satisfied, un-cocked his Cobra and walked back to the basket.

I afterward learned that nodding meant "No" and wobbling your head side to side meant "Yes".

I  guess I should have read up on the cultural signals before I left on the trip.

Do you know an unacceptable risk when you see it?  Or does it literally have to (almost) bite you before you know it is "unacceptable"?

Defining Risk

In a previous article, we discussed the basic components of risk, the principles of pre-and post-event risk mitigation, and some basic risk assessment strategies. There is a continuum of risk - and where a specific risk falls will depend on the impact of the risk if it occurs, but also your personal or corporate risk tolerance. In the basic model, we looked at "High/Low impact" and "High/Low probability" in relation to anticipating risk events. But there is another aspect to risk management that is very important to consider, that may sometimes be less tangible and hard to quantify in numerical terms.

Is a risk "acceptable" or not? In order to determine this, we need to take a deeper look at managing risks.

Assessing Risk

In order to assess risk, you need accurate information, experience, and a solid dose of common sense (which apparently I was lacking at the time). If you don't know enough about the potential risk area, ask an expert, or at least a colleague who knows more about it than you. As a Project Manager, your job is to make sure that the team delivers - but it is not your job to know everything. Having an awareness of the big picture and the moving parts, yes - but you are not generally the detail expert. That is why you have teams with people who know each area much better than you do.
So employ their experience and skills when you do your planning and your risk assessments. More heads are better than one, especially when it comes to gauging risk. If you don't have anyone on your team who is experienced in that risk area, bring someone in from elsewhere in the organization, or bring in a consultant. If it is potentially a major concern, it may well be worth the investment of a few hours or days of someone with a keen eye and battle scars taking a closer look.

You also need to keep in mind the bigger picture beyond your corporate walls to fully consider the level of risk involved, and the true impact of what might happen. You might end up changing your project plan, scope and vision significantly if you determine that a high impact negative risk event is not only likely to occur if you continued along the current path - but would be completely unacceptable if it did. 

One thing to consider in your planning is that what may be "acceptable" to you may be completely unacceptable to others. So you need to be prepared to walk a mile in the others' shoes so you don't have a one-sided perspective.

Acceptable vs Unacceptable Risk

Acceptable risks are ones that you can generally live with if they occur. (Ideally, that everyone can live with.) You may have a delay in your schedule and/or additional costs, and perhaps disgruntled users or stakeholders. But at the end of the day, there is no real harm done. What you deem "acceptable" is relative based on your context, and may be very different for another person, project or business. 

An unacceptable risk might be defined as one that would do harm, fiscally or physically to person(s), a business or the environment. However, it is also fair to say that an "unacceptable risk" for one person might be quite acceptable to another.

Financial Risks
Your company might invest 10 million dollars on the "Next Big Thing" in the anticipation that if you are successful in the market, your product would be poised to bring in hundreds of millions or even billions of dollars in sales. That's a calculated risk by the stakeholders before they even start the project - and if they have deep enough pockets, it may be an acceptable risk. 

If, however you were a small company with an idea and very little funding and very little awareness of the potential market for your product, investing the last $10,000 you had might not be an acceptable risk. You might even lose your house, and have nowhere to go. 

For financial risks, deciding whether it is "acceptable" or not is generally dependent upon whether your business would survive, or the project could still be completed (or worth completing) if the risk event occurred.

Material or Bodily Risk
If you are a skilled mountaineer, climbing Everest or a sheer rock face may be seen as an acceptable risk because you are well prepared for the activity. Yes, you might fall to your death or suffer hypothermia, but the chances may be very low due to your level of experience, conditioning and confidence in your abilities and those of those going with you, and the quantity and quality of your gear.

If, however you were new to the outdoors, the same activity would not pose an acceptable risk, as you would likely be completely unprepared and much more likely to suffer a mishap, or even die.

Preparedness and experience are key contributors in assessing risk - and not just for yourself, but for the entire team, project and stakeholders. A seasoned mountaineer would refuse to take a new, untested person on the hard climbs with them. They would need to ensure that they had been prepared, conditioned and practiced on the smaller climbs first, with lower elements of risk. Eventually they would gain enough experience to join you on the difficult slopes.

If you were constructing a bridge or a building that thousands of people used every day, it would be unacceptable for it to fail or collapse, so all planning and quality control efforts should be utilized to ensure that will not happen - as the injuries and loss of life would be unacceptable.

Similarly, if your project may cause environmental damage should something go wrong, you need to assess the risks and take active pre-event risk mitigation strategies in order to avoid an occurrence.

Some of it is just common sense (which can sometimes be hard to find during hectic times on a project).

When I sat down with the snake charmer, I thought I had good information but I misunderstood him, and also failed to use common sense. Things might have turned out badly for me, due to being naive (and stupid). I had based my assessment on the skills of the snake charmer being able to safely handle the snake, and my understanding it was no longer poisonous. The act of him later posing the snake as a weapon caused me to swiftly reassess the situation, and therefore the level and nature of the risk. Definitely "unacceptable" in hindsight, based on my normal aversion to risk.

The Sleep Test

If you are sill not sure about the acceptability of a risk, there is one way to get a gut feel for"acceptable" vs "unacceptable".

Would you be able to sleep at night if it happened? If you cared about someone else affected by the event, would you still be able to sleep with it?

Well, perhaps you always sleep like a baby. But let's take it up another notch. Could you live with yourself, should the risk event occur?

Balancing Risk

The partner company hired us a car and driver, so that we would not face the perils of driving on the New Delhi roads. It was an acceptable risk to have the car and driver get us from place to place, as they were local and familiar with the city and road rules. Every day while at home, we determine that driving our own car to the shopping mall, to work or to the kids' music recital is an acceptable risk - even though we could end up in a fiery crash. We judge that based on the condition of the vehicle, the condition of the roads and our own skills, we think will be able to navigate the streets to the destination and back again safely. That was the premise of hiring local drivers - that their skills and competence would significantly reduce the risk of any traffic mishaps. Well, that was the theory anyway.

We actually had two cars and two drivers due to the number of people at the trade show. One was very responsible and relatively risk-averse, and then there was the one who ended up driving me most of the time. He incidentally was also the guy who introduced me to the snake charmer. I should have seen it coming.

Having a driver was definitely a good idea, as the road rules are quite different in India (well, at least they were in 1993).There you could turn a good two-lane-each way marked road into four or more threads of traffic going each way, with cars, trucks, motorcycles and three-wheelers weaving along together at different speeds. They had foot-high curbs on the side of the road, and the only reasonable explanation I could think of was that they were trying to keep the vehicles off the sidewalk - they drove everywhere else!

It was when our driver pulled straight out into oncoming traffic for the first time that I realized that in the end, there was only one practical rule of the road. "If I am bigger than you, get out of my way!" There we were, across the center line, ploughing on ahead with the oncoming motorcycles and three-wheelers diving for safety on the other side of the road. Until a delivery truck came roaring straight at us that is, whereupon our driver promptly forced his way back into the traffic on our side of the road. He may have saved me from the snake, but I was convinced he had other plans to finish me off using his car.

I will admit, he was not all bad - he did employ active pre-event risk mitigation strategies while driving. Every time we overtook a bus going in the same direction, he was constantly beeping the horn, indicating to the bus "I am here! Don't swerve into my lane and crush me." I then began to notice the continual honking everywhere we went, by all sorts of vehicles - all announcing they were there and not to swerve into them. Apparently nobody does a shoulder check before changing lanes. But nobody was angry - if you heard that much honking in North America, it would indicate a lot of swearing and frustration.

As much as his driving unnerved me, he did keep us safe - and did a much better job of it than any of us foreigners could have managed. This was because he knew the conditions, how other people drove, and what to expect. All in all it was an "acceptable" risk, if a bit frightening for the passengers.

He did make me wonder one further time though - after leaving the reception at the Canadian embassy, he drove us back to the hotel. The road was not busy, and there was no oncoming traffic - but he was impatient with the drivers in front of him. So naturally, he pulled into the empty oncoming traffic lane. He was speeding along at nearly 100kph/60mph as we came up to a very large traffic circle, which had large concrete barriers running along the side of the entry and exit roads, merging into a solid point - a point which was rapidly getting closer. He just managed to pull back into our lane a few feet in front of the barrier before zooming around the circle to the exit on the far side.

A stiff drink was definitely in order when we got back to the hotel. Only 10 more days of this until we were to finish the trade show and get to go home.


Determining whether a risk is "acceptable" is not a simple matter, and it is certainly a situation where you need the team's input. Determining the acceptability of a risk should never rest with just one person. Sure, there may be a final decision-maker, but only after due consideration of the perspectives and opinions of the team are taken into account.

What may be acceptable to you may not be acceptable to the sponsor, the stakeholders, the company or the public at large. If you lack experience, you are more likely to underestimate the impact of a risk, and therefore judge it "acceptable" when a more seasoned person would not.

Conversely, a seasoned consultant may deem a risk as acceptable, but you as the new Project Manager may feel quite nervous about it. In the end - after listening to the counsel of others, you have to go with your gut - could you live with the risk event should it happen on your current path? If not, then you might override it and say it is not "acceptable" - or at least put more efforts into mitigating the risk to prevent it from happening.

As for me? I am not quite as risk-averse as I was when I was younger. Perhaps more "risk-mature" would be a better word. I still will not do a bungee jump, and although I have since considered riding a motorcycle, my wife has assured me it is not a good idea. But I do take some calculated risks, with open eyes and some common sense.

The good news is that I have already crossed off "put a poisonous snake on your neck" from my bucket list. Been there, done that - and got the photo. I don't ever need to do that again.

Good luck with your projects, and carefully consider what risks are "acceptable" on your projects by tapping the experience of your team.

Thursday, August 30, 2012

Leadership: On Developing Teams - Are you alone on the Ice?

[Also available as a podcast]

Alone on the ice, surrounded by mountains and snow in the darkness. The faintest sliver of moon is barely brighter than the thousands of stars overhead. A cold, clear sky on a windless night, -16C/3F outside. I am dressed warmly but a small shiver escapes me.

Feeling very, very small indeed.

I am standing in the middle of Lightning Lake, British Columbia, Canada. The light of the stars is bright enough for me to easily see the contrast of light and dark - brighter, actually than I thought it would be. An igloo stands a ways back, off to my left. 

I check my watch. Time to go in.

I turn and walk in silence, a hundred paces back the way I came - where I join the rest of the scout troop I am leading. They have retraced their own steps back to the circle.

Technically I was not really alone - however with everyone separated and facing away from each other, looking only at the sky, the lake and the mountains, it was very easy to imagine you were indeed alone out there.  

In absolute stillness.

We waited for the last few to join the circle and then we quietly shared observations of the experience. Most felt small, insignificant, alone in the vastness - but also not alone, either. They were not talking about the other members of the troop hundreds of feet from them - they were feeling small, but also part of their surroundings.  Maybe the start of a sense of belonging to nature, and a few did not feel as cold standing there as they did on the walk out onto the lake.

The interesting part of the whole exercise was that from being and feeling quite alone out on the ice, we walked back to camp with a deeper connection from the shared experience of being alone in the universe - together. And I am quite sure that each of them will remember the experience as long as they live.

There is no one prescribed way to build a team, but the common thread in all successful methods is in doing things together. Whether you are leading and developing the youth who will be the leaders of tomorrow, or working with already-grown-ups, the principle is the same.

Teams grow and bond (and sometimes break apart) through challenges and the shared experience of building or accomplishing things - together.

Developing a Team

I was a Scout Leader for almost 11 years. I started as a youth member as a Cub and then continued on through Scouts and Venturers to Rovers, when each of us assisted other groups as adult leaders. My first few years as a leader with the Scout troop were learning years; I made a lot of mistakes and learned from them. The troop was a pretty steady size through the years as youth entered from Cubs and then moved on to Venturers (if they continued with it). We did the camps, skills training, all of that - and it was rewarding to see the kids learning and gaining self-confidence.

Around half-way through my years as a Scout Leader, we gained new kids and their parents as leaders, which is usually how it works. However, that year, we gained an exceptional Leader in one of the parents, who had moved with his kids up from Cubs. The leadership team flourished under his guidance; we felt supported and energized and together we were able to put on an exceptional programme that year. The following year he surprised me. He refused to be the head leader again. He insisted that I should do it - me, the youngest of them all, in my early 20's. All of the other leaders were in their thirties or more, some with other kids older than the scouts. Worst of all, they all supported his endorsement.

What were they thinking?

No Going Back

I was terrified.

What if I screwed up? What if I embarrassed myself in front of the other, much more experienced adults? Would people take me seriously? I suddenly felt a lot younger than 20-something. I felt like a kid. I wasn't ready for this!

However, there was no going back. They would not take "no" for an answer. My sentence was to be carried out, starting the first week of September that year.

Building by Stepping Back

I did not know it yet, but the other Leaders were following the adage "It's better to build a boy than mend a man." I was not a boy any more, though I suddenly felt like one in the face of this challenge. But the principle is one that I have tried to use myself on a regular basis over the years, because it works - and it is the only way that society moves forward.

You need to build up your replacements - the next generation who will take over from you, who will (in theory) in turn help raise up the generation after that.

I made a lot of mistakes that year. Far more than I had made in all the prior years as a leader. Of course any of the other leaders could have done the job, or even stepped in to clean up after me, or even taken back the reins. But they never did, even though a few times in the first few months I secretly wished they would.

The mistakes I made were not really "big" in the scale of things; nobody was ever at risk and the evenings and camps went off fairly smoothly with the leadership team working together. But to me - as my first time as the "Main Leader" (or "Skip"), every mistake seemed big to me, with all eyes watching.

I kept waiting for the shoe to drop. But it never did. The other leaders supported me, coached me, mentored me - but did not embarrass or chastise me. It was an amazing year - I learned an incredible amount, and even more in the years that followed as we worked together. I grew in confidence and ability all the while - and I also wanted to prove them right in putting their faith in me. I still made mistakes here and there in later years - but they always helped me out.

They wouldn't let me be anything other than "Skip" for several years. In time, l left the group when I finally had my own baby at home and time pressures and priorities changed.

It was a humbling first-hand lesson in "Building by Stepping Back" - seeing potential in another person, putting them into a position where they have no choice but to grow and develop - all the while encouraging them, building them up and not letting them quit.

They were, without question, all Exceptional Leaders, for which I am grateful.

Don't Give Up - And Don't Touch the Reins

When you are working with people on your team - youth, adults, it does not matter - you need to have extreme patience as they gain experience. They, as I did, will make mistakes. Probably a lot of them at first, and fewer as time goes on. Most people want to do well, to prove to themselves and others that they can do the task, and be good at it. Few people plan to be screw-ups.

In fact, if someone feels that they are continually a screw-up, it is often not their fault - the fault most likely rests soundly with their leadership. Here are some key ingredients to ensuring that your new team member can flourish in whatever role they are assigned:
  • Give them the full Job Description
  • Give them the Tools
  • Give them time to Learn
  • Encourage Questions
  • Let them make Mistakes
  • Support / Coach them
  • Don't Step In
  • Give them latitude to Grow

Give them the full Job Description
Most people will be frustrated if they are given a task without a good description of what it is they are supposed to do. If you have not clearly told them the goals or objectives, you can't expect them to deliver. Some will quit and move on, others will stay and struggle noisily or slide backward in silence. So tell them clearly what it is you want them to do from the outset.

Give them the Tools
There is nothing more frustrating than being assigned to do something, and then not be given the tools, resources or authority to do so. The "tools" will vary, but whatever it is they need to get the task done, you should provide for them. The trick is if you know at least some of the tools they will need, to have them available at the beginning - and when they recognize what else they need, be willing and able to provide those as well. This might include training, so be prepared to invest the time and expense for them to take it.

Give them time to Learn
Learning something new takes time. The time will vary from person to person based on their skills, aptitude and background - but they will take some time to ramp up before they can start performing well on the task. Of course, they can't take forever to get up to speed; if they are having trouble doing so, it might be a skills gap, or they might not be a good fit. So be reasonable in your expectations - but if they seem to be struggling, make sure they are clear on the description and have the tools available to them before you pounce.

Encourage Questions
"There are no dumb questions" is an approach that will get you better results than persecuting those who seem to ask "dumb" obvious questions. The answers may be obvious to you, but give the team members the benefit of the doubt that their questions are sincere, and they are not just mucking about. If you put down or dismiss the "dumb" questions, this will more than likely cause them to shut down and not ask the next questions - the really important ones that may make a difference to the outcome of your project.
Let them make Mistakes
Let them know that making a mistake is not a punishable offence. (Well, unless it is a reaaally big one, or if they intentionally screw things up, maybe). We all make mistakes as we learn and grow and try new things. But making a lot of small mistakes and learning from them early on can prevent some biggies later on. I know I have learned a lot more from my mistakes than my successes. Learning from your mistakes makes for a stronger team - and if you encourage an open, sharing environment, others in the team can learn from each other's mistakes rather than them all having to make the same mistake on their own schedule. 

If you look to some of the great inventions of history, those often came out of a "mistake" - a side effect of an experiment that did not quite work out, or "happy accidents". So encourage mistakes - it could even lead to the Next Big Idea for your company.

Support / Coach them
This one is important, and is a delicate balancing act for the leader. Early on, you will need to be around more, checking on them for progress and to see if they need anything, any clarifications on the task, tools or resources. Also make yourself available, ad-hoc or scheduled times, whichever works for each team member. However, don't smother them. The art of coaching and mentoring deserves volumes on its own, but let's sum up by saying you will benefit from knowing when you need to be there close by - and when you need to step back. As the team matures and becomes more self-motivating and more self-sustaining, you will often be best to step back further out of the works, but keep track of things and make sure they know you are available when they need you.

It also goes without saying that coaching does not equal chastising; sometimes you might want to yell at the team member for something "really stupid" that they did - but unless it is a very serious concern, try to avoid criticizing as much as you can. It takes months or years to build up a team - and seconds to destroy it. If you do need to correct a team member's behaviour or work approach, look at less confrontational ways to go about it, and start with something positive.

Don't Step In
It is very tempting to step in and "help" the team member do something they have not quite gotten the hang of yet - especially if you used to do it yourself. Resist the temptation. Let them try and work it out themselves - and if they ask for help, give them specific help and then step back. No baby ever learned to walk by having their parents do it for them.

Give them latitude to Grow
Odds are, the team member is going to approach the task in a different way than you would. Unless it would negatively affect the work result, it is usually best to let them figure out a method that works for them. They might hit a wall and have to go back to the way that it is normally accepted to do the task - but sometimes their fresh approach with new eyes will reveal a much better way of doing things. So don't stifle creativity unnecessarily - unless it does seem to be putting the deliverable at risk.  (Some people just like to figure out new ways to do things just because they can).

Note: In some countries, if you hire a contractor to do a job and then you proceed to tell them in detail HOW to do the job, you can be sued for Breach of Contract. The reason being is that you hired them, as an expert, to do a specific job. How they do it is up to them - as long as they produce the result (within safety and legal limits and regulations as applicable). They are the expert in doing that task, after all.

Not exactly the same situation when you are dealing with a team member, but you get the idea.

If you support your team members, provide them the tools and give them clear direction - they will often out-perform your expectations. They may even go on to become a High-Performing team.

If your team can accomplish that, it's a sign of good leadership. The credit does not all belong to you though - yes, the team achieved that level with your guidance. However you could just have easily prevented them from accomplishing what they had by making poor leadership decisions. So don't get cocky! There are no guarantees on what will happen with the next team.

Your High-Performing Team Gets Stale

Eventually, after your team has been working together for some time, you may reach a very high-performing level (Not all teams do). When you do, you will be able to accomplish some pretty amazing things - and the team could be a key differentiator for your company in the market.

But there is a risk with High-Performing Teams. If they are not presented with new challenges to work on, they could get stale if they are a long-standing team. If the tasks become repetitive, your team will lose interest, and lose their edge. Eventually, the team will dissolve as one after another they move on to new challenges.

This might be an inevitability - you might have a team that reached a high performing level during the project, but then the need for the team is removed. You can't keep them together on this project, so you have two choices:

  • Try to get them involved in the next project together, where they will have a big head start on working together effectively, or
  • Seed them throughout the organization. When you have people that have been part of a high-performing team, they will want to try to replicate what worked for them in their next team. You might end up with multiple new High-Performing teams as a result. Not all of them will pan out, but if you are able to expose more people to what it is like to be part of a High-Performing team, you have a better chance of spreading it to the reaches of your organization - and that may truly differentiate you in your market segment.


A quite different Troop walked back to camp from the center of the lake. Much more subdued and contemplative than the noisy bunch of kids that were chatting away as we walked out onto the ice earlier in the evening. In some small way they had changed that night - matured, or at least become more aware of the world around them. A small step towards leadership - you cannot lead others by only looking at yourself. Unfortunately, all too many of the activities that our children participate in these days are the exact opposite - self-absorbing video games, texting, online chats and social media that insulate them from direct personal contact with others. There is no substitute for the real thing - human interaction and learning to observe others. I look around me sometimes and wonder where the next generation of leaders will come from - and how they will manage.

That was my last year as Skip with the Scout Troop, and the last year working on a regular basis with that particular leadership team. A wonderful shared experience through all of those years - both working with the leadership team and the support they provided, and witnessing the accomplishments of the youth in the Troop as they outperformed our expectations within their smaller Patrol teams. Anyone who has low expectations of the capabilities and skills of a 10-13 year old never met any of our Scouts.

Note: The igloo was a real one - someone had carved the blocks out of the firm snow earlier in the day. We all took turns going inside it - and it definitely was warmer inside than out. The whole camping weekend was a great experience - and it stayed cold enough so that we did not have a problem with thawing and slushy snow. Nothing worse than trying to dry your gear outside when the temperature is around 0C/32F. Wet gear is not only inconvenient, but dangerous in those temperatures and below.

Good luck with your projects, and my advice today is not "Go jump in a lake" but "Go for a long walk on a lake" - just make sure it is winter, and check the ice thickness before you go.

Sunday, August 26, 2012

Teams, People and Change: You Can't Push a String

[Also available as a podcast]

When I was younger and preparing to go to University, I received some strange but sage advice. I was told that if you wanted to go into Engineering, the two main things you needed to remember was "E=MC squared, and You can't push a string".

Image licensed from  

Then a lateral thinker I know said "if you wet it and freeze it, you can push the string". Needless to say, he went on into Engineering on a path that eventually led to Project Management, while I completed a degree in Computing and came into Project Management from a slightly different direction. 

Of course, the person who provided the sage advice was merely describing the physical limitations of the string and its behavior when force was applied "in the wrong direction". As we  all know, it is much more effective to pull a string in order to move whatever it is attached to.

Unless, apparently, you wet it and freeze it.

Then it would be definitely easier to push it. It might even be harder to pull it, with it being all wet, cold and slippery. You probably would need gloves or some pliers to grab it so you could pull it.

It has been many years since I was told that message, but often the strange or different sticks with you. This advice came back to me most recently when I was contemplating a new project, and refreshing my thoughts about team development, and preparing for change within organizations.

In fact, it is a perfect description of what is NOT part of a successful approach to building a team or managing change. (The string part, not the E-MC squared part. And real string, not any quantum mechanical string theory stuff).

Because when it comes right down to the bare bones of it, People are like strings. Pushing them is rarely effective - but ah, if you can lead them (and pull them along in the same direction), there is no limit to what can be accomplished.

String Theory

Yes, you are a string.  Complex, multi-threaded, multi-faceted, different from everyone else in subtle or not-so-subtle ways, but yes - a string. And not the quantum mechanical variety, though apparently if they are right we are all made up of a lot of those too, billions, trillions of them, who's counting?

But where it counts, people behave an awful lot like string in certain situations.

Don't Push That String

If you push a string, what does it do? It collapses into a muddle of overlapping loops - and whatever it was attached to has not budged an inch. Of course, if you keep pushing until the string is all wadded up against the object, you can push against the object with the mashed-up string, but that is not really the point, is it? If that was all you wanted to do you did not need the string in the first place.

If the string is near a corner or another obstruction, there is a tendency for the string to collapse back into a corner and pile up there. It is also likely to form a knot, making it more difficult to sort out once you stop pushing and go in the "right" direction.

String was not designed to be pushed - and neither are people. And when you push people, they tend to behave like string - they slide to the side, push back into a corner, and generally go in any other direction than the one you are pushing. (Incidentally, this is why I don't like backing up with a trailer). And just like the string, you don't get a very satisfactory result from all of your pushing.

Don't believe me? Just try to push a Teenager into doing something they don't want to do.

So how do we get an object, a person, a team, or an entire organization moving with you in the desired direction, and even working together?

We pull.


You are right in thinking that you will be more effective in pulling than in pushing the string, but there are a number of other things to consider.
  • How much resistance is there?
  • How big is the object we need to move? 
  • How much effort do you need to pull?
  • Where do we want it to go? In what direction? 
  • Do we pull straight ahead, or start at a bit of an angle? 
  • Is it on wheels, skids, or what?
And in our case - it is a person who is attached to the string - maybe the "string" could be their tie, or a string wrapped around their waist. Or perhaps it is tied to a wagon, sled, or pallet. But be nice on where and how you fasten than string, it will likely be your turn to be pulled for something else later on.

Ok, so you are all hitched up, and raring to go. But first let's check on one more thing:
  • Are they ready to be pulled?
There is a psychiatrist version of the light bulb joke that goes like this: "How many psychiatrists does it take to change a light bulb?" Answer: "Only one, but it has to really want to change."

It's an old joke, but it does help us out in looking at our problem - of trying to get a person (or object) moving in the direction we want them to. They have to be open to the idea of change, and moving - or at the very least, not anchored firmly in place. The worst case would be if they were actively pulling against us, going the opposite direction. And you also have to remember that you are usually trying to get more than one person moving in your direction and working together - in other words, you almost always start out the process outnumbered.


Ok, so you are gung-ho, convinced of the need for everyone to go in a new direction, certain everyone will come along easily with you, because you have a great idea, right? So you pull. Perhaps gently at first, then a bit harder, but nothing is happening. So you pull even harder. Still nothing. So you get impatient, and you jerk the the string quick and hard - surely that will get them moving!

And then - snap! - you have broken the string and you land on your rear end with a surprised look on your face. What happened?

You just exceeded the tensile strength of the string in one impulsive action. Actually it is interesting to note that in physics, impulse is the name of a calculation that combines force with the time interval it is applied over. When force is applied to an object (and the object moves), the momentum of the object changes. If you apply a smaller force for a long period of time, the momentum of the object will eventually reach (X). If, however you apply a stronger force over a short period (like jerking on the string), the momentum of the object will reach (X) more quickly, unless of course you break the string with the effort.The second action has a higher impulse value.

If a string is designed to withstand a steady pulling force of, say, 100 pounds (448 Newtons), you can pull with almost 100 pounds of force applied in a slow and steady motion for an extended period of time. However if you suddenly applied a minute's worth of pulling into one swift motion, the impulsive force applied to the string will vastly exceed the 100 pound threshold limit of allowable steady force, snapping the string.

The same thing happens in reverse with whiplash in car accidents, when the momentum swiftly changes from (X) to zero. If you gradually slow to a stop from 60 mph/100kph over 4-5 seconds, your body slows gradually with the car, and you come to a comfortable stop at the traffic light. If, however, the same net braking force that was needed to stop the vehicle was applied in 1/10 of a second, i.e. during a crash, the vehicle and its contents (including you) undergo extreme impulsive force. And if you survive, you will have a nasty case of whiplash and sore or injured neck.

Ok, so I didn't do the whole Engineering bit. I did enjoy Physics though.

So there you are, flat on your rear with a broken string, and not a little bit embarrassed. Actually most likely a lot embarrassed, with the whole crowd you are trying to pull watching you. A stellar beginning.

Time to regroup and change tactics.

Reduce the Friction

Ok, so we have to take it slow and steady. But the last time we tried, they did not budge an inch. So what do we do? We can get a thicker string, but we can only pull so hard, being just one person.

When you are trying to move a heavy object, there are two main ways to increase the chances of making it move.
  • Increase the force applied
  • Reduce the friction
We already know we are currently limited on the first part - so what can we do to reduce the friction? If it was a large block, you could try pulling it over logs, put it on wheels, or put a lubricant, like water, graphite powder or oil on the surface underneath and in front of it, depending on the material the surface and the object are made from.

But that is assuming the object is just sitting there - what if it is something with roots, like a tree, or an object embedded in the ground? If this is the case, there will need to be some excavating going on, or at least some loosening of the soil around the base. 

We had a very wet winter here, and the ground was quite soggy. We wanted to transplant a couple of small bushes to another spot in the yard, but when we went to dig them up the ground was so soft and muddy, we merely had to pull them out by hand. Ok, probably not a good practice and any gardeners out there are probably shaking their heads - but so far, the bushes are doing ok. 

[Oct 7, 2012 Update: The bushes both died. Maybe they were too big to be transplanted, or they took extreme offense at being uprooted like that. So use a shovel and be careful to keep more roots!]

I am not saying you need to yank anyone out by the roots, just that it is easier to move something that is rooted or stuck in the ground when the ground has been prepared (loosened up) before you start pulling. This is just another form of reducing friction.

When we are dealing with people in a team, or a group of users/stakeholders in the context of a change management plan, we need to look at the current state of affairs - who is entrenched, who is open at least a little bit to the change you want to make. You then need to think about what will help loosen them up and be more open to the idea of change. Even better, if you can identify a few people who support you among their peers (advocates), they can help convince the others to give it a try. The advocates can also help to reduce friction between the project team and those you are trying to move/change, by spreading a positive message. Because in all likelihood, the advocates are trusted by their peers, but the masses may not trust you - yet.

So, with things loosened up a bit and friction gradually reducing, you can again start to pull. It will be slow at first, but you at least have them moving.


And suddenly, you stop. Even worse, the string is pulling you backward. Somebody is playing tug-of-war, and you are outnumbered. You are not on your rear because you bought a stronger string - but you are now moving in the wrong direction.

You need more people at your end of the string, and to possibly bring their own strings. You need the advocates to help pull with you, all the while working to reduce friction and pass along the positive message. If there are only a few people pulling against you, you will still be able to make progress once the advocates are helping you pull. Of course, ideally you will want those digging in or pulling against you to see reason and just "get with the program", but as we well know, often that simply does not happen - and you will have lingering resistance, even when most of the people have accepted the change.

So, you pull together, you and your advocates - and, here and there, others come to the front to join you. And the great thing about that is if they are pulling with you, they are not being dragged, so it is suddenly just that bit easier to pull because you gained a puller, but you also removed a resistor (source of friction), so it is a 2-for-1 bonus.

Pulling your Wagon down the Hill

When my oldest son was only 2 years old, we bought an old Radio Flyer metal wagon at a garage sale. The wheels were plastic and brittle, but the rest of the wagon was still solid - rusty in spots, but I stripped it back to bare metal and painted it up shiny red, with black for the handle and axles (of course). But I replaced the worn out plastic wheels with four good quality steel and rubber wheelbarrow wheels, with exposed ball bearings. I bought a tube of lithium grease and thoroughly lubed the bearings. When it was all finished, we had to chock the wheels because the slightest slope caused it to roll. Today, three kids and many years later, the wagon is still going strong - and although a bit dented from lots of use, it still rolls fairly smoothly.

If you are successful in your efforts to bring people along with you (i.e. leading them), you will reach a point where it no longer feels like you are dragging a heavy block. It will feel like you are pulling a wagon - much easier, with greased wheels and less friction. Which is good, because a lot of your journey has been an uphill climb. But soon enough, the crest of the hill will be in sight, and you will have a significant number of people helping you pull it to the top before jumping back on the wagon for the rest of the ride.

And then - you are over the crest, and what happens next? Do you remember trying to pull your wagon downhill as a child? Once it gets moving, there is a point where you cannot run fast enough and you have to make a choice.
  • Let go and let the wagon race on ahead, and probably crash.
  • Jump onto the wagon, grab the handle and steer to a triumphant finish.
 But you are the Project Manager, so really there is only one choice. Watch for the right moment, and then jump on and grab that handle. Steer that wagon, with all of the team riding with you and cheering you on, all the way to the finish line. Just watch for that bump on the left.


Project String Theory applies not only to organizational change, but to building teams as well.The expected results will be a bit different, of course.  But the mechanics are quite similar.

When you are building a team, trust is paramount, and you won't get very far by pushing. But if you can be an effective leader and work with your team, set the vision and goals and have the team buy into them, you won't be pulling them for very long - they will be blazing the trail in the direction you have set, with you bringing up the rear. They might even call you a slowpoke.

Good luck with your projects, and watch out for knots in your string. If you get any, you probably just forgot the lesson for a moment and did a push instead of a pull.

Wednesday, August 8, 2012

Built to Last: Forget Waterfall, Forget Agile - Let's Talk Tectonic Project Methodologies

[Also available as a podcast]

Have you ever managed a really big project? I am certain that many of you have managed some very large projects. But how big is that, exactly? As big as the pyramids? Well, maybe some of you have. But there are some projects that make even those pale in comparison.

As a matter of fact, I am currently sitting in the middle of one of the world's largest Projects. No, it was not my project - not by a long shot. We don't actually have the email or mobile number for the project manager responsible - but you can clearly see the results.

I am sitting here typing away in Hamilton - roughly in the middle of the North Island of New Zealand.

No, Hamilton is bigger than a pyramid, but it is not the project either. It is a nice place to live, and a medium sized city for New Zealand - actually the largest inland city as the main ones are along one coast or another.

The project of which I am speaking is the whole of the North Island itself. The island is 113,729 square kilometres (43,911 sq mi) in area, making it the world's 14th-largest island.

Ok, ok, you say - what's the point, and how is this a project?

I suggest this is a project because it is almost entirely volcanic in origin. Just like Hawaii or any of the smaller pacific islands - but on a much, much larger scale - both geographically and the project timeline.

I guess we should really call it a Program, because it is so large. Ok then, it's a very large program - with each of the volcanoes an individual project. 27 major volcanoes in the Taupo Volcanic zone itself, with another 15 or so scattered in the North Island - well, much more than that because the Auckland Volcanic Field features more than 60 cones. After a while, you lose count of the smaller volcanoes.

Then there is the South Island - a very different kind of project and island.

So - let's translate this to Project Management terms - and build ourselves an island or two.

Making an Island

Why the sudden interest in geology? August 6, 2012, 23:50 - Mt Tongariro erupted for the first time since 1897. Mt Tongariro is a large volcano just to the south of Lake Taupo. It has several nearby sister volcanoes, Mt Ngarahoe, which last erupted in 1977 and is technically a vent on Mt Tongariro, and Mt Ruapehu, an impressive volcano with several major ski fields which last erupted in 1995-1996. And of course, Lake Taupo itself (616 square km / 238 square miles) is in the crater of New Zealand's largest volcano.

Mt Ruapehu and Ngarahoe (right), Taupo Volcanic Zone

Growing an island by volcano is a much different activity than slamming tectonic plates together and uplifting a new mountain range - a process called thrust faulting, where the shock wave of the plate collision forces huge masses of rock to crack and slide up over its neighbour. This is how the South Island, the Rockies and all major mountain ranges formed.

The other way - one might even say a more elegant way - to grow an island is slowly, progressively, from the bottom up like the North Island. Layer upon layer, the volcanic cones rise from magma vents in the ocean floor until they break through the surface of the water - a noisy birth with lots of steam and splashing. Most of the Pacific Islands formed this way, and the peak is just the tip of a very tall volcanic cone rising from the sea floor. Some quit shortly after they broke through the water - forming a lot of the smaller islands, while others continued to grow and form mountains and valleys in between.

Comparing Tectonic Project Methodologies

Ok, so we have two main methods to choose from to build your island and raise it up above the waterline, or increase its height. 
  1. Thrust Fault (convergent plate movement)
  2. Volcanic (convergent or divergent plate movement)
Both processes occur due to changes at plate boundaries, and you may even have volcanic activity around the edges of a thrust fault, depending on any weak points (hot spots) created along the underlying plate.

But enough geology - how does this apply to projects? Both have the same eventual goal - to create an island where once there was water. Let's look at the differences in approach - and the lessons we can learn when applied to our projects.

Thrust Fault Projects

Some projects have a lot of things thrust together by force to produce a project outcome - often with major clashes and collisions between stakeholders and the project team as well. And although the results can be breathtaking when you look at it later, it is certainly disruptive while the building-up part is going on. Car wrecks are sudden, spectacular and breathtaking too - just not very healthy for the stakeholders.

The main feature about this methodology is the use of sudden change to complete the project after a long quiet buildup. With little or no warning, there is a flurry of activity,  a lot of energy expended, and suddenly it is over and things will never be the same again.

One of the problems with this approach from a people perspective is that sudden, unexpected change tends to cause resentment and feelings of loss to those affected. This may be the users of the old system, or a person whose house was flattened by the Richter 9.5 triggered by the nearby hill's ambition to suddenly become a mountain. In both cases, you have ripped out the foundations from underneath people with no warning or preparation - in other words, there was no Change Management Plan. Put simply, there was not a lot of communication about what was coming, period.

One minute, you and all your fishy buddies are swimming away close to the shoreline, and then - BAM!- you are high and dry and upwardly mobile. No change management plan for you - learn to walk and breathe air, or die. Not everyone survives this type of project. 

In real life, an event like this results in a major earthquake - and it is usually not the last. There is almost always an adjustment period, as things settle into place - accompanied by a rash of smaller earthquakes over time. Expect the same things on your Thrust Fault projects - when you suddenly change or impose things on your users, there will be a lot of adjusting, support and probably apologizing to do before they settle in to the new way of things. 

Project Change Requests in this type of project are rarely uneventful.

And like the vertical adjustment to Mt Cook a couple years back, where a huge chunk of rock slid off the peak down into the valley, not everyone will want to stay on after the thrust fault event, but they might not leave right away. Just don't be surprised when they do leave.

Of course, not all Thrust-Fault projects are bad news. If you are launching a new product or a rocket to the stars, you will necessarily have your major event at the end. There will be a lot riding on the outcome, and a lot of internal activity leading up to it - but it is not as visible as the actual public launch.

Volcanic Projects

Volcanoes get a bad rap. Compared to the energies and destruction caused by raising a thrust-fault mountain range, volcanoes are positively gentle. When they are first forming, you have plenty of warning that they are coming - gas venting, steam, warming of the water. Once they clear the water, they even provide you with night-lights to stay clear as the red-hot magma flows down the mountain side. If it thinks you are getting to close for your own safety, it may blow off some steam or ash. They are playful too - they may toss you a few pyroclastic boulders. (I don't recommend you do the "catching" part though). Sometimes you even get a free fireworks display.

 Sure, they can cause destruction  and changes to the terrain, but aside from ash clouds there are limited effects far from the volcano. Lava flows downhill, boulders can only be tossed so far. I am not downplaying ash clouds though - they can be very disruptive to the areas coated with ash - nearby and far afield, and they are a threat to aircraft. However this is a matter of perspective. None of us have seen a mountain range suddenly thrust out out of the earth beneath you. Volcanic eruptions are much more common in comparison. It is unlikely you would survive a mountain-building thrust fault event near you - you have a much higher chance of survival being near a volcano, as bad as it may seem.

The main feature about this methodology that makes it preferable on most projects is that while you are building your volcano, it is a gradual process. You have plenty of time to communicate with those affected and utilize a Change Management Plan as you build up towards the project goals, layer by layer. Sure, there will be some excitement and fireworks, but most of the growth in your project will be like the layering of magma as the volcano grows taller. While magma is flowing, the Volcano is actually relatively happy - there is a steady release of pressure without excessive build-ups. It is only when you run into obstacles and blockages that you have a danger of outbursts or violent eruptions. But again - you have the element of time. It takes many years to grow a volcano, so even though there seems to be bursts of short-term activity, the overall progress is relatively steady.

The one trick with volcanoes, of course, is the Project Change Requests. With a Thrust Fault project, you know to expect a flurry of these after the main event, and then things will tail off. With the Volcanic Project, things may seem to be quiet for a long period and then you may have an unexpected eruption of post-build activity.

Not a problem, really - unless you decided to build your house on the side of the volcano because of the nice view.


So what kind of project are you on? Thrust-Fault or Volcano? The needs of your project will generally dictate which approach is best.
  • If your project outcome is necessarily a sudden cut-over or launch type event, you might need to use Thrust-Fault. (Just do as much as you can on the communication side of things)
  • If your project outcome affects a lot of people, it is usually best to use the Volcano approach when you can - build up slowly, and employ your Change Management Plan liberally.

The key is to keep an eye on how your project is turning out - if you planned for a Volcano, watch that you don't end up with a Thrust-Fault because you stopped communicating. It makes for a strangely shaped deliverable.

Good luck with your projects, and if you get a chance, come on "down under" to visit New Zealand. You will see an amazing variety of geology and scenery if you do!