Category Archives: Uncategorized
March 20, 2010 Busting up Mis-Communication with the Clarification Timeout
I came downstairs this bright Saturday morning to see my teenage son watching Who’s On First on You Tube, and I thought to myself, ‘Where have I heard this before? That sounds so familiar.’
Ah Yes! THE PMO!!
Are your project team meetings like on on-going round of Who’s On First? Is it like an endless cycle of mis-understandings piling up on each other like snowflakes in the blizzard of 2010? Eventually, frustration sets in, and then hurt feelings. If you’ve never see Who’s On First, stop now for a very good demo of escalating mis-communication.
So what does a PM do in this situation? One of the things I relish about being a PM, because the gratification is instant, is the ability to bring clarity to the project team. I say, grab the moment by interrupting to clarify. I like to call this a Clarification Timeout.
The Clarification Timeout
A Clarification Timeout enables you to quickly de-escalate conflicts in situations where you perceive that clarification would move conflicting parties forward. There are three basic steps to the clarification timeout.
- ask for permission
- clearly state your intent
- use extremely neutral, non-judgemental action language
Here’s the format: Permission – Intent – Action using non-judgmental language
Example 1:
“If I may” (permission),
“I’d like to aid in the discussion” (intent)
“by putting some terms on the wipe board” (non-judgement action)
Example 2:
“Could I take a quick moment” (permission)
“to help the team understand” (intent)
“by writing down what has been said to this point” (non-judgement action)
Why this works Asking permission shows respect to the parties in conflict. Chances are they are in conflict because of some perceived lack of respect between each other. So when you come to the discussion, show respect by asking permission.
Stating your intent enables parties in conflict to know where you are coming from. In conflict, they are questioning each other’s motives. So you can be the person whose motives they don’t have to question by clearly stating your intent.
Taking a non-judgemental action means that you aren’t going to explicitly state that you want to de-escalate the conflict through clarification. Rather, you are just going to ‘write something down’ or ‘wipeboard the idea’ or ‘draw a picture’. These are actions that won’t hurt either side. Whereas if you use words like ‘clarify’ or ‘re-phrase’ or ‘re-state’ then parties in conflict may think you’ll get it wrong, or they may feel that are already being extremely clear, in which case they may even be offended if you imply that they are not, through your need to ‘restate the issue’.
However, the irony, and the golden opportunity, is that the very action of getting a breather, so to speak, enables you to jump in clarify. And I’ve found that clarification is usually all that’s needed in many cases.
Just the other day, I watched an escalation in the PMO about the need to produce a security plan. The engineering lead believed that enterprise networking would take care of it, while the PMO contact believed that it was a deliverable the PMO had to produce. They started getting louder, and interupting each other and talking over each other, just like in Who’s on First. I jumped in with a Clarification Timeout. From my own experience, I know that a ‘security plan’ means one thing to requirements folks (usually a document that describes who can do what in a system from the user’s perspective) and another thing to engineering (usually a document that describes how the application will be safe from hackers, attacks and so on). I knew that they were really arguing apples and oranges.
“If I may,” I said (asking permission), “I would like help” (stating my intent), “..understanding what is the substance of each plan.”(non-judgmental action).
The room got quiet, and the engineering lead explained his understanding followed by the requirements lead explaing his understanding; which illuminated, of course, that they were talking about two different things. The funny thing is that I see this kind of escalation happen over and over again, in different environments with different clients. So I know that the clarification timeout is relatively rare.
With Abbot and Costello a clarification timeout would have resulted in a wipe board that looks like this:
Ohhhhhh....I get it!
Then one could walk through perhaps giving nicknames to the players to help in discussion..but that, of course, wouldn’t be as funny.
- 2 comments
- Posted under Uncategorized
February 16, 2010 PMOT Washington, DC Tweetup Thursday 2/18 at 6PM
Be there are be square…or something like that!
Curious to put a face to a tweet? Come meet your DC PM Twitter buds at the Inox Restaurant in Tysons.
This tweetup is a first and hosted by @ProjectRecovery in close collaboration with @TheGreenPM and @JosephGruber.
We’ll be at the bar 
Find everything you need to get there here: http://www.inoxrestaurant.com/
Hope to see you there
Signed the DC PMOT heads
- Leave a comment
- Posted under Uncategorized
August 14, 2009 Teaching Project Management to Juvenile Felons
Today I was able to present Project Management as a career at the Alfred D Noyes Center’s annual Career day. I volunteered out of a spirit of service and a firm belief that project management skills can be applied to real life. The Alfred D. Noyes Center is a juvenile detention center. I didn’t realize this when I signed up – I sort of thought it was a center for at-risk youth. No indeed, it’s a center for already-done-the-risk youth, kids who have committed felony’s including rape and murder.
I had four groups of kids, two sets of boys and two sets of girls for about 1/2 hour each. I prepped my presentation using materials on Careers in Project Management and Project Management for Life from the PMI Education Foundation. So I didn’t have to create any slides, rather, I whittled the slides down to the basics and what I thought the kids could easily grasp;ie what is a project, what do project managers do, what are stakeholders. I also focused on the earnings potential in project management and my message to the kids was:
Principal Britton and me
You already have basic project management skills
That proved to be a good message that kept the kids engaged and interested in Project Management
My first group of boys ranged from about 14-18. I started off describing earnings potential and then got into a project analogy I knew they could grasp: football. I borrowed from Any Given Sunday. “Football is a game of inches.” Then I got them thinking about when preparation for those final inches of super bowl began? Did the team just show up and poof they won? The boys surmised that planning started back at the draft with questions like ‘who do I need on my team?’, ‘how much money do I have to work with?’, ‘what equipment do I need?’
They got the idea. “Hey isn’t a building a skyscraper Project management?” they asked. “Indeed” I replied. “What about landscaping?” asked another. “That too.” I said.
I then asked them to tell me when they played the role of Project Manager.“Well, I can’t really give you any details” one boy began. “But I did plan to do something and got stakeholders (yes, he used the word stakeholders cause we had just gone over it) and team members to do what I wanted them to do.”
“Great.” I said. “That is exactly my point. The same skills you used there, thinking ahead, planning, organizing a team, figuring out who can do what, and figuring out a schedule, can be refocused and used for good and believe it or not, people need you because of your ability to think ahead, and to lead.”
But I really got into serious project planning with the girls. They wanted to know how to plan. So we did the Who-What-Where-Why questions using their real life need, which is the need to gain more Noyes center privileges through moving up a ‘level’ system. It’s clear that the levels system is Noyes way of encouraging good behavior. They get points for eating, for good hygiene, doing their homework etc.
“So how long does it take to get to the highest level?” I asked.
“20 days.” Said one Girl. “What?” exclaimed another. “You wack. It takes like 5 to 6 weeks.”
“Excellent,” I said, “Let’s do some realistic estimating and activity identification to build a schedule towards your getting towards the highest level” And that led into a discussion about activity identification, activity length and the total amount of points one could get in a day, 100. It takes 2000 points to get to the highest level.
“So,” said one girl, “See that’s 20 days.”
“Ok,” I said, “That’s a good optimistic estimate. But realistically, are you going to have 20 great days where nobody pisses you off and you do everything right.” “No, probably not.” She said.
“So let’s talk about a realistic estimate.” And from there we determined that the 5-6 weeks was a realistic estimate. The girls realized that getting to the highest level was a project and that they were all project managers on their self-improvement project. Further, they defined each other as stakeholders, because they could positively or negatively influence each other’s plan. Finally, they defined the Noyes center as their sponsor and staff as team members.
This wound up being one of the most enjoyable days of my year. I got to be the geeky PM that I am and at the same time open up a new world of possibilities. I was most impressed with the kids. They quickly grasped the basics of Project Management and were able to apply it to not only what they had done in the past, but think realistically about what they could do in the future.
Tags: Fun
- 5 comments
- Posted under Real Life, Uncategorized
July 10, 2009 People, Rules and Tools in Baseball and Software Development: A New Way to Think
Driving into work the other day I started thinking about one of the apps I’m managing and how it has become a miss mash of code as developers attempted to code every requirement before true business analysis had occurred. I’ve seen this before –communication breakdowns between developers and business users leading to applications that force business users to change their business rules due to the limitations of the system.
That has always seemed backward to me. The only reason IT exists in the first place is help people enforce business rules and be more efficient in their business processes. It’s the rules first and then the tools. Yet development teams sometimes force business users to adjust or change their business rules and processes to fit into a tool. At least that what was happening on this one project.
For some reason, a baseball analogy popped into my head. It’s like a bat manufacturer was unable to make a straight bat and created a curved bat instead. Then, the manufacturer insists that baseball change the rules to accommodate a curved bat.
By the same token, sometimes business users ask developers to build functionality that only humans should do. That’s like building a tool to determine a strike. You need an umpire, a physical person, to do that.
It’s just silly how things go in software development sometimes. Baseball, however, is pretty clear. You have three basic elements:
• People: batter, pitcher, umpire, shortstop, 1st, 2nd, 3rd etc.
• Tools: bat, glove, bases, scoreboard
• Rules: All the rules of baseball, what a run is, what a ball is, what a home run is, what stealing a base is, how many players have to be on a team, when players can be substituted
In baseball:
• Rules come first and determine how people and tools interact
• The rules (how the game is played) are created by people.
• The rules determine what the tools should be.
• People then use the tools to conduct and enforce the rules.
This means that:
• No tools exist unless its use is specified in the rules
• Rules clearly describe what people are responsible for and what tools are responsible for
The diagram for baseball would look like this:
Can this analogy could be applied to software development? The modified diagram would look like this:
IT Governance in this model would be Tool Governance. The question from a Tool Governance standpoint would be:
For existing tools:
• What is the purpose for the tool?
• Is the tool linked to a rule?
• Are tools being asked to do what only people can do?
In baseball, tools only exist to enforce the rules and to promote efficiency in the execution of rules. If we applied this guideline to software development then tools that don’t enforce rules and promote efficiency should be re-evaluated for their necessity.
For the consideration of future tools:
• Does this proposed tool have a rule that it clearly links to?
• Is the rule clear about how the tool should be used?
• How will the tool promote efficiency in the execution of the rules?
• Is the tool designed to do things only people can do?
I like this model because it’s easy to describe and grasp and for that reason, I think I will use it with my executive sponsors . It also brings up fundamental questions that help get to the heart of the purpose of software applications. It simplifies the issues to clarify understanding about why we are building a tool, what people are supposed to do with it and how it supports the business.
Tags: process
- Leave a comment
- Posted under Uncategorized
