The Project Shrink
by Bas de Baar
Bas de Baar is a Dutch visual facilitator, creating visual tools for dialogue. He is dedicated to improve the dialogue we use to make sense of change.
As The Project Shrink, this is the riddle he tries to solve:
“If you are a Project Manager that operates for a short period of time in a foreign organization, with a global team you don’t know, in a domain you would not know, using virtual communication, high uncertainty, limited authority and part of what you do out in the open on the Internet, how do you make it all work?”
Recent Posts
The Final Project World Collectable Card. Nr 16.
Old School Teams Stick Together
Saving The Planet
What Makes A Culture A “Project Culture”?
Plan B. Another Path For Problem Solving And Innovation.
Categories
collectable cards,
old school
Date
|
I see a lot of people running (as in the "exercise" thing) with their iPods on. Earplugs in, and trying to catch the rhythm pumped into their ears.
That's great. You get into your zone. Just you and the environment. Running with golden tunes, making you utterly happy.
It's bliss when you can keep some sounds out. It is hard thinking with someone yapping on the phone next to you.
Isolation. It has its advantages.
Until you're hit by a truck. A big yellow truck you didn't hear because you were chilling to Shabba Ranks.
"Mr Loverman."
"Shabba!"
Now, this has something to do with projects.
A project is a temporary structure within the host organization. This cocoon, yes - your project, allows you to do your thing without having too much interference from the outside world. Read: stakeholders, managers, men in black.
Think about it as a hospital tent set up in a field. It allows the doctors to perform surgery isolated from what happens around them. It provides focus and shelter. It’s not a fortress. The walls are thin and allow for surrounding noises to enter. It’s put up when needed and taken away when it has served its purpose.
Isolation is not the key. Key is tranquility. A chilling atmosphere.
You need to let information from the stakeholders in. They have changes. They bring gifts of incredible awesomeness. They have power. The power to run you over like a big yellow truck.
Let me provide you with two example of boundaries.
The old famous and loyal change procedure. You can set it up to be fluent and swift. Small quantified changes come in and can be absorbed somewhere in the process. Or you can setup your own version of the Atlantic Wall: nothing can get past it. You need five approvals from a board with four members. Ha!
Boundaries.
Or setting up dedicated time slots for asking questions so people don't continuously interrupt each other. Regular short meetings with some key stakeholders where they can ask questions or perform some other interrupt will regulate the information flows. If people know they will be helped, they'll wait. If they have no idea, they'll just keep on ripping up that tent you just put up.
"Shabba."
|
Posted on: November 14, 2010 12:16 PM
|
Permalink |
Comments (4)
|
You need to let people and information into your project to accomplish something. But not all. Some stakeholders might suck the life out of your team while information can be irrelevant and just darn confusing.
If your project is an intervention in a larger organization, your project boundaries are like a membrane. Some stuff gets in, some stuff gets out, some stuff doesn't pass the project boundaries ever. Your project is a temporary structure within the host organization. This cocoon allows you to do your thing without having too much interference from the outside world.
It needs to be a membrane. If you seal of your project so no information gets out, or your move your cocoon to some obscure, remote part of an organization, out of sight, you get other issues.
During the PMI Global Congress earlier this month in Washington DC one of the interesting speakers was Vivek Kundra. He is the CIO of the United States. The one responsible for all IT spending in the US government. He talked among other things about failing projects in the federal IT arena.
About multi-billion dollar projects that are years behind schedule and might deliver results that might be obsolete when launched. That kind of projects.
Shining Light
One of the initiatives he talked about to tackle the problem I found very interesting. Especially in the way it is phrased: to shine light. Make sure that every IT investment is visible to everyone. For this purpose the US government launched the IT Dashboard in the summer of 2009. This highlights the status of major IT projects and identifies worst performing projects and root causes.
The dashboard also provides the name and contact information of the official responsible for the execution. Vivek Kundra mentioned in his speech that citizens contact people from troubled projects and point them to cheaper alternative solutions.
After setting up the dashboard, departments halted and terminated some troubled projects. Of course it is hard to establish of the IT Dashboard was the direct cause for this. But getting feedback from the outside about your own performance can create miracles.
If you are working in a closed system with feedback just from within the system, the information can get contaminated. Unchallenged groupthink can lead to biased opinions about the state of the investment. |
Posted on: October 24, 2010 02:27 PM
|
Permalink |
Comments (4)
|
When you are stuck in organizational policies, structures and rituals it may be wise to look at the environment before you as a blank canvas. See the elements for what they are: artificial. They may be there for a good reason, but still, artificial. They are not a physical reality.
I wrote recently a comment on the excellent BetterProjects blog that illustrates my point:
"I look at it sometimes like this: the human system (people interacting) is like the infrastructure, and the belief systems/methods/rules of engagement/culture are kind of like an operating system which agrees on certain protocols. And yes, projects would be applications, needing both layers."
Nothing is a given. If you are stuck, look at your organization as people interacting and start from there. Write your own operating system or hack the current one.
Always remember: do no evil. I am not talking about anarchy or doing anyone or anything harm.
There are formal approaches to Stakeholder Management that involve recipe like instructions on how to plot people in grids. But sometimes people don't like to be plotted on grids. Throw preconceived ideas overboard and start with a blank sheet. And draw an adventure map for example. There is no physical rule that forces you to follow one approach.
Another example are discussions around the "plan-driven" vs "agile" debate. Should you use one over the other? Is one of them stupid?
Some Project Managers for example position “agile” as an opponent, the other extreme end of some scale. They think outside a "plan-driven" box. And vice versa. This is something that mostly works. Many people will get this “thinking outside the box”. But this is not what I mean. It is the next step of awareness that is more difficult to explain.
There is no box.
As Brian Clark explains:
“Just like Neo needed to understand that “there is no spoon” in the film The Matrix, you need to realize “there is no box” to step outside of. You create your own imaginary boxes simply by living life and accepting certain things as “real” when they are just as illusory as the beliefs of a paranoid delusional. The difference is, enough people agree that certain man-made concepts are “real,” so you’re viewed as “normal.” This is good for society overall, but it’s that sort of unquestioning consensus that inhibits your natural creative abilities.”
There is no plan-driven. Agile doesn’t exist.
There is just a problem that needs to be taken care of. There is just a team that must be managed. Just observe the situation and look for the cause.
And yes, you are left with aspects of humans and their emotions towards change. But than you are operating on the "infrastructure level". |
Posted on: October 09, 2010 07:11 AM
|
Permalink |
Comments (0)
|
Some PMs give me this weird look when I start singing tunes from "The Wizard of Oz" when discussing stakeholders.
Others give me the evil eye when suggesting you turn your project into a pirate ship.
Arrr. Let them walk the plank!
Metaphors are not part of their professional arsenal. Because, it's just not that! Professional.
This are the same people that are using words like "marching orders" and "the troops". If a Project Manager has a mindset like this, war as a metaphor, his mind is thinking in friends and foes, allies and enemies. You are either with him or against him. This view of the world will make it very difficult to collaborate with this person if you disagree.
Hmmm. More "professional"?
Somewhere, sometimes, some people still think "fun" and "professional" don't mix.
Woaha.
Fun and creativity does have an amazing effect on how people work together. It’s actually a shame that fun and games are treated like an add on, a nice to have.
“The customer doesn’t pay you to have fun and be creative.”
The customer doesn’t pay for the air conditioning either.
He does pay for an awesome product or service. Happy people provide happy result. Simple as that.
Happy metaphors, means fun, means great results.
Recently I started experimenting with Adventure Mapping. This a highly playful, interactive and intuitive way of communicating complex elements in your project.

The main concept is simple: picture your project as a Big Adventure. Together with a ragtag crew you are on a quest, to save the princess, find the Spaghetti Monster, blow up a meteorite, or some other awesome thing.
Now all you need is a piece of paper or a whiteboard and draw a line towards a big shiny treasure. Together with your team you can start to fill in every detail about your Big Adventure.
The map reflects the storyline of the project. The episodes of the project life cycle. The glory days of starting the project. The period in which the project was under attack by vicious stakeholders.
How did the crew meet? Why did they join the Big Adventure?
Since I proposed this technique (and its application to Stakeholder Management and the evolution of my blog) more and more practitioners approach me with their usage of the technique and offer suggestions.
It is a easy and effective technique. I'll hope you give it a try and share you're experiences.
|
Posted on: September 26, 2010 02:29 PM
|
Permalink |
Comments (2)
|
Sometimes I wonder if I suffer from tunnel vision. Or perhaps I really found the "true source" of project problems.
The question I try to answer for years now is how to make global, virtual and multi cultural projects work?
The answer I found is quite simple and has two elements:
1.
Make sure everyone involved is going after the same goal and envisioning the same result.
A project has a goal, an objective. This is part of the larger context of the goals of the organization.
Individuals have goals, ambitions, interests. If peoples goals are met, they work happy; if not, they don’t.
Job for the Project leader is to align the goals on all levels. Keep on tweaking and adjusting. Make sure everyone understands. Make sure they are all in balance.
2.
Make sure that everybody is using the same approach. I don't care what your rules of engagement are, spiral, incremental, waterfall or spiritual, as long as all involved are adopting the same set of rules.
If you use a “standard” rule set by it’s name, like Scrum, XP, Prince2, you really have to use the entire set that is covered by the label. PINO, as in Prince In Name Only, or SINO, Scrum In Name Only, is worst case. People will assume they are working according to a certain set of rules, when in reality they are not. Total misalignment.
That's it.
Everything else is just a sub theme from this gigantic obvious observation. Communication. Culture. Behavior.
Now my blog and this blog are called "The Project Shrink". There is a reason for that. I want to emphasize “human behavior” in projects and I have difficulty pronouncing “Project Sociologist”.
Cliche alert. To a guy with a hammer, everything looks like a nail.
Or, perhaps more appropriate: to a shrink every problem is psychological.
I view projects as a set of social interactions. And because we all define problems, solutions and things in general from our belief system, I see most project events in terms of communication, culture and behavior.
If I read Standish Chaos Reports about the causes of project failure, I read “80% are communication / people problems”. Others might read “lack of certain process components”, and others might see faulty research.
I find project problems in communication, culture and behavior. It is difficult to determine how much of "reality" is colored by your own preferences and believes.
Even if your topic is about exactly this phenomenon.
So. Tunnel vision? True source? |
Posted on: September 19, 2010 04:41 AM
|
Permalink |
Comments (2)
|
"That rainbow song's no good. Take it out."
- MGM Executive Memo after first showing of The Wizard of Oz
|