Showing posts with label management. Show all posts
Showing posts with label management. Show all posts

Thursday, August 28, 2008

Should You Manage People or the Environment?


Fish do not notice the water in which they swim.

Every company has a culture. There are myths and stories that are told which reflect the company culture. Its hard to define, its difficult to see and it affects every decision, project and action a company takes.

Is it easier for a fish to swim with the current or against it? Does the pounding rain, rocking waves and conflicting currents lead to curious and creative fish or small, protectionist and defensive fish?

Should you try and manage the fish or will you do better managing the environment?


Photo Credit: Olive Eyel

Wednesday, August 27, 2008

Aligning People or Letting them Align Part IV

Bill Miller and I have been talking about whether it is better to align people or let them align. You can read the other three parts here, here and here. Its been a great discussion, to make it clearer, I'd like to reframe my response. I always hate it when girlfriends do this to me, so I'm apologizing up front. [Editor: No need to apologize, I've been suggesting girls do that to you for years and it's benefited me tremendously.]

A little background on business
To get some insight to this, let's think about why businesses were really founded. The modern corporation came into being in Britain in the early seventeenth century, when some very intelligent and presumably humble nobleman noticed that there’s no correlation between intelligence and wealth. In fact, there may even be an inverse correlation, but I’ll resist the urge to rant about Paris Hilton and spare you my other Hilton-esque urges. [Editor: Please do.]

What these noblemen realized was that if they gave up a portion of their capital and entrusted it to an organized group of intelligent, motivated and hungry workers selected from the masses, they could make themselves much wealthier. A side benefit to this was the incredible improvement in the standard of living for those working for them. This is the genesis of the modern corporation.

Why is this important? What these noblemen and now women realized was that they had to set up the appropriate structures so the intelligent, motivated and hungry workers had proper direction and incentives to make the business successful and them wealthier.

Project Structures
Should teams self-organize? Absolutely. As a project goes along, the team needs the freedom to realign itself to meet the demands of the project. What an effective manager does is define the structures within which to project will operate to deliver what the business needs. If the project team has the correct direction and incentives, they will align themselves and the project has a better chance of success.

Does this make sense?

Photo Credit: Eric Lafforgue

Saturday, August 23, 2008

Aligning People or Letting them Align Part III

Bill Miller, confound him, asked an excellent question. Normally I avoid people asking excellent questions, but as he paid me the compliment of commenting on what I wrote, [Editor: and I made sound intelligent] I felt obligated to respond. And it is an excellent question.

What is the essence of self organization as opposed to their being organized?
The crucial question is responsibility. If a group organizes itself, the group is responsible for the outcome. If someone else organizes the group, the organizer is responsible the outcome.

If ten kids get together to play basketball, then they choose teams, call plays and evaluate the results. If a coach organizes a team, schedules the practices and calls the plays, then the coach is responsible.

Accepting Responsibility Versus Diffusing It
If three people get together and start a company to implement a new idea for running projects, they are responsible for developing the products, the methodologies and finding the customers. If their products and services work, customers continue working with them and the company grows. If their approach doesn't work, the company goes out of business. Those three people and the others who join them are responsible. (This is how CAP was born)

If a company decides that it wants to implement a new program, it picks three people and tells them to implement it. The first thing those people do (if their smart) is ask for more money, more people and more time. In this situation, it is in the three peoples' best interest to make the program as large, as expensive and as time consuming as possible. If they are smart, they diffuse responsibility, but accept credit.

What Advantage do Entrepreneurs Have?
An entrepreneur and the people starting a company take responsibility for making it succeed. People taking a job are responsible to do what someone else organized for them to do.

Are both important? Absolutely.
Which one is likely to effectively produce defined products and services?
Which one is likely to produce innovative products and services?
Which one are you looking for?

Friday, August 22, 2008

Does Technology Create Transparency or Mirages?

Many companies implement huge IT packages to get better visibility into what's happening and to (presumably) get more control, but this begs the question, does technology give you better transparency? Theoretically, it should and even could. Practically, technology may create mirages more effectively than a desert.

Why Does Technology Create Mirages?
Transparency comes from corporate strategies that value transparency. Technology effectively supports that approach if it exists or it obfuscates if one is not careful. If the departments and groups implementing the technology want people to know what they are doing, then you'll get a lot of transparency. If the departments and groups do not think it is in their best interest to have people know what they are doing, technology will not help; in fact, it will probably show you a corporate mirage. [Editor: Sort of like I help you look intelligent.]

Just like in the picture above, the peaceful and attractive house with bushes around it reflected in the lake is a mirage, sophisticated managers can manipulate technology to show whatever it most benefits them to present. Technology is not a magical elixir.

How can Technology Provide Transparency and Control?
If there is:
  • Clear thinking about the business objectives
  • Products and services that customers value
  • Business models that support the required infrastructure to deliver those products and services and create reasonable profit margins
  • Appropriate incentives to motivate employees to deliver those products and services
If those things exist, there will be transparency and control will not be a problem. Technology enhances the processes and systems a business uses to do its work. So, will adding technology enhance your transparency or create corporate mirages?

Photo Credit: mbz

Wednesday, August 20, 2008

Aligning People or Letting them Align Part II

Bill Miller made an interesting suggestion about self organizing teams. As kids playing baseball, the first decision was often who would be the two team captains. Those captains then picked the teams. Sometimes they were the two best players or more often the two players most able to help their team win. As kids, we knew what was important to win.

An interesting circle of dependencies. The kids picked the captains and the captains picked the teams. Almost an implicit contract. The group gave the captain the right to organize the team, but if the team didn't win, but they had to win to be captain in the future.

Captains changed. Sometimes one person was a captain for one sport, but not for another. Sometimes frustration over past performances lead to minor mutinies. [Editor: That will be fine, thank you.] Sometimes new leaders emerged as time went on. What's important is that the process was self regulating. If the captain helped the team win, they continued as captain.

Can Business be Self Regulating?
There are obviously differences between ten year olds playing baseball and business, though I suspect there are not as many as one might hope. How different would it be if the workers picked the manager? If the people working on a project were responsible for identifying the person most likely to make the project succeed, who would they pick? And why?

Often times in business executives picks a manager or team lead and then charge that person with assembling a team. What if the team were selected first and that teams first responsibility was to pick the team lead?

Have you heard of people taking this approach? How did it work out?

Saturday, July 26, 2008

Response to "Freedom is Overrated"

Professor Andrew McAfee has an interesting blog entry Freedom is Overrated in his Harvard Business School blog. In it, he discusses Facebook and Twitter and asks about their uses as business tools. In response to his question, I made several comments from my personal experience . I have found that social networks are used on the fringes of business, not in core businesses. I'll offer an example of the first, reasons for the second and insight into what I think will happen with them.

Use in the Fringes of Business
Please note that my saying "Fringes" is not pejorative, but rather it refers to the outer edges of the network, which is where the really interesting things happen.

One of the great things about FB (Facebook) is that it allows people to create verifiable and yet pseudonymous users. Furthermore, it allows you to create private groups, where only people who are known and invited can participate. Might there not be groups who want to securely blog and discuss events who would find FB useful?

Core Businesses Concerned about Social Tools
Many executives and managers in core businesses are rightfully concerned about the time wasting that accompanies FB and other social tools. There is also a security threat, which is very real. Additionally, there is the bigger issue, that there isn't a clearly defined business problem that social tools solve. Finally, there is the hurdle that many in IT view social networks, SaaS, etc as a threat. This is a valid concern, which, coupled with other issues, will probably keep social tools out of core business applications.

There are business leaders struggling to get blogging and other social/collaborative tools used in corporations. Their struggles are interesting to consider and offer interesting insights that the creators of social tools are not paying as much attention to as they should.

What I Believe will Happen
I do believe these tools will be used, but not in their social sense. They will be used as compliments to other processes (project management, corporate communications etc.) in modified forms. There are people whom I greatly admire who are trying to do this. They are the pioneers developing new, more efficient methods of solving business problems. I look forward to hearing about their successes and insights.

Wednesday, July 23, 2008

Why Change is so Difficult

Peter Vajda has an excellent post on Why People Resist Change. While I have a lot of respect for Peter, I think his argument misses some important facts. Namely the fact that people resist change because they can't see how it benefits them. In fact, often times the changes will hurt them. In those situations, no amount of involving them in the decision making process is going to persuade them to execute the decision.

Very briefly, Peter's thesis is that people resist change because they are not involved in the decision to change. While his arguments are compelling, they don't address the core reason why people resist change.

Why People Resist Change
When someone is trying to change a structure or process, by definition there is a structure and process which already exists. It's a good bet that someone put it in place because it benefits them, intentionally or accidental. In either case, they are probably the key power brokers necessary to make the new processes work. The new processes are often more efficient because they get rid of the loopholes that the power brokers currently exploit.

Everyone will often agree that the new structures and processes benefit the company as a whole. However, it's a good bet that they will not benefit the people who are benefiting today. And its a better bet, that even if those people agree in principle, when it comes to executing them, they will resist. They may resist passively or subversively, but they will resist. And it's good bet that they'll be smart enough to do it quietly.

Think of it this way. If your mother suggested changing from eating spinach to eating cake, it's quite likely that you'd implement that change easily. However, if she suggested changing your desert from cake to spinach, no matter how much healthier the diet would be, you're likely to resist. Do you really think being involved in the decision making process would change your outlook?

Monday, July 21, 2008

Are Project Managers Marooned on an Island?

Projects often pull people from different departments together to work on a project. While that is what the project requires to be successful, what does that mean for the people pulled from the different departments? Is the project of primary importance to them or is what's happening in their department of primary importance?

Business in Silos
When the modern corporation was formed, different departments were organized around specific functions. Accounting, Marketing, Sales, Finance, Operations and even IT all had separate requirements, required different skills and had different, recognizable paths for promotion. These departments offered structure, communications channels and common ground which was the basis for understanding.

Project management for larger projects, doesn't fit in any of those silos [Editor: we prefer the word department, thank you.] For a large project, people are drawn from across the organization, often temporarily, to work on that one project. Where is the common ground or structure?

Is PM unique?
PM often is unique, especially in organizations that are not focused around doing projects. Not only must the team get from NY to LA, but often times they have to invent the car, build the roads and put in the gas stations.

Not only does the team have to get from NY to LA, they have to go through the four stages of team development (Forming – Storming – Norming – Performing), usually very quickly.

What happens after the project?
All of this is very interesting, the question of whether project managers are on an island, but for someone with promotion aspirations, what is the next step after being a PM?

What have you seen?

Saturday, July 19, 2008

Does PMI (Project Management Institute) find value in Project Management?

On July 15, PMI presented the finding of their four year, $3M study looking to see if project management added value. You can see their presentation here: PMI Presentation

Their results reminded me of Churchill's quote about democracy:

Democracy is the worst form of government except all those other forms that have been tried. — Winston Churchill

PM is messy, imperfect and immature, but what are the alternatives? I give Dr. Janice Thomas and Mr Mark Mullaly credit for presenting as objective of a report as they could. PMI gave them a lot of money to say that PM adds value. Reality is messy and that is really what their study found.

Consider that they looked at 65 companies in different industries, countries and organization structures. They looked at private, public, government and sole proprietorships. What insights do government findings offer to sole proprietorships? Equally, PM in office construction bears little resemblance to PM in software development. They also found that culture and context in China bear much resemblance to that in the US. All of these affect outcomes.

To me, what they did was the equivalent of asking 65 different groups of people who grow vegetables to comment on the value of water and fertilizer. I'm not sure what conclusions you could draw looking at my mother's tomato plants in Wisconsin, hog farms in Canada or government farming cooperatives in China.

I'll save researchers $3M and emphatically state that the empirical evidence shows that fertilizer is valuable.

That's pretty much what I think PMI found. Any thoughts?

Saturday, July 12, 2008

Personal Project Planning

Have you ever interviewed someone for a project management position and heard them rattle on how great they think PM is? How it makes everything better? Everything more organized?

Here's a question to ask them. If they're married, did they put together a project plan and schedule for their wedding? If their single, dating works just as well, but the wedding a beautiful example.

If people are so enthusiastic about PM, why don't they use it in their private lives? A wedding would be the perfect situation. There are a large number of people, many things to be taken care of, a deadline, dependencies etc. Custom made for project planning.

Except, I've never had a single person who did it. If it's good for work, why don't people use it personally? If they don't use PM personally, how committed to it can they be at work?

Things that make you go, hummmmm

Wednesday, July 9, 2008

Celebrating Victories on Projects

Be faithful in small things because it is in them that your strength lies. - Mother Teresa

Projects, deliverables, tasks and success are made up of little things. If people working on projects are going to care about little things, the people running projects better care about the little things. Many of them are too small to mention outside the team. That's fine. In fact, that's great. All success will begin with the team. Whether a project is just kicking off, maturing after the novelty has worn off or is stuck in the tar pits, as a project manager, you strength lays in the little things.

Recognize people for accomplishing them. Celebrate them. It doesn't have to be huge, but acknowledging the little victories will go along way.

Maybe there is some piece of data which the team needed to get access to, some GUI which needs to be built, some interface completed etc. They may be tasks, sub-tasks or just important work elements. The important thing is that there needs to be realization and celebration of progress that is being made. To keep morale up, people must see that progress is being made and that there is an end in sight, whether its success or the project being ended.

There are many ways to do this, email, blogs, discussions, team meetings are all good. There is one other way that I found very successful. Marking a bottle was also very useful.

Marking a bottle really works if everyone is in the same office. The way we did it, was to use a bottle of reasonably sweat liquor (Bacardi Limon was our choice). Whenever there was some success, we noted that success on a post-it note, put the initials of everyone involved and present and then poured each of them a shot. The post it note was then taped to the bottle so that the bottle was marketed with successes as the project went along. Similar things could be done with notes and pictures on a wall or web-page. At the point of the project we were on, we needed alcohol. Hopefully you don’t reach that same point.

When the project is in the tar pits or at any other time, remember and take advantage of the steps that are available to you.

  1. Identify how the project can be killed if necessary and admit that it is possible.
  2. Refine the scope so that nice to haves are on a “Not right now” list and critical items are the main focus.
  3. Make sure the communication channels between the project sponsor and PM and clear, with the team and with the organization are known.
  4. Celebrate victories that move the team forward.

Sunday, July 6, 2008

How to React When Things Start Going Bad on a Project

Machiavelli: “As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after a time, unless it has been diagnosed and treated at the outset, it becomes easy to diagnose but difficult to cure.”

Diagnosing problems early is the goal. If you can and apply corrective measures, issues are resolved or effectively managed. How do you identify risks? Other than that dull sinking feeling in your gut. Use your judgment and communications skills.

Ideally you have risk registers or have at least done enough risk analysis to be open to recognizing risks or when something is different. Lacking the formal elements isn’t a problem if the structures that identify risks (known or unknown) make it much easier to know when an issue starts and if it has the potential to pull the project into the tar pits.

Knowing that something is becoming an issue is the first step. Next find the root cause. This is critical because you want to address the root cause, not the symptom. How do you find the root cause?

Try thinking about it as similar to clicking down into hyper links in a web page. Rather than just talking like you're just reading along on a page, which is how most conversations go, click down to discover the deeper meanings.

Let me explain what I mean. Most conversations take place at the surface level. “Hi, how are you? Wasn’t the weather great over the weekend? Who do you think is going to win the game on Sunday? Did you get the report? etc. etc. etc.”

This conversation takes place entirely at the surface level. People talk without clicking down to the deeper level to look for meaning. To do so, think about asking reflective questions as a way to click down to the root cause. Reflective questions take the key idea from a statement and reflect it back as a question looking for more information about that area.

For example:

  • Developer: “We have a problem on the deliverable.”
  • Project Manager: “What is the problem?”
  • Dev: “The interface isn’t working”
  • PM: “What’s not working about the interface?”
  • Dev: “We can’t get what we need.”
  • PM: “What do you need?”
  • Dev: “The data we need isn’t there.”
  • PM: “What data is that?”
  • Dev: “The shipping notice information isn't available out of the ERP system in a way we can access it consistently.”

The example is greatly simplified, but it shows how reflectively asking questions helps you click down to identify root causes. The symptom is that there is a problem with the deliverable; the root cause is that the data can’t be accessed consistently through the interface.

If you identify the root causes, you can judge if there are issues to be managed or if those issues may grow into threats to the project. It is this judgment which differentiates great project managers from the competent.

Judgment is what you want to develop. Judgment can’t be measured or taught, it can only be learned. It’s a little like the abdominal snowman. You’ll see the footprints, but never the snowman.

You learn judgment through experience, making mistakes and learning. There are a couple of things to think about when you’re judging an issue:

  • Can it be addressed without affecting the critical path?
  • Will it significantly affect the project buffers?
  • What will the impact be?
  • How can I tell if it’s getting worse?

Use your judgment – it will help you learn and address issues early and effectively.

Tips for Project Management Success

“There is nothing more difficult to take in hand, more doubtful in its success, more dangerous in its execution, than to take the lead in the introduction of a new order of things. The innovator makes enemies of all those who prospered under the old order, and only lukewarm support is forthcoming from those who would prosper under the new. Their support is lukewarm partly from fear of their adversaries, who have the existing laws on their side, and partly because men are generally incredulous, never really trusting new things unless they have tested them by experience.”

- Machiavelli

There are many things which will determine success or failure on a project. The biggest, by far, is the relationship the project manager has with the project sponsor. Out of that relationship will come the strategies, tactics, communication and vision of what the project will be and how it will operate in the organization.

There are a couple things to keep in mind with this relationship.

  1. Form matters. Who says what, when is it said, how is it said, who is it said to by whom all matter. The bigger and more political the project, the more important this is.
  2. The sponsor – pm relationship will matter more than anything else in determining project success or failure.
  3. Look for patterns and be alert for any changes.

Make sure you know who your sponsor is. There is only one. This is the person who controls the budget and succeeds or fails based upon the success or failure of the project. While you may not spend the majority of your time with this person, a lot of your thinking will be focused around this person and communicating with this person.

There are some things to understand.

a) What is the person’s standing in the organization?

b) Is the sponsor writing checks that they can’t cash? The sponsor must have the direct strength to make a project work. If they are not strong enough, when push comes to shove, they will be run over. If they must depend upon someone else’s strength, the project has a huge risk.

c) Relatively, is the sponsor rising or falling? This will change through the life of the project. That will be critical to how what and when you communicate things on the project.

d) The sponsor must always know the truth. There may be reasons that something other than “the truth, the whole truth and nothing but the truth” may be communicated at particular times, but that person’s footing must always be solid. No one else can know more about the project than they do.

e) Understand and develop a pattern for how this relationship works and how communications are handled. Be extremely sensitive to changes in that pattern. Be extremely sensitive to changes in the organization which effect that person’s relative position.

f) How does the sponsor relate and maneuver people in the organization? Figure this out early and pay attention to whether it changes.

Respect the sponsor’s time. If you see any changes, investigate it early.

The most important thing to establish: How do you want me to let you know if there are problems?

Wednesday, July 2, 2008

Warning signs of trouble on a project

Is there a way of predicting which projects will have problems?

Sun Tzu reminds us:
"Every battle is won or lost before it's ever fought." The same is true with projects. So what should one look for to see if the battle will be won or lost? Here are nine questions to ask:
  1. Are we trying to put stretch pants on a rhino?
  2. Am I working for a lone wolf?
  3. Is there a silent assassin?
  4. Has a "can't fail" mentality developed around the project?
  5. Is there a let's just get started and plan later attitude?
  6. Is there a threshold to determine if we go on?
  7. Are processes followed?
  8. Is there a focus on deliverables and budget, but no thought about technology?
  9. Has the company ever done a project like this before?
Are we trying to put stretch pants on a rhino?
I'm serious about this. There are many times that in order to sell a project in a company, managers promise everything to everybody. They will do whatever pet idea is necessary to get someone to approve the project. They try and stretch the project to appease everyone. Have you seen this?

The problem is, like stretch pants on a rhino, it will work for awhile, but as soon as the rhino sits down, or runs or engages in some type of bodily relief, it's going to get ugly. The fabric will rip and mending it could be temporary and painful. Especially if the needle pokes the rhino, it could get ugly.

Be wary of stretch the project to cover the rhino.

Am I working for a lone wolf?
Are you working for one person? Do they say, "Ask me any questions." or "Don't bother other's with what we're doing." or "We need to get this working before we involve too many other people."

This can be a good approach if the project has a short enough duration, but if the project exists entirely at the whim of one person, watch out if that persons focus or status changes.

Beware if you're working for a lone wolf.

Is there a silent assassin?
Often times there will be people who don't want the project to succeed. There may be many reasons for this and you should try to discover them, but the first thing to find out is: "Who wants this to succeed and who doesn't?"

Silent assassins are particularly dangerous because you don't know who they are and so you can't know how to deal with them. If you're lucky, they're public about their opposition. Then you know what you're up against.

Rather than agonizing yourself about silent assassins' motivations, take a different approach. While it might seem counter intuitive, announcing a threshold or gate level that the project must exceed to continue gives the silent assassin a way to kill a project if they are strong enough. If they are not strong enough to keep the project from meeting this threshold, getting over the threshold or through the gate will build more public support.

The point is, if the assassin knows how to kill the project, they have to decide if they are strong enough and determined enough to do so. What you want to be careful of is letting someone nick and cut you to death without your knowing where it's coming from.

Has a "can't fail" mentality developed around the project?
The problem is that, if a project takes on a "can't fail" approach, it almost guarantees failure. It puts too much pressure on the project team and prevents clear thinking and communications.

Set up gates and threshold points where a project is objectively reviewed and there is a real possibility that the project can be killed. This focuses people and prevents a "can't fail" mentality from developing.

Is there a let's just get started and plan later attitude?
It's been said a thousand times: "If you fail to plan, you're planning to fail." Unfortunately, too often, one spends immense amounts of time and energy "selling" a project inside a company. When the project eventually gets approved, people are so quick to want to show progress and justify the project, that planning gets lost.

Don't give into temptation and remember to plan the project, work the plan and evaluate the plan as you're going along.

Is there a threshold to determine if we go on?
Thresholds are your friend. How do you know if something is successful? You know if it meets the goals that enable it to cross the threshold.

How do you prevent people adding every dream and wish they ever had into your project? Having a threshold defines what you have to do to continue the project AND it defines what you cannot spend time on. Thresholds focus attention, giving people on the project something to shoot for and a reason to celebrate when its achieved.

One of the biggest mistakes a project manager can make is never celebrating success. Thresholds provide the target, the yard marker and the reason to pat people on the back and celebrate success. Use them, they are your friend.

Are processes followed?
Have you ever been in a company where there are no processes? It's like trying to push a river upstream. Have you been in a company that has processes, but they're not followed? Or even worse, they're used as method to kill something that got approved but no one wants to do. Put it into an endless process.

Look around and see if there are processes by which things get done at a company compared to if things get accomplished through heroic effort. Whether it's ordering supplies, doing employee reviews or executing projects; a company either follows processes or it doesn't follow processes.

If it doesn't follow processes, know what you're getting into. Before you start the project, you'll have to define the processes necessary for the project to succeed, train people on them and then make them work. It can be very rewarding, but know what you're getting yourself into.

Is there a focus on deliverables and budget, but no thought about technology?
Many times businesses will know what the deliverables are that they want and they'll think about the time it will take, but they won't know about what it will take technically to get there. Even worse, they'll listen to a salesman from a software or consulting company sweet talk them into thinking that it'll be so easy with their technology or methodology.

But it's still work and it adds another layer of complexity which is rarely accounted for. When looking at a project, think about how much of the technology that is being used is new to the organization. Having consultants and contractors who know the stuff is nice, having employees who know how something works is even better.

Ignorance with new technologies is not bliss, it's a devil you know nothing about that is waiting to torture your life.

Has the company ever done a project like this before?
Actually, the question could be better thought of as, has anyone working on the project ever done anything like this before? If the company has experience doing these types of projects, then they know what to expect. If people on the project, working for the company have experience, then they are battle tested and know where many of the snakes are lurking in the grass.

You wouldn't feel comfortable having your house built by people who had never built a house before. Be just as concerned about executing a project with people who have never done a project like this before.

These are some of the warning signs to look for when you're considering going onto a project. Are there other signs you've seen?

Inquiring minds want to know...

Saturday, June 28, 2008

Risk goes way back

There's a lot of talk today about risk mitigation on projects. It's an important field and hugely important, but no one should that that it is new. Almost all financial services is really about mitigating risk. A great example of this comes from founding Virginia.

In 1585, Sir Walter Raleigh, one of the wealthiest men in England at the time, privately funded the founding of Roanoke. There were issues and threats (think storms, Indians, the difficulty of supplies) and by 1590 the endeavor was lost, one of the colonies was entirely lost and Raleigh lost a huge amount of money.

It took another sixteen years for the British to take another run at founding a colony. The Virginia Company was set up as a joint-stock company. Many people invested money (bought shares) and the risks were spread (mitigated) across a large number of people. Likewise, the gains would accrue to that same large number of people.

Now, one might say that this has nothing to do with risk mitigation on projects and directly, it probably doesn't. But you better believe buying ships, equipment, supplies, sailors, colonists and then sailing the Atlantic and founding a colony was a huge project. And you better bet there were some people very interested in how things were going. Remember that dueling was a valid way of settling disputes!

My point is simply that people have thought about how to mitigate risks for a long time. Spreading the risk, giving people participating in the project an opportunity to buy into the project and share in its success or failure have a long history of success.

I wonder was a risk register would look like for the founding of a colony?

Sunday, June 15, 2008

The Blind Men and the Elephant

It was six men of Indostan
To learning much inclined,
Who went to see the Elephant
(Though all of them were blind),
That each by observation
Might satisfy his mind.

The First approached the Elephant,
And happening to fall
Against his broad and sturdy side,
At once began to bawl:
“God bless me! But the Elephant
Is very like a wall!”

The Second, feeling of the tusk,
Cried, “Ho! What have we here,
So very round and smooth and sharp?
To me ‘tis mighty clear
This wonder of an Elephant
Is very like a spear!”

The Third approached the animal,
And happening to take
The squirming trunk within his hands,
Thus boldly up he spake:
“I see,” quoth he, “the Elephant
Is very like a snake!”

The Fourth reached out an eager hand,
And felt about the knee:
“What most this wondrous beast is like
Is mighty plain,” quoth he;
“’Tis clear enough the Elephant
Is very like a tree!”

The Fifth, who chance to touch the ear,
Said: “E’en the blindest man
Can tell what this resembles most;
Deny the fact who can,
This marvel of an Elephant
Is very like a fan!”

The Sixth no sooner had begun
About the beast to grope,
Than, seizing on the swinging tail
That fell within his scope,
“I see,” quoth he, “the Elephant
Is very like a rope!”

And so these men of Indostan
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were in the wrong!

Moral:
So oft in theologic wars,
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean,
And prate about an Elephant
Not one of them has seen!
- John Godfrey Saxe (1816-1887)


This may well be the most insight piece ever written about project management and what it means to try and run a project. Each person working on a project has a different perspective. They are confident in their perspective because they have personally lived it. They are suspicious of other people's perspectives, because in large ways or small ways, someone's experience is different from theirs.

How can one align all these different perspectives, identify an end point that one keeps moving toward, learn what everyone is experiencing and avoid being pulled onto meaningless paths which may look promising at first but don't lead to a constructive conclusion?

Remember that running a project is a little like running a hundred yard dash, except for one small difference. After you start running, someone fires a bullet at your head. If you cross the finish line before the bullet reaches your head, you're fine. If the bullet reaches you before you reach the finish line, well, that's not so good.

That is the demand of project management and alignment. Aligning people in the face of ambiguity and getting them to all work together to cross the finish line before the bullet reaches your head.

The world of the project manager.