What’s Really Bothering You? Ask Why Five Times.

Why, Why, Why, Why, Why

I’d like to share with you just a a few of the fresh ideas and new ways of thinking shared by Eric Ries at a LeanDC talk at American University last night.

For those who’ve never heard of Eric Ries, he is the visible speaker for the lean startup movement. You can read more at TheLeanStartup.com but briefly, the lean startup movement is about a huge paradigm shift in our ideas about management.

We are still using legacy ideas about entrepreneurship so the failure rate is embarrassing
Eric Ries

Evidently, lots of people agree with him; lean startup incubators are popping up across the country, and universities like Harvard are creating lean startup courses, all around the ideas Eric Ries uses and describes in his blog, Startup Lessons Learned. (he hasn’t even put out a book yet – that’s coming).

Master the Details in the Bone-Crushingly boring Act Two

There comes a time in the life of every startup when what you’re doing is no longer sexy.

Eric compared this period to the company story montage that happens in movies about businesses. Act One is always the setup, the good and the bad about the protaganist, that comes into play when they face a great challenge.

Act Two is always a photo montage of the protaganist setting up the business, maybe moving in, happy shots with customers, getting bigger, hiring people and eventually ends with the protaganist on the cover of a major magazine cover. This part always takes about two minutes in the movie and it’s usually setup for some major challenge in Act Three.

Eric says that the most important act for any company is Act Two – the no-longer-sexy middle part when all the fun and games are over and the ‘bone-crushingly boring’ stuff like product development meetings, and learning how to prioritize occurs.

In Act Two you’ve got to figure out how to constantly create value and eliminate waste, you’re still making those important strategy ‘pivots’ that may send you in a brand new direction entirely, you’re figuring out how to support your existing early adopter customers, while at the same time position yourself for new products. And all of that is the boring stuff, and the hard stuff.

I asked Eric this question: What was the hardest thing and/or most boring change that had to be put in place in Act Two to get to Act Three?

And he responded: “The Five Whys”.

“The Five Whys” is a lean manufacturing technique where you ask simply, why something occurred – but you must ask five times. I guess there is some magic in the number five, but evidently, when you keep asking why, you get to the root cause of the problem and deal with that, rather than wasting time and energy on a solution that doesn’t address the problem.

In a manufacturing environment, you can’t stop and revisit your process for three months. You have to keep moving. So he says that at his company, every time there’s a mistake, there is an immediate post-mortem; a simple, short meeting where the root cause is identified through five whys analysis.

Why, Why, Why, Why, Why

Here’s a common five why example

  • I gained five pounds over the holidays (problem)
  1. Why? – That damn rum cake.
  2. Why? – After that my sweet tooth kicked in and I wanted more sweets.
  3. Why? -I’ve been dieting for so long that I’d been deprived.
  4. Why? – My diet doesn’t allow sweets for rapid weight loss.
  5. Why? – (But I gained), maybe my diet doesn’t work for me (root cause)
  • I will find a diet that allows me to lose weight and also have sweets, so I won’t over do it (conclusion).

Wikipedia has a great, simple intro to the Five Whys and I encourage you to read it. Here’s an excerpt:

“ The real key is to encourage the trouble-shooter to avoid assumptions and logic traps and instead to trace the chain of causality in direct increments from the effect through any layers of abstraction to a root cause that still has some connection to the original problem. Note that… the fifth why suggests a broken process or an alterable behavior, which is typical of reaching the root-cause level.

“It’s interesting to note that the last answer points to a process. This is actually one of the most important aspects in the 5 Why approach…the real root cause should point toward a process”

If you follow five whys, the system will teach you where you need to make adjustments.

My key takeaway is that it’s that incremental benefit of boring but constant investigation, that supports the engine of success.

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!

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.

PMOT Washington, DC Tweetup Thursday 2/18 at 6PM

twitter

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

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

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.

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:

Baseball People, Rules, Tools

Can this analogy could be applied to software development? The modified diagram would look like this:

Software Development People,Rules, Tools

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.

Reestablishing Communications on a Stalled Project – Five steps to success

SeaLight, LLC Principal Consultant  Michiko Diby contributed this article to the June 10, 2009 Project Times

Any study on project failure will list poor stakeholder communication as one of the top three reasons for a project’s demise. This brief case study discusses the steps I took to revive project stakeholder communications and move a group of stakeholders from intense distrust to frequent (and pleasant) collaboration.

Background: This web application redesign project for the military had petered to a low level grind, characterized by tersely worded emails, accusations and entrenched opinions. Project status meetings were held monthly, and sometimes skipped. There were no other recurring communications.

Following please find key steps I used to shift this group to collaboration.

Step 1: Perform a Gap Analysis on as-is and should-be communications

The PMBOK version 4 now includes a Stakeholder Management Plan, which should be used by every PM. Many of us PMs were already doing something similar with the communication plan. The key here is to recognize that the PMBOK does have tools that, when used, will actually help you. I used the Communication Matrix and RACI chart to scope out all the stakeholders Just the process of interviewing stakeholders to fill in the RACI chart surfaced mis-conceptions about roles and responsibilities that proved to be the source of many an argument.

Step 2: Use your ability to be impartial as long as you can

When you are a brand new PM on a contentious project, you have a window of opportunity in which you are perceived as impartial; you just haven’t had time to form opinions yet. Use this time to your advantage. I decided to talk to the customer, the armed forces personnel, first. I wanted to understand how they perceived my team before my team could influence me. I knew from my stakeholder review in Step 1 that their experience with each other was based on the lack of clear role definition from the start. I also used this time to clearly understand the client’s perspective on scope, time and cost.

Step 3: Establish your credibility by responding to your action items right away

After my initial set of meetings with stakeholders, I came away with a list of action items. These became my priority. In an environment where trust has been broken, it takes many demonstrations, over time, to regain trust. But you can start off on the right foot but simply responding and responding quickly. Distribute meetings notes right away, do what you say you’re going to do, but do it sooner than expected. If you can’t do it, communicate why and explain when you can.

Step 4: Set up recurring meetings right away

The first thing stakeholders are going to do when they stop trusting each other, is to stop meeting. My job as PM was to get them back in the same room again, stay calm and not take sides. The first few meetings were not stellar. But, I knew that the point is that they actually get face time, even begrudgingly, on a recurring basis.

Step 5: Don’t get sucked in the vortex

In stalled projects, people can behave badly. They will say things that are hurtful and don’t move things forward. Many times I made the conscious choice not to get sucked in. I knew that it took history for negative feelings to develop, and I didn’t have that history. As the new person, I had to be impartial and mature – at times it was a huge struggle to do so. When problems do surface, focus on the problem, not the people. Shift the group to problem analysis, not people analysis.

Result: Within six months of recurring meetings, reestablishment of credibility, slowly introducing proper roles and responsibilities and keeping my mouth shut when I wanted to scream, this group of about 20 armed forces personnel, civilians, and contractors have become re-energized, meeting weekly for a Change Control Board that is effective and collaborative.