Try something!

Quote from the noteworthy:

"It is common sense to take a method and try it. If it fails, admit frankly and try another. But above all, try something." FDR

Franklin Roosevelt was famous for his tolerance for ambiguity. In the scope of leadership styles, on many difficult and uncertain occasions, he was the supreme delegator.

Among those that practice this style with aplomb, and Roosevelt was certainly one, a good deal of trust flows down, ceremony is minimum, and for the one who is the "paper at the bottom of the birdcage", there is no help coming from above!

And, expect not only ambiguity, but also competition. It's common for delegating leaders to empower more than one and let the best rise to the top!

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.

Project CEO's of something

Ever thought about being a CEO of something on your project?  That's the question and the theme of an interesting interview with entrepreneur Mark Pincus  in the "Corner Office" [The New York Times, Sunday January 31, 2010]

Actually, Pincus is describing how he solved another problem: scaling personnel management beyond what he considers practical for the personal touch: about 50 people.

His solution is low tech, but it's easy to see how it could work: Give everybody a sticky note and a white board and ask them to write down what they want to be CEO of--something for which they will take personal responsibility, for which they will be the playmaker and make it happen!

Everyone that has managed more than a small team can remember the first time their management role took them out of close physical proximity to the team--a move into an office, a move to another building or floor, or venue. Good grief! How do I manage if I can't observe what's going on?

Making a team of little CEO's may be the answer!

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.

Of Maps and Compass

A recent  piece by Piers Brendon* caught my eye as I was preparing a recent presentation on value earning:

"...the past is a map, not a compass. It charts human experience [read: project team], stops at the present, and gives no clear sense of direction"

One might argue a bit with the last point, but the first is clear enough: beware extrapolations of history based on trends developed from linear equations of past performance that purport to represent an accurate forecast of the uncertainties of the future.

The project manager's mission is clear: "Defeat the unfavorable forecast with assertive action to deliver the best value to the customer, taking measured risks to do so"


Bendon goes on: .."History does not repeat itself, nor does it proceed in rhythms or cycles [read: agilists beware!]. Events buck trends [read: have a decision protocol at the ready to deal with the uncertain]. Everything is subject to the 'viccistudes of fortune"

I don't get to use 'viccissitudes' that often, so I thought I would through that in!

*Noted author of "The Decline and Fall of the British Empire"

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

Bookmark this on Delicious

Todd's Tech Bite - 4 - Small Teams

My fourth interview with Todd Ruopp was published on slideshare.net.

In this tech bite, the subject is small teams, typically 6-12 people, co-located to the extent possible.

The point made in the interview is that trust is the number one ingredient to making a team work. Everyone comes into a team situation with some degree of trustfulness, what Covey calls the initial deposit, but personal performance on behalf of the team is needed to seal the deal!

Todd's Tech Bite #4 Small Teams

View more presentations from John Goodpasture.

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

Bookmark this on Delicious

Random Numbers on the WBS? OMG!!

Yikes! who said random numbers belong on the WBS? Well, actually everyone who knows a lot about this business, and for that matter, a bunch of others who usually weigh in, say that single-point estimates are a poor choice, indeed in most situations they're a bad choice.

What's better? 'They' say: A three-point estimate--most optimistic, most pessimistic, and single trial most likely--is much 'better' for forming estimates and thereby budgets.

And, 'they' are right! Why so, why 'better'? A lot of reasons, but an obvious one is that there is simply more information, and so more information usually means a better outcome.

But, alas, a three point estimate is really three random numbers. A random number is really a number pair: < event value, event probability >, so what do you do when your work package managers hand you a bunch of charts that plot these number pairs on orthogonal axis', or just as bad, hand you a bunch of bivariate estimates?

You can't pass along a bunch of charts to your sponsor. You can't arithmetically add the number pairs--you can only convolve them. Egads! Convolution does not sound like program management--do we need a system engineer here?

You could outsource the whole thing to your project analysts and have them run a Monte Carlo simulation which does the convolution for you. However, that may be expensive and not timely, and certainly does not work off the back of an envelope.

The thing to do is what John Schyuler recommends in his excellent text on decision analysis, entitled "Risk and Decision Analysis in Projects", to wit: convert those three pesky random number estimates to a risk weighted average for each work package and then add them up!

That means doing the simple arithmetic to multiply the value times the value probability for each random number; then add all three for a risk weighted average.

There is actually rigorous proof for this idea that you can find in most applied handbooks on statistics, but it works well enough for project management without looking into the proof.

In the approximate world of ONE-SIGMA project management, 'risk weighted average' is what passes for expected value, the most powerful idea in statistics for the average project manager.

Of course, you may get asked about your confidence in the WBS budget as a weighted average. That takes a little more arithmetic, but that's all it is. However, that calculation is for another time.

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

Bookmark this on Delicious