What time is the 3pm meeting?

---

Have you ever been asked: "What time is the 3 pm meeting?" 
You're thinking: "This guy is on something; or he's texting while talking!"


We here in the backyard of the seemingly larger-than-life Walt Disney World* pay some attention to the management paradigms coming out of our corporate neighbor.

And, so the Disney response to that question is instructive, as given in this blog post from the Disney Institute, which I sum up as:

'Any interaction provides an opportunity to add value and improve quality of communications'

“What time is the 3 o’clock parade?” On any given day in the Magic Kingdom at Walt Disney World Resort, you might hear Guests asking our Cast Members this seemingly peculiar question. And, while the question appears to have an obvious answer, we also know that frequently the true question lies beyond the obvious.

As our Guests are often excited and distracted ..... So, Cast Members will ask some additional questions to uncover what it is that the Guest really wants to know…such as, “What time will the parade get to me?” “When should I start waiting to get a good viewing spot?” and “Where is the best place to stand?”

Instead of simply repeating the obvious answer—the actual parade start time—back to the Guest, our Cast Members take this opportunity to .... share with the Guest what time the parade will pass by certain locations in the park, offer possible vantage points to view the parade or advise when to leave another area and still arrive at the parade on time.

This is important, because rather than dismissing the “3 o’clock parade?” question as something trivial and offering a blunt response, Cast Members understand that it offers the opportunity to exceed the Guests’ expectations ...... 
.... the “3 o’clock parade” question is commonly used to help Cast Members understand that their answer can either end the conversation, or it can begin a quest for richer discovery.
....

*Did I mention:7 parks, 29 hotels on property, 40,000 acres, and tens of thousands of "cast members
And, I am an un-paid volunteer for Disney Sports Attractions

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

That moral hazard thing

Moral hazard: we learn these from the knowledge base at wikipedia:

A moral hazard is a situation where there is a tendency [by a work package manager, for example] to take undue risks because the costs are not borne by the party taking the risk.

And, somewhat related, we are informed that "adverse selection" is described this way:

Adverse selection is a situation where an individual's demand for [relief from risk] is positively correlated with the individual's risk of loss (e.g. higher risks buy more insurance), and the [project manager] is unable to allow for this correlation in the [project plan]

---

This discussion about moral hazard came up with some of my students in my Agile PM class. We were discussing how tightly to schedule a project.

My thinking: a plan without slack is not really a plan; it's a hope.

Two ways to get slack planned into the project baseline:

1. Assume there's always going to be "labor loss"... That is, no one can really work 100% of the time they are schedule to work. It just doesn't ever seem to work that way. From dental appointments to coffee bar chat, some labor is lost. I always estimate 15%
2. Put in what I call "pipeline buffers", to allow some "breathing" in the schedule plan. (I may call it pipeline buffers, but others call it critical chain method) 

(Many reading this blog may have never seen an install of pipelines; nevertheless, I'll describe it by saying that what they do is put in expansion joints every few lengths by letting the pipe zig and then zag. These zig zags absorb the changing length of the pipe with temperature, something like an accordion, and something you have to worry about in the physical world)

So, now moral hazard: the team knows there is slack built-in. In the agile business, we don't schedule for more than 85% of velocity, and we always put in a zero activity iteration before every release (a release is some number of iteration's deliverables). If the team knows this, it creates a moral hazard. They know they can use the slack without having to pay the price of the longer schedule.

And, that creates the correlation of the adverse selection dilemma: a demand for schedule relief on the one hand, and a correlation with the propensity of work packages and iterations to run over.

What's a PM to do to fight moral hazard? Here are a few ideas:

• Incentives to do good, i.e. pay for performance (or 'show me the money')
• Penalties if the schedule is blown
• Keep the labor loss to yourself; that just happens. No point in offering it up to the general population
• Make it hard to use the buffer time (after all, the PM should be in charge of constraints, not the inmates)

In effect, any schedule that's going to work has got some slack (some room to zig and zag)

Time zone bubbles

Sometimes, it's the simplest ideas that are the most effective. In the IT production control world, "bubble charts" are a common artifice to show the workflow of various scripts, user/operator interactions, and programs that have to run in sequence, or with dependencies, or a particular time (scheduler), or "on demand".

 

Fair enough, but no news there.

 

Then I read a blog post by agile guru Johanna Rothman about time zone bubble charts. So simple, but so effective as a communications device for the distributed team. It's a simple image, suitable for the war room or the background on some far flung work station.

 

 

 

Johanna offers six ideas for dealing with the myriad issues of time zones and teams. She writes:

1. Show the timezone bubble chart to your managers so they understand what you are attempting to manage.
2. Share the timezone bubble chart, so all the team members can participate in selecting planning and standup times.
3. Share the timezone pain. Do not make only one person or only one timezone delegate always arise early or stay late.
4. Know if everyone needs to participate.
5. Ask people if they will timeshift. Make sure you ask in advance, so people can make arrangements for their personal lives.
6. Make sure people either have necessary bandwidth to participate at home or food and beds to participate at work, if they need to participate outside of normal work hours.

 

My experience was [India west coast (UTC +5:30)] to [US East coast (UTC -5)]. That's 10:30 hours difference in time, and not all that uncommon among software teams.

 

Here's what we did:

• Dedicated phone room with open line for about 4-6 hours per day (anyone could walk in and talk or set up an offline conference)
• Time shift (mostly by the India workers)
• Alternate early/late conferences so that both US and India shared the inconvenience
• Real-time document sharing via shared resources
• Teleconferences by video on a case by case basis. (We didn't have Skype or Facetime at the time)
• More care with documentation to compensate for ESL (English as second language)

Hey! you can make it work
Bookmark this on Delicious

Time Management of Complex Projects

Lynda Bourne has a post about a new book to be published in the United States this month: "Guide to Good Practice in the Management of Time in Complex Projects" . It was written by the Chartered Institute of Building in the UK.

I was intrigued by the title, and although I have not read the book, there is a nice 8 page Preamble at the publisher's site that invites more reading.

From that free document come the principles shown below. Of the four principles listed, three deal with risk--I guess that follows naturally from the topic of the book which is complex projects, complex enough to require some serious analaysis to synthesize a schedule from the project plan.

I like the one second one because it speaks directly to the role of architecture in the design of the project narrative and the management of risk. I don't necessarily agree that parallel structures are needed, but definitely there needs to be loose coupling between problematic elements, even in sequence.

In order to achieve effective time management there must be:

■ A competent appraisal of the risks which are likely to severely disrupt and delay the progress of the work;

■ A design which permits the work sequences that are likely to be severely disrupted and delayed by foreseeable events to be separated into parallel, rather than sequential paths;

■ A‘ time - model ’ for the project against which progress, or lack of it, can be measured;

■ A practically achievable strategy for dealing with intervening events during the design, procurement and construction processes.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Standing waves

Is everyone familiar with the "standing wave ratio", SWR?

If you are a little vague on this, first think about the incident [or driving] energy that is directed toward an objective. If the objective absorbs all the effort directed toward it, there is no reflected or unused effort. But when there is unused effort then interference is felt between the effort directed toward the objective and effort reflected from it or not used.

Interference causes waves form; in the project context interference waves cause periodic delays alternating with progress. The degree, or amplitude of the interference is felt by the duration of the delays and progress.  These waves are called 'standing waves', and the SWR is simply the ratio of the energy directed to the objective to the energy unused and reflected back.

The traffic model
We've all experienced standing waves. Just drive in traffic. Inexplicably the traffic stops or slows, then speeds up, only to slow or stop again.  Why?!

These are standing waves of progress and delay. The objective [the road ahead] can't absorb all the incident effort [traffic], so some effort is reflected that interferes with oncoming traffic.

Typically, traffic waves occur--and flow is disturbed--when the road changes character, usually because of a discontinuity: a traffic accident, a slow driver, a change in the number of lanes, or a traffic light. Remove the discontinuity, and the standing waves decrease, flow improves, and effort is used more effectively. Friction [non value add effort, in this case standing in traffic burning fuel and consuming time without result] is reduced. Thus, during rush hour, you may notice the traffic lights tend to be retimed to reduce the SWR of the traffic and improve flow.

The project effects
Now, what about projects? Don't project discontinuities produce a project SWR? They do indeed. Project processes are like the highway, conveying effort to the objective. But processes are embedded in the project network schedule. If there are sequencing, resource, or task discontinuities then there will be waves of delay and progress.

So, what are we talking about when we say "discontinuities"?  Examples:

• Successor tasks mismatched to predecessor tasks; the successor resources can't absorb all the predecessor results, thereby creating a constraint and changing flow
• Incorrect sequencing that disturbs timing
• Parallel paths joining; two or more teams now feed into one or more successor teams, disturbing flow
• Work-flow decision loops that are out of sync or not paced to maintain flow in project processes
• Batch schedules rather than real-time
• Lead and lag effects in schedules that change the coupling between the project clock and the wall clock
• Idle staff...marching army effects...who distract engaged staff

So, in one sense, the project SWR is the ratio of the applied effort to the effective effort. Or, in more familar words: the ratio of the total effort to the value add effort.


Think about this the next time you are in traffic.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Your schedule is Your Swiss Army Knife

A few years ago I did a presentation that was one part tongue-in-cheek and one part serious about the fact that the typical schedule tool makes the project schedule a Swiss Army knife of information.  The missing 'tool' is quantitative risk analysis.  The presentation is about how to add that important element

Here are the charts

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Favorite quote: Time

"There is no undo button for our oceans of time"

Tom Pike
"Rethink, Retool, Results"

Projects are one-time endeavors; there's only one change to get them right!

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Start on the critical path?

In project management school, the lesson on Critical Path includes Rule #2: "Apply resources first to the critical path and subordinate demands of other paths to ensure the critical path is never starved."

Most of the time, Rule #2 is good advice. [Rule #1, if you haven't guessed is: create a schedule network so that the critical path is revealed; Rule #1 is ignored by those that work only with milestones]

Some of the time, Rule #2 has unintended consequences, like making the critical path longer! How does this happen?

The problem arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. Now, the parts are not interchangeable. Now we must consider not the generic staffing profile for a task but actual capabilities of real people.

Now we must consider the intersection of the staffing plan with the schedule plan. When two plans intersect, the results are not always as we want them. Intersection means overlap, and overlap means that the planning elements must be moved about so that each overlap is harmonious.

Take a look at the following figure for Rule #2:

You can probably see that if not for the specific assignments of Mary and John, the critical path could be as short as 50days, not 65 as shown.

Let's violate Rule #2 and invent Rule #3: Reorganize the network logic

Staffing does not actually start on what was the critical path, but the overall schedule is shorter nonetheless. A new critical path is born which incorporates the sequencing constraints of the original path and the staffing constraints brought about by Mary and John.

Obviously, on any network of non-trivial scale you can not really do this by hand; it requires a schedule optimizer and the optimizer has to be configured to try, at least, violating Rule #2.

Are you on LinkedIn? Share this article with your network by clicking on the link.

Culture, projects, and politics

Here's a quote worth considering the next time politics interrupts your project:

"...the central conservative truth is that it is culture, not politics, that determines the success of a society [read: project]. The central liberal truth is that politics can change a culture and save it from itself [read: avoid dissing a project that might be worthy but not culturally compatible].”

Who said these words of wisdom? None other than Daniel Patrick Moynihan, former White House advisor and U.S. Senator.

So, what to make of this idea?

Point 1: Culture dominates! If your project methodology is counter-cultural, then be advised: "some work required here"

Point 2: Culture is changeable, but politics is untidy tool!. Politics, sometimes at variance with long-held beliefs [organizational, not necessarily personal], and sometimes at variance with principles [actionable guidance around beliefs] is often the tactial plan of the moment.

Point 3: Culture adapts to the new reality over time, if actions are repeated consistently.

Are you on LinkedIn? Share this article with your network by clicking on the link.

Glen's Quote of the Day: schedule risk!

Glen Alleman comes up with some nice quotes of the day. One of my favorites is about the swooshing sound of milestones as they fly by:

I love deadlines; I especially like the SWOOSHING sound they make as they fly past
— Douglas Adams

Glen has a nice little post on this, and he mentions another favorite of mine: the Monte Carlo simulation to get a handle on schedule risk. The fact is, the statistical math is either not closed form or impractical to evaluate for any real schedule, so the only way to really see what is going on is with a simulation--and it's fast!

The Central Limit Theorem tells us the outcome distribution of a long term schedule with a lot of activities is going to be nearly symmetric--that is, about as many things are going to go right as not over a long term--but the confidence interval, in real numbers, for any particular schedule is only knowable with simulation. And simulation is the best way to get a fast read on the project manager's best friend in statistics: Expected Value

Give it a try!

Are you on LinkedIn? Share this article with your network by clicking on the link.

Ideas for Managing at the Milestone

Nothing really good happens at a milestone because too many things have to come together to have success.  At a milestone, seemingly independent activities have their fate joined.  At the milestone, everyone is in, or else everyone is stymied when the gate is not opened to pass through.  

Here's one idea: The fact is, joining together at a common event, like a milestone, is hazardous because of the concept of ‘merge bias’.  Merge bias simply means there is a strong tendency to slip to the right at a milestone, thereby stretching the schedule.  In other words, when you look at a schedule and you see a milestone, think immediately that there is a risk to shift right—that is, milestones are hazards to on-time performance and represent the first weakness to look at when assessing the schedule for risk.

Here's another: It’s common sense that the more independent an activity is, the more freedom of action there is.  After all, there is minimum need to coordinate outcomes and processes if no one else is depending on your production.  So, by corollary, dependencies limit choices, limit agile methods, and place constraints where there would not otherwise be inhibitions.  Dependencies increase the effort that must go into coordination—team of teams, staff meetings, and the like—and this effort must come from some budget, and potentially the distraction of more coordination could impact other value-add work.

It’s no accident that milestones tend to shift to the right on the schedule.  There is actually a mathematical explanation for this phenomenon that arises from the statistical behavior of somewhat risky activities.  In a project, no activity can be known for certain—there is always some risk that things will take longer than planned, or in some cases take less time than planned

In statistics, the explanation comes from behavior of intersections and unions of events.  A union is an ‘or’ case; an intersection is an ‘and’ case.  A milestone is an intersection of two or more joining tasks.  

Statistics defines the intersection of independent events by the product of their probabilities.  There is no general formulation for the statistics of an intersection unless the events are independent.  If they are not, then the only practical way to determine the performance of the intersection—in our case, the milestone—is to simulate the project by running many trials.  Simulation for this purpose is the subject of another presentation.  

In similar fashion, we can multiply out all the other cases of one late/early and the other either late/early or on time.  For two joining paths, there is one success case—both on time—and three failure cases—one or the other or both are late.  The sum of the success case and all of the failure cases must account for all the possibilities—100%.  If the sum of all cases is not 100%—either more or less than—then the analyst has made some error in accounting for the possibilities.

For the project manager, the quick take away is that by glancing at the schedule and picking out milestones defined by joining paths, the weak points of the schedule are immediately seen.  At every such milestone, there is a bias towards shifting to the right—an obvious hazard to on time performance

Take a look at this slideshare presentation for more information

Are you on LinkedIn?

Share this article with your network by clicking on the link.

Ideas for Managing at the Milestone

View more presentations from John Goodpasture.