The Funnel Effect and My Kanban

GuyKawasaki tweeted about a really cool infographic on Alltop titled Why freeways come to a stop. I checked it out and what most interested me was the graphic The funnel effect (I circled it in red).

WIP

The funnel effect is a really good analogy of why you should limit your work in progress, like I do on my Personal Kanban.  In the analogy, just the right amount of water can go through as fast as it's put into the funnel.  But add extra water to the funnel, and the whole thing backs up.

Personal Kanban

In reality, keeping focus on just the right amount of work can allow you to finish more than if you didn't. Personally, I limit my work in progress to 3 items. I never thought it would have such a positive impact. So, what do you have to lose? Do you have a long list of to-do's, doing a little here and doing a little there?  Do you ever feel like you're not actually getting anything done?  Today, rather than trying to multitask, focus on just a few tasks until they are DONE. If you complete one task, you can add another to your focus list. Remember, 99% done is still not done.  At the end of the day, you'll feel a sense of accomplishment, preventing a traffic jam of work and actually getting stuff done.

Warning – Use of PM Force Authorized

We went to an airshow this last weekend. Being I was in the Marines some 20+ years ago and spent the best of my time in the air in a helicopter, it was like a trip down memory lane. I loved the smells and sounds of the flightline. I even got to walk onto a CH-53.  It was the first time since May 09, 1990.  But I digress. Upon arriving at the airshow, I noticed a warning was painted on the flightline that made me clap my hands like a cymbal-banging monkey. My wife took a picture so I could somehow relate it to project management in a future blog post.

Here is my Project Management translation:

WARNING

Efficiently Managed Project

It is unacceptable to do work on this project without motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Principle 5 Agile Manifesto of 2001 - February 11-13

While on this project all team members and the work under their control are subject to refinement.

USE OF PROJECT MANAGEMENT FORCE AUTHORIZED

Occam's razor and my project management approach

Occam's razor (or Ockham's razor) is the principle that "entities must not be multiplied beyond necessity". The popular interpretation of this principle is that the simplest explanation is usually the correct one. It has inspired numerous expressions including "parsimony of postulates", the "principle of simplicity", the "KISS principle" (Keep It Simple, Stupid).

Though most of Occam's principles are enrooted in philosophy, many approaches (especially the principle of simplicity) can be found in the basics of design principles.

Given a choice between functionally equivalent designs, the simplest design should be selected. Implicit in Ockham’s razor is the idea that unnecessary elements decrease a design’s efficiency, and increase the probability of unanticipated consequences. [¹]

When comparing technologies that perform the same function, a technology that is simpler in design will tend to be simpler to construct and repair, but will tend to require greater skill to use, whereas a technology that requires less skill to use will tend to be more complex in design and more complex to construct and repair. For example, a straight razor is relatively simple in design and construction, but requires considerable skill to use, whereas an electric razor is relatively complex in design and construction but requires little skill to use. [²]

Now, go back and reread the two referenced passages, substituting

design

and

technology

with

project management approach

.  I particularly like the straight razor analogy, mostly because I shave using a straight razor.  I only had to cut myself once (badly) before I realized I needed real skills to use such a simple tool.

So, what's my transition?  Just because you may know a lot about project management, doesn't mean you need to make things complicated.  At the end of the day, very few customers care how it got done.  They just care that the product or service was delivered on time and within budget.  If you're looking to add project management control points, look for what will lower risk and increase value throughput.  The idea is to make your process as simple as possible, allowing things to get done.  Don't add control points to a process for no other reason than to make work for everyone.  Don't simplify too much either, resulting in the wild wild west.  I'm always looking for that happy medium.  So, go forth.  Study your craft and learn everything you can about project management.  Just be careful not to cut yourself.

[¹] http://www.visualgui.com

[²]  http://www.omick.net

Image source: suddenimpactmedia

Let's do what makes sense

I sat in a meeting Friday afternoon to meet the new guy over at the vendor's office and give my assessment to my client.  It never gets boring, listening to rhetoric from a vendor.  They usually speak to my client, not with my client.  A few months ago, after I asked the vendor a very specific question about the sloppiness of a metric, the vendor replied  Do you have a problem with that!? Well, actually, I think both of us (the vendor and I) have a problem.  We're both here to ensure this client gets quality work.  It doesn't matter if it's a software build, documentation, or even a graph is a slide deck.  The vendor lamented and the metric actually makes sense now. The new guy, though perhaps giving us lip service, actually established himself as a bridge builder and communicator.  He said he wanted to know our concerns so we'll all be in step.  He gave us his email address and mobile telephone number, telling us not be hesitate contacting him.  When we pressured him on a request we've been demanding from the previous leadership, he said they would figure out a way to get it done.  When asked of our first steps going forward, his response was...

Let's do what makes sense.

What a refreshing response. No "let me get back to you". No "let me check with my boss".  It was a direct answer.  It was ambiguous but I thought it was acceptable considering the situation.  Compared to hearing traditional responses like "Ya, we can do that" when asked to if the vendor could make a change or deliver something, this guy actually said Let's do it.  If we can be in agreement as to what makes sense, we're golden.

At the end of the day, I don't care what they can do.  I care what they will do.  Let's hope we're turning over a new leaf.

The Pepsi Challenge of Waterfall, Agile, or Kanban

I kind of enjoy it when people get all in a huff over which soda is the best.  It's bad enough they can't even decide what to call it. Is it soda, pop, or soda-pop?  I've even heard a few refer to any brown carbonated non-alcoholic beverages as a "Coke".  I don't get that at all.  I'm going to assume these people just don't care.  All they want is a brown carbonated non-alcoholic beverage that will satisfy their thirst.  As far as soda-pop, I am the complete extreme opposite.  I drink Coca-Cola.  I don't drink Coke; I don't drink Pepsi.  If I ask you for a Coca-Cola and you ask me if Pepsi is OK, I'm going to respond with a stern but polite "No".  But, at the end of the day, I am also just looking for something to satisfy my thirst.  But, I digress. Since the Pepsi Challenge in the mid-70's, there has been another battle raging.  Let's call it the Delivery Challenge.  Regardless of what facts may be reports, detailing which approach lowers risk the most, which approach delivers the most value up front, or which approach leaves the stakeholders feeling the most satisfied, we all have our favorite.  If delivery approaches were soda-pop (yes, soda-pop) in a blind taste test, chances are we'd stick with our favorite regardless of what we may have picked.

From my own perspective, I don't believe we should be so blind to these opportunities.  We should be open to the idea that formulas can be improved and we should be open to the idea that processes can as well.

When I'm dealing with the government client on a particular contract, I use Waterfall.  We're talking Waterfall the size of Niagara Falls.  It's not that I choose this approach (drink).  It's all that is currently offered. When I'm managing my own personal projects and deliverables, I use Agile and Kanban.  I'm not saying one is better than the other!  But, when the choice is mine, I know what I like from each.  I ala carte the way I do things, so (as the customer) I get the most value while not bastardizing the original processes.

I know there are those out there who are cursing me.  They are strict Coke, Pepsi, and Dr. Pepper zealots.  Think of me as that kid down at the local Kwik-E-Mart who takes his cup and adds a little of each soda-pop in his 64 ounce cup.  It may look nasty but it sure tastes good.

...and at the end of the day, isn't it important that I just satisfy my thirst?

Image source: USAGeorge

Measuring Success in NYC

When you have a project, you need to find out from the customer how they will judge the success of the project.  Don't go off giving the team high 5's and leave the customer scratching their head looking at the bill.  At the inception of the project and at the identification of each deliverable, get agreement from the customer as to success criteria. I just returned from a trip to New York.  Let's use that trip to illustrate my point.  My wife and I will represent the customers.  Both of us had a different measurement of success.

For my wife, the trip would be a success if we made it to the Gershwin on time to see Wicked.  For me, the trip would be a success if I got to have dinner at John's Pizzeria.

We identified contingency plans, so we could have different levels of success.  [1] Drive almost an hour and a half to Union Station in Washington DC.

Milestone 1 - Success

[2] Take the train to Penn Station in New York.

Milestone 2 - Success

[3] Get to the W Hotel in Time Square and check in.

Milestone 3 - Success

[4] Get to the Gershwin Theater

Milestone 4 - Success (Customer #1 is 100% satisfied)

The show was really good.  If you haven't seen it, I would recommend it.  It was odd seeing some people not dressed up.  Call me old fashioned but if you're going to the theater, it wouldn't hurt you to dress up.

[5] The next milestone was get to John's Pizzeria.  I just wanted a pie and a beer.

Milestone 5 - Success (Customer #2 is 100% satisfied)

After dinner, we returned to the hotel and then spent the evening in Time Square.  Last time we were in there, I proposed.  Not a coincidence, our hotel room was right over the spot where I popped the question. Since I take everything so seriously, we then went to a toy store, where I was promptly attacked by a Transformer.  Needless to say, that was not on my risk register.

Thank you to my wife for allowing me to check in via Foursquare and Gowalla.  I didn't do it a lot.

How was your weekend?

A Schedule More Complicated Than a Rube Goldberg

I just reviewed an Integrated Master Schedule (IMS) comprised of almost 5000 lines.  I didn't write the thing.  I was just asked to review it.  You might be saying to yourself that must be an absolutely awesome schedule, detailing every nuance of a project.  Counter to that, you might be saying to yourself that is the most overdeveloped schedule ever creating, complicating the most trivial of work. In the business of project management or leadership, you should always be asking yourself, "does this make sense?"  If it doesn't, you should be looking for the Goldilocks approach to documentation or process.  Do something that is not too complicated or simple.  Do something somewhere in the middle.

Don't make your schedule as complicated as a rube goldberg machine

As I read through the IMS, I started to think of a Rube Goldberg machine and the OK Go video titled This Too Shall Pass.  Rather than reading a very straightforward schedule, identifying all of the deliverables and a decomposition ad nauseam, I saw a schedule that both inveigled and obfuscated.  A Rube Goldberg machine is the perfect analogy for this schedule.

A Rube Goldberg machine is irreducibly complex. It is a single system which is composed of several interacting parts, and where the removal of any one of the parts causes the system to break down. If one component is missing, the machine doesn't work; the whole system is useless.  This is NOT how an IMS should be written.  I see a schedule as a tool of transparency.  It is a way to communicate if a project is on time in a passive manner.  A fully resource loaded (properly decomposed) schedule can help you do a lot of other things.  But 5000 lines?  I don't think so, not in this case.

Image Source:  www.rubegoldberg.com

Why You Should Use Common PM Language

I don't normally drink coffee from Starbucks but someone gave me a gift card.  I like black coffee, with no cream or sugar.  I like my coffee fresh so I order a small size.  So, why on Earth did the person behind the counter not listen to me? I ordered a small Caffè Americano. For those who do not drink coffee, that's nothing more than a small espresso and water.  My expectation was I would get a small cup of coffee.  When I looked at my receipt it said Tall.  I brought this to their attention and I was dismissed.  "Oh, it's the same thing."

Well, no, it's not.  Line up the cups and this is what you will see.  Extra-Small, Small, Medium, Large, and Extra-Large.  What does Starbucks call them? Tiny, Small, Tall, Grande, Venti. So, what I got was a medium.  I'm not going to split hairs here.  I'm trying to make a point.  There needs to be a common understanding between the vendor and the customer when you both define the same thing differently.  This is a financial transaction.  I want what I paid for.

How does this apply to Project Management?  From the customer's perspective, what is the definition of done.  From the vendor's perspective, what is the definition?  From every stakeholder perspective, do you all have the same definition of done?  You should!

It's important to note, it doesn't matter which approach you use.  Waterfall, RUP, Agile, or Kanban.  Everyone needs to understand and agree to what done means.