Questions a Change Agent Ought to Ask

Susan Cramm of Harvard presents interesting questions from the new HBR article "How Project Leaders Can Overcome the Crisis of Silence."  We are all familar with the type of statistics persented, that 70% of IT-enabled business initiatives fail or fall short of expectations.  The authors try to get project leaders to engage in five conversations to gain greater insight into whether a project is going in the wrong direction:

1. How often do you plan projects around how you would like the business to operate rather than the way it really operates?  How often are estimates and deadlines set using the PDOOMA methodology (PDOOMA - Pulled Directly Out Of My Ass)
   
2. How often is the Project Sponsor drafted, un willing or uninterested?  I've written on this before "Project Manager: Right Person, Wrong Title" and unless the Project Sponsor is fully committed and powerful enough, there is no amount of project leadership, management or funds to make a project succeed.
   
3. Are we faithful the the approval process?  How often do we follow a process when it's beneficial only to leave it when it's more expedient to cut corners?
   
4. Are we honestly assessing our progress and risks?  How often do we put in work arounds, short cuts or make desperate efforts to complete a deadline knowing things have been left out?  How do we communicate the issue after it has happened?
   
5. Are team members pulling their weight?  What can we do about it if someone isn't?
   

These are all discussions the project leadership should have.  Not only to gain insight into them, but also to find effective ways leaders can confess if the pressures of deadlines have forced them to take short cuts they would rather not have taken.

God is in the Why

The old saying goes that "god is in the details."  That might be.  Success is often made or lost in how the details are handled.  However, if you want to align and do what they need to do to all arrive in the same place, god is in the why.  If you want people aligned, they better see the same why, they better be singing from the same hymm book.

A child asks why something happens, why something was done, why people came together.  It's when everyone can honestly answer the question as it uniquely applies to them and find the direction that takes everyone to the same place, that you get alignment.

You cannot supply every answer, convince every skeptic or solve every problem necessary to make a project succeed.  If everyone knows the why and it relates to them, they'll come up with the right answers without you.

If you want alignment and success, god is in the why.

Photo Credit: escapista

Are You a Tribal Leader?

How does a manager get their power? Maybe it's organizational, maybe it's access to information, but if you're on a project team to initiate something in a company, it comes from the people on your team. Do you understand the stages and dynamics of the team interactions?

Dave Logan has a great book out discussing different team stages and their dynamics. I consider Dave a friend with great insights. [Editor: Yea and you've also deluded yourself into thinking Natalie Portman would be your friend.]

Working with BNET, Dave's released a video describing these stages.

Briefly, the Five Stages are:
1. Life sucks.
2. My life sucks. [Editor: Working with you, that's me!]
3. I'm great.
4. We're great.
5. Life's great.

Check out the video and buy the book. You and your teams will be more successful.

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

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

How to Engage People

Dennis D. McDonald in his always educational blog, got me thinking again today. He is absolutely right when he says that blogs would greatly improve communications between distributed teams. The real difficulty is getting people to participate.

The Problem
It is fairly well understood that in most social type application, from youTube to blogs, that 2 to 3% of the people contribute 90% of the material. The question is, how do you get the other 97% to engage? [Editor: 97% of them are intelligent enough not to engage with you. I'm so jealous of them...]

The Solution
You have to offer a way to get feedback in a simple way that requires little effort and recognizes their input. That is why we give people the ability to answer questions (multiple choice, percentage, yes/no) and rank people based on the accuracy of their answers.

As a manager, you don't know what they answered, but you do know that Dennis is more involved and knowledgeable than Andy. [Editor: That's not saying much. The slowest third grader is more knowledgeable than you.]

If you make things entertaining and engaging, people will participate. If you set up a little competition that rewards their engagement, they will engage more.

If you want to know more, email me: ameyer@go2incent.com

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?

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

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.

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?

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...

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.